Re: [payload] payload Digest, Vol 14, Issue 10

 I DONT UNDERSTAND THESE EMILS 
From: payload-request@ietf.org
Subject: payload Digest, Vol 14, Issue 10
To: payload@ietf.org
Date: Mon, 27 Feb 2012 12:00:09 -0800

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/payload

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send payload mailing list submissions to
	payload@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/payload
or, via email, send a message with subject or body 'help' to
	payload-request@ietf.org

You can reach the person managing the list at
	payload-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of payload digest..."

--Forwarded Message Attachment--
From: pravindran@sonusnet.com
CC: payload@ietf.org
To: pkyzivat@alum.mit.edu; mperumal@cisco.com
Date: Mon, 27 Feb 2012 18:21:55 +0000
Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt

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