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

["Parthasarathi R (partr)" <[e-mail]>]

John/Hadriel,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Elwell, John
Sent: Wednesday, March 30, 2011 8:33 PM
To: Hadriel Kaplan; Paul Kyzivat (pkyzivat)
Cc: [e-mail]; Leon Portman
Subject: Re: [siprec] Multiplexing different participants' streams on
the same port

(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. 
<partha> IMO, This problem will be solved in case bandwidth attribute
under the single stream is populated properly. If it is the problem,
then the problem is outside the scope of SIPREC. </partha>

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...
<partha> May take time to adopt..As less RTP MUX in single stream
implementation may be one of the reason. </partha>
 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.
> 
<partha> I guess that it is possible to populate SSRC while offer is
sent out and it is implementation specific </partha>
  
> I humbly suggest that UDP port numbers are not in short supply, and 
> using one per stream is both simple and effective.
<partha> may not always the case. There are nightmare with multiple
m-lines passing through some middle boxes </partha?>
> 
> -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
> 
_______________________________________________
siprec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/siprec