[asterisk-bugs] [Asterisk 0018611]: inband DTMF cannot be detected and trigger service execute when A and B both use u-law (the same codec)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18611 
====================================================================== 
Reported By:                shihchuan
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18611
Category:                   Core/RTP
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.8.1.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-01-13 05:04 CST
Last Modified:              2011-01-14 05:06 CST
====================================================================== 
Summary:                    inband DTMF cannot be detected and trigger service
execute when A and B both use u-law (the same codec)
Description: 
1. A and B both use the same codec (u-law, a-law).
When A enter *96(transfer feature key), transfer service don't be executed
but B hear dtmf tone.

2. If A and B use different codec.(A use u-law, B use a-law) 
When A enter *96(transfer feature key), transfer sevice is executed.

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

---------------------------------------------------------------------- 
 (0130489) davidw (reporter) - 2011-01-14 05:06
 https://issues.asterisk.org/view.php?id=18611#c130489 
---------------------------------------------------------------------- 
You need to provide the SIP(?) debug output, so one can tell whether the
problem is that the call is being erroneously externally bridged, and more
generally, the nature of the bridge being created.

More generally, it is generally better to include the actual debug output
in a report, rather than a interpretation that it shows nothing. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-14 05:06 davidw         Note Added: 0130489                          
======================================================================