Re: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)]

[Suhas Nandakumar <[e-mail]>]

+1 on  we need to add the analysis for dealing with this issue.  I had
raised similar issue as applied to Mux attributes draft here:

http://www.ietf.org/mail-archive/web/mmusic/current/msg12572.html

I was wondering, given the above "Codec Configuration" definition, do we
have enough information to suggest on the category assignment for PT scoped
attributes from RFCs like RFC4585 (a=rtcpfb:PT),  RFC5583(a=depend:PT)


Thanks
Suhas


On Wed, Oct 30, 2013 at 8:03 AM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> >>> This works as an outline, but I'm afraid it'll be too vague for solid
> interoperability.
> >>
> >> At the end of the day, it is the receiver that informs the remote party
> which PT values it wants to receive, so if it chooses the same PT values it
> has to know that it is able to handle it.
> >>
> >> We COULD go even more into detail, but then I'm afraid we would have to
> start defining codec specific criteria etc, and I don't think we should go
> that way.
> >
> > I don't want codec-specific criteria -- but I do want to know, e.g.,
> whether PT-specific a=rtcp-fb: attributes MUST be aligned across bundled
> m-lines, or if they're free to vary, or what.
> >
> > There are a bunch of SDP attributes that have PT-scoped properties.  I
> think this analysis needs to be added to the mux-attributes draft.
>
> I am not so worried about where we'll document it - first I want us to
> agree on some criteria :)
>
> I DO agree, though, that we probably need to go through the PT-scoped
> attributes.
>
> Regards,
>
> Christer
>
>
>
> > I think it works as a set of principles to guide discussion of
> PT-specific definitions in the mux-attributes draft, though.
> >
> > On Oct 27, 2013, at 5:03 PM, Christer Holmberg
> > <[e-mail]>
> > wrote:
> >
> >> This time in non-HTML format.
> >>
> >> Lähettäjä: Christer Holmberg
> >> Lähetetty: 27. lokakuuta 2013 23:03
> >> Vastaanottaja: Christer Holmberg; Bo Burman; Jonathan Lennox
> >> Kopio: mmusic
> >> Aihe: VS: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value
> >> re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for
> >> single codec configuration)]
> >>
> >> Hi,
> >>
> >> It would be really great if those who have an opinion on this would
> >> indicate whether they are ok with the approach below. Then we can
> >> focus on where to document it :)
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >> Lähettäjä: [e-mail] [mailto:[e-mail]]
> >> Puolesta Christer Holmberg
> >> Lähetetty: 23. lokakuuta 2013 13:37
> >> Vastaanottaja: Bo Burman; Jonathan Lennox
> >> Kopio: mmusic
> >> Aihe: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value
> >> re-usage
> >> [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec
> >> configuration)]
> >>
> >> Hi,
> >>
> >> Below is a copy of the current text in my Vancouver slide regarding the
> criteria for PT value re-usage in multiple m- lines within a BUNDLE group.
> >>
> >> It is based on the ideas provided by Jonathan L and Bo B.
> >>
> >> As you can see, apart from the rtpmap and fmtp attributes, it is not
> possible to define an exclusive list of attributes that must be identical.
> Such lists may also be codec dependent. Instead, the text talks more
> generally about memory and buffer sizes.
> >>
> >>
> >>> REQUIREMENTS
> >> - Decoder agnostic
> >>> It shall be possible to switch decoders between media flows using
> >>> the same PT value
> >> - Codec agnostic
> >>> The criteria shall be applicable to any codec CRITERIA
> >> - SDP rtpmap and fmtp attribute values must be equal (order of
> >> attribute parameters not significant)
> >>> All parameters must be included
> >> - Explictily
> >> - Implicitly, if a default value is defined for the parameter
> >>> Parameters not included are assigned their default values (if
> >>> defined)
> >> - Decoder maximum memory and buffer sizes shall be assumed to match
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Christer Holmberg
> >> Sent: 16. lokakuuta 2013 12:12
> >> To: Bo Burman; Jonathan Lennox
> >> Cc: mmusic
> >> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific
> >> PT value for single codec configuration
> >>
> >> Hi Bo,
> >>
> >> Thanks for your input!
> >>
> >> I'd ask anyone who might have an opinion about this to take a look at
> >> the proposal, comment on the list if needed, and hopefully we can
> >> agree on way forward in Vancouver (or, even earlier :)
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >> From: Bo Burman
> >> Sent: 16. lokakuuta 2013 11:44
> >> To: Christer Holmberg; Jonathan Lennox
> >> Cc: mmusic
> >> Subject: RE: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific
> >> PT value for single codec configuration
> >>
> >> Hi,
> >>
> >> I agree with Jonathan that in order to make two PT values "equal",
> their rtpmap and fmtp lines must be equal, as a start.
> >>
> >> I don't think there is any "correct" criterion that can be used to
> judge PT for equality, but we just have to decide on a "reasonable" one
> that is as simple as possible without causing any major problems.
> >>
> >> I have assumed a conceptual equality criterion where PT value A should
> be considered equal to another PT value B if an RTP stream with PT A can be
> fed into a decoder stack configured with PT B, and vice versa, without
> causing either decoder stack to "break".
> >>
> >> I don't think we should require the fmtp lines are textually equal, but
> only that the same parameters are present and have the same values. The
> order of the parameters on the fmtp line does not matter. There is also the
> case when a parameter is specified with the default value for one PT and
> omitted for the other. To identify those as equal, which they semantically
> are, would require an "equality parser" to know every default value of
> every fmtp parameter for all codecs. This seems unreasonable.
> >>
> >> Regarding Jonathan's question on H.264 sprop-., I guess they don't
> strictly need to be equal to make the PTs equal, but they may have to be.
> They effectively configure the decoder in some way and if there is a
> mismatch, the decoding process will likely break; like mis-interpretations
> or buffer overflows. On the other hand, some sprop-. can be updated by
> in-band information, overriding what is specified on the fmtp line, and in
> this case the fmtp line sprop-. information is obsolete. Requiring that all
> fmtp of the line is equal however makes a simple rule, which should be
> preferable and I don't think it is too restrictive or excessive.
> >>
> >> However, if the potentially equal PT values are defined as part of
> different media descriptions, other media level attributes also contribute
> to the decoder stack configuration. Some attributes, like maxptime, can
> clearly cause problems (in this case buffer overflow) if it differs.
> Others, like ptime, framerate and imageattr are more of a receiver
> preference within a more formal "conformance point" and would not "break" a
> decoder stack if they differ.
> >>
> >> I agree it can be a good idea to add some text into the mux-attributes
> draft about attributes that have to be the same to consider two PT in
> different media descriptions to be "equal", of course given that rtpmap and
> fmtp are also equal.
> >>
> >> /Bo
> >>
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Christer Holmberg
> >> Sent: den 11 september 2013 09:12
> >> To: Jonathan Lennox
> >> Cc: mmusic
> >> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific
> >> PT value for single codec configuration
> >>
> >> Hi,
> >>
> >> It would be so easy if we could define the PT mappings on the SDP
> >> session level, and then simply refer to them within the m- lines :)
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >> From: Jonathan Lennox [mailto:[e-mail]]
> >> Sent: 10. syyskuuta 2013 22:18
> >> To: Christer Holmberg
> >> Cc: mmusic
> >> Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific
> >> PT value for single codec configuration
> >>
> >> My strawman proposal at the mic in Berlin was that a codec
> configuration is defined by the top-level media type of the m= line and the
> content of a given PT value's rtpmap and fmtp lines.  I.e., the full media
> type, with all its parameters.
> >>
> >> The questions I would have to this straw man are:
> >>
> >> * Is this excessive?  E.g., should items like H.264's sprop- parameters
> be allowed to differ across m= line blocks?
> >>
> >> * Is this sufficient?  Should other items (sometimes) indexed by PT
> (e.g., the imageattr, rtcp-fb, or extmap attributes) need to be the same
> across m-lines as well?
> >>
> >> My suggestion would be that this work should be folded into the work
> being done in draft-nandakumar-mmusic-sdp-mux-attributes (which really
> should be integrated with BUNDLE).  Currently (I believe) the
> mux-attributes draft assumes that PTs are unique across m-lines, so this
> work is going to imply changes to the analysis of a number of attributes in
> that draft, regardless.  Probably a new category will need to be defined
> for attributes which have to be consistent per payload type.
> >>
> >> On Sep 10, 2013, at 5:56 AM, Christer Holmberg <
> [e-mail]> wrote:
> >>
> >>
> >> Hi,
> >>
> >> Below is the "official" (from the minutes) outcome of questions Q1,Q2
> and Q7 in Berlin.
> >>
> >> Questions:
> >>
> >> 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?"
> >> Q2: "If Q1, do we agree that we need EXPLICIT text somewhere*, as there
> are opinions that simply referencing RFC 3550 might not be clear enough?"
> >> Q7: "Within a BUNDLE group, do we allow the usage of the same PT value
> in multiple RTP m- lines, for the SAME codec configuration?"
> >>
> >> Outcome:
> >>
> >> Q1: Yes
> >> Q2: Yes, Lennox will send suggested text to clarify the term "codec
> configuration".
> >> Q7: Yes.
> >>
> >> So, again, we need definition text for "codec configuration". Jonathan
> promised to submit something, but anyone is of course welcome to do that.
> >>
> >> The other alternative is to not say anything about PT value usages
> within the scope of BUNDLE, but that is not what the meeting wanted.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Christer Holmberg
> >> Sent: 23. elokuuta 2013 13:53
> >> To: mmusic
> >> Subject: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT
> >> value for single codec configuration
> >>
> >> Hi,
> >>
> >> One of the open issues related to BUNDLE presented in Berlin (Q1, Q2
> and Q7 in my slides) was regarding the usage of any given PT value.
> >>
> >> My take of the outcome was that:
> >>
> >> -          We agreed that any given PT value can only be used for a
> single codec configuration (Q1)
> >> -          We agreed that we need some definition text for "codec
> configuration" (Q2)
> >> -          We agreed that, within a BUNDLE group, any given PT value
> can be used in multiple m- lines, as long as it is used for a single codec
> configuration (Q7).
> >>
> >> Jonathan Lennox promised to suggest some definition text for "codec
> configuration", so let's wait for that until we go into those discussions.
> >>
> >> But, if you have any issues with the agreements in general, please
> >> bring them up :)
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >> --
> >> Jonathan Lennox
> >> [e-mail]
> >>
> >
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>