[asterisk-dev] Advanced Codec Negotiation: Asymmetric Codecs

Tue Jun 16 15:01:21 CDT 2020

So I went back all the way to RFC 3264 on these and it's relatively clear
to me from the reading it that different sending and receiving codecs is,
at least strictly speaking, legal:
,

Once the answerer has sent the answer, it MUST be prepared to receive
   media for any recvonly streams described by that answer.  It MUST be
   prepared to send and receive media for any sendrecv streams in the
   answer, and it MAY send media immediately.  The answerer MUST be
   prepared to receive media for recvonly or sendrecv streams using any
   media formats listed for those streams in the answer, and it MAY send
   media immediately. When sending media, it SHOULD use a packetization

   interval equal to the value of the ptime attribute in the offer, if
   any was present.  It SHOULD send media using a bandwidth no higher
   than the value of the bandwidth attribute in the offer, if any was
   present.  The answerer MUST send using a media format in the offer
   that is also listed in the answer, and SHOULD send using the most
   preferred media format in the offer that is also listed in the answer.

In the same RFC section discussing unicast stream negotiation, this
language appears, in more or less direct contradiction:

This helps assure that the same codec is used in
   both directions.

I also agree with the sentiments about this being kind of a weird
situation. As for the necessity of this functionality, I know it's been
desirable for us to avoid transcoding burden in some situations and I could
imagine some weird edge cases where extreme asymmetric send/receive
bandwidth situations could make this kind of functionality desirable. I
don't really think either of those are show-stoppingly major issues, but
someone else might.

The issues you raise on Alice's behavior are also legitimate, and I don't
love the scenarios there with topology changes and reinvites from a
practical point of view.

As for whether this is broken UA behavior, I think that's a conversation
for happy hour beers somewhere, whenever that's allowed again. :) This is
one area where some UA designers have deviated from a strict reading of the
spec and done the thing that makes sense to them and simplifies behavior.
So really, what's the philosophical definition of "broken"?

If the community consensus is that it's not worth maintaining this
functionality, I'm totally fine with eliminating it. We'll just have to do
some planning for how to accommodate the transition.

Hope that helps muddy the water!

Josh

On Mon, Jun 15, 2020 at 1:01 PM George Joseph <gjoseph at digium.com> wrote:

>
>
> On Mon, Jun 15, 2020 at 11:57 AM Joshua Elson <joshelson at gmail.com> wrote:
>
>> So I am the one responsible for this situation, if I recall the
>> discussion a few years back. We actually have had to support several phones
>> - Yealink being the most distinctly memorable - that support asymmetric
>> codecs on a single call leg, and from our reading, it's legal in the RFC.
>> In some very high throughput cases, it was preferable to reduce overall
>> transcoding use in our infrastructure when you did the math on having a few
>> thousand of these phones in the same situation.
>>
>>
> So if we send an offer to Bob (who has one of the phones in question) with
> g722, ulaw, alaw in that order, would Bob respond with an answer in the
> same order but then start sending ulaw for instance?  Or would Bob send an
> answer with uaw, g722, alaw?   The reason I ask is that if they respond
> with g722, ulaw, alaw, then we'll probably also send that back in the
> answer to Alice. If Bob subsequently starts sending ulaw, we _may_ (I have
> to check) simply pass that through to Alice since ulaw was in the final
> topology but Alice's phone might not be prepared to receive media in a
> format other than the first in the answer.  This seems to be common,
> especially if the phone uses the pjproject SIP stack.
>
> Other things to consider...
> Does Alice's asymmetric_codecs setting apply?
> If transcode is "no" would we have to trigger a topology change and do
> re-INVITES?   This could get ugly.
> If transcode is "yes" but Alice's asymmetric_codecs is "no" do we
> transcode in the 1 direction only?
>
> How does this fit with earlier "general" assumptions that Asterisk should
> not be trying to compensate for broken UAs?
>
>
>> That being said, it's conceivable we could live without that option now,
>> and some phone vendors do still not properly implement the RFC standard
>> around this, but we do still run in production with asymmetric codecs on a
>> single call leg for a slight majority of our devices.
>>
>> Josh
>>
>> On Mon, Jun 15, 2020 at 10:42 AM Michael Maier <m1278468 at mailbox.org>
>> wrote:
>>
>>> Hello George,
>>>
>>> in terms of uses cases? I'm not aware of any use case which would need
>>> asymmetric codecs. The opposite is true: my phones can't handle asymmetric
>>> codecs at all - therefore it's
>>> forbidden.
>>>
>>> But I'm not the only one using asterisk - others may have an use case.
>>>
>>>
>>> On 15.06.20 at 01:56 George Joseph wrote:
>>> > Given the earlier discussions, under what conditions is it desirable
>>> to use
>>> > a different codec in one direction than the other on the same call leg?
>>>
>>>
>>> Thanks
>>> Michael
>>>
>>> --
>>> _____________________________________________________________________
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> George Joseph
> Asterisk Software Developer
> direct/fax +1 256 428 6012
> Check us out at www.sangoma.com and www.asterisk.org
> [image: image.png]
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200616/9a4b988c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5142 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200616/9a4b988c/attachment-0001.png>