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

["Kevin P. Fleming" <[e-mail]>]

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>
>>
>> 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:[e-mail]>
>> [mailto:i-d-announce-bounces@__ietf.org
>> <mailto:[e-mail]>] On Behalf Of
>> [e-mail] <mailto:[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>
>>
>> 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] <mailto:[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] <mailto:[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] <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>
>>
>>
>


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