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

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 27 Feb 2012 17:03:57 +0530

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

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.

Muthu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, February 24, 2012 5:57 PM
To: [email-masked]
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
3-g729-00.txt

Internet-Drafts are also available by anonymous FTP at:
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
-g729-00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 27 Feb 2012 18:21:55 +0000

Paul,

I agree with your proposal of (2) for answerer as it makes sure that "annexa=no" in G.723 or "annexb=no" in G.729 is negotiated in case offerer requested for. 

The issue with (4) in offerer is that offerer may ignore or treat as "no" but answerer treats negotiated parameter as "yes" and answerer exchanges/expects further media packets based on this assumption which leads to call failure or interop issue in reality. I agree with (4) in case we get the opinion from others that (4) is the best common practice in the industry.

Thanks
Partha

>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: Monday, February 27, 2012 10:42 PM
>To: Muthu Arul Mozhi Perumal (mperumal)
>Cc: [email-masked]; Ravindran, Parthasarathi
>Subject: Re: FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-
>00.txt
>
>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:
>> 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.
>
>	Thanks,
>	Paul
>
>> Muthu
>>
>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Feb 2012 12:12:19 -0500

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.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 28 Feb 2012 10:54:14 -0600

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

> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: "Chhatwal, Harprit S" <[email-masked]>
Date: Tue, 28 Feb 2012 17:34:16 +0000

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 <[email-masked]> wrote:

>>> http://sipforum.org/pipermail/**discussion/2008-January/**004026.html<http://sipforum.org/pipermail/discussion/2008-January/004026.html>
>>>
> 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.
>
> issues are really just very poorly coded implementations. I would interpret
> the current RFC language as follows:
>
> 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
>>>
>>> [mailto:i-d-announce-bounces@**ietf.org <[email-masked]>]
>>> On Behalf Of
>>> [email-masked]
>>> Subject: I-D Action: draft-muthu-payload-offer-**answer-g723-g729-00.txt
>>>
>>>
>>> draft-muthu-payload-offer-**answer-g723-g729-00.txt
>>> Pages : 8
>>> Date : 2012-02-24
>>>
>>> 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
>>>
>>> ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/>
>>>
>>> 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
>>>
>>> ______________________________**_________________
>>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/payload<https://www.ietf.org/mailman/listinfo/payload>
>>
>
>
> --
> Kevin P. Fleming
> ______________________________**_________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/payload<https://www.ietf.org/mailman/listinfo/payload>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Feb 2012 13:07:04 -0500

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.

	Thanks,
	Paul

On 2/28/12 12:34 PM, Chhatwal, Harprit S wrote:
> 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
> 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
> 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.
>
> 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:
>
> 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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>             http://sipforum.org/pipermail/__discussion/2008-January/__004026.html
>             <http://sipforum.org/pipermail/discussion/2008-January/004026.html>
>
>     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:
>
>             <mailto:[email-masked]>
>             [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of
>             [email-masked] <mailto:[email-masked]>
>             To: [email-masked] <mailto:[email-masked]>
>             Subject: I-D Action:
>             draft-muthu-payload-offer-__answer-g723-g729-00.txt
>
>
>             draft-muthu-payload-offer-__answer-g723-g729-00.txt
>             Pages : 8
>             Date : 2012-02-24
>
>             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
>
>             ftp://ftp.ietf.org/internet-__drafts/
>             <ftp://ftp.ietf.org/internet-drafts/>
>
>             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
>
>             _________________________________________________
>             [email-masked] <mailto:[email-masked]>
>             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
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/payload
>         <https://www.ietf.org/mailman/listinfo/payload>
>
>
>
>     --
>     Kevin P. Fleming
>     Jabber: [email-masked] <mailto:[email-masked]> | SIP:
>     [email-masked] <mailto:[email-masked]> | Skype: kpfleming
>     Check us out at www.digium.com <http://www.digium.com> &
>     www.asterisk.org <http://www.asterisk.org>
>     _________________________________________________
>     payload mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/payload
>     <https://www.ietf.org/mailman/listinfo/payload>
>
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 28 Feb 2012 13:10:38 -0600

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

---

From: "Chhatwal, Harprit S" <[email-masked]>
Date: Tue, 28 Feb 2012 20:58:16 +0000

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 <[email-masked]> wrote:

> 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
>>
>>> 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>
>>> >
>>>
>>> <mailto:i-d-announce-bounces@**ietf.org <[email-masked]>>
>>> [mailto:i-d-announce-bounces@_**_ietf.org
>>> <mailto:i-d-announce-bounces@**ietf.org <[email-masked]>>]
>>> On Behalf Of
>>> [email-masked] <mailto:internet-drafts@ietf.**org<[email-masked]>
>>> >
>>> draft-muthu-payload-offer-__**answer-g723-g729-00.txt
>>>
>>>
>>> draft-muthu-payload-offer-__**answer-g723-g729-00.txt
>>> Pages : 8
>>> Date : 2012-02-24
>>>
>>> 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-**
>>> 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/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-**
>>> ______________________________**___________________
>>> 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>
>>> >
>>> 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
>>> 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
>>> ______________________________**___________________
>>> payload mailing list
>>> 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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 28 Feb 2012 15:01:23 -0600

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 <[email-masked]
>     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 28 February 2012 16:54, Kevin P. Fleming
>             <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>             wrote:
>
>             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>>
>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>
>             [mailto:i-d-announce-bounces@
>             <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>] On Behalf Of
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             Subject: I-D Action:
>             draft-muthu-payload-offer-____answer-g723-g729-00.txt
>
>
>             draft-muthu-payload-offer-____answer-g723-g729-00.txt
>             Pages : 8
>             Date : 2012-02-24
>
>             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
>
>             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/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
>
>             ___________________________________________________
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             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>>
>             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
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             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
>             Jabber: [email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>> | SIP:
>             [email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             | Skype: kpfleming
>             Check us out at www.digium.com <http://www.digium.com>
>             <http://www.digium.com> &
>             <http://www.asterisk.org>
>             ___________________________________________________
>             payload mailing list
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             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

---

From: "Chhatwal, Harprit S" <[email-masked]>
Date: Wed, 29 Feb 2012 14:34:34 +0000

On 28 February 2012 21:01, Kevin P. Fleming <[email-masked]> wrote:

> 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 <[email-masked]> wrote:

> 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
>>
>>            <mailto:[email-masked] <mailto:[email-masked]>>**>
>>
>>            wrote:
>>
>>            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>
>> >>
>>
>>            specified in an answer, then it will default to yes, even if
>> the
>>            offer
>>            contained "no".
>>
>>            I guess my preference is to make (2) normative for the
>> answerer,
>>            while
>>            <mailto:i-d-announce-bounces@**ietf.org<[email-masked]>
>> >
>>            <mailto:i-d-announce-bounces@_**_ietf.org
>>            <mailto:i-d-announce-bounces@**ietf.org<[email-masked]>
>> >>
>>            <mailto:i-d-announce-bounces@>**____ietf.org <http://ietf.org>
>>            <mailto:i-d-announce-bounces@_**_ietf.org
>>            <mailto:i-d-announce-bounces@**ietf.org<[email-masked]>>>]
>> On Behalf Of
>>            <mailto:[email-masked]**_org
>>
>>            <mailto:internet-drafts@ietf.**org <[email-masked]>
>> >>
>>            <mailto:[email-masked] <mailto:[email-masked]>**
>> >
>>            Subject: I-D Action:
>>            draft-muthu-payload-offer-____**answer-g723-g729-00.txt
>>
>>
>>
>>            draft-muthu-payload-offer-____**answer-g723-g729-00.txt
>>
>>            Pages : 8
>>            Date : 2012-02-24
>>
>>            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>
>>            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/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>
>>            ______________________________**_____________________
>>
>>            <mailto:[email-masked] <mailto:[email-masked]>**
>> >
>>            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>
>>            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>
>>            ______________________________**_____________________
>>
>>            payload mailing list
>>            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>
>>            ______________________________**_____________________
>>
>>            payload mailing list
>>            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>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Feb 2012 10:31:15 -0500

On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote:
> On 28 February 2012 21:01, Kevin P. Fleming <[email-masked]
>     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).
>

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 <[email-masked]
>     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
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>                 In my comments on the draft I was not questioning the
>         assumption
>                 of that
>                 *If* you accept that assumption then my comments
>         hopefully make
>                 sense.
>
>                 declarative, then that needs to be settled first, before
>         nailing
>                 down
>                 Not being a codec person, I don't know what the common
>         practice
>                 is here.
>                     First of all, from RFC3264, I agree with you that
>         for things
>                     like IP
>                     indicates the address/port/PT/ptime that the sender
>         would
>                     like to
>                     parameters. For instance, for codecs (again from
>         RFC3264),
>                     the codec(s)
>                     included in an SDP offer indicates the codec(s) the
>         offerer
>                     is willing
>                     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
>                     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’ :
>
>                     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
>
>                     acceptable for each agent to use different values.
>         In that
>                     case, the
>
>                     To me, ‘annexb’ is more like a parameter in this
>         sense and,
>                     in this
>                     doesn’t say whether it can be used asymmetrically
>         (or how).
>                     The only
>                     The list of media formats for each media stream
>         conveys two
>                     pieces of
>
>                     So, this appears to be lumping codec parameters with
>         codecs
>                     and so both
>                     indicating ‘annexb=no’ indicates that the sender of
>         this SDP
>                     is willing
>                     this, if the offerer sends ‘annexb=yes’ in the offer
>         and the
>                     answerer
>                     send a re-INVITE with ‘annexb=no’ to resolve the
>         conflict.
>                     According to
>                     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
>
>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>__>
>
>                     wrote:
>
>                     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>>>
>
>                     The fundamental point is that RFC4856 specifies a
>         *default*
>                     value of
>                     specified in an answer, then it will default to yes,
>         even if the
>                     offer
>                     contained "no".
>
>                     default, at least when used with O/A. Instead
>         specify the
>                     defaulting
>                     offer contained "no", but allow the answer to
>         *implicitly*
>                     contain
>                     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
>                     that endpoint is *prepared to accept*, and has
>         nothing at
>                     all to do
>                     2) If an offer/answer contains 'annexb=yes', the
>         receiver of
>                     that
>                     independent of the value (if any) present in the
>         offer it is
>                     answering.
>
>
>                     Thanks,
>                     Paul
>
>                     Muthu
>
>         <mailto:i-d-announce-bounces@
>         <mailto:[email-masked]>>>
>         <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:[email-masked]>>>] On Behalf Of
>         <mailto:internet-drafts@ietf. <mailto:internet-drafts@ietf.>____org
>
>         <mailto:[email-masked]>>>
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__>
>                     Subject: I-D Action:
>                     draft-muthu-payload-offer-______answer-g723-g729-00.txt
>
>
>
>                     draft-muthu-payload-offer-______answer-g723-g729-00.txt
>
>                     Pages : 8
>                     Date : 2012-02-24
>
>         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
>
>         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/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
>
>                     _____________________________________________________
>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__>
>         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>>>
>         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>>>
>
>
>                     _____________________________________________________
>
>                     payload mailing list
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         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
>                     Jabber: [email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> | SIP:
>         <mailto:[email-masked] <mailto:[email-masked]>
>                     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
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         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
>         <mailto:[email-masked] <mailto:[email-masked]>> |
>         Skype: kpfleming
>
>         www.asterisk.org <http://www.asterisk.org> <http://www.asterisk.org>
>
>
>
>
>     --
>     Kevin P. Fleming

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 1 Mar 2012 06:13:05 +0000

Hi Harpit,

Thanks for looking into the draft. I agree with you that asymmetric annexb negotiation is not taken into the account in the draft currently. In fact, I come across the scenario wherein annexb is not supported by offerer ,mentioned in offer SDP as annexb=no and answerer assumes about annexb support (no annexb parameter in answer) in offerer side which leads to the call failure. 

I'm not very clear on the bandwidth optimization based on asymmetric annexb parameter negotiation. Could you please elaborate.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Paul Kyzivat
>Sent: Wednesday, February 29, 2012 9:01 PM
>To: Chhatwal, Harprit S
>Cc: [email-masked]
>Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-
>g723-g729-00.txt
>
>> 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.
>
>>         Speaking as a codec person :-), I think the draft does address
>a
>>         real
>>         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
>>                 But if there is debate regarding whether the parameter
>is
>>                 negotiated or
>>                 So I'm going to let those that have the knowledge
>argue
>>         that.
>>
>>
>>             Correct on all points; your comments make complete sense
>if
>>         'annexb'
>>             I'm not a codec person (although I'd probably be willing
>to
>>         play one
>>             codec/format parameters that are declarative already that
>I
>>         don't
>>             using Annex B or not is purely on one direction of the
>media
>>         stream,
>>             implementation that cannot accept incoming SID frames
>would
>>         also be
>>                     addresses, ports, payload types, ptime, the SDP
>that one
>>                     party sends
>>                     receive on. However, I don't believe this is
>generally
>>                     correct for all
>>                     to send AND receive (if the directional attribute
>is
>>                     'sendrecv'). As an
>>                     'annexb' :
>>                     parameters. In many cases, those parameters
>describe
>>         specific
>>
>>                     the media format they describe is present in the
>answer.
>>                     Other fmtp
>>
>>                     parameters are more like parameters, for which it
>is
>>         perfectly
>>
>>                     extensions that define new parameters SHOULD
>specify
>>         the proper
>>
>>                     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
>>                     information, namely the set of formats (codecs and
>any
>>                     parameters
>>
>>                     associated with the codec, in the case of RTP)
>that the
>>                     offerer is
>>
>>                     ...For a sendrecv stream, the offer SHOULD
>indicate
>>         those
>>
>>                     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
>>                     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
>>                     We have a couple of open items in the I-D. We
>expect
>>         the WG
>>                     discussions
>>                     1) revise the IANA registration for annexa and
>annexb to
>>                     remove the
>>                     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
>>                     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
>>                     offer/answer MUST NOT send G.729 Annex B SID
>frames
>>         to the
>>                     not describe the offerer and answerer behavior
>when the
>>                     value of the
>>                     annexa or annexb parameter does not match in the
>SDP
>>         offer and