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

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

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