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
- [payload] draft-ramalho-payload-g7110-00 to be di… Michael Ramalho (mramalho)
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Hadriel Kaplan
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Michael Ramalho (mramalho)
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Hadriel Kaplan
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Kevin P. Fleming
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Michael Ramalho (mramalho)
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Michael Ramalho (mramalho)
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Hadriel Kaplan
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Hadriel Kaplan
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Kevin P. Fleming
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Stephen Botzko
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Hadriel Kaplan
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Muthu Arul Mozhi Perumal (mperumal)
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Michael Ramalho (mramalho)
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Michael Ramalho (mramalho)
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Hadriel Kaplan
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Randell Jesup
- Re: [payload] draft-ramalho-payload-g7110-00 to b… Michael Ramalho (mramalho)