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

On 02/27/2012 11:12 AM, Paul Kyzivat wrote:
> 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.

I must *really* be missing something here; why does the usage of G.729 
Annex B have to be symmetrical? Until I saw this thread, it was always 
my understanding that the 'annexb' format parameter for G.729 in SDP 
indicated the preference of the endpoint sending that parameter. Like 
nearly everything else in SDP, it indicates what that endpoint is 
*prepared to accept*, and has nothing at all to do with what it will (or 
could) send.

Unless that's a completely broken understanding, then these 'interop' 
issues are really just very poorly coded implementations. I would 
interpret the current RFC language as follows:

1) If an offer/answer contains 'annexb=no', the receiver of that 
offer/answer MUST NOT send G.729 Annex B SID frames to the 
offering/answering endpoint.

2) If an offer/answer contains 'annexb=yes', the receiver of that 
offer/answer SHOULD send G.729 Annex B SID frames to the 
offering/answering endpoint.

3) An answer's value for the 'annexb' parameter is completely 
independent of the value (if any) present in the offer it is answering.

>
> 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-g72
>> 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-g723
>> -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
>>
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org