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

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

On 28 February 2012 21:01, Kevin P. Fleming <[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.

Regards.  Harprit.

Harprit S. Chhatwal
InnoMedia

On 28 February 2012 21:01, Kevin P. Fleming <[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]>> 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>
>> >
>>            <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]>
>> >>
>>            [mailto:i-d-announce-bounces@
>>            <mailto:i-d-announce-bounces@>**____ietf.org <http://ietf.org>
>>            <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]>
>> >
>>            <mailto:internet-drafts@ietf._**_org
>>
>>            <mailto:internet-drafts@ietf.**org <[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>
>> >
>>
>>
>>            <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]>**
>> >
>>            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]>>
>>            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>
>>            ______________________________**_____________________
>>
>>            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>
>> >
>>
>>            <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
>