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

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

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:[e-mail]] 
Sent: Wednesday, July 27, 2011 1:42 AM
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 4:32 PM, Michael Ramalho (mramalho) wrote:

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

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


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

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? 


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

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