[Home]

Summary:ASTERISK-15525: [patch] [regression] DTMF Relaying appers broken
Reporter:Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech)Labels:
Date Opened:2010-01-27 05:11:53.000-0600Date Closed:2010-04-13 14:21:34
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ast14271-dtmf-filtered-and-selected.pcap.bz2
Description:When accepting calls from a SIP provider (VoxBone) and then terminating to another provider (any SIP termination), DTMF signals will not pass utilizing RFC2833 configuration.



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

We've established that in version 1.4.26.3 this was working just fine, as all of our machines are utilizing that version of 1.4. Following below are the peer configurations:

--- Inbound Peer ---
[voxbone21]
disallow=all
host=81.201.82.45
dtmfmode=rfc2833
type=friend
context=from-trunk
insecure=port,invite
nat=never
allow=ulaw
allow=alaw
allow=g729
canreinvite=yes

--- Outbound Peer ---
[outPeer]
disallow=all
host=XXX.XXX.XXX.XXX
type=peer
allow=g729
context=from-trunk
dtmfmode=rfc2833
rfc2833compensate=yes
nat=yes

Now, we've increased the LOGGER level to include dtmf messages and examined the following:

[Jan 27 08:13:08] DTMF[24982]: channel.c:2856 __ast_read: DTMF begin '1' received on SIP/voxbone21-00000006
[Jan 27 08:13:08] DTMF[24982]: channel.c:2866 __ast_read: DTMF begin passthrough '1' on SIP/voxbone21-00000006
[Jan 27 08:13:08] DTMF[24982]: channel.c:2784 __ast_read: DTMF end '1' received on SIP/voxbone21-00000006, duration 280 ms
[Jan 27 08:13:08] DTMF[24982]: channel.c:2824 __ast_read: DTMF end accepted with begin '1' on SIP/voxbone21-00000006
[Jan 27 08:13:08] DTMF[24982]: channel.c:2840 __ast_read: DTMF end passthrough '1' on SIP/voxbone21-00000006
[Jan 27 08:13:11] DTMF[24982]: channel.c:2856 __ast_read: DTMF begin '1' received on SIP/voxbone21-00000006
[Jan 27 08:13:11] DTMF[24982]: channel.c:2866 __ast_read: DTMF begin passthrough '1' on SIP/voxbone21-00000006
[Jan 27 08:13:12] DTMF[24982]: channel.c:2784 __ast_read: DTMF end '1' received on SIP/voxbone21-00000006, duration 360 ms
[Jan 27 08:13:12] DTMF[24982]: channel.c:2824 __ast_read: DTMF end accepted with begin '1' on SIP/voxbone21-00000006
[Jan 27 08:13:12] DTMF[24982]: channel.c:2840 __ast_read: DTMF end passthrough '1' on SIP/voxbone21-00000006
[Jan 27 08:13:14] DTMF[24982]: channel.c:2856 __ast_read: DTMF begin '1' received on SIP/voxbone21-00000006
[Jan 27 08:13:14] DTMF[24982]: channel.c:2866 __ast_read: DTMF begin passthrough '1' on SIP/voxbone21-00000006
[Jan 27 08:13:15] DTMF[24982]: channel.c:2784 __ast_read: DTMF end '1' received on SIP/voxbone21-00000006, duration 300 ms
[Jan 27 08:13:15] DTMF[24982]: channel.c:2824 __ast_read: DTMF end accepted with begin '1' on SIP/voxbone21-00000006
[Jan 27 08:13:15] DTMF[24982]: channel.c:2840 __ast_read: DTMF end passthrough '1' on SIP/voxbone21-00000006

It would appear that the DTMF is being accepted, however, not relayed to the second peer. We've tested with multiple carriers as LEG-2, however, all exhibited the same behavior.

We've also tried using version 1.4.28 and 1.4.29, both exhibited the same issue as 1.6.0.21. We've currently downgraded to 1.4.26.3 - however, this appears to be a solid issue across the board.

The installation was performed utilizing Digium supplied RPM packages from http://packages.asterisk.org
Comments:By: Walter Doekes (wdoekes) 2010-01-28 04:01:46.000-0600

I can confirm this issue. A customer of ours had a DTMF issue with 1.4.27.1. Downgrading to 1.4.26.3 just now seems to have fixed it.

NB:
* I did see RTPEVENTS sent (relayed) from the 1.4.27.1, but the destination asterisk (1.4.24) did not handle the DTMFs, although the logs did state that it received them.
* When sending the DTMF as info, the destination asterisk didn't like the DTMF either.
By: Russell Bryant (russell) 2010-02-01 11:32:50.000-0600

Can you please provide a packet capture of a call demonstrating the problem?  Along with that, I'd like to see the associated sip.conf, extensions.conf, and console output if different from what is already included in the report.  Thanks.
By: Walter Doekes (wdoekes) 2010-02-04 02:30:34.000-0600

ast14271-dtmf-filtered-and-selected.pcap.bz2 is a pcap of RTP traffic between 10.0.0.35 (a phone) and 10.0.0.3 (asterisk 1.4.27.1) and between 10.0.0.3 and 95.215.204.68 (IVR on destination 1.4.24.1).

It contains the RTP DTMF events along with surrounding RTP voice.

(I had to trim it to the selected RTP portion only, as the PHP-upload didn't like my 6MB file. You may need to decode-as-rtp some UDP packets when using wireshark.)
(I don't have time to plough through the FreePBX sip and extensions configs right now, but they should be pretty standard. Console logs are unavailable but I saw nothing unusual.)
By: Walter Doekes (wdoekes) 2010-02-05 06:08:33.000-0600

Forget my note about the INFO DTMF's. The destination asterisk was never told (through relaxdtmf or dtmfmode) that it should have to interpret the SIP INFO's. Sorry about any confusion.
By: moshe Teitelbaum (moshe) 2010-03-05 11:05:06.000-0600

It seems that I might have the same issue, I thought that I have the snus bug issue 15642 tried the patchs didn't work

Running 1.4.29
By: Terry Wilson (twilson) 2010-03-12 19:04:00.000-0600

I have made a change to the 1.4, 1.6.0, 1.6.1, 1.6.2 branches and trunk that may affect this issue. Can you please check out the code from svn and see if it fixes the problem for you?
By: James Lamanna (jlamanna) 2010-04-01 14:24:48

Has this been fixed in 1.4.30?
By: Terry Wilson (twilson) 2010-04-01 14:37:25

jlamanna: no. The fix has not gone into a release yet. You can set constantssrc=yes in sip.conf to try to work around the issue until a new release is made with the fix.
By: Brian Camp (briancamp) 2010-04-02 09:38:37

FYI, we we're experiencing this issue with Polycom phones after updating to 1.4.30 and adding "constantssrc=yes" to sip.conf successfully worked around the issue.


By: Terry Wilson (twilson) 2010-04-02 10:23:28

briancamp: Good to hear. That means that the next release should fix the issue without requiring constantssrc=yes. The option itself is removed and the behavior sent back to the way things were before it existed for almost all situations.
By: Erik Smith (eeman) 2010-04-07 21:07:32

by 'next release' are you referring to the 1.4.31-RC1 or do you mean the version following this release? Also is constantssrc=yes placed in general? or in each peer config?
By: Terry Wilson (twilson) 2010-04-07 22:12:22

constantssrc=yes can be placed in either general or peer. But the setting will be gone in newer releases--including 1.4.31* (it won't be needed).
By: Leif Madsen (lmadsen) 2010-04-13 14:21:32

Closed per twilson and others. This should be fixed in the latest (or next) release of Asterisk.