Re: [avtext] [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT
"Michael Ramalho (mramalho)" <mramalho@cisco.com> Tue, 26 July 2011 17:02 UTC
Return-Path: <mramalho@cisco.com>
X-Original-To: avtext@ietfa.amsl.com
Delivered-To: avtext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268E81F0C36; Tue, 26 Jul 2011 10:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=1.211, 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 9KuMOGVTxGJD; Tue, 26 Jul 2011 10:02:02 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB31F0C35; Tue, 26 Jul 2011 10:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=6156; q=dns/txt; s=iport; t=1311699722; x=1312909322; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MBQ7FyXq8UIIXOTbLBj38/GOqZYvQgVyw8NO+cmHlyA=; b=cLvIXOnUzNpW1OiHgs7LduWMaj37dlmwNYONpsrEj7l+ahheExRQfa8/ m2pkVuEQLXb4xa9k5RJqxk/6jma9MYkfnXNW/yb0Gkubg34fmUOH9HveP /uiUwfSXhGWrUunF8llwQ8TAEmBpaMc6pe8yOqD3/ROZP4VAajcJSQ5LL M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuYAANXxLk6tJXG9/2dsb2JhbAArCwEBAQECAQEBAREBIQo6CwUHBQIBCQ4DBAEBCwYjAQYBExgjDggBAQUBFgwSCZdUj1p3iHwEowqeY4VhXwSHV5Ari24
X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6558096"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jul 2011 17:02:01 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QH21JZ001856; Tue, 26 Jul 2011 17:02:01 GMT
Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 12:02:01 -0500
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jul 2011 12:01:52 -0500
Message-ID: <999109E6BC528947A871CDEB5EB908A0044E2EEB@XMB-RCD-209.cisco.com>
In-Reply-To: <DCD4D03D-93A3-4EC9-A099-F22D92DE4BAC@acmepacket.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT
Thread-Index: AcxLnfa5ON9/+YDUQsu+wdrgliSsAgAFt/Iw
References: <DCD4D03D-93A3-4EC9-A099-F22D92DE4BAC@acmepacket.com>
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, draft-ramalho-payload-g7110@tools.ietf.org
X-OriginalArrivalTime: 26 Jul 2011 17:02:01.0157 (UTC) FILETIME=[BC8F3F50:01CC4BB5]
Cc: avtext@ietf.org, payload@ietf.org
Subject: Re: [avtext] [payload] draft-ramalho-payload-g7110-00 to be discussed inAVTEXT
X-BeenThere: avtext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Extensions working group discussion list <avtext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avtext>, <mailto:avtext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avtext>
List-Post: <mailto:avtext@ietf.org>
List-Help: <mailto:avtext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avtext>, <mailto:avtext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 17:02:03 -0000
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: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, July 26, 2011 10:12 AM To: draft-ramalho-payload-g7110@tools.ietf.org Cc: avtext@ietf.org; payload@ietf.org 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, 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. > _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload
- [avtext] draft-ramalho-payload-g7110-00 to be dis… Michael Ramalho (mramalho)
- Re: [avtext] [payload] draft-ramalho-payload-g711… Michael Ramalho (mramalho)
- Re: [avtext] draft-ramalho-payload-g7110-00 to be… Hadriel Kaplan
- Re: [avtext] [payload] draft-ramalho-payload-g711… Michael Ramalho (mramalho)
- Re: [avtext] [payload] draft-ramalho-payload-g711… Michael Ramalho (mramalho)
- Re: [avtext] [payload] draft-ramalho-payload-g711… Michael Ramalho (mramalho)