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

["Charles Eckel (eckelcu)" <[e-mail]>]

Typically they appear in RTCP only, and not in SIP or SDP. 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
> >>>
> >