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

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

Speaking as a codec person :-), I think the draft does address a real issue
and is reasonably clear in its content.  However, it does not appear to
address (as far as I can see), the case where an asymmetric use of G.729B
is required.  This is an actual issue as we are faced with a customer
requirement where the use of G.729B is required in one direction and not
the other (for bandwidth reasons).  Given the current specs do not appear
to definitively cover this case, it would be good to see if this can be
addressed through the proposed draft.

Regards.  Harprit.

Harprit S. Chhatwal
InnoMedia

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

> On 02/28/2012 12:07 PM, Paul Kyzivat wrote:
>
>> Clarification:
>>
>> In my comments on the draft I was not questioning the assumption of that
>> draft that a common value of this parameter is *negotiated* via O/A.
>> *If* you accept that assumption then my comments hopefully make sense.
>>
>> But if there is debate regarding whether the parameter is negotiated or
>> declarative, then that needs to be settled first, before nailing down
>> clarifications for how the negotiation happens.
>>
>> Not being a codec person, I don't know what the common practice is here.
>> So I'm going to let those that have the knowledge argue that.
>>
>
> Correct on all points; your comments make complete sense if 'annexb' is
> intended to be a negotiated parameter.
>
> I'm not a codec person (although I'd probably be willing to play one on TV
> is the need arose <G>), but there are so many other codec/format parameters
> that are declarative already that I don't see any need for this one to have
> to be negotiated. The impact of using Annex B or not is purely on one
> direction of the media stream, and it's not even mandatory that the encoder
> use Annex B mode just because 'annexb=yes'. Granted, it's pretty unlikely
> that an implementation that cannot accept incoming SID frames would also be
> able to generate them, but I can think of completely reasonable situations
> for an implementation that can generate them being willing to do so while
> at the same time disallowing reception of them.
>
>
>
>> Thanks,
>> Paul
>>
>> On 2/28/12 12:34 PM, Chhatwal, Harprit S wrote:
>>
>>> 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]
>>> <mailto:[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>
>>> <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]>>
>>> [mailto:i-d-announce-bounces@_**_ietf.org
>>> <mailto:i-d-announce-bounces@**ietf.org <[e-mail]>>]
>>> On Behalf Of
>>> [e-mail] <mailto:internet-drafts@ietf.**org<[e-mail]>
>>> >
>>> Sent: Friday, February 24, 2012 5:57 PM
>>> To: [e-mail] <mailto:[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>
>>>
>>> <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/>
>>> <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>
>>>
>>> <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] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/_**_listinfo/i-d-announce<https://www.ietf.org/mailman/__listinfo/i-d-announce>
>>> <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>
>>> <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>
>>> <ftp://ftp.ietf.org/ietf/**1shadow-sites.txt<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>> >
>>>
>>>
>>> ______________________________**___________________
>>> payload mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/_**_listinfo/payload<https://www.ietf.org/mailman/__listinfo/payload>
>>> <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] <mailto:[e-mail]> | SIP:
>>> [e-mail] <mailto:[e-mail]> | Skype: kpfleming
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>> Check us out at www.digium.com <http://www.digium.com> &
>>> www.asterisk.org <http://www.asterisk.org>
>>> ______________________________**___________________
>>> payload mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/_**_listinfo/payload<https://www.ietf.org/mailman/__listinfo/payload>
>>> <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
>