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

[Hadriel Kaplan <[e-mail]>]

On Jul 26, 2011, at 1:01 PM, Michael Ramalho (mramalho) wrote:

> RE: "For one, just to be able to do this requires sniffing SDP "
> 
> Not true. Virtually every implementation using G.711 I have found in
> practice uses the STATIC payload type of 0 or 8 for G.711.
> 
> Thus every RTP packet with PT = [ 0 | 8 ] can only have a G.711 payload
> inside of it.

Sorry I should have been explicit.  It needs to sniff to detect the PT of the G.711.0 payload.  I.e., for the example diagram figure 4 in the draft, device E needs to sniff the SDP offer to determine what the "Q" value is, and device C needs to do the same for the SDP answer for the reverse media stream.


> 
> When G.711.0 is negotiated end to end, it will have its own media line.

Ummm... I'm confused.  The example in the draft is:
   m=audio RTP/AVP 0
   a=rtpmap: 0 PCMU
   a=fmtp:0 G7110 = Q   <<< the G.711 SDP hint

Are you saying that it's really this?:
   m=audio 49120 RTP/AVP 0
   a=rtpmap:0 PCMU
   a=fmtp:0 G7110 = Q
   m=audio 49120 RTP/AVP 99
   a=rtpmap:99 G7110/8000
   a=ptime:20
   a=fmtp:98 complaw=mu


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

-hadriel