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

["Michael Ramalho (mramalho)" <[e-mail]>]

Hadriel,

Thanks for the volley.

Comments in-line below (w/ MAR:).

Michael

-----Original Message-----
From: Hadriel Kaplan [mailto:[e-mail]] 
Sent: Tuesday, July 26, 2011 1:51 PM
To: Michael Ramalho (mramalho)
Cc: [e-mail]; [e-mail];
[e-mail]
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed
inAVTEXT


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.

MAR: Thanks for the clarification. Yes, you have got it right (one
exception shortly). SBCs normally "sniff SDP", so that might not be an
issue for them. But in the case where there are multiple SBCs in the
end-to-end path, one or more of them may strip out the G.711.0 m line
(as you have it below) before a given SBC sees the end-to-end SDP.

MAR: As an aside, some network providers may "configure PT = Q" in their
networks to make things easier (at the downside of not allowing their
applications to use PT = Q), although that would not be recommended (in
the IETF or in general).

MAR: Lastly, the compression can be applied in specific topologies -
when there are no middleboxes that deny flows based on RTP PT changes -
by tunnel endpoints that know how to compress/decompress G.711/G.711.0.
This tunneling is unspecified magic in the draft. It can also be used in
many of the same topologies where multi-hop header compression is
employed.

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

MAR: Precisely ... one m-line for G.711 (in your case mu-law) and one
m-line for G.711.0 (complaw=mu, PT = 99). The "hint" is in the G.711
m-line (and the draft says so ... but you example makes it more clear ..
thanks).

MAR: I want to know if anyone "objects" to a new fmtp parameter
"G7110/8000". Worse case, if an SBC doesn't like that parameter, it
could strip it with no harm to setting up a G.711 flow.

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

MAR: OK .. we are even now .. I should have been more explicit here ;-).

MAR: While I believe the best "in the middle" use cases are when SBCs
are involved in the (lossless) transcode ... there are SOME LIMITED
cases in which SPs desire to switch from G.711 to G.711.0 though such
boxes without the transcode and without signaling (so-called "in-media
methods"). Such SPs account for the bandwidth savings relative to G.711
in their traffic engineering. Like I said earlier, I have a longer talk
on the subject and would be happy to discuss further. Perhaps I should
have asked for a slot in the behave WG for these issues?

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)

MAR: See my last comment; there may be exceptions for specific customers
and topologies. Indeed, the reason for the "hint" is precisely to inform
devices such as SBCs that the switch from PT=0 to PT=99 (your example)
could occur naturally, so please don't kill the flow.

MAR: Thanks again for your commentary, I appreciate it.

-hadriel