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

On 2/28/2012 9:36 PM, Paul Kyzivat wrote:

> On 2/28/12 7:05 AM, alvin hut wrote:
>> I DONT UNDERSTAND THESE EMILS
> 
> Could you say more about what you are having trouble with?
> Did you read the draft?

My guess is that Mr. Hut somehow became accidentally subscribed to this
list.

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