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

Hadriel Kaplan <HKaplan@acmepacket.com> Tue, 26 July 2011 14:11 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 1125E21F8CB2; Tue, 26 Jul 2011 07:11:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.389
X-Spam-Level:
X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599]
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 molQ6hVkKhx4; Tue, 26 Jul 2011 07:11:53 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AE39121F8BF2; Tue, 26 Jul 2011 07:11:52 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 10:11:51 -0400
Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jul 2011 10:11:51 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "draft-ramalho-payload-g7110@tools.ietf.org" <draft-ramalho-payload-g7110@tools.ietf.org>
Date: Tue, 26 Jul 2011 10:11:49 -0400
Thread-Topic: draft-ramalho-payload-g7110-00 to be discussed in AVTEXT
Thread-Index: AcxLnfa5ON9/+YDUQsu+wdrgliSsAg==
Message-ID: <DCD4D03D-93A3-4EC9-A099-F22D92DE4BAC@acmepacket.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="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAgAAAUAAAAFR
Cc: "avtext@ietf.org" <avtext@ietf.org>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] draft-ramalho-payload-g7110-00 to be discussed in AVTEXT
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: Tue, 26 Jul 2011 14:11:54 -0000

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