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

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

[Resending as my previous message exceeded 120 KB and got blocked]

 

Thanks for everyone's inputs..

 

Asymmetric bandwidth is typical for DSL links I think, where the
downstream bandwidth is typically higher compared to the upstream
bandwidth. So, while a user may want to receive HD quality video, the
user may want send only SD quality video because of the upstream
bandwidth constraints.

 

However, I agree that the problem of asymmetric codec negotiation is a
more general O/A problem and needs to be solved more generically before
applying it for specific codecs.

 

For G.723/G.729, the source of the interop issue is not asymmetric
behavior. Instead, even when both ends want symmetric behavior, one end
considers the Annex B (or Annex A) flavor of the codec as incompatible
with the non-Annex B (or non-Annex A) flavor of the same codec, while
the other end expects the least common denominator to be used.

 

Describing the symmetric behavior for these codecs unambiguously (which
is what the draft tries to do) would help implementers achieve pragmatic
end results I think.

 

Muthu

 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of David R Oran
Sent: Thursday, March 08, 2012 7:34 PM
To: Chhatwal, Harprit S
Cc: [e-mail]
Subject: Re: [payload] FW: I-D
Action:draft-muthu-payload-offer-answer-g723-g729-00.txt

 

 

On Mar 8, 2012, at 8:13 AM, Chhatwal, Harprit S wrote:





	I didn't fully understand your network. My guess is that  in
case of bandwidth constrained in one direction of the session, then the
low-bandwidth codec has to be negotiated in that direction. ISTM,
asymmetric annexb parameter negotiation is not going to solve the
bandwidth issue. Please let me know how asymmetric annexb will solve
bandwidth issue. 

 

Perhaps I have not explained this clearly enough previously, so allow me
to try again.  The bandwidth in the customer's network is sufficiently
constrained in one direction that the customer wishes to use
G.729/G.729A with G.729B active (ie using VAD/DTX) to allow the speech
codec bandwidth requirements in this direction to fit within the network
bandwidth envelope. In the other direction, the network bandwidth
available is somewhat less constrained, so the customer would like to
use G.729/G.729A without G.729B active to get slightly better quality.  

Well, even if you've negotiated it, it doesn't mean you actually have to
use it. If the endpoint is smart enough to know whether to negotiate it
or not, I suspect it's smart enough to know not to bother using it when
the bandwidth is sufficient.

 

Seems like a corner case, although the general problem of how to do
asymmetric codec negotiation probably has more compelling use cases.





However, even in this direction, the network bandwidth is still limited
enough that a higher-rate codec such as G.711 will not work.

 

For the second part of your question, please see the earlier mails on
this thread as this has been covered previously.

 

Regards.  Harprit.

 

Harprit S. Chhatwal

InnoMedia

 

On 8 March 2012 10:12, Ravindran, Parthasarathi
<[e-mail]> wrote:

Hi Harpit,

 

Sorry for the delay reply.

 

I didn't fully understand your network. My guess is that  in case of
bandwidth constrained in one direction of the session, then the
low-bandwidth codec has to be negotiated in that direction. ISTM,
asymmetric annexb parameter negotiation is not going to solve the
bandwidth issue. Please let me know how asymmetric annexb will solve
bandwidth issue.

 

AFAIK, answerer expectation of asymmetric annexb will leads to the
interop issue in case of offerer mentions as "annexb=no" but answerer
mandates to have "annexb=yes".  Please let me know your opinion on the
same.

Thanks
Partha

 From: Chhatwal, Harprit S [mailto:[e-mail]] 
Sent: Thursday, March 01, 2012 4:59 PM
To: Ravindran, Parthasarathi
Cc: Paul Kyzivat; Kevin P. Fleming; [e-mail]


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

 

 

On 1 March 2012 06:13, Ravindran, Parthasarathi
<[e-mail]> wrote:

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

 

This is for a network where the bandwidth is severely constrained in one
direction, so the operator wishes to use G.729B to minimise bandwidth
usage in one direction, while not using G.729B in the other direction
where bandwidth is less constrained.

 

Regards.  Harprit.

 

Harprit S. Chhatwal

InnoMedia

 

On 1 March 2012 06:13, Ravindran, Parthasarathi
<[e-mail]> wrote:

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


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Paul Kyzivat
>Sent: Wednesday, February 29, 2012 9:01 PM
>To: Chhatwal, Harprit S
>Cc: [e-mail]
>Subject: Re: [payload] FW: I-D Action:
draft-muthu-payload-offer-answer-
>g723-g729-00.txt
>
>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.
>>
>>