[Home]

Summary:ASTERISK-17755: DTMF ( RFC2833 or SIP INFO ) sent incorrectly when bridged to a DAHDI channel on remote server.
Reporter:David Lublink (dlublink)Labels:
Date Opened:2011-04-26 12:38:14Date Closed:2011-07-26 14:14:51
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:1.6.2.17 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dtmf-SIP2SIP2Dialplan.pcap
( 1) dtmf-SIP2SIP2Sangoma.pcap
Description:I have two asterisk boxes. The first box dials the second box, the second box's dialplan connects the channel to DAHDI. The first box dials DTMF but are incorrectly transmitted ( whether sent on SIP INFO OR RFC2833 ).

****** ADDITIONAL INFORMATION ******

If the second box plays audio instead of connecting to the DAHDI channel, the DTMF's are transmitted properly.

It would seem that something about the DAHDI channel on the second server is causing the first server to incorrectly transmit the DTMF. The DAHDI channel is connected to a Sangoma A108D card.

This problem can also be reproduced on 1.6.2.5-0ubuntu1.3 and 1.4.17~dfsg-2ubuntu1.1.

It was tested on Asterisk 1.6.2.17.3 on CentOS 5.5.

In every case, if the DAHDI channel is involved, the DTMF is improperly transmitted.

I have tried hard to reduce the complexity of this problem as much as possible.

The two servers are running default configurations unless otherwise noted.

The SIP-only asterisk box has the following differents with default configs :

I removed all the contexts that were not global variables or general and added this :

[default]
exten => 22,1,Dial(SIP/6@74.121.161.163,30,D(132412983#))
exten => 24,1,Dial(SIP/5@74.121.161.163,30,D(132412983#))

Everything else on this server is by default.

On the Asterisk machine with the DAHDI channels,

I added to sip.conf :

[testserver]
host=74.121.161.165
type=friend
context=from-server
dtmfmode = rfc2833

I added to extensions.conf :

[from-server]
exten=>_1X.,1,Dial(DAHDI/g1/${EXTEN:1})
exten=>_2X.,1,Dial(DAHDI/g2/${EXTEN:1})
exten=>_3X.,1,Dial(DAHDI/g3/${EXTEN:1})

exten => 5,1,Dial(DAHDI/g1/14186939930,30)

exten => 6,1,Progress
exten => 6,n,Wait(5)
exten => 6,n,Answer
exten => 6,n,Playback(vm-login&vm-login&vm-login&vm-login&vm-login)
exten => 6,n,Wait(30)

I will add chan_dahdi.conf to the ticket as an attachement.

I added ",dtmf" to the console line in logger.conf on both machines.

Comments:By: David Lublink (dlublink) 2011-04-26 12:45:40

If you look at the two pcap files, you can see the two tests I made. They correspond to "console dial 22" and "console dial 24" on the sip only asterisk machine.

The DTMF sequence should be the same in both cases, but is not. Notice that duration of some of the DTMFs in the second PCAP file.
By: David Lublink (dlublink) 2011-04-26 12:47:39

I am currently working with Sangoma to see if we can eliminate the card in the cycle to reproduce the issue. You should also note that the invalid DTMFs are being sent by the server without the PRI card in it. So it would seem that something in the audio stream from the PRI card is confusing the sip only asterisk and causing it to break it's DTMF support.
By: David Lublink (dlublink) 2011-04-26 12:59:00

I tried to get the latest 1.6.2 branch, but was unable to :
root@asterisk1:/usr/src# svn co http://svnview.digium.com/svn/asterisk/branches/1.6.2/ here
svn: Repository moved temporarily to '/svn/asterisk/branches/1.6.2/'; please relocate

Please advise.
By: David Lublink (dlublink) 2011-04-26 14:09:40

If you open the pcap files in wireshark and go into Telphony menu into VoIPCalls. Click the call, and graph it.

Look at the number of packets sent, that is clearly an error.
By: David Lublink (dlublink) 2011-04-26 14:36:15

I called in to the asterisk server using a loopback extension ( inbound did dials outbound test number on another dahdi channel), it works perfectly.

So I called in DAHDI/1-1 which connected to DAHDI1-2 using the dialplan, and the DTMF works perfectly.
By: Leif Madsen (lmadsen) 2011-05-05 07:09:42

dlublink: the path to the SVN repo is:

svn co http://svn.asterisk.org/svn/asterisk/branches/1.6.2

You're trying to check out from svnview.
By: Russell Bryant (russell) 2011-07-26 14:14:45.552-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions