[asterisk-dev] Advanced Codec Negotiation: Asymmetric Codecs

Tue Jun 16 15:36:08 CDT 2020

On Tue, Jun 16, 2020 at 2:02 PM Joshua Elson <joshelson at gmail.com> wrote:

> 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.
>
>
>
Oh yeah, it's "legal" and a non issue if you're an endpoint.  It's a whole
different story when you're a Back-to-Back UA like Asterisk though. :)
And yeah..  I saw that contradictory statement as well.

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

Fair enough.

>
> 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"?
>

Instead of "broken", how about "weird"?  :)  In this case, if Bob responds
with g722, ulaw,alaw in that order in the answer but starts sending alaw,
that's "legal" but "weird".  If he didn't like g722 or ulaw then he
shouldn't have included it in the answer and if he preferred alaw, that
should have been the first codec in the answer "m" line.  It gets even more
complicated for a B2B-UA if Bob starts sending media _before_ the SDP
answer.   We would _like_ to send Alice an SDP answer where the first codec
matches the media she's already getting or will be getting.

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

Let's see how things go.

>
> Hope that helps muddy the water!
>

Heh, just wait until we start in on Direct Media. :)

>
> 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
>
> --
> _____________________________________________________________________
> -- 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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200616/75d83a67/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/75d83a67/attachment-0001.png>