[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

Fri Feb 20 14:18:41 CST 2009

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14283 
====================================================================== 
Reported By:                jcovert
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   14283
Category:                   Channels/chan_iax2
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
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:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-01-20 01:25 CST
Last Modified:              2009-02-20 14:18 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0100467) svnbot (reporter) - 2009-02-20 14:18
 http://bugs.digium.com/view.php?id=14283#c100467 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 177697

_U  trunk/

------------------------------------------------------------------------
r177697 | dvossel | 2009-02-20 14:18:41 -0600 (Fri, 20 Feb 2009) | 13
lines

Blocked revisions 177696 via svnmerge

........
  r177696 | dvossel | 2009-02-20 14:17:37 -0600 (Fri, 20 Feb 2009) | 8
lines

  Fixes issue with undefined audio codecs in chan_iax2

  During iax2 call negotiation, supported codecs are passed in an
Information Element containing a 2 byte field where each bit correlates to
a specific codec.  In 1.4 only audio codec bits 0-12 are defined, leaving
bits 13-15 undefined.  By default all bits are enabled unless specified
otherwise.  Since its a 2 byte field and 13-15 are not defined, these bits
are never turned off.  In trunk, bits 13-15 are defined, which means 1.4 is
advertising support for codecs it does not have when talking to trunk.  I
fixed this by adding #define for undefined audio codec bits.  These bits
are then removed from iax2's full bandwidth capabilities.   

  (closes issue http://bugs.digium.com/view.php?id=14283)
  Reported by: jcovert
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=177697 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-20 14:18 svnbot         Checkin                                      
2009-02-20 14:18 svnbot         Note Added: 0100467                          
======================================================================