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<https://www.ietf.org/mailman/listinfo/payload>
>