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

Michael Maier m1278468 at allmail.net
Mon Jan 30 04:13:28 CST 2017


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


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.


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!



Thanks,
kind regards,
Michael Maier


[1]
https://issues.asterisk.org/jira/browse/ASTERISK-26736



More information about the asterisk-dev mailing list