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

[Paul Kyzivat <[e-mail]>]

On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote:
> On 28 February 2012 21:01, Kevin P. Fleming <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>     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).
>
>
> Yes, I concur that the draft (as it currently stands) cannot accommodate
> an asymmetric use of G.729B.  However, if we agree that both scenarios
> are true, real-world scenarios that need addressing, ie (a) the
> negotiated case where the use of G.729B is symmetric and (b) the
> declarative case where the use of G.729B can be asymmetric (and, in my
> opinion, both are valid scenarios), then I would suggest that we need to
> come up with a way of handling both situations (perhaps through the use
> of an extra fmtp parameter indicating whether the use is declarative or
> negotiated - or any other suggestions the group might have).
>
> If not, and we are only to allow the negotiated, symmetric use, then I'd
> appreciate any suggestions from the group for how my organisation might
> deal with the requirement of an asymmetric use of G.729B mentioned below.

There is one way that is available right now:

Negotiate two separate one way m-lines.
But this might be too weird for common use.

	Thanks,
	Paul

> Regards.  Harprit.
>
> Harprit S. Chhatwal
> InnoMedia
>
> On 28 February 2012 21:01, Kevin P. Fleming <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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]>
>         <mailto:[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]>>
>         <mailto:[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>>
>         <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]>>>
>                     [mailto:i-d-announce-bounces@
>         <mailto:i-d-announce-bounces@>
>         <mailto:i-d-announce-bounces@
>         <mailto:i-d-announce-bounces@>>______ietf.org <http://ietf.org>
>         <http://ietf.org>
>         <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]>>
>         <mailto:internet-drafts@ietf. <mailto:internet-drafts@ietf.>____org
>
>         <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]>>
>         <mailto:[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>>
>
>
>         <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/>>
>
>         <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>>
>
>
>         <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]>>
>         <mailto:[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>>
>
>         <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>>
>         <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>>
>         <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]>>
>         <mailto:[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>>
>
>         <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]>>
>         <mailto:[e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> | SIP:
>         [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>         <mailto:[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>
>         <http://www.digium.com> &
>         www.asterisk.org <http://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]>>
>         <mailto:[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>>
>
>         <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>
>
>
>
>
>     --
>     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>
>
>