[asterisk-bugs] [Asterisk 0010500]: [patch] teach chan_iax2 to offer the calling channel's codec first, like chan_sip does it

noreply at bugs.digium.com noreply at bugs.digium.com
Thu Oct 11 02:24:05 CDT 2007


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10500 
====================================================================== 
Reported By:                stevedavies
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10500
Category:                   Channels/chan_iax2
Reproducibility:            N/A
Severity:                   minor
Priority:                   normal
Status:                     ready for testing
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 80048 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-20-2007 11:24 CDT
Last Modified:              10-11-2007 02:24 CDT
====================================================================== 
Summary:                    [patch] teach chan_iax2 to offer the calling
channel's codec first, like chan_sip does it
Description: 
We discussed this issue on asterisk-dev under the title "IAX codec
selection".

Currently, outgoing IAX NEW packets contain two codec-related IEs. 
"FORMAT" will contain the format bits for the calling channel.  CODEC_PREFS
is a list of codecs allowed, taken as-is from the allow= of the peer.

Now it is preferable not to transcode - so it makes sense that the calling
channel's codec should be moved first in the CODEC_PREFS list (provided
that it is one of the allowed codecs).  

This is what chan_sip does.

So this patch brings that behaviour to IAX.

As a demonstration of the issue, here's a peer:

[xxxx]
type=friend
host=xxx.co.za
username=us
secret=ourpass
trunk=no
notransfer=yes
transfer=no
context=from-peer-xxxx
disallow=all
allow=alaw
allow=ulaw
allow=g729
allow=ilbc
allow=gsm
allow=speex
qualify=500
qualifysmoothing=yes

Now we send a call to this peer from a phone using iLBC.  chan_iax2 as was
sends this NEW:

Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass:
NEW
Timestamp: 00017ms  SCall: 00001  DCall: 00000 [A.B.C.D:4569]
VERSION         : 2
CALLED NUMBER   : 082XXXXXXX
CODEC_PREFS     : (alaw|ulaw|g729|ilbc|gsm|speex)
CALLING NUMBER  : 021XXXXXXX
CALLING PRESNTN : 35
CALLING TYPEOFN : 0
CALLING TRANSIT : 0
CALLING NAME    : Steve Davies
LANGUAGE        : en
USERNAME        : us
FORMAT          : 1024
CAPABILITY      : 59150
ADSICPE         : 2
DATE TIME       : 2007-08-15  10:18:02

So even though ILBC is the current codec, the CODEC_PREFS has ALAW first.

After my patch, the NEW is:

Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW
   
Timestamp: 00016ms  SCall: 00012  DCall: 00000 [A.B.C.D:4569]
VERSION         : 2
CALLED NUMBER   : 082XXXXXXX
CODEC_PREFS     : (ilbc|alaw|ulaw|g729|gsm|speex)
CALLING NUMBER  : 021XXXXXXX
CALLING PRESNTN : 35
CALLING TYPEOFN : 0
CALLING TRANSIT : 0
CALLING NAME    : Steve Davies
LANGUAGE        : en
USERNAME        : us
FORMAT          : 1024
CAPABILITY      : 59150
ADSICPE         : 2
DATE TIME       : 2007-08-20  18:37:16


====================================================================== 

---------------------------------------------------------------------- 
 pj - 10-11-07 02:24  
---------------------------------------------------------------------- 
OK, but tried anybody this patch with in h323-iax environment?
as I wrote (msg 0071188, 0070248), 
seems that it not working as expected in this case.... 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-11-07 02:24  pj             Note Added: 0071804                          
======================================================================




More information about the asterisk-bugs mailing list