Re: [MMUSIC] DECISION: Unique PT value/codec configuration mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June 19th)]

["Hutton, Andrew" <[e-mail]>]

+1

Andy

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Emil Ivov
> Sent: 24 June 2013 18:11
> To: Mary Barnes
> Cc: [e-mail]; Paul Kyzivat; Christer Holmberg
> Subject: Re: [MMUSIC] DECISION: Unique PT value/codec configuration
> mapping in a BUNDLE group [WAS: BUNDLE TEXT: De-mux procedures (June
> 19th)]
> 
> +1
> 
> Emil
> 
> On Mon, Jun 24, 2013 at 7:10 PM, Mary Barnes
> <[e-mail]> wrote:
> > I too agree with Q1 and Q2.
> >
> > Mary.
> >
> > On Mon, Jun 24, 2013 at 5:40 AM, Christer Holmberg
> > <[e-mail]> wrote:
> >>
> >> Hi,
> >>
> >> Based on the input and discussion, let's see if we can make a couple
> of decisions :)
> >>
> >>
> >> Q1: Can we agree that, within a BUNDLE group (including all m- lines
> associated with the group), any given PT value can only be used for a
> single codec configuration?
> >>
> >> NOTE: If you think we need some clarification text on what "codec
> configuration" means, or if you think we should use some other wording
> - feel free to suggest :)
> >>
> >>
> >>
> >> Q2: If we agree on Q1, do we agree that we need EXPLICIT text in
> BUNDLE, as there are opinions that simply referencing RFC 3550 might
> not be clear enough?
> >>
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Paul Kyzivat
> >> Sent: 20. kesäkuuta 2013 17:33
> >> To: [e-mail]
> >> Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
> >>
> >> On 6/20/13 8:37 AM, Colin Perkins wrote:
> >>> On 20 Jun 2013, at 05:53, Christer Holmberg wrote:
> >>>>>> Using 96 for both Opus and VP8 is flat out illegal according to
> the RTP specs.
> >>>>>
> >>>>> Agree.
> >>>>
> >>>> So, we DO agree that the usage of the *same* PT value (even if in
> different m= lines) for different codecs, or different codec
> configurations, is not allowed.
> >>>>
> >>>> Is there some specific section in some specific RFC that can be
> referenced to show that?
> >>>
> >>> RFC 3550 Sections 1, 5.1, 12, and 13 make it clear that the mapping
> is defined per RTP profile (i.e., for RTP/AVP and profiles derived from
> it). The BUNDLE defines a single RTP session, which operates under a
> single RTP profile, so must have a single mapping from Payload Type to
> Payload Formats. RFC 3551 section 3 says:
> >>>
> >>>     ...
> >>>     mechanisms for defining dynamic payload type bindings have been
> >>>     specified in the Session Description Protocol (SDP) and in
> other
> >>>     protocols such as ITU-T Recommendation H.323/H.245.  These
> mechanisms
> >>>     associate the registered name of the encoding/payload format,
> along
> >>>     with any additional required parameters, such as the RTP
> timestamp
> >>>     clock rate and number of channels, with a payload type number.
> This
> >>>     association is effective only for the duration of the RTP
> session in
> >>>     which the dynamic payload type binding is made.  This
> association
> >>>     applies only to the RTP session for which it is made, thus the
> >>>     numbers can be re-used for different encodings in different
> sessions
> >>>     so the number space limitation is avoided.
> >>>
> >>> You'll note that the association is per RTP session, not per SSRC
> or other subset of the session.
> >>
> >> I'm not inclined to argue the details of RTP with an RTP expert!
> >> But just wearing my standards-lawyer hat I read all of the above
> references, and could not find anything that clearly justified the
> assertions you make. I read them as clearly stating that the *static*
> ones are defined for a profile. I guess the key part of the quote above
> >> is: "This association is effective only for the duration of the RTP
> session". That seems to *bound* the scope of the association, but
> doesn't explicitly state that it must be unique within that scope.
> >>
> >> But maybe that is just a matter of me not reading it right, or of
> the text not having captured every nuance of the intent.
> >>
> >>> If you're looking for a statement that two m= lines in an SDP can't
> map the same PT value to different things, you're unlikely to find it,
> since pre-BUNDLE those two m= lines would refer to different RTP
> sessions, so it would be legal to reuse PT values across m= lines. It's
> because BUNDLE makes a single RTP session out of several m= lines that
> you need unique PT mapping across all the m= lines.
> >>
> >> Of course. So I think that means its important for bundle to clearly
> state the requirement, if it is to be a real one.
> >>
> >>         Thanks,
> >>         Paul
> >>
> >>> Colin
> >>>
> >>>
> >>>>>> The corner case where we're discussing whether one can use the
> same
> >>>>>> payload type is if you have two M-lines that both specify VP8,
> with the same codec parameters - whether they can both use 96, given
> that it's the same codec.
> >>>>>
> >>>>> Surely yes, but you lose the ability to distinguish the m= line
> >>>>> based on the PT if you use the same PT (mapped to the exact same
> >>>>> codec and set of codec parameters) in several m= lines. Some
> applications care about distinguishing m= lines based on PT values, and
> so need distinct PT values for every m= line; others don't care, and
> can use the same PT to represent the same codec across multiple m=
> lines.
> >>>>
> >>>> Exactly. So, I think it's a good idea to have some text about that
> in BUNDLE.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >> _______________________________________________
> >> mmusic mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mmusic
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> 
> 
> 
> --
> Emil Ivov, Ph.D.                       67000 Strasbourg,
> Project Lead                           France
> Jitsi
> [e-mail]                        PHONE: [phone]
> https://jitsi.org                       FAX:   [phone]
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic