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

[Paul Kyzivat <[e-mail]>]

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
>>>
>