Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt

"Ravindran, Parthasarathi" <pravindran@sonusnet.com> Mon, 27 February 2012 18:22 UTC

Return-Path: <pravindran@sonusnet.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 A1D8021F87C9 for <payload@ietfa.amsl.com>; Mon, 27 Feb 2012 10:22:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.337
X-Spam-Level:
X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5YmRiqI7BK6 for <payload@ietfa.amsl.com>; Mon, 27 Feb 2012 10:22:24 -0800 (PST)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACC921F8794 for <payload@ietf.org>; Mon, 27 Feb 2012 10:22:24 -0800 (PST)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1RIN9lI019214; Mon, 27 Feb 2012 13:23:09 -0500
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 13:21:59 -0500
Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 23:51:56 +0530
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 27 Feb 2012 23:51:56 +0530
From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Thread-Topic: FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt
Thread-Index: Aczy76RuUdH+fAkZQlC7A4SkY3tb3ACKA7GQAAtKSIAADaFX0A==
Date: Mon, 27 Feb 2012 18:21:55 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04F128@inba-mail01.sonusnet.com>
References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu>
In-Reply-To: <4F4BB973.4060508@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [121.242.142.186]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Feb 2012 18:21:56.0782 (UTC) FILETIME=[B0338CE0:01CCF57C]
Cc: "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt
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: Mon, 27 Feb 2012 18:22:26 -0000

Paul,

I agree with your proposal of (2) for answerer as it makes sure that "annexa=no" in G.723 or "annexb=no" in G.729 is negotiated in case offerer requested for. 

The issue with (4) in offerer is that offerer may ignore or treat as "no" but answerer treats negotiated parameter as "yes" and answerer exchanges/expects further media packets based on this assumption which leads to call failure or interop issue in reality. I agree with (4) in case we get the opinion from others that (4) is the best common practice in the industry.

Thanks
Partha

>-----Original Message-----
>From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>Sent: Monday, February 27, 2012 10:42 PM
>To: Muthu Arul Mozhi Perumal (mperumal)
>Cc: payload@ietf.org; Ravindran, Parthasarathi
>Subject: Re: FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-
>00.txt
>
>On 2/27/12 6:33 AM, Muthu Arul Mozhi Perumal (mperumal) wrote:
>> We have submitted an I-D clarifying the offer/answer considerations
>> for the Annex A flavor of G.723 and the Annex B flavors of G.729,
>> G.729D and G.729E. This clarification is missing in RFC 4856, leading
>> to interop issues, for e.g:
>> http://sipforum.org/pipermail/discussion/2008-January/004026.html
>>
>> We have a couple of open items in the I-D. We expect the WG
>> discussions would guide us on how to go about them.
>>
>> Comments welcome.
>
>I'm the source of the issues. :-)
>
>The fundamental point is that RFC4856 specifies a *default* value of
>"yes" for annexa and annexb. This means that if annexa/annexb is not
>specified in an answer, then it will default to yes, even if the offer
>contained "no".
>
>I see a few ways to fix this:
>
>1) revise the IANA registration for annexa and annexb to remove the
>    default, at least when used with O/A. Instead specify the defaulting
>    separately for offers and answers.
>
>2) REQUIRE that the answer contain "no" if the offer contained "no".
>
>3) permit the answer to contain "yes" (explicitly or by default)
>    when the offer contained "no", and specify that this still means
>    that the annex is *not* to be used.
>
>4) forbid the answer from *explicitly* containing "yes" when the
>    offer contained "no", but allow the answer to *implicitly* contain
>    "yes" (via the default) and ignore it/treat it as "no".
>
>None of these are ideal. (1) is problematic because this is used in non-
>O/A contexts, such as RSVP. (2) begs the question of what should be done
>if this is violated. (3) risks failing to recognize that the two sides
>disagree. (4) is pragmatic but seems to violate the spirit of defaults.
>
>I guess my preference is to make (2) normative for the answerer, while
>making (4) normative for the offerer, and put enough words in so its
>very clear what is being specified and why.
>
>	Thanks,
>	Paul
>
>> Muthu
>>
>> -----Original Message-----
>> From: i-d-announce-bounces@ietf.org
>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>> internet-drafts@ietf.org
>> Sent: Friday, February 24, 2012 5:57 PM
>> To: i-d-announce@ietf.org
>> Subject: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> 	Title           : Offer/Answer Considerations for G.723 Annex A
>> and G.729 Annex B
>> 	Author(s)       : Muthu Arul Mozhi Perumal
>>                            Parthasarathi Ravindran
>> 	Filename        :
>> draft-muthu-payload-offer-answer-g723-g729-00.txt
>> 	Pages           : 8
>> 	Date            : 2012-02-24
>>
>>     [RFC4856] describes the annexa parameter for G723 and the annexb
>>     parameter for G729, G729D and G729E. However, the specification
>does
>>     not describe the offerer and answerer behavior when the value of
>the
>>     annexa or annexb parameter does not match in the SDP offer and
>>     answer.  This document provides the offer/answer considerations
>for
>>     these parameters.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-muthu-payload-offer-answer-g
>> 72
>> 3-g729-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-muthu-payload-offer-answer-g7
>> 23
>> -g729-00.txt
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>