[asterisk-dev] Wish: adding intelligent codec negotiation to asterisk / pjsip

Mon Jan 30 16:44:14 CST 2017

On Mon, Jan 30, 2017 at 3:32 PM, Matthew Jordan <mjordan at digium.com> wrote:

>
>
> On Mon, Jan 30, 2017 at 3:22 PM, Matt Fredrickson <creslin at digium.com>
> wrote:
>
>> Hey Michael,
>>
>> First off, thanks for taking the time to express some of your thoughts
>> and concerns to the asterisk-dev list.  I'll keep my reply to your
>> email inline below.
>>
>> On Mon, Jan 30, 2017 at 4:13 AM, Michael Maier <m1278468 at allmail.net>
>> wrote:
>> > Dear developers,
>> >
>> > I've been redirected to this mailing list by Joshua Colp during fixing a
>> > one way audio bug[1] to discuss another solution as provided in the fix.
>> >
>> > Background:
>> > - A lot of people complain about bad VoIP call quality compared to the
>> > old POTS / ISDN devices. What do they mean from a technical point of
>> > view: High latencies (resulting in echo), digital sound because of "bad"
>> > codecs, general quality loss during transcoding and many other reasons
>> more.
>> > - In Europe, HD audio is being adopted slowly. This means, more and more
>> > UAs can natively handle HD codecs like g722. But they must be downward
>> > compatible at the same time for older UAs, which just speak alaw (like
>> > the old POTS devices e.g. or UAs which are not yet HD capable).
>> > Therefore, they advertise at least two codecs: g722 and alaw (mostly
>> > plus some more like ulaw or some other codecs).
>>
>> So there are multiple reasons why you could be seeing reportedly bad
>> call quality that come to my mind:
>>
>> 1. Transcoding - changes the audio, but typically doesn't make things
>> sound *too* bad.  Obviously it is codec dependent as to how bad it
>> sounds afterwards, but most modern codecs aren't terrible for speech
>> replication and encoding.  Usually this is not where call quality
>> problems are noticed.
>>
>> 2. Packet loss and jitter related problems.  In an ISDN network, there
>> is a guaranteed real time audio channel for transporting media.  As
>> long as the data pumps on the transmit and receive side are working
>> properly, you should hear almost no audio quality issues.  VoIP tries
>> to transport real time audio over a non-guaranteed transport channel.
>> This sometimes causes bad audio quality issues due to packet loss,
>> packet reordering, or extreme packet delays.  Enabling Asterisk's
>> jitter buffers typically improves many problems that arise due to
>> this.  They are typically *not* enabled by default and so must be
>> explicitly enabled.
>>
>> I'm hoping you already have dived into your problem to look at both
>> the above elements, and have confirmed that you are not dealing with
>> the second problem instead of voice mutation due to the first problem.
>> Usually you can track the second problem by doing packet captures of
>> the voice conversations in question as well as look at RTCP
>> statistics.
>>
>> > What does this mean to Asterisk?
>> > My conviction is, that Asterisk shouldn't make things even worse when
>> > handling calls / codecs by forcing unnecessary transcoding, which
>> > unnecessarily harms call quality. Next point of unnecessary transcoding:
>> > it unnecessarily steals system resources from the machine asterisk is
>> > running on.
>> > Asterisk should harm each call it handles and the underlying machine as
>> > little as possible.
>> >
>> > Therefore I would like to see a (switchable) feature, that asterisk /
>> > pjsip always tries to primarily advertise codecs, which are supported by
>> > both UAs and remove those codecs, which are not supported by one of the
>> > UAs. This prevents unnecessary transcoding.
>>
>> This actually would be a really neat thing for Asterisk to be able to
>> do.  Last time I looked at it, there are quite a few challenges in
>> making it happen.  Asterisk is designed to be a back to back user
>> agent, and it inherently is designed to terminate media and codecs
>> individually with each leg in question, but not necessarily together.
>> It "makes things work" on each leg separately, based on the allowed
>> codecs for each endpoint.
>>
>> This is a needful behavior since many times an Answer() has already
>> occurred and negotiated the codec capabilities for a call and most
>> dial plan applications assume a call needs to have media fully
>> negotiated in order to interact on the channel.
>>
>> For the simple case where your dial plan doesn't do any intense media
>> interaction with a channel and simply Dial()'s out, a significant
>> portion that doesn't work right now is that the codec information from
>> the 200 OK received from the outbound channel is not passed back
>> through to the inbound channel - I'm assuming that's what you're
>> referring to.  Hopefully Josh or Mark will correct me if my memory is
>> off.
>>
>>
> We've looked at doing this several times.
>
> The last time I gave that a shot I more or less had it working, and then
> broke myself (and my patch) on the rocks of Local channels. Trying to get
> Local channel chains to respect the codecs down a chain (generally 3+ is
> enough to trip errors) is a non-trivial operation. When setting up the call
> you more or less can control the situation - the codec preferences are
> passed down the chain via ast_request. However, when things are coming back
> in the other direction, you don't have an easy reference to the channel
> that created you. It can involve reaching across bridges and local channel
> bridges, which is dangerous. Both are prone to error and deadlocks. Holding
> a reference to your creator isn't safe, as the creator can be masqueraded
> away (in really weird situations). The other option is to pass the
> information down in a frame, but now you can't guarantee much, as that's an
> asynchronous operation.
>
> In transcoding situations, you also have to pick where in that chain you
> choose to do transcoding - which is not always easy to figure out.
>
> Things get challenging as well when you have a multi-party bridge involved
> at all - either when a dialed party has to be placed into a multi-party
> bridge or when you have a chain of Local channels dialing someone and the
> far end of the Local channel chain is already in a multi-party bridge.
>
> Generally, this is an architectural limitation of Asterisk that - while
> not impossible to craft a solution for - is far harder than it may seem
> when you're only thinking of two-party calling with non-Local channels.
>

How hard do you think it would it be to limit the attempt to the 90% use
case of a call coming in on one channel and causing an originate going out
on another channel?  Simple PBX scenarios?  No answer in the middle, no
early media, etc.

>
> --
> Matthew Jordan
> Digium, Inc. | CTO
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> --
> _____________________________________________________________________
> -- 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
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170130/dc71c9be/attachment-0001.html>