Hi, I'm facing a "strange" problem with DTMF, on a FS server I'm using (Version 1.5.8b git fe2a4d6 2014-02-14 00:03:11Z 64bit). For some calls going through FS, when customers send DTMF tones (using RFC2833), I see those logs : 2014-11-14 15:47:48.516849 [DEBUG] switch_rtp.c:5683 RTP RECV DTMF 1:742
2014-11-14 15:47:48.516849 [DEBUG] switch_channel.c:489 RECV DTMF 1:742 2014-11-14 15:47:49.056857 [DEBUG] switch_rtp.c:5683 RTP RECV DTMF C:640 2014-11-14 15:47:49.056857 [DEBUG] switch_channel.c:489 RECV DTMF C:640 2014-11-14 15:47:49.356848 [DEBUG] switch_rtp.c:5683 RTP RECV DTMF 2:661 2014-11-14 15:47:49.356848 [DEBUG] switch_channel.c:489 RECV DTMF 2:661 2014-11-14 15:47:49.696846 [DEBUG] switch_rtp.c:5683 RTP RECV DTMF 3:665 2014-11-14 15:47:49.696846 [DEBUG] switch_channel.c:489 RECV DTMF 3:665 2014-11-14 15:47:50.256872 [DEBUG] switch_rtp.c:5683 RTP RECV DTMF 4:745 2014-11-14 15:47:50.256872 [DEBUG] switch_channel.c:489 RECV DTMF 4:745 2014-11-14 15:47:50.796855 [DEBUG] switch_rtp.c:5683 RTP RECV DTMF 5:741 2014-11-14 15:47:50.796855 [DEBUG] switch_channel.c:489 RECV DTMF 5:741 2014-11-14 15:47:51.236850 [DEBUG] switch_rtp.c:5683 RTP RECV DTMF 6:664 2014-11-14 15:47:51.236850 [DEBUG] switch_channel.c:489 RECV DTMF 6:664
Here, the customer tried to send "123456". So, I don't know why this "C" character has been sent, and I'm sure the customer didn't send this, because there's no "C" touch on his phone's keypad... And this "C" results in a double "1" received on the IVR server (hosted on another server than FS). (Ex : 123456 => 1C23456 => 1123456) It doesn't happen everytime, but for around 80% of calls... So it's really a problem for us... I looked at PCAPs for concerned calls, and saw that DTMF tones are only sent with RFC2833, not with SIP INFO nor InBand. I first thought that digits may be received simultaneously with RFC2833 and InBand but definitely not. Do you think what could be the cause of that ? I don't use "start_dtmf" in my diaplans, I already saw in other ML topics that this may cause double digit problems. Is there a way to ask freeswitch to only handle 0-9*# characters ? Or any idea, I'll be glad to try anything that can help us ! Thanks for help, Kevin *Bien cordialement, Best Regards, **Kevin MATHY* | Ingénieur VoIP --
I looked at PCAPs for concerned calls, and saw that DTMF tones are only sent with RFC2833, not with SIP INFO nor InBand. I first thought that digits may be received simultaneously with RFC2833 and InBand but definitely not.
Is that end-to-end, or are they reaching you via someone else? Or something else (ATA adapter)? If so perhaps some inband->RFC2833 is happening between you and them that's introducing the bad digit. If not can you share the PCAP (or just its RFC2833 packets)? That might explain what's happening. Do you think what could be the cause of that ? I don't use "start_dtmf" in
my diaplans, I already saw in other ML topics that this may cause double digit problems.
That's only if there's inband and out-of-band (RFC2833/INFO) DTMF at the same time. There's no issue otherwise, but using it on a call without inband DTMF is a waste of CPU. If you're getting RFC2833 then any inband audio will only cause double digits if you run start_dtmf, inband will be ignored by default. Is there a way to ask freeswitch to only handle 0-9*# characters ? Or any
idea, I'll be glad to try anything that can help us !
The problem is RFC2833 will be saying the 1 digit finished before the C one started, FS can only interpret it as its told to.
Dialing on speaker phone maybe? On Mon, Nov 17, 2014 at 3:57 AM, Steven Ayre <steveayre@gmail.com> wrote:
I looked at PCAPs for concerned calls, and saw that DTMF tones are only
sent with RFC2833, not with SIP INFO nor InBand. I first thought that digits may be received simultaneously with RFC2833 and InBand but definitely not.
Is that end-to-end, or are they reaching you via someone else? Or something else (ATA adapter)? If so perhaps some inband->RFC2833 is happening between you and them that's introducing the bad digit.
If not can you share the PCAP (or just its RFC2833 packets)? That might explain what's happening.
Do you think what could be the cause of that ? I don't use "start_dtmf"
in my diaplans, I already saw in other ML topics that this may cause double digit problems.
That's only if there's inband and out-of-band (RFC2833/INFO) DTMF at the same time. There's no issue otherwise, but using it on a call without inband DTMF is a waste of CPU.
If you're getting RFC2833 then any inband audio will only cause double digits if you run start_dtmf, inband will be ignored by default.
Is there a way to ask freeswitch to only handle 0-9*# characters ? Or any
idea, I'll be glad to try anything that can help us !
The problem is RFC2833 will be saying the 1 digit finished before the C one started, FS can only interpret it as its told to.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
participants (3)
-
Brian West
-
Kevin Mathy
-
Steven Ayre