[asterisk-bugs] [Asterisk 0017843]: DTMF Manager events missing with some codecs on bridged SIP calls

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Aug 11 14:43:02 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17843 
====================================================================== 
Reported By:                bklang
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17843
Category:                   Channels/chan_sip/CodecHandling
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.8.0-beta3 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-08-11 13:34 CDT
Last Modified:              2010-08-11 14:43 CDT
====================================================================== 
Summary:                    DTMF Manager events missing with some codecs on
bridged SIP calls
Description: 
I am placing calls from a SIP client endpoint (tested with various hard and
soft phones) calling to Asterisk via SIP.  Once connected to Asterisk the
caller makes choices that then sends a call out via a different SIP peer
(an outbound proxy in this case).

The endpoints and the outbound proxy are both configured to use
dtmfmode=rfc2833, a fact I can confirm by looking at packet captures and
Asterisk console output.  Enabling RTP debugging also shows the DTMF being
processed.  In addition, both the endpoints and the peer are configured
with canreinvite=no, forcing Asterisk to stay in the media path.  I have
confirmed this as well with RTP debugging.

When a call comes in from the endpoint the DTMF is working properly to
collect the destination phone number.  Each digit that is entered by the
user triggers the appropriate DTMF event on the AMI socket.  Next the call
is placed outbound via the proxy.  As soon as the call is bridged DTMF
events on AMI cease.  The RTP continues to work end-to-end and the DTMF is
received by the far end.  The only thing that appears to be broken is that
AMI events are not sent to my AMI listener.

The strange thing is that events DO work as expected, even when bridged,
when I use GSM or uLaw.  When using aLaw no events are sent by AMI once the
calls are bridged. 

This has been tested with 1.6.1.11 and 1.8.0-beta3 with the same behavior
observed.
====================================================================== 

---------------------------------------------------------------------- 
 (0125852) gamedna (reporter) - 2010-08-11 14:43
 https://issues.asterisk.org/view.php?id=17843#c125852 
---------------------------------------------------------------------- 
Created a simple test setup, and I confirm the above behavior using the
following configuration:

Zoiper SIP -> BOX A -> IAX or SIP TRUNK -> BOX B

AMI DTMF Events are produced when using ulaw or gsm on all devices.  When
configured for alaw, the AMI DTMF events are no longer produced on Box B. 
RFC 2833 DTMF events are visible on Wireshark from both Zoiper->Box A and
Box A->Box B

Asterisk versions: 
BOX A: Asterisk SVN-trunk-r280910 built by nick @ NickMAC.local on a i386
running Darwin on 2010-08-05 09:02:54 UTC

BOX B: Asterisk 1.6.0.26-FONCORE-r78 built by root @ revisor.trixbox.com
on a i686 running Linux on 2010-06-08 22:01:27 UTC 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-11 14:43 gamedna        Note Added: 0125852                          
======================================================================




More information about the asterisk-bugs mailing list