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

["Elwell, John" <[e-mail]>]

(this time as individual)

It occurs to me that if you just indicate, say, audio in the m-line and a given codec, middleboxes doing call admission control might make some assumptions about bandwidth and assume just a single stream at the rate concerned. Putting several such streams over the same path, from different participants, might cause problems. Any opinions?

John 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Hadriel Kaplan
> Sent: 30 March 2011 13:58
> To: Paul Kyzivat
> Cc: [e-mail]; Leon Portman
> Subject: Re: [siprec] Multiplexing different participants' 
> streams on the same port
> 
> 
> 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
> 
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec
>