[asterisk-bugs] [Asterisk 0012608]: Always transcoding G729 so slin

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12608 
====================================================================== 
Reported By:                Delvar
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12608
Category:                   Codecs/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.19 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-08-2008 05:04 CDT
Last Modified:              05-08-2008 10:35 CDT
====================================================================== 
Summary:                    Always transcoding G729 so slin
Description: 
Im using asterisk 1.4.19 and have noticed that when a user agent is using a
codec other than alaw/ulaw it ends up transcoding to slin for both channels
even though both legs of the call are the same codec.
this is most promemnet when using G729 because it uses 2 licances per
call.
below is a sample call to our sip provider and the show channels for each
channel.
in 1.2 we didn't have this issue.
====================================================================== 

---------------------------------------------------------------------- 
 Delvar - 05-08-08 10:35  
---------------------------------------------------------------------- 
nope.. the dialplan is
[msg-test-001]
exten => _X.,1,Dial(SIP/pstn-provider/${EXTEN})

but looking into it, the PSTN provider doesnt support RFC2833, and looking
at the sip.conf comments when dtmfmode=auto if the far end doesnt support
rfc2833 then it fails back to inband.

would this cause the extra transcoding seen here?, if so then ill chase up
the provider and see about fixing it :) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-08-08 10:35  Delvar         Note Added: 0086610                          
======================================================================