Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F80211E836A for ; Wed, 23 Oct 2013 03:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.819 X-Spam-Level: X-Spam-Status: No, score=-3.819 tagged_above=-999 required=5 tests=[AWL=-1.221, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWA4U6sMvyYl for ; Wed, 23 Oct 2013 03:36:50 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id CEC7111E835A for ; Wed, 23 Oct 2013 03:36:47 -0700 (PDT) X-AuditID: c1b4fb38-b7f178e00000233b-3b-5267a6bebf29 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1B.69.09019.EB6A7625; Wed, 23 Oct 2013 12:36:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 12:36:46 +0200 From: Christer Holmberg To: Bo Burman , Jonathan Lennox Thread-Topic: DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)] Thread-Index: Ac7P2vGs9p8QnbkDQqupWHlVcDQlnw== Date: Wed, 23 Oct 2013 10:36:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EDA3D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4EDA3DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje6+ZelBBvdmmVjsX3ye2WLq8scs DkweS5b8ZPJoe3aHPYApissmJTUnsyy1SN8ugSvjyJcu5oKeJcwVd683sTQwfv7O1MXIySEh YCKxYV4rG4QtJnHh3nowW0jgKKPEqhcCEPYSRomjJ5m7GDk42AQsJLr/aYOYIgI+Egf3pYFU MAvISMw42wg2UVhgJqPEw29AcS6gknmMEl0bFzCCJEQE9CR6XqxhAbFZBFQlOs+vBFvFK+Ar cersUrBmRqATvp9awwQxVFzi1pP5UGcKSCzZc54ZwhaVePn4HyuErShxdfpyqPp8iY/Tr7NA zBSUODnzCcsERuFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XIUZxa nJSbbmSwiREYJQe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1KzU1MLUovii0pzUosPMTJx cEo1MJ7c5+Lm3NxTw65Vt7Jx1bLtefPm7Taa1WowcSZnMz/rhQd+T+f/KlNjnp7inch4dOIV w5tR55+5PV3UUtxzqCbb7X+X+95nkxb7NUm+i0pIE9lxnpV9v3ptg9JtZc4ZYUZeDsIsV/9n PJjZHatwdU30/mQG7nsXvq+d216hYb6hbeJ3z+8hb5VYijMSDbWYi4oTAVcS4otgAgAA X-Mailman-Approved-At: Wed, 23 Oct 2013 03:38:04 -0700 Cc: mmusic Subject: [MMUSIC] DECISION (VANCOUVER-Q9): Criteria for PT value re-usage [WAS: (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec configuration)] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 10:36:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4EDA3DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is a copy of the current text in my Vancouver slide regarding the cri= teria 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 possib= le to define an exclusive list of attributes that must be identical. Such l= ists may also be codec dependent. Instead, the text talks more generally ab= out memory and buffer sizes. > REQUIREMENTS - Decoder agnostic > It shall be possible to switch decoders between media flows using t= he 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 attribu= te 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 defin= ed) - Decoder maximum memory and buffer sizes shall be assumed to match Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 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 valu= e 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 p= roposal, comment on the list if needed, and hopefully we can agree on way f= orward 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 valu= e for single codec configuration Hi, I agree with Jonathan that in order to make two PT values "equal", their rt= pmap 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 c= onsidered 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 onl= y 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, wo= uld 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 strict= ly need to be equal to make the PTs equal, but they may have to be. They ef= fectively configure the decoder in some way and if there is a mismatch, the= decoding process will likely break; like mis-interpretations or buffer ove= rflows. On the other hand, some sprop-... can be updated by in-band informa= tion, overriding what is specified on the fmtp line, and in this case the f= mtp 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 differen= t media descriptions, other media level attributes also contribute to the d= ecoder stack configuration. Some attributes, like maxptime, can clearly cau= se problems (in this case buffer overflow) if it differs. Others, like ptim= e, framerate and imageattr are more of a receiver preference within a more = formal "conformance point" and would not "break" a decoder stack if they di= ffer. I agree it can be a good idea to add some text into the mux-attributes draf= t 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: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] 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 valu= e for single codec configuration Hi, It would be so easy if we could define the PT mappings on the SDP session l= evel, and then simply refer to them within the m- lines :) Regards, Christer From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: 10. syyskuuta 2013 22:18 To: Christer Holmberg Cc: mmusic Subject: Re: [MMUSIC] DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT valu= e 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=3D line and the content of a = given PT value's rtpmap and fmtp lines. I.e., the full media type, with al= l 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=3D 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 as= sumes that PTs are unique across m-lines, so this work is going to imply ch= anges 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 > wrote: Hi, Below is the "official" (from the minutes) outcome of questions Q1,Q2 and Q= 7 in Berlin. Questions: Q1: "Can we agree that, within a BUNDLE group (including all m- lines assoc= iated with the group), any given PT value can only be used for a single cod= ec 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 m= ultiple RTP m- lines, for the SAME codec configuration?" Outcome: Q1: Yes Q2: Yes, Lennox will send suggested text to clarify the term "codec configu= ration". Q7: Yes. So, again, we need definition text for "codec configuration". Jonathan prom= ised 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 t= he scope of BUNDLE, but that is not what the meeting wanted. Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusi= c-bounces@ietf.org] 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 fo= r 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 configura= tion" (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 config= uration (Q7). Jonathan Lennox promised to suggest some definition text for "codec configu= ration", 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 th= em up :) Regards, Christer -- Jonathan Lennox jonathan@vidyo.com --_000_7594FB04B1934943A5C02806D1A2204B1C4EDA3DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Below is a copy of the cu= rrent text in my Vancouver slide regarding the criteria for PT value re-usa= ge in multiple m- lines within a BUNDLE group.

 <= /p>

It is based on the ideas = provided by Jonathan L and Bo B.

 <= /p>

As you can see, apart fro= m 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 memo= ry and buffer sizes.

 <= /p>

 <= /p>

&= #8250;  &n= bsp;    REQUIREMENTS

–= ;   &= nbsp;  Decoder agnost= ic

›= ;   &= nbsp;   It shall be possi= ble to switch decoders between media flows using the same PT value

–= ;   &= nbsp;  Codec agnostic

›= ;   &= nbsp;   The criteria shal= l be applicable to any codec

&= #8250;  &n= bsp;    CRITERIA

–= ;   &= nbsp;  SDP rtpmap and fmtp attribute values must be equal (order = of attribute parameters not significant)

›= ;   &= nbsp;   All parameters mu= st be included

-    &= nbsp; Explictily

-    &= nbsp; Implicitly, if a = default value is defined for the parameter

›= ;   &= nbsp;   Parameters not in= cluded are assigned their default values (if defined)

–= ;   &= nbsp;  Decoder maximum m= emory and buffer sizes shall be assumed to match

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: mmusic-b= ounces@ietf.org [mailto:mmusic-bounces@ietf.org] 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,<= /p>

 <= /p>

Thanks for your input!

 <= /p>

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

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: Bo Burma= n
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,

 <= /p>

I agree with Jonathan tha= t in order to make two PT values “equal”, their rtpmap and fmtp= lines must be equal, as a start.

 <= /p>

I don’t think there= is any “correct” criterion that can be used to judge PT for eq= uality, but we just have to decide on a “reasonable” one that i= s as simple as possible without causing any major problems.

 <= /p>

I have assumed a conceptu= al equality criterion where PT value A should be considered equal to anothe= r 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 eith= er decoder stack to “break”.

 <= /p>

I don’t think we sh= ould require the fmtp lines are textually equal, but only that the same par= ameters 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 t= he other. To identify those as equal, which they semantically are, would re= quire an “equality parser” to know every default value of every fmtp parameter for all codecs. This seems unr= easonable.

 <= /p>

Regarding Jonathan’= s question on H.264 sprop-…, I guess they don’t strictly need t= o 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. O= n 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 o= r excessive.

 <= /p>

However, if the potential= ly equal PT values are defined as part of different media descriptions, oth= er media level attributes also contribute to the decoder stack configuration. Some attributes, like maxptime, can clearly cause pro= blems (in this case buffer overflow) if it differs. Others, like ptime, fra= merate and imageattr are more of a receiver preference within a more formal= “conformance point” and would not “break” a decoder stack if they differ.

 <= /p>

I agree it can be a good = idea to add some text into the mux-attributes draft about attributes that h= ave to be the same to consider two PT in different media descriptions to be “equal”, of course given that rtpmap and fm= tp are also equal.

 <= /p>

/Bo

 <= /p>

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 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,

 <= /p>

It would be so easy if we= could define the PT mappings on the SDP session level, and then simply ref= er to them within the m- lines :)

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

 

My strawman proposal at the mic in Berlin was that a= codec configuration is defined by the top-level media type of the m=3D lin= e 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=3D line blocks?=

 

* Is this sufficient?  Should other items (some= times) indexed by PT (e.g., the imageattr, rtcp-fb, or extmap attributes) n= eed to be the same across m-lines as well?

 

My suggestion would be that this work should be fold= ed into the work being done in draft-nandakumar-mmusic-sdp-mux-attribu= tes (which really should be integrated with BUNDLE).  Currently (I bel= ieve) the mux-attributes draft assumes that PTs are unique across m-lines, so this work is going to imply changes to t= he analysis of a number of attributes in that draft, regardless.  Prob= ably a new category will need to be defined for attributes which have to be= consistent per payload type.

 

 

 

Hi,

 

Below is the “offic= ial” (from the minutes) outcome of questions Q1,Q2 and Q7 in Berlin.<= /span>

 

Questions:<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">

 

Q1: “Can we agree t= hat, within a BUNDLE group (including all m- lines associated with the grou= p), any given PT value can only be used for a single codec configuration?&#= 8221;

Q2: “If Q1, do we a= gree that we need EXPLICIT text somewhere*, as there are opinions that simp= ly referencing RFC 3550 might not be clear enough?”

Q7: “Within a BUNDL= E group, do we allow the usage of the same PT value in multiple RTP m- line= s, for the SAME codec configuration?”<= /span>

 

Outcome:

 

Q1: Yes

Q2: Yes, Lennox will send= suggested text to clarify the term “codec configuration”.

Q7: Yes.

 

So, again, we need defini= tion text for “codec configuration”. Jonathan promised to submi= t 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 t= hat is not what the meeting wanted.

 

Regards,

 

Christer

 

 

From: mmusic-bounces@ie= tf.org [mailto= :mmusic-bo= unces@ietf.org] On Behalf Of Christer H= olmberg
Sent: 23. elokuuta= 2013 13:53
To: mmusic
Subject: [MMUSIC] = DECISION (BERLIN-Q1/Q2/Q7): Usage of specific PT value for single codec con= figuration

 

Hi,

 

One of the open issues related to BUNDL= E 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:

 

-<= span style=3D"font-size:7.0pt">       &n= bsp;  We agreed that any given PT value can only be used for a single codec configuration (Q1)<= o:p>

-<= span style=3D"font-size:7.0pt">       &n= bsp;  We agreed that we need some definition text for “codec configuration” (Q2)

-<= span style=3D"font-size:7.0pt">       &n= bsp;  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 som= e definition text for “codec configuration”, so let’s wai= t for that until we go into those discussions.

 

But, if you have any issues with the ag= reements in general, please bring them up :)

 

Regards,

 

Christer

 <= o:p>

 <= o:p>

 <= o:p>

 

--

Jonathan Lennox
jonathan@vidyo.com

 

--_000_7594FB04B1934943A5C02806D1A2204B1C4EDA3DESESSMB209erics_--