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

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

On 02/28/2012 02:58 PM, Chhatwal, Harprit S wrote:
> 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.

That requirement is counter to what the draft proposes. We can't have it 
both ways: either the G.729 'annexb' format parameter is a negotiated 
parameter (in which case its usage is symmetrical by definition) or it 
is a declarative parameter (in which case the usage can be, but is not 
required to be, asymmetrical).

>
> Regards.  Harprit.
>
> Harprit S. Chhatwal
> InnoMedia
>
> On 28 February 2012 19:10, Kevin P. Fleming <[e-mail]
> <mailto:[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]>
>             <mailto:[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:[e-mail]>
>             <mailto:i-d-announce-bounces@__ietf.org
>             <mailto:[e-mail]>>
>             [mailto:i-d-announce-bounces@
>             <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
>             <mailto:i-d-announce-bounces@__ietf.org
>             <mailto:[e-mail]>>] On Behalf Of
>             [e-mail] <mailto:[e-mail]>
>             <mailto:internet-drafts@ietf.__org
>             <mailto:[e-mail]>>
>             Sent: Friday, February 24, 2012 5:57 PM
>             To: [e-mail] <mailto:[e-mail]>
>             <mailto:[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]>
>             <mailto:[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]>
>             <mailto:[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]>
>             <mailto:[e-mail] <mailto:[e-mail]>> | SIP:
>             [e-mail] <mailto:[e-mail]>
>             <mailto:[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>
>             <http://www.digium.com> &
>             www.asterisk.org <http://www.asterisk.org>
>             <http://www.asterisk.org>
>             ___________________________________________________
>             payload mailing list
>             [e-mail] <mailto:[e-mail]>
>             <mailto:[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>
>
>


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