[asterisk-bugs] [Asterisk 0014283]: Codec negotiation fails on calls from 1.2 -> 1.6, and is sub-optimum on calls from 1.6->1.6
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Jan 20 01:25:32 CST 2009
The following issue has been SUBMITTED.
======================================================================
http://bugs.digium.com/view.php?id=14283
======================================================================
Reported By: jcovert
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14283
Category: Channels/chan_iax2
Reproducibility: always
Severity: major
Priority: normal
Status: new
Asterisk Version: 1.6.0.3
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-01-20 01:25 CST
Last Modified: 2009-01-20 01:25 CST
======================================================================
Summary: Codec negotiation fails on calls from 1.2 -> 1.6,
and is sub-optimum on calls from 1.6->1.6
Description:
http://bugs.digium.com/view.php?id=1 is a major problem, although there is a
work-around.
http://bugs.digium.com/view.php?id=2 is minor.
(1) Given a 1.2 system with the following codec settings:
disallow=all ; Dis-Allow all codecs
;
allow=ULAW ; except for this list of Codecs
allow=ALAW
allow=GSM
allow=G726
allow=ADPCM
allow=LPC10
allow=SPEEX
allow=ILBC
and a 1.6 system with
allow=g722
allow=ulaw
allow=alaw
allow=G726
disallow=adpcm ; Horrid. --jrc
disallow=lpc10 ; Icky sound quality... Mr. Roboto.
allow=gsm ; Always allow GSM, it's cool :)
allow=iLBC ; if it's all they've got
And the default codecpriority = host setting,
we see the following on a call from 1.2 -> 1.6 :
-- Accepting UNAUTHENTICATED call from 12.237.35.32:
> requested format = ulaw,
> requested prefs = (ulaw|alaw|gsm|g726|adpcm|lpc10|speex|ilbc),
> actual format = g722,
> host prefs = (g722|ulaw|alaw|g726|gsm|ilbc),
> priority = mine
But since 1.2 can't do G.722, we end up with no audio, and a stream of the
following messages:
[Jan 20 00:04:25] NOTICE[13875]: channel.c:2714 __ast_read: Dropping
incompatible voice frame on IAX2/12.237.35.32:4569-6213 of format ulaw
since our native format has changed to 0x1000 (g722)
(2) If the call comes from a device on a 1.6 system which can do ulaw but
not G.722, and this system has "bandwidth=high" set to accomodate ulaw and
"allow=ulaw,allow=gsm" but does not include g.722 because it has no g.722
clients, when it connects to the 1.6 system in (1) above, we see
-- Hungup 'IAX2/jrclaptop-14482'
-- Accepting AUTHENTICATED call from 192.168.0.4:
> requested format = ulaw,
> requested prefs = (ulaw|gsm),
> actual format = g722,
> host prefs = (g722|ulaw|alaw|g726|gsm|ilbc),
> priority = mine
and as a result, we do a lot of unecessary transcoding.
The workaround given only these two cases is to set codecpriority to
caller or to reqonly, but there are obviously other cases where these will
cause problems.
It seems that the default "host" priority should (as it says) give
priority to the host's codec, but not if that codec is not in the requested
list at all. If the host's first priority was not one of the requested
codecs, but the host's second (or third) priority is one of the requested,
we should take that.
Maybe this needs to be a different option, but as it stands, unless the
requesting host explicitly disallows the receiving host's choice (which the
disallow=all in 1.2 unfortunately does not do) we end up with something not
at all requested (and possibly not supported) by the originator.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2009-01-20 01:25 jcovert New Issue
2009-01-20 01:25 jcovert Asterisk Version => 1.6.0.3
2009-01-20 01:25 jcovert Regression => No
2009-01-20 01:25 jcovert SVN Branch (only for SVN checkouts, not tarball
releases) => N/A
======================================================================
More information about the asterisk-bugs
mailing list