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

[Matt Fredrickson]

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.

> Example:
>
> Configuration of asterisk:
>
> extension: g722,alaw,ulaw
> trunk: g722,alaw,ulaw
>
> Today's behavior w/ pjsip:
>
> *Incoming* call from provider to asterisk
> INVITE from provider contains alaw.
> INVITE from asterisk to extension contains g722,alaw,ulaw
> OK 200 SDP from extension to asterisk contains g722
> OK 200 SDP to provider contains alaw
>
> Result: asterisk has to transcode between extension and provider,
> because it has to use alaw to provider and extension uses g722
> (extension chooses the primary codec of the list in initial INVITE).
>
>
> *Outgoing* call from extension to provider
> INVITE from extension to asterisk contains g722,alaw,ulaw.
> INVITE from asterisk to provider contains g722,alaw,ulaw.
> OK 200 SDP from provider to asterisk contains alaw.
> OK 200 SDP from asterisk to extension contains g722,alaw,ulaw.
>
> Result: asterisk has to transcode between extension and provider,
> because it has to use alaw to provider and extension uses g722 (the
> primary codec of the list in 200 OK SDP).
>
>
> Both transcode actions above are completely unnecessary, because both
> UAs would be able to use a common codec!
>
>
> Preferred behavior:
>
> *Incoming* call from provider to asterisk
> INVITE from provider contains alaw.
> INVITE from asterisk to extension contains alaw
> OK 200 SDP from extension to asterisk contains alaw
> OK 200 SDP to provider contains alaw
>
> Result: no transcoding is necessary. Quality of call isn't harmed
> unnecessarily! No unnecessary CPU load.
> BTW: That's the way it already works with chan_sip!
>
>
> *Outgoing* call from extension to provider
> INVITE from extension to asterisk contains g722,alaw,ulaw.
> INVITE from asterisk to provider contains g722,alaw,ulaw.
> OK 200 SDP from provider to asterisk contains alaw.
> OK 200 SDP from asterisk to extension contains alaw.
>
>
> Result: no transcoding is necessary. Quality of call isn't harmed
> unnecessarily! No unnecessary CPU load.
>
>
> I would be really glad to have this intelligent codec handling w/
> asterisk / pjsip!

I think we would love to see some work in this area as well.  I'm not
aware of anybody working on it right now, but if you'd like to help
out with adding this feature, I know that there are a number of other
people beside yourself that would be glad to see it.

-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA