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

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 27 July 2011 05:42 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4504311E8076; Tue, 26 Jul 2011 22:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_72=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUkeiI2sEHnD; Tue, 26 Jul 2011 22:42:23 -0700 (PDT)
Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC811E8072; Tue, 26 Jul 2011 22:42:23 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 27 Jul 2011 01:42:19 -0400
Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 27 Jul 2011 01:42:17 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
Date: Wed, 27 Jul 2011 01:42:16 -0400
Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT
Thread-Index: AcxMH/HOYigxaGnNRSO18vl/0yq1kw==
Message-ID: <23FA88EE-A4E7-4A57-93BA-8B91501050F6@acmepacket.com>
References: <DCD4D03D-93A3-4EC9-A099-F22D92DE4BAC@acmepacket.com> <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com> <CDB75F50-9298-4711-8C0B-968B47D3EE10@acmepacket.com> <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com>
In-Reply-To: <999109E6BC528947A871CDEB5EB908A0044E3025@XMB-RCD-209.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAUA=
Cc: "avtext@ietf.org" <avtext@ietf.org>, "payload@ietf.org" <payload@ietf.org>, "draft-ramalho-payload-g7110@tools.ietf.org" <draft-ramalho-payload-g7110@tools.ietf.org>
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 05:42:24 -0000

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