Re: [siprec] Review Request for draft-ram-siprec-metadata-format-01

[Paul Kyzivat <[e-mail]>]

ISTM the issue with a mixed stream with separate SSRC values is 
correlating the SSRC values to the signaling identities (URIs) of the 
participants. AFAIK there are currently no specifications for doing that.

	Thanks,
	Paul

On 3/18/2011 2:55 AM, Parthasarathi R (partr) wrote:
> Charles,
>
> Please read inline
>
> Thanks
> Partha
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Charles Eckel (eckelcu)
> Sent: Friday, March 18, 2011 2:01 AM
> To: Elwell, John; Paul Kyzivat (pkyzivat)
> Cc: [e-mail]
> Subject: Re: [siprec] Review Request for
> draft-ram-siprec-metadata-format-01
>
> Please see single comment inline.
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Elwell, John
>> Sent: Tuesday, March 15, 2011 6:56 AM
>> To: Paul Kyzivat (pkyzivat)
>> Cc: [e-mail]
>> Subject: Re: [siprec] Review Request for
> draft-ram-siprec-metadata-format-01
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[e-mail]]
>>> Sent: 15 March 2011 13:03
>>> To: Elwell, John
>>> Cc: [e-mail]
>>> Subject: Re: [siprec] Review Request for
>>> draft-ram-siprec-metadata-format-01
>>>
>>> On 3/15/2011 7:22 AM, Elwell, John wrote:
>>>
>>>>>> 2. We perhaps need to think about mixed RS media streams,
>>>>> i.e., where several CS media streams have been mixed to produce a
>
>>>>> single RS media stream. In this case, the several Media Stream
>>>>> objects would all point to the same SDP label, I guess. This then
>
>>>>> brings into question the mode element (type
>>>>> streamMode) - why is this needed? The fact that several Media
>>>>> Stream objects (stream elements) point to the same label would
>>>>> imply there has been mixing, so the mode element seems to be
>>>>> redundant.
>>>>>
>>>>> My thinking is that situation is modeled as a single media stream
>
>>>>> with multiple participants.
>>>> [JRE] I was confused by section 4.5 of the metadata model
>>> draft. It does indeed seem to say that it represents an RS media
>>> stream:
>>>> "A Media Stream block shall have properties of media as
>>> seen by SRC and sent to SRS."
>>>> And hence your interpretation above would seem reasonable.
>>> On the other hand, in 4.5.2 it says:
>>>> "A Media Stream SHALL be associated with Participant and CS."
>>>> This misled me. Also in 4.5.1:
>>>> "Codec params - represents codec parameters of the CS media"
>>>> This also seemed to imply the Media Stream object relates
>>> to a CS media stream.
>>>> Perhaps some clarification is needed in the Metadata draft.
>>>> Anyway, assuming we go with your interpretation, I suppose
>>> what we end up with is that if streams are mixed (whether this be at
>
>>> an MCU, say, or just part of the SRC in order to send the streams to
>
>>> the SRS), the net result will be modelling as a single stream in the
>
>>> metadata. Is this a common understanding?
>>>
>>> You may have a point here - that things are somewhat ambiguous.
>>>
>>> If we have two distinct media streams in the CS, and they are mixed
>>> together by the SRC before sending to the SRS, then they could be
>>> treated different ways:
>>>
>>> - The SRC could report this as a single media stream with multiple
>>> participants. But then it would have to report its metadata as if it
>
>>> were a single stream from a mixer.
>>>
>>> - The SRC could report it as multiple media streams from a metadata
>>> perspective, but map them all onto the same RS media stream.
>>> (This is a
>>> possibility I had never considered/recognized.)
>>>
>>> Is there a desire to support both? If so, the metamodel and
> mechanism
>>> will probably need some tweaking.
>> [JRE] Consider:
>> "REQ-009: The mechanism MUST support the ability for an SRC to
>>     deliver mixed audio streams from different parties of a given
>>     Communication Session to an SRS."
>> One particular case I believe this covers is the simple 2-party call,
> where there are two media
>> streams, one from A to B and the other from B to A. The SRC could mix
> the two together into a single
>> stream to the SRS. Certainly useful for bandwidth constrained
> environments, but not so friendly
>> towards speech analytics.
>>
>> John (as individual)
>
> Once the stream is mixed meaning all packets have the same SSRC and
> CSRC, I think there is no point in trying to represent it as anything
> other than a single stream.
> <Partha>  I'm of the same opinion</Partha>
>
> If the metadata can indicate all the individual participants in the
> mixed stream, that would be great, but I doubt you will get this in all
> cases.
> <Partha>  agreed</Partha>
>
> If it is a single RTP stream with multiple identifiable media streams
> muxed together, then it would be good to model as independent streams.
> In this case the different streams could be uniquely identified by a
> SSRC or CSRC.
>
> <Partha>  I wish to get more clarity for this scenario. In the mentioned
> scenario, whether RFC 5576 ssrc attribute or some other attribute is
> used in CS SDP to indicate RTP muxing in m-line. If so, the same
> attribute shall be extended for RS session as well. There is no need to
> push the information to metadata XML. In case there is no indication of
> multiple stream in CS, it is possible that SRC may not able to indicate
> explicitly in RS signaling but RTP muxed passed to SRS with different
> SSRC or CSRC.</Partha>
>
>
> Cheers,
> Charles
>
>>
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>> _______________________________________________
>> siprec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/siprec
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec
>