[FS-8275] RFC2833 DTMF broken in recent master Created: 01/Oct/15  Updated: 13/Nov/18  Resolved: 20/Oct/15

Status: Resolved
Project: FreeSWITCH
Component/s: freeswitch-core
Affects Version/s: 1.6
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Stanislav Sinyagin Assignee: Anthony Minessale II
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

debian Jessie

Attachments: Text File notworking.txt     Text File working.txt    
CPU Architecture:
Distribution Version:
Debian 8 jessie
FreeSWITCH GIT Revision: f1c61f6
GIT Master Revision hash:: f1c61f6


The server is using the unstable FreeSWITCH packages, and is running some basic IVR on incoming calls.

After upgrading from 1.7.0~351~721ea6d-1~jessie+1
to 1.7.0~357~730c79c-1~jessie+1
the server stopped recognizing the DTMF completely.

Upgrading to the latest available deb package
did not solve the issue.

After downgrading to 1.6.2~9-1~jessie+1, the DTMF function is back to normal.

Comment by Stanislav Sinyagin [ 01/Oct/15 ]

it seems to be related to FS-8220.
In my case, the incoming calls are in G711, and IVR is launched immediately after answering.

Comment by Marc Olivier Chouinard [ 16/Oct/15 ]

NOTE: I'm not using latest, but I do have those 2 DTMF patch (the one that break it, and the one that 'fix' it), and I didn't see any changes that might resolved my problem in later commit... But I'll update to latest tonight and report back.

But here my issue I had :

It might still not fully resolved yet. I had to revert back both patch to get DTMF to work correctly in 1 scenario.

An Polycom IP 320/330 receiving a call cannot send DTMF (To open a office building door for example). But it worked fine on my Polycom VVX 1500 with the same config (though, maybe other codec was involved...).

Reverting both patch resolve the problem.

Comment by Marc Olivier Chouinard [ 17/Oct/15 ]

I confirm that the issue is still there in latest as of saturday night ! c7d5d49ff6c6dd4d2d57bec25414f8ac3b173225

Reverting both commit : c71b0cbd86b5292163715cb88fd9f27feaef97fc d335fb089ef0fab6617326efb16b96ecf17d19e6
resolve the problem.

Comment by Anthony Minessale II [ 17/Oct/15 ]

All reported scenerios are fixed.
If you have alternate scenario, can you provide precise reproduction steps. Full logs and exact setup so we can fix it.

Comment by Marc Olivier Chouinard [ 17/Oct/15 ]

It as described in my previous comment.

Issue occur on Polycom IP 330 phone receiving a call, it cannot send DTMF (sending dtmf to open a building door). But it can make a call a place DTMF.

So setup is : Polycom IP 330(3.3.5) receiving a call. User press 9, no dtmf is recognized on FS side. Source call is from another FS, but spandsp locally on the box is converting the DTMF to sound before it sent out.

I've attached the log file of when it working without the 2 patch, and one when it not working with both patch on.

Comment by Brian West [ 18/Oct/15 ]

What are the call flows here? I can't replicate this but I can't downgrade my 33X to 3.3.5.

Your saying that when the phone receives an inbound call, that phone can't send DTMF? Do you see anything on the wire? packet capture or something? The description is really vague, I've even tested with the most brain damaged thing I have "Bria" on my iPhone and too works correctly when receiving a call, the DTMF is received by FreeSWITCH. I've also tested with a Polycom IP7000, getting a 560 setup now to test with too.


Comment by Brian West [ 18/Oct/15 ]

On a side note, the Polycom 560 croaks and just stops working when we send it a full video invite!


Comment by Brian West [ 18/Oct/15 ]

I also tried various rate combos:

o=FreeSWITCH 1445152369 1445152370 IN IP4
c=IN IP4
t=0 0
m=audio 30296 RTP/AVP 0 102 103 104 101 105 107 109
a=rtpmap:0 PCMU/8000
a=rtpmap:102 G7221/16000
a=fmtp:102 bitrate=32000
a=rtpmap:103 G7221/32000a=fmtp:103 bitrate=48000
a=rtpmap:104 opus/48000/2
a=fmtp:104 useinbandfec=0; usedtx=1; cbr=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:105 telephone-event/16000
a=fmtp:105 0-16
a=rtpmap:107 telephone-event/32000
a=fmtp:107 0-16
a=rtpmap:109 telephone-event/48000
a=fmtp:109 0-16

o=- 1445182666 1445182666 IN IP4
s=Polycom IP Phone
c=IN IP4
t=0 0
m=audio 2234 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000

I think the issue is a Polycom one, i can get the IP7000 to not be able to send DTMF when we don't offer an 8k codec there by not offering telephony-event/8000,

Whats puzzling is the 335 can't do anything but 8k... need full packet capture to explore more.

Comment by Marc Olivier Chouinard [ 18/Oct/15 ]

I've tested with an VVX 1500 and a IP 330 (client have a 320). VVX 1500 it worked fine. But not on the IP 320, so I've setup a 330 on my end and replicated the issue. I haven't tried on a IP 335 yet or IP 331.

The actual setup is this PRI -> FS Gateway Server -> FS Client Server -> Polycom Phone.

dialplan bridge call between the FS Gateway leg to the Polycom Phone on FS Client. The DTMF is handled on the FS Client Server using spandsp dtmf.

I haven't did a dump on the wire from the phone when it doesn't work. I'll try to check it really soon !

Comment by Marc Olivier Chouinard [ 18/Oct/15 ]

I just emailed you a pcap.

As you can see, the phone does send the DTMF, but on the FS side, nothing appear in the logs.

Comment by Marc Olivier Chouinard [ 18/Oct/15 ]

I've tested on a Polycom IP 335 (4.0.8) and the problem doesn't occur.

Comment by Brian West [ 18/Oct/15 ]

The issue is narrowed down to the telephony-event PT, The phone answers 127, when we offered 101, If you set the PT in sofia to 127 it also works, if you reconfigure the phone to match FreeSWITCH's settings be it 101 or 127 it also works.



Comment by Marc Olivier Chouinard [ 18/Oct/15 ]

Correct, either changing FS to match the phone, or the phone to match FS. For the time being, I've set on my phone to force 101. Should FS handle both case like it did before, or that could cause other issues as we support more features ?

Comment by Brian West [ 18/Oct/15 ]

I guess it would have worked fine had the phone sent the DTMF on 127 like it said. But it was sending on 101 per the pcap.

Comment by Brian West [ 18/Oct/15 ]

but I'm guessing maybe they expected asymmetric telephony-event PTs, send to us 101 and se send to them on 127.

Comment by Anthony Minessale II [ 19/Oct/15 ]

please test branch bugfix/FS-8275

Comment by Marc Olivier Chouinard [ 19/Oct/15 ]

I've just tested it with the same result as head.

Generated at Tue Aug 20 02:21:50 CDT 2019 using Jira 8.1.0#801000-sha1:2e1cd1bb771978cda2c5e8f3f10539ab180613f6.