Re: [siprec] Multiplexing different participants' streams on the same port

[Hadriel Kaplan <[e-mail]>]

In practice we see all kinds of things in the RTCP cname, often unrelated to signaling info.
But you can't rely on it anyway, since you can't rely on there being any RTCP.

Furthermore, although I've (shockingly) seen some devices indicate SSRC in SDP per RFC 5576, it's rare... which means you won't know the SSRC at call setup time, so it won't be available to send in metadata at that time, requiring an update.

I humbly suggest that UDP port numbers are not in short supply, and using one per stream is both simple and effective.

-hadriel


On Mar 29, 2011, at 6:13 PM, Paul Kyzivat wrote:

> On 3/29/2011 6:05 PM, Charles Eckel (eckelcu) wrote:
>> Typically they appear in RTCP only, and not in SIP or SDP.
> 
> I understand that.
> 
> I'm just wondering what is done by typical sip devices that handle both
> media and signaling - e.g. phones and gateways. Presumably *something*
> is put in for the cname. But I suspect that layering will result in the
> media layer doing its own thing without knowledge of what sort of names
> are being used in the signaling layer.
> 
> If so, just reporting the cname in the metadata might not provide any
> benefit if it can't be correlated with some signaling name.
> 
>        Thanks,
>        Paul
> 
>  The RTCP
>> identify the mapping of CNAME to SSRC. In the SDP, you can specify the
>> SSRC for a media stream as described in RFC 5576 - Source-Specific Media
>> Attributes in the Session Description Protocol (SDP). I am not sure if
>> there are many existing implementations that do this.
>> 
>> Cheers,
>> Charles
>> 
>>> -----Original Message-----
>>> From: Paul Kyzivat (pkyzivat)
>>> Sent: Tuesday, March 29, 2011 11:41 PM
>>> To: Charles Eckel (eckelcu)
>>> Cc: Leon Portman; Parthasarathi R (partr); [e-mail]
>>> Subject: Re: [siprec] Multiplexing different participants' streams on
>> the same port
>>> 
>>> Charles,
>>> 
>>> *In practice* how are cnames set for sip calls?
>>> I'm assuming they are something canned and unrelated to the signaling
>>> identity.
>>> 
>>>     Thanks,
>>>     Paul
>>> 
>>> On 3/29/2011 10:20 AM, Charles Eckel (eckelcu) wrote:
>>>> For the format and value of the CNAME, I suggest having a look at
>>>> "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names
>>>> (CNAMEs)", draft-ietf-avt-rtp-cnames-05.
>>>> If the SIP AOR is meant to be the AOR registered by the participant,
>>>> this is almost certainly going to be something different.
>>>> The participant AOR is per participant. The CNAME is per media
>> stream.
>>>> 
>>>> Cheers,
>>>> Charles
>>>> 
>>>>> -----Original Message-----
>>>>> From: Paul Kyzivat (pkyzivat)
>>>>> Sent: Tuesday, March 29, 2011 2:23 PM
>>>>> To: Leon Portman
>>>>> Cc: Parthasarathi R (partr); Charles Eckel (eckelcu);
>> [e-mail]
>>>>> Subject: Re: [siprec] Multiplexing different participants' streams
>> on
>>>> the same port
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/29/2011 7:21 AM, Leon Portman wrote:
>>>>>> I like it.
>>>>>> 
>>>>>> Quick question. In metadata we are using "<aor>" attribute but in
>>>> SDP, it is "CNAME"? Can we use the
>>>>> same?
>>>>> 
>>>>> Charles knows more than I about RTP. AFAIK CNAME is an essentially
>>>>> arbitrary string that is assigned by the media source. (Are their
>>>>> constraints on its length or format?) Perhaps it could be formatted
>> as
>>>> a
>>>>> sip AOR, perhaps not. Even if it *could*, in practice *will* it be?
>>>> ISTM
>>>>> it would not be wise to count on these being the same.
>>>>> 
>>>>> We should probably allow participants to specify their cname as
>> well
>>>> as
>>>>> their AOR. This may get complicated if the same participant ends up
>>>> with
>>>>> differing media streams it sends.
>>>>> 
>>>>> I also wonder if the SRC will always know the CNAMEs of the
>> streams. I
>>>>> suspect we can't count on that.
>>>>> 
>>>>>   Thanks,
>>>>>   Paul
>>>>> 
>>>>>> Leon
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Parthasarathi R (partr)
>>>>>> Sent: Monday, March 28, 2011 10:42 AM
>>>>>> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat);
>>>> [e-mail]
>>>>>> Subject: Re: [siprec] Multiplexing different participants' streams
>>>> on the same port
>>>>>> 
>>>>>> Charles,
>>>>>> 
>>>>>> IMO, the current metadata model helps to address RTP MUX streams
>> as
>>>> well. In terms of model,
>>>>> multiple participants (P1, P2, P3) metadata block points to the
>> single
>>>> stream (S1) and stream block
>>>>> contains SSRC&    CSRC information. IOW, SIPREC model abstract RTP
>> MUX
>>>> stream within media stream block.
>>>>> Please let me know in case you feel that model does not address it.
>>>>>> 
>>>>>> In case of metadata format, multiple "participant" elements have
>>>> send element with single stream
>>>>> element. The stream element has a label attribute which points to
>> the
>>>> m-line which contains "ssrc"
>>>>> attribute with CNAME parameter. I attached the example for your
>>>> reference and The example is the one
>>>>> of the way to represent RTP-MUX stream in the metadata format.
>> Please
>>>> let me know the issues with this
>>>>> format and example.
>>>>>> 
>>>>>> I agree with Paul and you that we need to understand how RTP mux
>>>> stream will be standardized but
>>>>> IMO, it is not the limiting factor for SIPREC as of now.
>>>>>> 
>>>>>> Thanks
>>>>>> Partha
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Charles Eckel (eckelcu)
>>>>>> Sent: Friday, March 18, 2011 8:40 PM
>>>>>> To: Paul Kyzivat (pkyzivat); [e-mail]
>>>>>> Subject: Re: [siprec] Multiplexing different participants' streams
>>>> on thesame port
>>>>>> 
>>>>>> I agree with the comment regarding CLUE, so let me take a simpler
>>>> example, and audio mixer. This
>>>>> mixer may mix the audio from multiple participants.
>>>>>> 
>>>>>> Participant 1 (P1)
>>>>>> Participant 2 (P2)
>>>>>> Participant 3 (P3)
>>>>>> 
>>>>>> P1 sends audio stream with SSRC-P1
>>>>>> P2 sends audio stream with SSCR-P2
>>>>>> P2 sends audio stream with SSCR-P3
>>>>>> 
>>>>>> MixerA(Ma)
>>>>>> 
>>>>>> Ma sends mixed audio stream with SSRC SSRC-Ma and CSRC
>>>>>> SSRC-P1/SSRC-P2/SSRC-P3 as part of the CS.
>>>>>> The SRC sends this stream to the SRS for recording. I suspect it
>>>> might change the SSRC to be SSRC-
>>>>> SRC but maintain the CSRC information identifying P1/P2/P3.
>>>>>> I expect this would be modeled as a single stream with 3
>>>> participants P1, P2, P3. The mapping of P1
>>>>> to SSRC-P1 is captured in the RTCP data sent by SRC to SRS. In this
>>>> case, there is no need to anything
>>>>> in the metadata.
>>>>>> However, if the CSRCs are not propagated all the way to the SRS,
>>>> then perhaps participant info would
>>>>> need to be communicated via the metadata.
>>>>>> 
>>>>>> Note, I do not pretend to have this all figured out; rather, I am
>>>> putting out some ideas to see if
>>>>> this gels with what others have in mind.
>>>>>> 
>>>>>> Cheers,
>>>>>> Charles
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>>> Behalf Of Paul Kyzivat (pkyzivat)
>>>>>>> Sent: Friday, March 18, 2011 5:38 AM
>>>>>>> To: [e-mail]
>>>>>>> Subject: Re: [siprec] Multiplexing different participants'
>> streams
>>>> on
>>>>>> the same port
>>>>>>> 
>>>>>>> I don't know if this is a good idea or not. But if we want to
>>>> consider
>>>>>> 
>>>>>>> it, then we should probably enter into some discussion with CLUE,
>>>> to
>>>>>> see
>>>>>>> if there is any commonality.
>>>>>>> 
>>>>>>> Over in CLUE, this mixing of multiple streams over one RTP
>> session
>>>> has
>>>>>> 
>>>>>>> been brought up because it is a technique used in existing
>>>> proprietary
>>>>>> 
>>>>>>> products. But the CLUE wg isn't yet to a point where it is ready
>> to
>>>>>>> decide if this will be a requirement. And the AVT people have
>>>> strong
>>>>>>> opinions on what is/isn't appropriate.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Paul
>>>>>>> 
>>>>>>> On 3/18/2011 4:11 AM, Elwell, John wrote:
>>>>>>>> Something Charles mentioned in another thread triggered me to
>>>> raise
>>>>>> this.
>>>>>>>> 
>>>>>>>> We consider different participants in the CS as potentially
>>>>>> producing separate media streams that
>>>>>>> the SRC sends to the SRS, where the SRC can send them mixed or
>>>>>> unmixed.
>>>>>>>> 
>>>>>>>> When sending them unmixed, up till now I think we have
>> considered
>>>>>> sending them to separate ports on
>>>>>>> the SRS and identifying them as separate m= lines in the SDP.
>>>> Another
>>>>>> possibility might be to
>>>>>>> multiplex the different streams on the same port and identify
>> them
>>>> by
>>>>>> different SSRC values. I am not
>>>>>>> sure whether this would be a correct use of SSRC, and I suspect
>> we
>>>>>> would need to check with AVTCORE.
>>>>>>> Recent discussions in other contexts (telepresence, RTC-Web) have
>>>> also
>>>>>> drawn my attention to such
>>>>>>> possibilities. See also
>>>>>> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/.
>>>>>>>> 
>>>>>>>> Of course, it would mean that we would have to rethink how we
>>>>>> reference the different streams from
>>>>>>> metadata.
>>>>>>>> 
>>>>>>>> I am not necessarily proposing such a change - I just want to
>> make
>>>>>> sure we have given it due
>>>>>>> consideration.
>>>>>>>> 
>>>>>>>> John (as individual)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> siprec mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> siprec mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>> _______________________________________________
>>>>>> siprec mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>>>> 
>>>> 
>> 
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec