Re: [payload] draft-ramalho-payload-g7110-00 to be discussedinAVTEXT

It is literally impossible to assign one, because RFC 3551 establishes a
policy that no more static payload type values would be assigned for
RTP/AVP:

<snip>
   This specification establishes the policy that no additional static
   payload types will be assigned beyond the ones defined in this
   document.  Establishing this policy avoids the problem of trying to
   create a set of criteria for accepting static assignments and
   encourages the implementation and deployment of the dynamic payload
   type mechanisms.

   The final set of static payload type assignments is provided in
   Tables 4 and 5.
</snip>

Muthu

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
Behalf Of Stephen Botzko
Sent: Wednesday, July 27, 2011 7:05 PM
To: Kevin P. Fleming
Cc: payload@ietf.org
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be
discussedinAVTEXT

static payload types are a scarce resource, I wouldn't assign one to
this (even if it were practical), as this is a very specialized use case
for a rather specialized codec.

Stephen Botzko
On Wed, Jul 27, 2011 at 9:29 AM, Kevin P. Fleming <kpfleming@digium.com>
wrote:
On 07/26/2011 06:43 PM, Michael Ramalho (mramalho) wrote:
Kevin,

Re: "this really isn't much  different from a pair of middleboxes in the
path of a G.711 call choosing to transcode the audio stream to/from
G.729 in order to save bandwidth "

I respectfully disagree.

While a transcode from G.711 to G.729 "saves bandwidth" ... it also
DEGRADES VOICE QUALITY. Thus adjacent signaling elements and/or
endpoints and/or service providers SHOULD be informed that a transcode
that degraded voice quality occurred. A natural way to inform the "other
parties" is via signaling.

A transcode from G.711 to G711.0 "saves bandwidth" (for zero-mean
acoustic signals) ... but it does NOT degrade voice quality. Indeed,
after the decompression the IDENTICAL G.711 PAYLOAD is reproduced. Thus
adjacent signaling elements and/or endpoints and/or service providers
NEED NOT be informed that it even occurred!

So while I would heartily agree that lossy transcodes be signaled to the
endpoints, I disagree that they need to be informed of a transformation
which is truly invisible to the endpoints.

Fair enough. I probably shouldn't have tried to read the draft yesterday
in the middle of an IETF WG meeting. Mea culpa.

	Do we signal to the endpoints that RTP header compression
occurred
	somewhere on the end-to-end path? I don't think so.

No, but there is still signaling between the middleboxes that decide to
compress/uncompress RTP headers along the path, and the endpoints don't
even have to be aware that this is a possibility. Granted, this draft
also allows for such 'endpoint ignorance' if the middleboxes use some
signaling mechanism (defined elsewhere), but it just feels a bit strange
to me to have endpoints use a mechanism to indicate to some elements
that might be in the path how an optional behavior should be employed.

Is it at all realistic to get a static RTP payload number assigned for
G.711.0? If that was done, then such middleboxes wouldn't need any help
from the endpoints to select a payload number to use for the transformed
media.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype:
kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload