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

["Chhatwal, Harprit S" <[e-mail]>]

Kevin,

First of all, from RFC3264, I agree with you that for things like IP
addresses, ports, payload types, ptime, the SDP that one party sends
indicates the address/port/PT/ptime that the sender would like to receive
on.  However, I don't believe this is generally correct for all
parameters.  For instance, for codecs (again from RFC3264), the codec(s)
included in an SDP offer indicates the codec(s) the offerer is willing to
send AND receive (if the directional attribute is ‘sendrecv’).  As an
example, if party A is the offerer and sends G.729 & G.711 in its SDP
offer, it is saying that it is willing to use either codec.  If the
answerer replies with G.711, then it is only willing to use G.711, and then
G.729 will not be used in either direction.



Turning now to silence suppression, the situation does not seem very
clear.  This is what RFC3264 has to say about fmtp parameters such as
‘annexb’ :



   The interpretation of fmtp parameters in an offer depends on the

   parameters.  In many cases, those parameters describe specific

   configurations of the media format, and should therefore be processed

   as the media format value itself would be.  This means that the same

   fmtp parameters with the same values MUST be present in the answer if

   the media format they describe is present in the answer.  Other fmtp

   parameters are more like parameters, for which it is perfectly

   acceptable for each agent to use different values.  In that case, the

   answer MAY contain fmtp parameters, and those MAY have the same

   values as those in the offer, or they MAY be different.  SDP

   extensions that define new parameters SHOULD specify the proper

   interpretation in offer/answer.



To me, ‘annexb’ is more like a parameter in this sense and, in this case,
everything is allowed – the answer may contain the same fmtp or different.
 RFC3264 doesn’t appear to specify the interpretation.  The problem is that
I don't know of anywhere else where the interpretation is specified
either.  RFC4856  specifies the parameter ‘annexb’, but doesn’t say whether
it can be used asymmetrically (or how).  The only other guidance I can find
on this is elsewhere in RFC3264:



   The list of media formats for each media stream conveys two pieces of

   information, namely the set of formats (codecs and any parameters

   associated with the codec, in the case of RTP) that the offerer is

   capable of sending and/or receiving (depending on the direction

   attributes)...

   ...For a sendrecv stream, the offer SHOULD indicate those

   codecs that the offerer is willing to send and receive with.



So, this appears to be lumping codec parameters with codecs and so both
should behave in the same way.  If we take this interpretation, then
indicating ‘annexb=no’ indicates that the sender of this SDP is willing to
send and receive with silence suppression off.  So, according to this, if
the offerer sends ‘annexb=yes’ in the offer and the answerer sends back
‘annexb=no’, then there is a mismatch and the offerer should send a
re-INVITE with ‘annexb=no’ to resolve the conflict.  According to this
interpretation, we cannot have an asymmetric use of silence suppression.
However,  from the discussion we're having, I can see that all of this is
somewhat open to interpretation (since the specs do not seem to be clear)
and I agree with the authors of this ID that we need some clarification as
to how this issue should be dealt with (and whether asymmetric use of
annexb should be allowed and, if so, how).


Regards.  Harprit.


Harprit S. Chhatwal

InnoMedia

On 28 February 2012 16:54, Kevin P. Fleming <[e-mail]> wrote:

> 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<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: [e-mail]
>>> [mailto:i-d-announce-bounces@**ietf.org <[e-mail]>]
>>> On Behalf Of
>>> [e-mail]
>>> Sent: Friday, February 24, 2012 5:57 PM
>>> To: [e-mail]
>>> 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<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/<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<ftp://ftp.ietf.org/internet-drafts/draft-muthu-payload-offer-answer-g723>
>>> -g729-00.txt
>>>
>>> ______________________________**_________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/**listinfo/i-d-announce<https://www.ietf.org/mailman/listinfo/i-d-announce>
>>> Internet-Draft directories: http://www.ietf.org/shadow.**html<http://www.ietf.org/shadow.html>
>>> or ftp://ftp.ietf.org/ietf/**1shadow-sites.txt<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>>
>>>
>> ______________________________**_________________
>> payload mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/payload<https://www.ietf.org/mailman/listinfo/payload>
>>
>
>
> --
> Kevin P. Fleming
> Digium, Inc. | Director of Software Technologies
> Jabber: [e-mail] | SIP: [e-mail] | Skype: kpfleming
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at www.digium.com & www.asterisk.org
> ______________________________**_________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/payload<https://www.ietf.org/mailman/listinfo/payload>
>