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

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.

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

Michael Ramalho

-----Original Message-----
From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
Behalf Of Kevin P. Fleming
Sent: Tuesday, July 26, 2011 2:02 PM
To: payload@ietf.org
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be
discussedinAVTEXT

On 07/26/2011 01:51 PM, Hadriel Kaplan wrote:

>> The suggested "hint" in the G.711 SDP is not to "signal G.711.0", but
>> rather for middleboxes like NATs/Firewalls/etc. to "expect G.711" in
>> either uncompressed (real G.711 with PT = [0 | 8]) or compressed
(with
>> PT = Q) form as equivalents.
>
> But they're NOT equivalent.  For all intents and purposes G.711.0 is a
different codec from G.711, afaict.  That it can be implemented as a
bump-in-the-wire without full DSPs matters not.  The most logical thing
for a middlebox to do would be to handle it exactly like it handles
middlebox-provided transcoding/transrating cases today, with normal SDP
modifications/behavior, no? (and by that I mean act as a first-class
participant in SDP, by inserting/adding codecs into the same m-line, and
handling offer/answer appropriately)

I tend to agree with Hadriel's opinion here; 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 (except that does require DSP-type processing, but that 
shouldn't affect how the transformation is signaled).

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