Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed in AVTEXT

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jul 2011 10:11:49 -0400

[sorry for cross-posting, but this draft is going to be presented in avtext]

Hi,
I read this draft and I have a couple comments, as follows:

1) Have any IPR disclosures been submitted to the IETF for this?  I ask because I believe there are several submitted to ITU for this codec.

2) The stuff in section 6 on "In the Middle" is really controversial, and arguably a very bad idea.  

For one, just to be able to do this requires sniffing SDP which is only possible if it's in cleartext, and if the sniffer can reassemble fragments or stream segments, and if the sniffer is guaranteed to be in the path for all SDP exchanges between the parties for ever.  And to be able to really do it you have to *modify* the SDP which is a whole different ballgame.  

And then there's the way in which the draft describes doing it, by inserting an fmtp attribute line of the new payload type, which is wrong in my opinion - it should either replace the payload type in the m-line and add the original 711a/u-law info as a new attribute, or better yet add the new payload type as another option in the m-line and wait for an SDP answer to choose (for protocols that have an offer/answer model).  Otherwise the middlebox has to know another middlebox is in the call path a priori.

And then there's the problem of SRTP: if SRTP prevents the middlebox from doing the compression, the middlebox needs to know when SRTP is going to be used by inspecting SDP, which isn't as straightforward as looking for "SAVP" in the m-line... e.g. the endpoints could be using RFC 5939.  

In summary: I would remove this idea/section from the draft.  Publishing a draft defining the payload format and media type for G.711.0 is fairly straight-forward and non-controversial (I think), but going beyond that to "support" this man-in-the-middle thing is going to cause you heartburn and delay getting the basic stuff published as an RFC.
Just my 2 cents.

-hadriel

On Jul 25, 2011, at 12:55 PM, Michael Ramalho wrote:

> This draft is a payload WG draft, but there isn’t a payload meeting at IETF 81. And this draft was previously scheduled to be discussed  the AVT core timeslot prior to its being moved to AVTEXT (thus the reason for the cross post to all AVT groups). Roni and Ali encouraged me to say a few words prior to the discussion this week.
> 
> G.711.0 is a stateless and lossless compression of G.711 VoIP RTP payloads. Thus it is a compression algorithm tailored for G.711. When negotiated end-to-end it is negotiated “as if it were a codec”.
> 
> However, being lossless and stateless, G.711.0 can be applied anywhere within an end-to-end G.711 negotiated session. When applied in this manner, it suffers no voice quality degradation relative to G.711 (duh, its lossless).
> 
> Most of the open issues in the draft relate to the use of G.711.0 within the context of an and-to-end G.711 negotiated session.
> 
> I look forward to comments generated from the discussion of this draft for those cases.
>

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Tue, 26 Jul 2011 12:01:52 -0500

Hadriel,

Thank you for asking your question.

Re: "Have any IPR disclosures been submitted to the IETF for this?"

For the G.711.0 IETF payload draft, no.

In the ITU-T there are four IPR disclosures for G.711.0 - one for each
of the collaborating companies.

However, Cisco had hoped for a disclosures to be filed at either the
IETF or the ITU-T by IETF 81 by all four collaborating companies
explicitly stating that G.711.0 for "consumer software terminals" (e.g.,
softclients) be royalty-free. We hope such a statement will be released
in the near future.

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.

When G.711.0 is negotiated end to end, it will have its own media line.
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.

Part of the reason for the "hint in the G.711 SDP" is because SBCs will
likely strip the G.711.0 m line from the SDP because it doesn't know
about G.711.0 and only let the m line for G.711 to pass ... it might
just let an unrecognized G.711 attribute through. I would like to get
opinions for the group and appreciate your question.

Re: SRTP

Yep, the raw G.711 needs to be in the clear for the compression to work.
Note that the PT is in the clear with SRTP (because the RTP header is in
the clear) ... and thus SRTP should be able to encrypt G.711.0 without
issues.

Re: "Cut out the "In the Middle" section".

That is a possibility. However I can say that we have explicit customer
requests that IF such a compression is likely to be used by "in the
middle entities" (i.e., service providers or administrative domains
within a service provider), that we provide guidance on how to
accomplish that compression so that everyone does it the same way.

I also agree that keeping it in the draft will cause heartburn relative
to its absence ;-). But I've got customers to please. And I have thick
skin ;-).

Re: "Middleboxes are a pain"

Yes they are; but the are also a fact of life. I have a longer talk in
which I enumerate the issues related to SBCs ... but that talk is
inappropriate for the IETF slot (at least that is what I have been
told).

Thanks again,

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Tuesday, July 26, 2011 10:12 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed
inAVTEXT

[sorry for cross-posting, but this draft is going to be presented in
avtext]

Hi,

1) Have any IPR disclosures been submitted to the IETF for this?  I ask
because I believe there are several submitted to ITU for this codec.

2) The stuff in section 6 on "In the Middle" is really controversial,
and arguably a very bad idea.  

For one, just to be able to do this requires sniffing SDP which is only
possible if it's in cleartext, and if the sniffer can reassemble
fragments or stream segments, and if the sniffer is guaranteed to be in
the path for all SDP exchanges between the parties for ever.  And to be
able to really do it you have to *modify* the SDP which is a whole
different ballgame.  

And then there's the way in which the draft describes doing it, by
inserting an fmtp attribute line of the new payload type, which is wrong
in my opinion - it should either replace the payload type in the m-line
and add the original 711a/u-law info as a new attribute, or better yet
add the new payload type as another option in the m-line and wait for an
SDP answer to choose (for protocols that have an offer/answer model).
Otherwise the middlebox has to know another middlebox is in the call
path a priori.

And then there's the problem of SRTP: if SRTP prevents the middlebox
from doing the compression, the middlebox needs to know when SRTP is
going to be used by inspecting SDP, which isn't as straightforward as
looking for "SAVP" in the m-line... e.g. the endpoints could be using
RFC 5939.  

In summary: I would remove this idea/section from the draft.  Publishing
a draft defining the payload format and media type for G.711.0 is fairly
straight-forward and non-controversial (I think), but going beyond that
to "support" this man-in-the-middle thing is going to cause you
heartburn and delay getting the basic stuff published as an RFC.
Just my 2 cents.

-hadriel

On Jul 25, 2011, at 12:55 PM, Michael Ramalho wrote:

> This draft is a payload WG draft, but there isn't a payload meeting at
IETF 81. And this draft was previously scheduled to be discussed  the
AVT core timeslot prior to its being moved to AVTEXT (thus the reason
for the cross post to all AVT groups). Roni and Ali encouraged me to say
a few words prior to the discussion this week.
> 
> G.711.0 is a stateless and lossless compression of G.711 VoIP RTP
payloads. Thus it is a compression algorithm tailored for G.711. When
negotiated end-to-end it is negotiated "as if it were a codec".
> 
> However, being lossless and stateless, G.711.0 can be applied anywhere
within an end-to-end G.711 negotiated session. When applied in this
manner, it suffers no voice quality degradation relative to G.711 (duh,
its lossless).
> 
> Most of the open issues in the draft relate to the use of G.711.0
within the context of an and-to-end G.711 negotiated session.
> I look forward to comments generated from the discussion of this draft
for those cases.

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jul 2011 13:51:13 -0400

> Thus every RTP packet with PT = [ 0 | 8 ] can only have a G.711 payload

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

> 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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 26 Jul 2011 14:01:39 -0400

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

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: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Tue, 26 Jul 2011 15:32:19 -0500

Hadriel,

Thanks for the volley.

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

Michael

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2011 1:51 PM
To: Michael Ramalho (mramalho)
Cc: [email-masked]; [email-masked];
[email-masked]

> Thus every RTP packet with PT = [ 0 | 8 ] can only have a G.711
payload

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.

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.

> 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

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Tue, 26 Jul 2011 17:43:48 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Kevin P. Fleming
Sent: Tuesday, July 26, 2011 2:02 PM
To: [email-masked]
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be
discussedinAVTEXT

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

Jabber: [email-masked] | SIP: [email-masked] | Skype:
kpfleming

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Jul 2011 01:42:16 -0400

> (as you have it below) before a given SBC sees the end-to-end SDP.

I think the odds of an SBC stripping out something would be far less if this weren't encoded as two m-lines for the same media type (audio).
I.e., just do normal SDP like this:
  m=audio 49120 RTP/AVP 0 99
  a=ptime:20
  a=rtpmap:99 G7110/8000
  a=fmtp:99 complaw=mu

> applications to use PT = Q), although that would not be recommended (in

But even if you fixed a PT for G.711.0, wouldn't you still need to sniff the SDP to learn the IP/port of the media?  Or are you just going to guess that if the packet looks like RTP it is RTP? 

> many of the same topologies where multi-hop header compression is

I don't understand what you mean, or why that matters.  All I have to go by is the diagram in the draft:

                                                **********************
                                                *                    *
      |------------|    |--------------------|  *  |---------------| *
      |     A:     |    |         B:         |  *  |  C: G.711.0   | *
      |  SENDING   |--->|    ZERO OR MORE    |---->|  Compression  | *
      |   G.711    |    |   ROUTING AND/OR   |  *  |   PT=[0|8]    | *
      |  ENDPOINT  |    |   SWITCHING HOPS   |  *  |  CHANGED TO   | *
      |            |    | AND/OR MIDDLEBOXES |  *  |    PT = Q     | *
      |____________|    |____________________|  *  |_______________| *
                                                *         |          *
                                               *          |          *
                                    ********* *           |          *
                                    *                     |          *
                                    *                     V          *
                                    *        |--------------------|  *
                                    *        |         D:         |  *
                          G.711.0   *        |    ZERO OR MORE    |  *
                        COMPRESSION *        |   ROUTING AND/OR   |  *
                          SEGMENT   *        |   SWITCHING HOPS   |  *
                         (payload   *        | AND/OR MIDDLEBOXES |  *
                           only)    *        |____________________|  *
                                    *                     |          *
                                    *                     |          *
                                    ***********           |          *
                                               *          |          *
                                                *         V          *
      |------------|    |--------------------|  *  |---------------| *
      |     G:     |    |         F:         |  *  |  E: G.711.0   | *
      | RECEIVING  |<---|    ZERO OR MORE    |<----| DECOMPRESSION | *
      |   G.711    |    |   ROUTING AND/OR   |  *  |    PT = Q     | *
      |  ENDPOINT  |    |   SWITCHING HOPS   |  *  | CHANGED BACK  | *
      |            |    | AND/OR MIDDLEBOXES |  *  |  TO PT=[0|8]  | *
      |____________|    |____________________|  *  |_______________| *
                                                *                    *
                                                **********************

Are you saying that there's a GRE or MPLS tunnel between C and E, and that C knows a priori (without SIP/SDP) that RTP it sends goes through E, and that C knows a priori that E is capable of G.711.0 decompression to 711a/u-law?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Jul 2011 01:49:18 -0400

On Jul 26, 2011, at 4:32 PM, Michael Ramalho (mramalho) wrote:
>  Like I said earlier, I have a longer talk

Yes a presentation discussion will help, but I don't think BEHAVE would be the right WG.
IMHO, most of this draft belongs in PAYLOAD, but all of section 6 belongs somewhere else, maybe MMUSIC.  Just my 2 cents though.

-hadriel

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 27 Jul 2011 09:29:22 -0400

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

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

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 27 Jul 2011 09:35:23 -0400

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 <[email-masked]>wrote:

> Fair enough. I probably shouldn't have tried to read the draft yesterday in
> the middle of an IETF WG meeting. Mea culpa.
>
>
> 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.
>
> 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
> ______________________________**_________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/payload<https://www.ietf.org/mailman/listinfo/payload>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Jul 2011 09:56:35 -0400

On Jul 26, 2011, at 6:43 PM, Michael Ramalho (mramalho) wrote:

> DEGRADES VOICE QUALITY.

It doesn't matter whether a particular codec or payload transform is lossless or not, from the perspective of SDP and RTP.  SRTP encrypt/decrypt and authentication is also completely "lossless".  You could, in theory, do SRTP between two middleboxes.  All you'd need is a way to exchange keys between the two middleboxes, just like for G.711.0 you need a way to exchange payload types and companding.  Obviously SBCs and other middleboxes can and do SRTP termination/origination, but we would never have done it the way this draft is describing to do G.711.0.  I must be missing something about your use-case that makes it different.

> somewhere on the end-to-end path? I don't think so.

ROHC for RTP only works in extremely constrained deployment scenarios, and as far as I'm aware can only be done either by the devices generating the RTP so they know what IP/UDP combo stream is RTP before-hand, or by channelization/separation and signaling for a context.  And as far as I know it has signaling in ROHC itself - it's not just blindly starting to compress without knowing the far-end is capable of decompressing and what modes. 

-hadriel

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 27 Jul 2011 21:21:06 +0530

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Botzko
Sent: Wednesday, July 27, 2011 7:05 PM
To: Kevin P. Fleming
Cc: [email-masked]
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 <[email-masked]>
wrote:
On 07/26/2011 06:43 PM, Michael Ramalho (mramalho) wrote:
Kevin,

I respectfully disagree.

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

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 27 Jul 2011 12:36:03 -0500

Hadriel,

Re: Put G.711.0 on one m-line.

If others believe, as you do, that having G.711.0 on it's own m-line is
actually worse (in the sense of the probability of it being stripped
out) than having in on the same m-line as G.711 ... I am OK with that.

Do others have an opinion?

I am inclined to go with your recommendation if no one objects.

Re: "Are you saying that there's a GRE or MPLS tunnel between C and E,
and that C knows a priori (without SIP/SDP) that RTP it sends goes
through E, and that C knows a priori that E is capable of G.711.0
decompression to 711a/u-law?"

A tunnel of some sort ... including WAAS-like tunnels in enterprise use
cases.

The question of how the end tunnels (Box C and E) "find themselves" is
purposely left outside the scope of the draft.

What I am hoping for is that we can specify some principals for how you
compress/decompress so that the flow to the "G.711.0 unaware" endpoints
don't know it occurred. Better text is always welcome.

Thanks again,

Michael

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 1:42 AM
To: Michael Ramalho (mramalho)
Cc: [email-masked]; [email-masked];
[email-masked]

> (as you have it below) before a given SBC sees the end-to-end SDP.

I think the odds of an SBC stripping out something would be far less if
this weren't encoded as two m-lines for the same media type (audio).
I.e., just do normal SDP like this:
  m=audio 49120 RTP/AVP 0 99
  a=ptime:20
  a=rtpmap:99 G7110/8000
  a=fmtp:99 complaw=mu

> applications to use PT = Q), although that would not be recommended
(in

But even if you fixed a PT for G.711.0, wouldn't you still need to sniff
the SDP to learn the IP/port of the media?  Or are you just going to
guess that if the packet looks like RTP it is RTP? 

> many of the same topologies where multi-hop header compression is

I don't understand what you mean, or why that matters.  All I have to go
by is the diagram in the draft:

                                                **********************
                                                *                    *

Are you saying that there's a GRE or MPLS tunnel between C and E, and
that C knows a priori (without SIP/SDP) that RTP it sends goes through
E, and that C knows a priori that E is capable of G.711.0 decompression
to 711a/u-law?

-hadriel

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 27 Jul 2011 13:36:28 -0500

Hadriel,

In-line below.

Michael

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 9:57 AM
To: Michael Ramalho (mramalho)
Cc: Kevin P. Fleming; [email-masked]
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be
discussedinAVTEXT

> While a transcode from G.711 to G.729 "saves bandwidth" ... it also

It doesn't matter whether a particular codec or payload transform is
lossless or not, from the perspective of SDP and RTP.  SRTP
encrypt/decrypt and authentication is also completely "lossless".  You
could, in theory, do SRTP between two middleboxes.

MAR: Not even in theory .. but also in practice!

MAR: SRTP was designed (as I understand it) from day one to encrypt
between "session endpoints".

MAR: Insofar as the UAs facing each other in two consenting SBCs are SIP
dialog endpoints (i.e., "in the middle" of a longer end-to-end "call")
... they can do SRTP between them!

MAR: I guess I don't get the "in theory" part.

All you'd need is a way to exchange keys between the two middleboxes,
just like for G.711.0 you need a way to exchange payload types and
companding.

MAR: The companding for the "G.711.0 compression segment" (as defined in
the draft) is assumed to be the companding used in the true user
endpoints ... which can be determined from the incoming PT (0 or 8).

MAR: The communication/negotiation/exchange between the "G.711.0 tunnel
endpoints" is purposely unspecified in the draft. Indeed, how the
G.711.0 compression/decompression endpoints "find themselves" is also
purposely unspecified in the draft.

MAR: In the absence of middleboxes and NAT/PAT and in certain topologies
... there are a variety of simple "in-media" methods by which
compression/decompression endpoints can find themselves. There are many
"gotchas" for those use cases ... but again ... these cases are
purposely unspecified in the draft. Unfortunately, I was not allotted
enough time to go through those cases in the avtext meeting today.

MAR: My comment about various forms of header compression was to point
out, via example, that SBCs do not always know what is going on "within"
the flows that traverse them (I could put a friendly comment that SBCs
being "control freaks" ... but I'll refrain ;-) ).

Obviously SBCs and other middleboxes can and do SRTP
termination/origination, but we would never have done it the way this
draft is describing to do G.711.0.  I must be missing something about
your use-case that makes it different.

MAR: I wouldn't use per-flow encryption in your example either ... but
that is a different story.

> somewhere on the end-to-end path? I don't think so.

ROHC for RTP only works in extremely constrained deployment scenarios,
and as far as I'm aware can only be done either by the devices
generating the RTP so they know what IP/UDP combo stream is RTP
before-hand, or by channelization/separation and signaling for a
context.  And as far as I know it has signaling in ROHC itself - it's
not just blindly starting to compress without knowing the far-end is
capable of decompressing and what modes. 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Jul 2011 15:52:54 -0400

> MAR: Not even in theory .. but also in practice!

Yes, exactly - they do it in *practice*, but SBCs don't do it by "not telling the endpoints" or hiding stuff, because the SBCs *are* the endpoints from the perspective of SDP and IP/UDP/RTP.  The "real" endpoints (namely your phones) don't know SRTP happened in the middle, and they don't know transcoding G.711<->G.729 happened either, etc., but the phones not the real endpoints from the perspective of IP, UDP, RTP, nor SDP - only from a human perspective.

-hadriel