Strange DTMF Tones On Inbound Calls
Hello all, Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn’t even pressed any keys. It normally happens with 10 seconds or so after the call has been answered. Here is the log of it happening earlier: - 2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0) 2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440 2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000 seq=46804 lw=49600 2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000 seq=46805 lw=49760 2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920 2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000 seq=46807 lw=50080 2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240 2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400 2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560 2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720 2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880 2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040 2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0) 2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040 2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000 seq=46865 lw=59200 2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000 seq=46866 lw=59360 2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520 2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000 seq=46868 lw=59680 2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840 2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000 2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160 2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320 2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480 2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640 2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800 I’m very sure the caller isn’t dialling “A” or “B”! Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is “FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)”. Currently there is a “bind_meta_app” in the config which binds a script on the B leg of the call which parks the call – I haven’t tried turning this off yet to see if it’s this. Wondering if anyone has any ideas or has come across this before? Thanks in advance. [cid:imageacd695.PNG@9e92e461.40aa4b96] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:image27a71e.PNG@c2da8488.4683bff1]
Please update to latest git. -BDF On Fri, Mar 23, 2012 at 7:19 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
Hello all,****
** **
Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn’t even pressed any keys.****
** **
It normally happens with 10 seconds or so after the call has been answered. ****
** **
** **
Here is the log of it happening earlier: -****
** **
2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0)****
2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2****
2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440****
2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000 seq=46804 lw=49600****
2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000 seq=46805 lw=49760****
2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920****
2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000 seq=46807 lw=50080****
2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240****
2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400****
2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560****
2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720****
2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880****
2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040****
2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms****
2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0)****
2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2****
2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040****
2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000 seq=46865 lw=59200****
2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000 seq=46866 lw=59360****
2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520****
2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000 seq=46868 lw=59680****
2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840****
2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000****
2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160****
2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320****
2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480****
2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640****
2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800****
** **
** **
I’m very sure the caller isn’t dialling “A” or “B”!****
** **
Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is “FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)”.* ***
** **
** **
Currently there is a “bind_meta_app” in the config which binds a script on the B leg of the call which parks the call – I haven’t tried turning this off yet to see if it’s this.****
** **
** **
Wondering if anyone has any ideas or has come across this before?****
** **
** **
Thanks in advance.****
Daniel Knaggs
Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk www.realitysolutions.co.uk ------------------------------ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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 D. Foster Endigo Computer LLC Email: bdfoster@endigotech.com Phone: 317-800-7876 Indianapolis, Indiana, USA This message contains confidential information and is intended for those listed in the "To:", "CC:", and/or "BCC:" fields of the message header. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
Have you checked for any faults on your TDM link on your side? On Fri, Mar 23, 2012 at 10:32 AM, Brian Foster <bdfoster@endigotech.com>wrote:
Please update to latest git.
-BDF
On Fri, Mar 23, 2012 at 7:19 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
Hello all,****
** **
Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn’t even pressed any keys.****
** **
It normally happens with 10 seconds or so after the call has been answered.****
** **
** **
Here is the log of it happening earlier: -****
** **
2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0)****
2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2****
2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440****
2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000 seq=46804 lw=49600****
2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000 seq=46805 lw=49760****
2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920****
2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000 seq=46807 lw=50080****
2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240****
2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400****
2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560****
2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720****
2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880****
2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040****
2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms****
2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0)****
2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2****
2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040****
2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000 seq=46865 lw=59200****
2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000 seq=46866 lw=59360****
2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520****
2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000 seq=46868 lw=59680****
2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840****
2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000****
2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160****
2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320****
2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480****
2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640****
2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800****
** **
** **
I’m very sure the caller isn’t dialling “A” or “B”!****
** **
Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is “FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)”. ****
** **
** **
Currently there is a “bind_meta_app” in the config which binds a script on the B leg of the call which parks the call – I haven’t tried turning this off yet to see if it’s this.****
** **
** **
Wondering if anyone has any ideas or has come across this before?****
** **
** **
Thanks in advance.****
Daniel Knaggs
Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk www.realitysolutions.co.uk ------------------------------ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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 D. Foster Endigo Computer LLC Email: bdfoster@endigotech.com Phone: 317-800-7876 Indianapolis, Indiana, USA
This message contains confidential information and is intended for those listed in the "To:", "CC:", and/or "BCC:" fields of the message header. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
They aren’t any faults that I can see. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of curriegrad2004 Sent: 23 March 2012 23:23 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Have you checked for any faults on your TDM link on your side? On Fri, Mar 23, 2012 at 10:32 AM, Brian Foster <bdfoster@endigotech.com<mailto:bdfoster@endigotech.com>> wrote: Please update to latest git. -BDF On Fri, Mar 23, 2012 at 7:19 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Hello all, Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn’t even pressed any keys. It normally happens with 10 seconds or so after the call has been answered. Here is the log of it happening earlier: - 2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0) 2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440 2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000<tel:320%2F320%2F2000> seq=46804 lw=49600 2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000<tel:480%2F480%2F2000> seq=46805 lw=49760 2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920 2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000<tel:800%2F800%2F2000> seq=46807 lw=50080 2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240 2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400 2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560 2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720 2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880 2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040 2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0) 2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040 2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000<tel:320%2F320%2F2000> seq=46865 lw=59200 2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000<tel:480%2F480%2F2000> seq=46866 lw=59360 2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520 2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000<tel:800%2F800%2F2000> seq=46868 lw=59680 2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840 2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000 2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160 2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320 2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480 2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640 2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800 I’m very sure the caller isn’t dialling “A” or “B”! Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is “FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)”. Currently there is a “bind_meta_app” in the config which binds a script on the B leg of the call which parks the call – I haven’t tried turning this off yet to see if it’s this. Wondering if anyone has any ideas or has come across this before? Thanks in advance. [Description: cid:imageacd695.PNG@9e92e461.40aa4b96] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [Description: cid:image27a71e.PNG@c2da8488.4683bff1] _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 D. Foster Endigo Computer LLC Email: bdfoster@endigotech.com<mailto:bdfoster@endigotech.com> Phone: 317-800-7876<tel:317-800-7876> Indianapolis, Indiana, USA This message contains confidential information and is intended for those listed in the "To:", "CC:", and/or "BCC:" fields of the message header. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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
I'd do an audio recording of the call and open the resulting file in Audacity. It can do kind of a spectrum analysis to show you if there are any frequencies that might be fooling the dtmf detector. Also, I'm not familiar with using Digium cards with FreeTDM. (I have a Digium TE121 or similar but I don't happen to have any mobo's with the PCIe or whatever slot type it uses.) To Moises I'd ask: is there hardware DTMF detection in the Digium cards that you know of? Also, any known or suspected issues with false DTMF detection in the scenario mentioned by the OP? Gracias, MC On Sat, Mar 24, 2012 at 5:27 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
They aren’t any faults that I can see.****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of * curriegrad2004 *Sent:* 23 March 2012 23:23 *To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls****
** **
Have you checked for any faults on your TDM link on your side?****
On Fri, Mar 23, 2012 at 10:32 AM, Brian Foster <bdfoster@endigotech.com> wrote:****
Please update to latest git.****
** **
-BDF****
On Fri, Mar 23, 2012 at 7:19 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:****
Hello all,****
****
Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn’t even pressed any keys.****
****
It normally happens with 10 seconds or so after the call has been answered. ****
****
****
Here is the log of it happening earlier: -****
****
2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0)****
2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2****
2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440****
2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000 seq=46804 lw=49600****
2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000 seq=46805 lw=49760****
2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920****
2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000 seq=46807 lw=50080****
2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240****
2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400****
2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560****
2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720****
2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880****
2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040****
2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms****
2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0)****
2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2****
2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040****
2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000 seq=46865 lw=59200****
2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000 seq=46866 lw=59360****
2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520****
2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000 seq=46868 lw=59680****
2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840****
2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000****
2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160****
2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320****
2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480****
2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640****
2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800****
****
****
I’m very sure the caller isn’t dialling “A” or “B”!****
****
Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is “FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)”.* ***
****
****
Currently there is a “bind_meta_app” in the config which binds a script on the B leg of the call which parks the call – I haven’t tried turning this off yet to see if it’s this.****
****
****
Wondering if anyone has any ideas or has come across this before?****
****
****
Thanks in advance.****
[image: Description: cid:imageacd695.PNG@9e92e461.40aa4b96]****
*Daniel Knaggs*****
Software Developer****
****
Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk www.realitysolutions.co.uk **** ------------------------------
Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire ****
[image: Description: cid:image27a71e.PNG@c2da8488.4683bff1]****
****
** **
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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 D. Foster Endigo Computer LLC Email: bdfoster@endigotech.com Phone: 317-800-7876 Indianapolis, Indiana, USA
This message contains confidential information and is intended for those listed in the "To:", "CC:", and/or "BCC:" fields of the message header. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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****
** **
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
Those detected tones could be something that the TDM provider didn't filter out for some odd reason. With E&M signalling on TDM links you may hear a squealing tone in the background. On Sat, Mar 24, 2012 at 6:20 PM, Michael Collins <msc@freeswitch.org> wrote:
I'd do an audio recording of the call and open the resulting file in Audacity. It can do kind of a spectrum analysis to show you if there are any frequencies that might be fooling the dtmf detector. Also, I'm not familiar with using Digium cards with FreeTDM. (I have a Digium TE121 or similar but I don't happen to have any mobo's with the PCIe or whatever slot type it uses.)
To Moises I'd ask: is there hardware DTMF detection in the Digium cards that you know of? Also, any known or suspected issues with false DTMF detection in the scenario mentioned by the OP?
Gracias, MC
On Sat, Mar 24, 2012 at 5:27 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
They aren’t any faults that I can see.****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of * curriegrad2004 *Sent:* 23 March 2012 23:23 *To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls****
** **
Have you checked for any faults on your TDM link on your side?****
On Fri, Mar 23, 2012 at 10:32 AM, Brian Foster <bdfoster@endigotech.com> wrote:****
Please update to latest git.****
** **
-BDF****
On Fri, Mar 23, 2012 at 7:19 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:****
Hello all,****
****
Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn’t even pressed any keys.****
****
It normally happens with 10 seconds or so after the call has been answered.****
****
****
Here is the log of it happening earlier: -****
****
2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0)****
2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2****
2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440****
2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000 seq=46804 lw=49600****
2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000 seq=46805 lw=49760****
2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920****
2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000 seq=46807 lw=50080****
2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240****
2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400****
2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560****
2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720****
2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880****
2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040****
2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200****
2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms****
2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0)****
2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2****
2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040****
2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000 seq=46865 lw=59200****
2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000 seq=46866 lw=59360****
2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520****
2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000 seq=46868 lw=59680****
2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840****
2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000****
2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160****
2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320****
2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480****
2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640****
2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800****
2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800****
****
****
I’m very sure the caller isn’t dialling “A” or “B”!****
****
Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is “FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)”. ****
****
****
Currently there is a “bind_meta_app” in the config which binds a script on the B leg of the call which parks the call – I haven’t tried turning this off yet to see if it’s this.****
****
****
Wondering if anyone has any ideas or has come across this before?****
****
****
Thanks in advance.****
[image: Description: cid:imageacd695.PNG@9e92e461.40aa4b96]****
*Daniel Knaggs*****
Software Developer****
****
Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk www.realitysolutions.co.uk **** ------------------------------
Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire ****
[image: Description: cid:image27a71e.PNG@c2da8488.4683bff1]****
****
** **
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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 D. Foster Endigo Computer LLC Email: bdfoster@endigotech.com Phone: 317-800-7876 Indianapolis, Indiana, USA
This message contains confidential information and is intended for those listed in the "To:", "CC:", and/or "BCC:" fields of the message header. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.****
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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****
** **
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
The quality of the calls are perfect, even when listening to silence over the ISDN it is perfect. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of curriegrad2004 Sent: 25 March 2012 04:14 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Those detected tones could be something that the TDM provider didn't filter out for some odd reason. With E&M signalling on TDM links you may hear a squealing tone in the background. On Sat, Mar 24, 2012 at 6:20 PM, Michael Collins <msc@freeswitch.org<mailto:msc@freeswitch.org>> wrote: I'd do an audio recording of the call and open the resulting file in Audacity. It can do kind of a spectrum analysis to show you if there are any frequencies that might be fooling the dtmf detector. Also, I'm not familiar with using Digium cards with FreeTDM. (I have a Digium TE121 or similar but I don't happen to have any mobo's with the PCIe or whatever slot type it uses.) To Moises I'd ask: is there hardware DTMF detection in the Digium cards that you know of? Also, any known or suspected issues with false DTMF detection in the scenario mentioned by the OP? Gracias, MC On Sat, Mar 24, 2012 at 5:27 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: They aren’t any faults that I can see. From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of curriegrad2004 Sent: 23 March 2012 23:23 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Have you checked for any faults on your TDM link on your side? On Fri, Mar 23, 2012 at 10:32 AM, Brian Foster <bdfoster@endigotech.com<mailto:bdfoster@endigotech.com>> wrote: Please update to latest git. -BDF On Fri, Mar 23, 2012 at 7:19 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Hello all, Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn’t even pressed any keys. It normally happens with 10 seconds or so after the call has been answered. Here is the log of it happening earlier: - 2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0) 2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440 2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000<tel:320%2F320%2F2000> seq=46804 lw=49600 2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000<tel:480%2F480%2F2000> seq=46805 lw=49760 2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920 2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000<tel:800%2F800%2F2000> seq=46807 lw=50080 2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240 2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400 2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560 2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720 2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880 2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040 2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0) 2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040 2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000<tel:320%2F320%2F2000> seq=46865 lw=59200 2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000<tel:480%2F480%2F2000> seq=46866 lw=59360 2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520 2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000<tel:800%2F800%2F2000> seq=46868 lw=59680 2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840 2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000 2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160 2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320 2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480 2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640 2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800 I’m very sure the caller isn’t dialling “A” or “B”! Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is “FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)”. Currently there is a “bind_meta_app” in the config which binds a script on the B leg of the call which parks the call – I haven’t tried turning this off yet to see if it’s this. Wondering if anyone has any ideas or has come across this before? Thanks in advance. [Description: cid:imageacd695.PNG@9e92e461.40aa4b96] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [Description: cid:image27a71e.PNG@c2da8488.4683bff1] _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 D. Foster Endigo Computer LLC Email: bdfoster@endigotech.com<mailto:bdfoster@endigotech.com> Phone: 317-800-7876<tel:317-800-7876> Indianapolis, Indiana, USA This message contains confidential information and is intended for those listed in the "To:", "CC:", and/or "BCC:" fields of the message header. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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
Not a bad idea, Michael! I'll see if I can get that sorted. The DTMF tones only appear to be "lettered" ones, could I comment those out in the source code and rebuild (which files would I need to change)? Not the best workaround but should work. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 25 March 2012 02:20 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls I'd do an audio recording of the call and open the resulting file in Audacity. It can do kind of a spectrum analysis to show you if there are any frequencies that might be fooling the dtmf detector. Also, I'm not familiar with using Digium cards with FreeTDM. (I have a Digium TE121 or similar but I don't happen to have any mobo's with the PCIe or whatever slot type it uses.) To Moises I'd ask: is there hardware DTMF detection in the Digium cards that you know of? Also, any known or suspected issues with false DTMF detection in the scenario mentioned by the OP? Gracias, MC On Sat, Mar 24, 2012 at 5:27 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: They aren't any faults that I can see. From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of curriegrad2004 Sent: 23 March 2012 23:23 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Have you checked for any faults on your TDM link on your side? On Fri, Mar 23, 2012 at 10:32 AM, Brian Foster <bdfoster@endigotech.com<mailto:bdfoster@endigotech.com>> wrote: Please update to latest git. -BDF On Fri, Mar 23, 2012 at 7:19 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Hello all, Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn't even pressed any keys. It normally happens with 10 seconds or so after the call has been answered. Here is the log of it happening earlier: - 2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0) 2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440 2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000<tel:320%2F320%2F2000> seq=46804 lw=49600 2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000<tel:480%2F480%2F2000> seq=46805 lw=49760 2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920 2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000<tel:800%2F800%2F2000> seq=46807 lw=50080 2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240 2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400 2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560 2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720 2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880 2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040 2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0) 2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040 2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000<tel:320%2F320%2F2000> seq=46865 lw=59200 2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000<tel:480%2F480%2F2000> seq=46866 lw=59360 2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520 2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000<tel:800%2F800%2F2000> seq=46868 lw=59680 2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840 2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000 2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160 2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320 2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480 2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640 2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800 I'm very sure the caller isn't dialling "A" or "B"! Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is "FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)". Currently there is a "bind_meta_app" in the config which binds a script on the B leg of the call which parks the call - I haven't tried turning this off yet to see if it's this. Wondering if anyone has any ideas or has come across this before? Thanks in advance. [Description: Description: cid:imageacd695.PNG@9e92e461.40aa4b96] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [Description: Description: cid:image27a71e.PNG@c2da8488.4683bff1] _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 D. Foster Endigo Computer LLC Email: bdfoster@endigotech.com<mailto:bdfoster@endigotech.com> Phone: 317-800-7876<tel:317-800-7876> Indianapolis, Indiana, USA This message contains confidential information and is intended for those listed in the "To:", "CC:", and/or "BCC:" fields of the message header. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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
OK, call recording has been setup - waiting for it to happen now. Interestingly, before I issue the "record_session" application (and of course the "RECORD_*" variables) I had to execute "ring_ready" then "pre_answer" otherwise the caller gets silence (changing the order of those two commands results in silence). From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Daniel Knaggs Sent: 26 March 2012 08:44 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Not a bad idea, Michael! I'll see if I can get that sorted. The DTMF tones only appear to be "lettered" ones, could I comment those out in the source code and rebuild (which files would I need to change)? Not the best workaround but should work. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 25 March 2012 02:20 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls I'd do an audio recording of the call and open the resulting file in Audacity. It can do kind of a spectrum analysis to show you if there are any frequencies that might be fooling the dtmf detector. Also, I'm not familiar with using Digium cards with FreeTDM. (I have a Digium TE121 or similar but I don't happen to have any mobo's with the PCIe or whatever slot type it uses.) To Moises I'd ask: is there hardware DTMF detection in the Digium cards that you know of? Also, any known or suspected issues with false DTMF detection in the scenario mentioned by the OP? Gracias, MC On Sat, Mar 24, 2012 at 5:27 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: They aren't any faults that I can see. From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of curriegrad2004 Sent: 23 March 2012 23:23 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Have you checked for any faults on your TDM link on your side? On Fri, Mar 23, 2012 at 10:32 AM, Brian Foster <bdfoster@endigotech.com<mailto:bdfoster@endigotech.com>> wrote: Please update to latest git. -BDF On Fri, Mar 23, 2012 at 7:19 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Hello all, Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn't even pressed any keys. It normally happens with 10 seconds or so after the call has been answered. Here is the log of it happening earlier: - 2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0) 2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440 2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000<tel:320%2F320%2F2000> seq=46804 lw=49600 2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000<tel:480%2F480%2F2000> seq=46805 lw=49760 2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920 2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000<tel:800%2F800%2F2000> seq=46807 lw=50080 2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240 2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400 2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560 2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720 2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880 2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040 2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0) 2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040 2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000<tel:320%2F320%2F2000> seq=46865 lw=59200 2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000<tel:480%2F480%2F2000> seq=46866 lw=59360 2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520 2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000<tel:800%2F800%2F2000> seq=46868 lw=59680 2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840 2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000 2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160 2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320 2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480 2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640 2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800 I'm very sure the caller isn't dialling "A" or "B"! Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is "FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)". Currently there is a "bind_meta_app" in the config which binds a script on the B leg of the call which parks the call - I haven't tried turning this off yet to see if it's this. Wondering if anyone has any ideas or has come across this before? Thanks in advance. [Description: Description: Description: cid:imageacd695.PNG@9e92e461.40aa4b96] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [Description: Description: Description: cid:image27a71e.PNG@c2da8488.4683bff1] _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 D. Foster Endigo Computer LLC Email: bdfoster@endigotech.com<mailto:bdfoster@endigotech.com> Phone: 317-800-7876<tel:317-800-7876> Indianapolis, Indiana, USA This message contains confidential information and is intended for those listed in the "To:", "CC:", and/or "BCC:" fields of the message header. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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
On Mon, Mar 26, 2012 at 3:01 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
OK, call recording has been setup – waiting for it to happen now.****
** **
** **
Interestingly, before I issue the “record_session” application (and of course the “RECORD_*” variables) I had to execute “ring_ready” then “pre_answer” otherwise the caller gets silence (changing the order of those two commands results in silence).
I find it odd that just doing a pre_answer wouldn't be sufficient. A pre_answer will send a 183 w/SDP whereas ring_ready simply sends a 180. In any case, I'm glad you got your recordings. I also find it curious that only the "letter" DTMFs are being detected. Let us know if you actually hear those tones in the audio stream. -MC
OK, it does NOT appear in the recordings. Here is a spectrum analysis of the call when it happened: - Frequency (Hz) Level (dB) 15.625000 -59.445583 31.250000 -69.136353 46.875000 -71.569084 62.500000 -72.445877 78.125000 -67.142319 93.750000 -63.964447 109.375000 -61.157677 125.000000 -58.849174 140.625000 -62.083492 156.250000 -51.071819 171.875000 -48.957565 187.500000 -48.156109 203.125000 -48.908588 218.750000 -47.891460 234.375000 -46.257698 250.000000 -43.011139 265.625000 -48.706509 281.250000 -53.241238 296.875000 -52.513802 312.500000 -50.387054 328.125000 -53.275459 343.750000 -56.096489 359.375000 -54.788857 375.000000 -52.283993 390.625000 -50.975601 406.250000 -49.737530 421.875000 -49.870571 437.500000 -50.445431 453.125000 -50.647591 468.750000 -49.450035 484.375000 -48.767914 500.000000 -48.281902 515.625000 -49.419975 531.250000 -52.635048 546.875000 -52.856857 562.500000 -51.675240 578.125000 -50.667599 593.750000 -51.584862 609.375000 -48.992435 625.000000 -48.492191 640.625000 -49.701382 656.250000 -53.005512 671.875000 -54.269699 687.500000 -54.937397 703.125000 -53.922794 718.750000 -51.949009 734.375000 -52.763660 750.000000 -53.731155 765.625000 -54.977795 781.250000 -54.029835 796.875000 -54.375313 812.500000 -54.419693 828.125000 -54.796967 843.750000 -55.052872 859.375000 -53.625359 875.000000 -54.649513 890.625000 -56.736855 906.250000 -57.202946 921.875000 -56.587177 937.500000 -57.263260 953.125000 -56.744713 968.750000 -57.710808 984.375000 -58.118694 1000.000000 -60.595867 1015.625000 -60.736752 1031.250000 -57.966949 1046.875000 -58.101311 1062.500000 -59.093056 1078.125000 -59.889881 1093.750000 -59.972092 1109.375000 -59.728626 1125.000000 -58.060120 1140.625000 -56.506371 1156.250000 -55.109329 1171.875000 -54.278183 1187.500000 -56.115913 1203.125000 -57.535069 1218.750000 -58.304485 1234.375000 -58.614723 1250.000000 -58.873520 1265.625000 -61.268688 1281.250000 -62.702538 1296.875000 -63.828163 1312.500000 -63.712082 1328.125000 -65.020050 1343.750000 -64.481941 1359.375000 -62.652424 1375.000000 -61.640785 1390.625000 -61.719952 1406.250000 -61.451962 1421.875000 -58.490433 1437.500000 -57.193993 1453.125000 -56.973965 1468.750000 -57.940182 1484.375000 -59.935654 1500.000000 -61.829227 1515.625000 -63.259266 1531.250000 -62.169945 1546.875000 -61.958508 1562.500000 -62.018082 1578.125000 -60.562317 1593.750000 -59.146374 1609.375000 -58.868763 1625.000000 -60.028801 1640.625000 -59.241119 1656.250000 -60.101322 1671.875000 -60.429554 1687.500000 -60.538834 1703.125000 -61.073635 1718.750000 -60.375114 1734.375000 -60.152672 1750.000000 -59.529144 1765.625000 -59.783649 1781.250000 -61.850414 1796.875000 -63.506111 1812.500000 -63.869320 1828.125000 -62.442127 1843.750000 -62.519482 1859.375000 -63.814472 1875.000000 -63.300858 1890.625000 -61.998482 1906.250000 -62.199738 1921.875000 -61.745621 1937.500000 -61.611210 1953.125000 -61.174740 1968.750000 -60.504318 1984.375000 -60.277737 2000.000000 -61.696060 2015.625000 -61.693054 2031.250000 -62.755184 2046.875000 -63.983723 2062.500000 -63.584675 2078.125000 -62.943420 2093.750000 -63.238541 2109.375000 -62.929970 2125.000000 -62.243599 2140.625000 -60.967789 2156.250000 -60.915421 2171.875000 -61.997654 2187.500000 -63.702518 2203.125000 -64.316109 2218.750000 -63.577995 2234.375000 -63.250530 2250.000000 -63.107010 2265.625000 -62.953743 2281.250000 -62.933647 2296.875000 -61.956242 2312.500000 -62.948036 2328.125000 -64.375603 2343.750000 -64.296860 2359.375000 -63.552139 2375.000000 -62.556362 2390.625000 -62.979954 2406.250000 -64.505875 2421.875000 -65.626236 2437.500000 -65.732819 2453.125000 -66.130798 2468.750000 -65.920502 2484.375000 -64.183731 2500.000000 -63.387459 2515.625000 -63.110027 2531.250000 -64.085106 2546.875000 -64.269905 2562.500000 -64.181808 2578.125000 -64.600060 2593.750000 -63.998692 2609.375000 -63.854473 2625.000000 -65.015961 2640.625000 -65.751480 2656.250000 -66.293800 2671.875000 -66.494102 2687.500000 -66.300240 2703.125000 -66.383118 2718.750000 -66.466385 2734.375000 -65.733604 2750.000000 -65.110283 2765.625000 -65.537567 2781.250000 -66.125465 2796.875000 -65.979088 2812.500000 -64.833984 2828.125000 -63.773678 2843.750000 -64.419113 2859.375000 -64.800369 2875.000000 -64.710480 2890.625000 -64.088387 2906.250000 -64.790306 2921.875000 -65.160469 2937.500000 -65.285408 2953.125000 -66.030342 2968.750000 -65.027481 2984.375000 -64.623558 3000.000000 -65.082748 3015.625000 -63.680820 3031.250000 -62.836716 3046.875000 -62.210663 3062.500000 -61.578278 3078.125000 -62.397720 3093.750000 -63.185940 3109.375000 -62.439983 3125.000000 -62.382778 3140.625000 -63.123928 3156.250000 -64.276588 3171.875000 -65.444725 3187.500000 -65.891289 3203.125000 -65.480240 3218.750000 -64.761063 3234.375000 -65.140015 3250.000000 -66.010643 3265.625000 -66.964401 3281.250000 -67.296051 3296.875000 -66.430000 3312.500000 -66.564758 3328.125000 -67.878830 3343.750000 -67.748436 3359.375000 -68.965981 3375.000000 -70.426888 3390.625000 -71.400375 3406.250000 -72.067627 3421.875000 -71.944176 3437.500000 -72.285637 3453.125000 -71.983047 3468.750000 -72.565109 3484.375000 -72.350845 3500.000000 -72.335533 3515.625000 -72.608849 3531.250000 -72.417786 3546.875000 -73.100441 3562.500000 -73.461548 3578.125000 -73.558250 3593.750000 -73.218422 3609.375000 -73.994888 3625.000000 -74.379204 3640.625000 -74.896202 3656.250000 -74.944405 3671.875000 -74.958710 3687.500000 -75.029655 3703.125000 -74.314133 3718.750000 -74.855209 3734.375000 -76.021591 3750.000000 -76.441444 3765.625000 -77.122787 3781.250000 -77.733589 3796.875000 -79.138847 3812.500000 -80.206360 3828.125000 -80.391960 3843.750000 -81.214249 3859.375000 -81.434105 3875.000000 -82.234749 3890.625000 -82.529884 3906.250000 -82.929169 3921.875000 -83.735237 3937.500000 -84.770660 3953.125000 -84.203438 3968.750000 -84.455025 3984.375000 -85.116302 2012-03-27 09:50:40.412101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=320/320/2000 seq=38825 lw=28160 2012-03-27 09:50:40.433101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=480/480/2000 seq=38826 lw=28320 2012-03-27 09:50:40.454100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=640/640/2000 seq=38827 lw=28480 2012-03-27 09:50:40.475100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=800/800/2000 seq=38828 lw=28640 2012-03-27 09:50:40.496100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=960/960/2000 seq=38829 lw=28800 2012-03-27 09:50:40.517100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1120/1120/2000 seq=38830 lw=28960 2012-03-27 09:50:40.538100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1280/1280/2000 seq=38831 lw=29120 2012-03-27 09:50:40.559099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1440/1440/2000 seq=38832 lw=29280 2012-03-27 09:50:40.580099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1600/1600/2000 seq=38833 lw=29440 2012-03-27 09:50:40.601099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1760/1760/2000 seq=38834 lw=29600 2012-03-27 09:50:40.622098 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1920/1920/2000 seq=38835 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38836 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38837 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38838 lw=29760 Any ideas? From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 26 March 2012 18:39 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls On Mon, Mar 26, 2012 at 3:01 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: OK, call recording has been setup – waiting for it to happen now. Interestingly, before I issue the “record_session” application (and of course the “RECORD_*” variables) I had to execute “ring_ready” then “pre_answer” otherwise the caller gets silence (changing the order of those two commands results in silence). I find it odd that just doing a pre_answer wouldn't be sufficient. A pre_answer will send a 183 w/SDP whereas ring_ready simply sends a 180. In any case, I'm glad you got your recordings. I also find it curious that only the "letter" DTMFs are being detected. Let us know if you actually hear those tones in the audio stream. -MC [cid:imageda5d6c.PNG@183a2c3f.4b84f9b4] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:image6d7ef5.PNG@b1008b83.44ae8694]
Any ideas, anyone? [cid:imagefb5387.PNG@ca5d49be.4fa92b00] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:image19a0f2.PNG@39ea781d.48900adc] From: Daniel Knaggs Sent: 27 March 2012 10:22 To: 'FreeSWITCH Users Help' Subject: RE: [Freeswitch-users] Strange DTMF Tones On Inbound Calls OK, it does NOT appear in the recordings. Here is a spectrum analysis of the call when it happened: - Frequency (Hz) Level (dB) 15.625000 -59.445583 31.250000 -69.136353 46.875000 -71.569084 62.500000 -72.445877 78.125000 -67.142319 93.750000 -63.964447 109.375000 -61.157677 125.000000 -58.849174 140.625000 -62.083492 156.250000 -51.071819 171.875000 -48.957565 187.500000 -48.156109 203.125000 -48.908588 218.750000 -47.891460 234.375000 -46.257698 250.000000 -43.011139 265.625000 -48.706509 281.250000 -53.241238 296.875000 -52.513802 312.500000 -50.387054 328.125000 -53.275459 343.750000 -56.096489 359.375000 -54.788857 375.000000 -52.283993 390.625000 -50.975601 406.250000 -49.737530 421.875000 -49.870571 437.500000 -50.445431 453.125000 -50.647591 468.750000 -49.450035 484.375000 -48.767914 500.000000 -48.281902 515.625000 -49.419975 531.250000 -52.635048 546.875000 -52.856857 562.500000 -51.675240 578.125000 -50.667599 593.750000 -51.584862 609.375000 -48.992435 625.000000 -48.492191 640.625000 -49.701382 656.250000 -53.005512 671.875000 -54.269699 687.500000 -54.937397 703.125000 -53.922794 718.750000 -51.949009 734.375000 -52.763660 750.000000 -53.731155 765.625000 -54.977795 781.250000 -54.029835 796.875000 -54.375313 812.500000 -54.419693 828.125000 -54.796967 843.750000 -55.052872 859.375000 -53.625359 875.000000 -54.649513 890.625000 -56.736855 906.250000 -57.202946 921.875000 -56.587177 937.500000 -57.263260 953.125000 -56.744713 968.750000 -57.710808 984.375000 -58.118694 1000.000000 -60.595867 1015.625000 -60.736752 1031.250000 -57.966949 1046.875000 -58.101311 1062.500000 -59.093056 1078.125000 -59.889881 1093.750000 -59.972092 1109.375000 -59.728626 1125.000000 -58.060120 1140.625000 -56.506371 1156.250000 -55.109329 1171.875000 -54.278183 1187.500000 -56.115913 1203.125000 -57.535069 1218.750000 -58.304485 1234.375000 -58.614723 1250.000000 -58.873520 1265.625000 -61.268688 1281.250000 -62.702538 1296.875000 -63.828163 1312.500000 -63.712082 1328.125000 -65.020050 1343.750000 -64.481941 1359.375000 -62.652424 1375.000000 -61.640785 1390.625000 -61.719952 1406.250000 -61.451962 1421.875000 -58.490433 1437.500000 -57.193993 1453.125000 -56.973965 1468.750000 -57.940182 1484.375000 -59.935654 1500.000000 -61.829227 1515.625000 -63.259266 1531.250000 -62.169945 1546.875000 -61.958508 1562.500000 -62.018082 1578.125000 -60.562317 1593.750000 -59.146374 1609.375000 -58.868763 1625.000000 -60.028801 1640.625000 -59.241119 1656.250000 -60.101322 1671.875000 -60.429554 1687.500000 -60.538834 1703.125000 -61.073635 1718.750000 -60.375114 1734.375000 -60.152672 1750.000000 -59.529144 1765.625000 -59.783649 1781.250000 -61.850414 1796.875000 -63.506111 1812.500000 -63.869320 1828.125000 -62.442127 1843.750000 -62.519482 1859.375000 -63.814472 1875.000000 -63.300858 1890.625000 -61.998482 1906.250000 -62.199738 1921.875000 -61.745621 1937.500000 -61.611210 1953.125000 -61.174740 1968.750000 -60.504318 1984.375000 -60.277737 2000.000000 -61.696060 2015.625000 -61.693054 2031.250000 -62.755184 2046.875000 -63.983723 2062.500000 -63.584675 2078.125000 -62.943420 2093.750000 -63.238541 2109.375000 -62.929970 2125.000000 -62.243599 2140.625000 -60.967789 2156.250000 -60.915421 2171.875000 -61.997654 2187.500000 -63.702518 2203.125000 -64.316109 2218.750000 -63.577995 2234.375000 -63.250530 2250.000000 -63.107010 2265.625000 -62.953743 2281.250000 -62.933647 2296.875000 -61.956242 2312.500000 -62.948036 2328.125000 -64.375603 2343.750000 -64.296860 2359.375000 -63.552139 2375.000000 -62.556362 2390.625000 -62.979954 2406.250000 -64.505875 2421.875000 -65.626236 2437.500000 -65.732819 2453.125000 -66.130798 2468.750000 -65.920502 2484.375000 -64.183731 2500.000000 -63.387459 2515.625000 -63.110027 2531.250000 -64.085106 2546.875000 -64.269905 2562.500000 -64.181808 2578.125000 -64.600060 2593.750000 -63.998692 2609.375000 -63.854473 2625.000000 -65.015961 2640.625000 -65.751480 2656.250000 -66.293800 2671.875000 -66.494102 2687.500000 -66.300240 2703.125000 -66.383118 2718.750000 -66.466385 2734.375000 -65.733604 2750.000000 -65.110283 2765.625000 -65.537567 2781.250000 -66.125465 2796.875000 -65.979088 2812.500000 -64.833984 2828.125000 -63.773678 2843.750000 -64.419113 2859.375000 -64.800369 2875.000000 -64.710480 2890.625000 -64.088387 2906.250000 -64.790306 2921.875000 -65.160469 2937.500000 -65.285408 2953.125000 -66.030342 2968.750000 -65.027481 2984.375000 -64.623558 3000.000000 -65.082748 3015.625000 -63.680820 3031.250000 -62.836716 3046.875000 -62.210663 3062.500000 -61.578278 3078.125000 -62.397720 3093.750000 -63.185940 3109.375000 -62.439983 3125.000000 -62.382778 3140.625000 -63.123928 3156.250000 -64.276588 3171.875000 -65.444725 3187.500000 -65.891289 3203.125000 -65.480240 3218.750000 -64.761063 3234.375000 -65.140015 3250.000000 -66.010643 3265.625000 -66.964401 3281.250000 -67.296051 3296.875000 -66.430000 3312.500000 -66.564758 3328.125000 -67.878830 3343.750000 -67.748436 3359.375000 -68.965981 3375.000000 -70.426888 3390.625000 -71.400375 3406.250000 -72.067627 3421.875000 -71.944176 3437.500000 -72.285637 3453.125000 -71.983047 3468.750000 -72.565109 3484.375000 -72.350845 3500.000000 -72.335533 3515.625000 -72.608849 3531.250000 -72.417786 3546.875000 -73.100441 3562.500000 -73.461548 3578.125000 -73.558250 3593.750000 -73.218422 3609.375000 -73.994888 3625.000000 -74.379204 3640.625000 -74.896202 3656.250000 -74.944405 3671.875000 -74.958710 3687.500000 -75.029655 3703.125000 -74.314133 3718.750000 -74.855209 3734.375000 -76.021591 3750.000000 -76.441444 3765.625000 -77.122787 3781.250000 -77.733589 3796.875000 -79.138847 3812.500000 -80.206360 3828.125000 -80.391960 3843.750000 -81.214249 3859.375000 -81.434105 3875.000000 -82.234749 3890.625000 -82.529884 3906.250000 -82.929169 3921.875000 -83.735237 3937.500000 -84.770660 3953.125000 -84.203438 3968.750000 -84.455025 3984.375000 -85.116302 2012-03-27 09:50:40.412101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=320/320/2000 seq=38825 lw=28160 2012-03-27 09:50:40.433101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=480/480/2000 seq=38826 lw=28320 2012-03-27 09:50:40.454100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=640/640/2000 seq=38827 lw=28480 2012-03-27 09:50:40.475100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=800/800/2000 seq=38828 lw=28640 2012-03-27 09:50:40.496100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=960/960/2000 seq=38829 lw=28800 2012-03-27 09:50:40.517100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1120/1120/2000 seq=38830 lw=28960 2012-03-27 09:50:40.538100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1280/1280/2000 seq=38831 lw=29120 2012-03-27 09:50:40.559099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1440/1440/2000 seq=38832 lw=29280 2012-03-27 09:50:40.580099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1600/1600/2000 seq=38833 lw=29440 2012-03-27 09:50:40.601099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1760/1760/2000 seq=38834 lw=29600 2012-03-27 09:50:40.622098 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1920/1920/2000 seq=38835 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38836 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38837 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38838 lw=29760 Any ideas? From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 26 March 2012 18:39 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls On Mon, Mar 26, 2012 at 3:01 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: OK, call recording has been setup – waiting for it to happen now. Interestingly, before I issue the “record_session” application (and of course the “RECORD_*” variables) I had to execute “ring_ready” then “pre_answer” otherwise the caller gets silence (changing the order of those two commands results in silence). I find it odd that just doing a pre_answer wouldn't be sufficient. A pre_answer will send a 183 w/SDP whereas ring_ready simply sends a 180. In any case, I'm glad you got your recordings. I also find it curious that only the "letter" DTMFs are being detected. Let us know if you actually hear those tones in the audio stream. -MC
Maybe its generated by an ata box if you have an analog phone? Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk> wrote:
Any ideas, anyone?
[cid:imagefb5387.PNG@ca5d49be.4fa92b00]
Daniel Knaggs
Software Developer
Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________
Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire
[cid:image19a0f2.PNG@39ea781d.48900adc]
From: Daniel Knaggs Sent: 27 March 2012 10:22 To: 'FreeSWITCH Users Help' Subject: RE: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
OK, it does NOT appear in the recordings.
Here is a spectrum analysis of the call when it happened: -
Frequency (Hz) Level (dB) 15.625000 -59.445583 31.250000 -69.136353 46.875000 -71.569084 62.500000 -72.445877 78.125000 -67.142319 93.750000 -63.964447 109.375000 -61.157677 125.000000 -58.849174 140.625000 -62.083492 156.250000 -51.071819 171.875000 -48.957565 187.500000 -48.156109 203.125000 -48.908588 218.750000 -47.891460 234.375000 -46.257698 250.000000 -43.011139 265.625000 -48.706509 281.250000 -53.241238 296.875000 -52.513802 312.500000 -50.387054 328.125000 -53.275459 343.750000 -56.096489 359.375000 -54.788857 375.000000 -52.283993 390.625000 -50.975601 406.250000 -49.737530 421.875000 -49.870571 437.500000 -50.445431 453.125000 -50.647591 468.750000 -49.450035 484.375000 -48.767914 500.000000 -48.281902 515.625000 -49.419975 531.250000 -52.635048 546.875000 -52.856857 562.500000 -51.675240 578.125000 -50.667599 593.750000 -51.584862 609.375000 -48.992435 625.000000 -48.492191 640.625000 -49.701382 656.250000 -53.005512 671.875000 -54.269699 687.500000 -54.937397 703.125000 -53.922794 718.750000 -51.949009 734.375000 -52.763660 750.000000 -53.731155 765.625000 -54.977795 781.250000 -54.029835 796.875000 -54.375313 812.500000 -54.419693 828.125000 -54.796967 843.750000 -55.052872 859.375000 -53.625359 875.000000 -54.649513 890.625000 -56.736855 906.250000 -57.202946 921.875000 -56.587177 937.500000 -57.263260 953.125000 -56.744713 968.750000 -57.710808 984.375000 -58.118694 1000.000000 -60.595867 1015.625000 -60.736752 1031.250000 -57.966949 1046.875000 -58.101311 1062.500000 -59.093056 1078.125000 -59.889881 1093.750000 -59.972092 1109.375000 -59.728626 1125.000000 -58.060120 1140.625000 -56.506371 1156.250000 -55.109329 1171.875000 -54.278183 1187.500000 -56.115913 1203.125000 -57.535069 1218.750000 -58.304485 1234.375000 -58.614723 1250.000000 -58.873520 1265.625000 -61.268688 1281.250000 -62.702538 1296.875000 -63.828163 1312.500000 -63.712082 1328.125000 -65.020050 1343.750000 -64.481941 1359.375000 -62.652424 1375.000000 -61.640785 1390.625000 -61.719952 1406.250000 -61.451962 1421.875000 -58.490433 1437.500000 -57.193993 1453.125000 -56.973965 1468.750000 -57.940182 1484.375000 -59.935654 1500.000000 -61.829227 1515.625000 -63.259266 1531.250000 -62.169945 1546.875000 -61.958508 1562.500000 -62.018082 1578.125000 -60.562317 1593.750000 -59.146374 1609.375000 -58.868763 1625.000000 -60.028801 1640.625000 -59.241119 1656.250000 -60.101322 1671.875000 -60.429554 1687.500000 -60.538834 1703.125000 -61.073635 1718.750000 -60.375114 1734.375000 -60.152672 1750.000000 -59.529144 1765.625000 -59.783649 1781.250000 -61.850414 1796.875000 -63.506111 1812.500000 -63.869320 1828.125000 -62.442127 1843.750000 -62.519482 1859.375000 -63.814472 1875.000000 -63.300858 1890.625000 -61.998482 1906.250000 -62.199738 1921.875000 -61.745621 1937.500000 -61.611210 1953.125000 -61.174740 1968.750000 -60.504318 1984.375000 -60.277737 2000.000000 -61.696060 2015.625000 -61.693054 2031.250000 -62.755184 2046.875000 -63.983723 2062.500000 -63.584675 2078.125000 -62.943420 2093.750000 -63.238541 2109.375000 -62.929970 2125.000000 -62.243599 2140.625000 -60.967789 2156.250000 -60.915421 2171.875000 -61.997654 2187.500000 -63.702518 2203.125000 -64.316109 2218.750000 -63.577995 2234.375000 -63.250530 2250.000000 -63.107010 2265.625000 -62.953743 2281.250000 -62.933647 2296.875000 -61.956242 2312.500000 -62.948036 2328.125000 -64.375603 2343.750000 -64.296860 2359.375000 -63.552139 2375.000000 -62.556362 2390.625000 -62.979954 2406.250000 -64.505875 2421.875000 -65.626236 2437.500000 -65.732819 2453.125000 -66.130798 2468.750000 -65.920502 2484.375000 -64.183731 2500.000000 -63.387459 2515.625000 -63.110027 2531.250000 -64.085106 2546.875000 -64.269905 2562.500000 -64.181808 2578.125000 -64.600060 2593.750000 -63.998692 2609.375000 -63.854473 2625.000000 -65.015961 2640.625000 -65.751480 2656.250000 -66.293800 2671.875000 -66.494102 2687.500000 -66.300240 2703.125000 -66.383118 2718.750000 -66.466385 2734.375000 -65.733604 2750.000000 -65.110283 2765.625000 -65.537567 2781.250000 -66.125465 2796.875000 -65.979088 2812.500000 -64.833984 2828.125000 -63.773678 2843.750000 -64.419113 2859.375000 -64.800369 2875.000000 -64.710480 2890.625000 -64.088387 2906.250000 -64.790306 2921.875000 -65.160469 2937.500000 -65.285408 2953.125000 -66.030342 2968.750000 -65.027481 2984.375000 -64.623558 3000.000000 -65.082748 3015.625000 -63.680820 3031.250000 -62.836716 3046.875000 -62.210663 3062.500000 -61.578278 3078.125000 -62.397720 3093.750000 -63.185940 3109.375000 -62.439983 3125.000000 -62.382778 3140.625000 -63.123928 3156.250000 -64.276588 3171.875000 -65.444725 3187.500000 -65.891289 3203.125000 -65.480240 3218.750000 -64.761063 3234.375000 -65.140015 3250.000000 -66.010643 3265.625000 -66.964401 3281.250000 -67.296051 3296.875000 -66.430000 3312.500000 -66.564758 3328.125000 -67.878830 3343.750000 -67.748436 3359.375000 -68.965981 3375.000000 -70.426888 3390.625000 -71.400375 3406.250000 -72.067627 3421.875000 -71.944176 3437.500000 -72.285637 3453.125000 -71.983047 3468.750000 -72.565109 3484.375000 -72.350845 3500.000000 -72.335533 3515.625000 -72.608849 3531.250000 -72.417786 3546.875000 -73.100441 3562.500000 -73.461548 3578.125000 -73.558250 3593.750000 -73.218422 3609.375000 -73.994888 3625.000000 -74.379204 3640.625000 -74.896202 3656.250000 -74.944405 3671.875000 -74.958710 3687.500000 -75.029655 3703.125000 -74.314133 3718.750000 -74.855209 3734.375000 -76.021591 3750.000000 -76.441444 3765.625000 -77.122787 3781.250000 -77.733589 3796.875000 -79.138847 3812.500000 -80.206360 3828.125000 -80.391960 3843.750000 -81.214249 3859.375000 -81.434105 3875.000000 -82.234749 3890.625000 -82.529884 3906.250000 -82.929169 3921.875000 -83.735237 3937.500000 -84.770660 3953.125000 -84.203438 3968.750000 -84.455025 3984.375000 -85.116302
2012-03-27 09:50:40.412101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=320/320/2000 seq=38825 lw=28160 2012-03-27 09:50:40.433101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=480/480/2000 seq=38826 lw=28320 2012-03-27 09:50:40.454100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=640/640/2000 seq=38827 lw=28480 2012-03-27 09:50:40.475100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=800/800/2000 seq=38828 lw=28640 2012-03-27 09:50:40.496100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=960/960/2000 seq=38829 lw=28800 2012-03-27 09:50:40.517100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1120/1120/2000 seq=38830 lw=28960 2012-03-27 09:50:40.538100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1280/1280/2000 seq=38831 lw=29120 2012-03-27 09:50:40.559099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1440/1440/2000 seq=38832 lw=29280 2012-03-27 09:50:40.580099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1600/1600/2000 seq=38833 lw=29440 2012-03-27 09:50:40.601099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1760/1760/2000 seq=38834 lw=29600 2012-03-27 09:50:40.622098 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1920/1920/2000 seq=38835 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38836 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38837 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38838 lw=29760
Any ideas?
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 26 March 2012 18:39 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
On Mon, Mar 26, 2012 at 3:01 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: OK, call recording has been setup – waiting for it to happen now.
Interestingly, before I issue the “record_session” application (and of course the “RECORD_*” variables) I had to execute “ring_ready” then “pre_answer” otherwise the caller gets silence (changing the order of those two commands results in silence).
I find it odd that just doing a pre_answer wouldn't be sufficient. A pre_answer will send a 183 w/SDP whereas ring_ready simply sends a 180. In any case, I'm glad you got your recordings. I also find it curious that only the "letter" DTMFs are being detected. Let us know if you actually hear those tones in the audio stream.
-MC
---------------------------------------------------- Alternatives:
---------------------------------------------------- _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com
Afraid not, as per my first post we're using ISDN. Daniel Knaggs Software Developer Reality Solutions Ltd 1 Global Business Park Hamburg Road Kingston upon Hull East Yorkshire, HU7 0AE Tel: 01482 373104 Mobile: 07932 408313 Email: mailto:Daniel.Knaggs@realitysolutions.co.uk http:// -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of covici@ccs.covici.com Sent: 30 March 2012 12:11 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Maybe its generated by an ata box if you have an analog phone? Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk> wrote:
Any ideas, anyone?
[cid:imagefb5387.PNG@ca5d49be.4fa92b00]
Daniel Knaggs
Software Developer
Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________
Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire
[cid:image19a0f2.PNG@39ea781d.48900adc]
From: Daniel Knaggs Sent: 27 March 2012 10:22 To: 'FreeSWITCH Users Help' Subject: RE: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
OK, it does NOT appear in the recordings.
Here is a spectrum analysis of the call when it happened: -
Frequency (Hz) Level (dB) 15.625000 -59.445583 31.250000 -69.136353 46.875000 -71.569084 62.500000 -72.445877 78.125000 -67.142319 93.750000 -63.964447 109.375000 -61.157677 125.000000 -58.849174 140.625000 -62.083492 156.250000 -51.071819 171.875000 -48.957565 187.500000 -48.156109 203.125000 -48.908588 218.750000 -47.891460 234.375000 -46.257698 250.000000 -43.011139 265.625000 -48.706509 281.250000 -53.241238 296.875000 -52.513802 312.500000 -50.387054 328.125000 -53.275459 343.750000 -56.096489 359.375000 -54.788857 375.000000 -52.283993 390.625000 -50.975601 406.250000 -49.737530 421.875000 -49.870571 437.500000 -50.445431 453.125000 -50.647591 468.750000 -49.450035 484.375000 -48.767914 500.000000 -48.281902 515.625000 -49.419975 531.250000 -52.635048 546.875000 -52.856857 562.500000 -51.675240 578.125000 -50.667599 593.750000 -51.584862 609.375000 -48.992435 625.000000 -48.492191 640.625000 -49.701382 656.250000 -53.005512 671.875000 -54.269699 687.500000 -54.937397 703.125000 -53.922794 718.750000 -51.949009 734.375000 -52.763660 750.000000 -53.731155 765.625000 -54.977795 781.250000 -54.029835 796.875000 -54.375313 812.500000 -54.419693 828.125000 -54.796967 843.750000 -55.052872 859.375000 -53.625359 875.000000 -54.649513 890.625000 -56.736855 906.250000 -57.202946 921.875000 -56.587177 937.500000 -57.263260 953.125000 -56.744713 968.750000 -57.710808 984.375000 -58.118694 1000.000000 -60.595867 1015.625000 -60.736752 1031.250000 -57.966949 1046.875000 -58.101311 1062.500000 -59.093056 1078.125000 -59.889881 1093.750000 -59.972092 1109.375000 -59.728626 1125.000000 -58.060120 1140.625000 -56.506371 1156.250000 -55.109329 1171.875000 -54.278183 1187.500000 -56.115913 1203.125000 -57.535069 1218.750000 -58.304485 1234.375000 -58.614723 1250.000000 -58.873520 1265.625000 -61.268688 1281.250000 -62.702538 1296.875000 -63.828163 1312.500000 -63.712082 1328.125000 -65.020050 1343.750000 -64.481941 1359.375000 -62.652424 1375.000000 -61.640785 1390.625000 -61.719952 1406.250000 -61.451962 1421.875000 -58.490433 1437.500000 -57.193993 1453.125000 -56.973965 1468.750000 -57.940182 1484.375000 -59.935654 1500.000000 -61.829227 1515.625000 -63.259266 1531.250000 -62.169945 1546.875000 -61.958508 1562.500000 -62.018082 1578.125000 -60.562317 1593.750000 -59.146374 1609.375000 -58.868763 1625.000000 -60.028801 1640.625000 -59.241119 1656.250000 -60.101322 1671.875000 -60.429554 1687.500000 -60.538834 1703.125000 -61.073635 1718.750000 -60.375114 1734.375000 -60.152672 1750.000000 -59.529144 1765.625000 -59.783649 1781.250000 -61.850414 1796.875000 -63.506111 1812.500000 -63.869320 1828.125000 -62.442127 1843.750000 -62.519482 1859.375000 -63.814472 1875.000000 -63.300858 1890.625000 -61.998482 1906.250000 -62.199738 1921.875000 -61.745621 1937.500000 -61.611210 1953.125000 -61.174740 1968.750000 -60.504318 1984.375000 -60.277737 2000.000000 -61.696060 2015.625000 -61.693054 2031.250000 -62.755184 2046.875000 -63.983723 2062.500000 -63.584675 2078.125000 -62.943420 2093.750000 -63.238541 2109.375000 -62.929970 2125.000000 -62.243599 2140.625000 -60.967789 2156.250000 -60.915421 2171.875000 -61.997654 2187.500000 -63.702518 2203.125000 -64.316109 2218.750000 -63.577995 2234.375000 -63.250530 2250.000000 -63.107010 2265.625000 -62.953743 2281.250000 -62.933647 2296.875000 -61.956242 2312.500000 -62.948036 2328.125000 -64.375603 2343.750000 -64.296860 2359.375000 -63.552139 2375.000000 -62.556362 2390.625000 -62.979954 2406.250000 -64.505875 2421.875000 -65.626236 2437.500000 -65.732819 2453.125000 -66.130798 2468.750000 -65.920502 2484.375000 -64.183731 2500.000000 -63.387459 2515.625000 -63.110027 2531.250000 -64.085106 2546.875000 -64.269905 2562.500000 -64.181808 2578.125000 -64.600060 2593.750000 -63.998692 2609.375000 -63.854473 2625.000000 -65.015961 2640.625000 -65.751480 2656.250000 -66.293800 2671.875000 -66.494102 2687.500000 -66.300240 2703.125000 -66.383118 2718.750000 -66.466385 2734.375000 -65.733604 2750.000000 -65.110283 2765.625000 -65.537567 2781.250000 -66.125465 2796.875000 -65.979088 2812.500000 -64.833984 2828.125000 -63.773678 2843.750000 -64.419113 2859.375000 -64.800369 2875.000000 -64.710480 2890.625000 -64.088387 2906.250000 -64.790306 2921.875000 -65.160469 2937.500000 -65.285408 2953.125000 -66.030342 2968.750000 -65.027481 2984.375000 -64.623558 3000.000000 -65.082748 3015.625000 -63.680820 3031.250000 -62.836716 3046.875000 -62.210663 3062.500000 -61.578278 3078.125000 -62.397720 3093.750000 -63.185940 3109.375000 -62.439983 3125.000000 -62.382778 3140.625000 -63.123928 3156.250000 -64.276588 3171.875000 -65.444725 3187.500000 -65.891289 3203.125000 -65.480240 3218.750000 -64.761063 3234.375000 -65.140015 3250.000000 -66.010643 3265.625000 -66.964401 3281.250000 -67.296051 3296.875000 -66.430000 3312.500000 -66.564758 3328.125000 -67.878830 3343.750000 -67.748436 3359.375000 -68.965981 3375.000000 -70.426888 3390.625000 -71.400375 3406.250000 -72.067627 3421.875000 -71.944176 3437.500000 -72.285637 3453.125000 -71.983047 3468.750000 -72.565109 3484.375000 -72.350845 3500.000000 -72.335533 3515.625000 -72.608849 3531.250000 -72.417786 3546.875000 -73.100441 3562.500000 -73.461548 3578.125000 -73.558250 3593.750000 -73.218422 3609.375000 -73.994888 3625.000000 -74.379204 3640.625000 -74.896202 3656.250000 -74.944405 3671.875000 -74.958710 3687.500000 -75.029655 3703.125000 -74.314133 3718.750000 -74.855209 3734.375000 -76.021591 3750.000000 -76.441444 3765.625000 -77.122787 3781.250000 -77.733589 3796.875000 -79.138847 3812.500000 -80.206360 3828.125000 -80.391960 3843.750000 -81.214249 3859.375000 -81.434105 3875.000000 -82.234749 3890.625000 -82.529884 3906.250000 -82.929169 3921.875000 -83.735237 3937.500000 -84.770660 3953.125000 -84.203438 3968.750000 -84.455025 3984.375000 -85.116302
2012-03-27 09:50:40.412101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=320/320/2000 seq=38825 lw=28160 2012-03-27 09:50:40.433101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=480/480/2000 seq=38826 lw=28320 2012-03-27 09:50:40.454100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=640/640/2000 seq=38827 lw=28480 2012-03-27 09:50:40.475100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=800/800/2000 seq=38828 lw=28640 2012-03-27 09:50:40.496100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=960/960/2000 seq=38829 lw=28800 2012-03-27 09:50:40.517100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1120/1120/2000 seq=38830 lw=28960 2012-03-27 09:50:40.538100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1280/1280/2000 seq=38831 lw=29120 2012-03-27 09:50:40.559099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1440/1440/2000 seq=38832 lw=29280 2012-03-27 09:50:40.580099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1600/1600/2000 seq=38833 lw=29440 2012-03-27 09:50:40.601099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1760/1760/2000 seq=38834 lw=29600 2012-03-27 09:50:40.622098 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1920/1920/2000 seq=38835 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38836 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38837 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38838 lw=29760
Any ideas?
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 26 March 2012 18:39 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
On Mon, Mar 26, 2012 at 3:01 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: OK, call recording has been setup – waiting for it to happen now.
Interestingly, before I issue the “record_session” application (and of course the “RECORD_*” variables) I had to execute “ring_ready” then “pre_answer” otherwise the caller gets silence (changing the order of those two commands results in silence).
I find it odd that just doing a pre_answer wouldn't be sufficient. A pre_answer will send a 183 w/SDP whereas ring_ready simply sends a 180. In any case, I'm glad you got your recordings. I also find it curious that only the "letter" DTMFs are being detected. Let us know if you actually hear those tones in the audio stream.
-MC
---------------------------------------------------- Alternatives:
---------------------------------------------------- _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
but how are your phones connected to fs? Is it through any kind of equipment? Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk> wrote:
Afraid not, as per my first post we're using ISDN.
Daniel Knaggs Software Developer
Reality Solutions Ltd 1 Global Business Park Hamburg Road Kingston upon Hull East Yorkshire, HU7 0AE
Tel: 01482 373104 Mobile: 07932 408313 Email: mailto:Daniel.Knaggs@realitysolutions.co.uk http://
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of covici@ccs.covici.com Sent: 30 March 2012 12:11 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
Maybe its generated by an ata box if you have an analog phone?
Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk> wrote:
Any ideas, anyone?
[cid:imagefb5387.PNG@ca5d49be.4fa92b00]
Daniel Knaggs
Software Developer
Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________
Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire
[cid:image19a0f2.PNG@39ea781d.48900adc]
From: Daniel Knaggs Sent: 27 March 2012 10:22 To: 'FreeSWITCH Users Help' Subject: RE: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
OK, it does NOT appear in the recordings.
Here is a spectrum analysis of the call when it happened: -
Frequency (Hz) Level (dB) 15.625000 -59.445583 31.250000 -69.136353 46.875000 -71.569084 62.500000 -72.445877 78.125000 -67.142319 93.750000 -63.964447 109.375000 -61.157677 125.000000 -58.849174 140.625000 -62.083492 156.250000 -51.071819 171.875000 -48.957565 187.500000 -48.156109 203.125000 -48.908588 218.750000 -47.891460 234.375000 -46.257698 250.000000 -43.011139 265.625000 -48.706509 281.250000 -53.241238 296.875000 -52.513802 312.500000 -50.387054 328.125000 -53.275459 343.750000 -56.096489 359.375000 -54.788857 375.000000 -52.283993 390.625000 -50.975601 406.250000 -49.737530 421.875000 -49.870571 437.500000 -50.445431 453.125000 -50.647591 468.750000 -49.450035 484.375000 -48.767914 500.000000 -48.281902 515.625000 -49.419975 531.250000 -52.635048 546.875000 -52.856857 562.500000 -51.675240 578.125000 -50.667599 593.750000 -51.584862 609.375000 -48.992435 625.000000 -48.492191 640.625000 -49.701382 656.250000 -53.005512 671.875000 -54.269699 687.500000 -54.937397 703.125000 -53.922794 718.750000 -51.949009 734.375000 -52.763660 750.000000 -53.731155 765.625000 -54.977795 781.250000 -54.029835 796.875000 -54.375313 812.500000 -54.419693 828.125000 -54.796967 843.750000 -55.052872 859.375000 -53.625359 875.000000 -54.649513 890.625000 -56.736855 906.250000 -57.202946 921.875000 -56.587177 937.500000 -57.263260 953.125000 -56.744713 968.750000 -57.710808 984.375000 -58.118694 1000.000000 -60.595867 1015.625000 -60.736752 1031.250000 -57.966949 1046.875000 -58.101311 1062.500000 -59.093056 1078.125000 -59.889881 1093.750000 -59.972092 1109.375000 -59.728626 1125.000000 -58.060120 1140.625000 -56.506371 1156.250000 -55.109329 1171.875000 -54.278183 1187.500000 -56.115913 1203.125000 -57.535069 1218.750000 -58.304485 1234.375000 -58.614723 1250.000000 -58.873520 1265.625000 -61.268688 1281.250000 -62.702538 1296.875000 -63.828163 1312.500000 -63.712082 1328.125000 -65.020050 1343.750000 -64.481941 1359.375000 -62.652424 1375.000000 -61.640785 1390.625000 -61.719952 1406.250000 -61.451962 1421.875000 -58.490433 1437.500000 -57.193993 1453.125000 -56.973965 1468.750000 -57.940182 1484.375000 -59.935654 1500.000000 -61.829227 1515.625000 -63.259266 1531.250000 -62.169945 1546.875000 -61.958508 1562.500000 -62.018082 1578.125000 -60.562317 1593.750000 -59.146374 1609.375000 -58.868763 1625.000000 -60.028801 1640.625000 -59.241119 1656.250000 -60.101322 1671.875000 -60.429554 1687.500000 -60.538834 1703.125000 -61.073635 1718.750000 -60.375114 1734.375000 -60.152672 1750.000000 -59.529144 1765.625000 -59.783649 1781.250000 -61.850414 1796.875000 -63.506111 1812.500000 -63.869320 1828.125000 -62.442127 1843.750000 -62.519482 1859.375000 -63.814472 1875.000000 -63.300858 1890.625000 -61.998482 1906.250000 -62.199738 1921.875000 -61.745621 1937.500000 -61.611210 1953.125000 -61.174740 1968.750000 -60.504318 1984.375000 -60.277737 2000.000000 -61.696060 2015.625000 -61.693054 2031.250000 -62.755184 2046.875000 -63.983723 2062.500000 -63.584675 2078.125000 -62.943420 2093.750000 -63.238541 2109.375000 -62.929970 2125.000000 -62.243599 2140.625000 -60.967789 2156.250000 -60.915421 2171.875000 -61.997654 2187.500000 -63.702518 2203.125000 -64.316109 2218.750000 -63.577995 2234.375000 -63.250530 2250.000000 -63.107010 2265.625000 -62.953743 2281.250000 -62.933647 2296.875000 -61.956242 2312.500000 -62.948036 2328.125000 -64.375603 2343.750000 -64.296860 2359.375000 -63.552139 2375.000000 -62.556362 2390.625000 -62.979954 2406.250000 -64.505875 2421.875000 -65.626236 2437.500000 -65.732819 2453.125000 -66.130798 2468.750000 -65.920502 2484.375000 -64.183731 2500.000000 -63.387459 2515.625000 -63.110027 2531.250000 -64.085106 2546.875000 -64.269905 2562.500000 -64.181808 2578.125000 -64.600060 2593.750000 -63.998692 2609.375000 -63.854473 2625.000000 -65.015961 2640.625000 -65.751480 2656.250000 -66.293800 2671.875000 -66.494102 2687.500000 -66.300240 2703.125000 -66.383118 2718.750000 -66.466385 2734.375000 -65.733604 2750.000000 -65.110283 2765.625000 -65.537567 2781.250000 -66.125465 2796.875000 -65.979088 2812.500000 -64.833984 2828.125000 -63.773678 2843.750000 -64.419113 2859.375000 -64.800369 2875.000000 -64.710480 2890.625000 -64.088387 2906.250000 -64.790306 2921.875000 -65.160469 2937.500000 -65.285408 2953.125000 -66.030342 2968.750000 -65.027481 2984.375000 -64.623558 3000.000000 -65.082748 3015.625000 -63.680820 3031.250000 -62.836716 3046.875000 -62.210663 3062.500000 -61.578278 3078.125000 -62.397720 3093.750000 -63.185940 3109.375000 -62.439983 3125.000000 -62.382778 3140.625000 -63.123928 3156.250000 -64.276588 3171.875000 -65.444725 3187.500000 -65.891289 3203.125000 -65.480240 3218.750000 -64.761063 3234.375000 -65.140015 3250.000000 -66.010643 3265.625000 -66.964401 3281.250000 -67.296051 3296.875000 -66.430000 3312.500000 -66.564758 3328.125000 -67.878830 3343.750000 -67.748436 3359.375000 -68.965981 3375.000000 -70.426888 3390.625000 -71.400375 3406.250000 -72.067627 3421.875000 -71.944176 3437.500000 -72.285637 3453.125000 -71.983047 3468.750000 -72.565109 3484.375000 -72.350845 3500.000000 -72.335533 3515.625000 -72.608849 3531.250000 -72.417786 3546.875000 -73.100441 3562.500000 -73.461548 3578.125000 -73.558250 3593.750000 -73.218422 3609.375000 -73.994888 3625.000000 -74.379204 3640.625000 -74.896202 3656.250000 -74.944405 3671.875000 -74.958710 3687.500000 -75.029655 3703.125000 -74.314133 3718.750000 -74.855209 3734.375000 -76.021591 3750.000000 -76.441444 3765.625000 -77.122787 3781.250000 -77.733589 3796.875000 -79.138847 3812.500000 -80.206360 3828.125000 -80.391960 3843.750000 -81.214249 3859.375000 -81.434105 3875.000000 -82.234749 3890.625000 -82.529884 3906.250000 -82.929169 3921.875000 -83.735237 3937.500000 -84.770660 3953.125000 -84.203438 3968.750000 -84.455025 3984.375000 -85.116302
2012-03-27 09:50:40.412101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=320/320/2000 seq=38825 lw=28160 2012-03-27 09:50:40.433101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=480/480/2000 seq=38826 lw=28320 2012-03-27 09:50:40.454100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=640/640/2000 seq=38827 lw=28480 2012-03-27 09:50:40.475100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=800/800/2000 seq=38828 lw=28640 2012-03-27 09:50:40.496100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=960/960/2000 seq=38829 lw=28800 2012-03-27 09:50:40.517100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1120/1120/2000 seq=38830 lw=28960 2012-03-27 09:50:40.538100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1280/1280/2000 seq=38831 lw=29120 2012-03-27 09:50:40.559099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1440/1440/2000 seq=38832 lw=29280 2012-03-27 09:50:40.580099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1600/1600/2000 seq=38833 lw=29440 2012-03-27 09:50:40.601099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1760/1760/2000 seq=38834 lw=29600 2012-03-27 09:50:40.622098 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1920/1920/2000 seq=38835 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38836 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38837 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38838 lw=29760
Any ideas?
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 26 March 2012 18:39 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
On Mon, Mar 26, 2012 at 3:01 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: OK, call recording has been setup – waiting for it to happen now.
Interestingly, before I issue the “record_session” application (and of course the “RECORD_*” variables) I had to execute “ring_ready” then “pre_answer” otherwise the caller gets silence (changing the order of those two commands results in silence).
I find it odd that just doing a pre_answer wouldn't be sufficient. A pre_answer will send a 183 w/SDP whereas ring_ready simply sends a 180. In any case, I'm glad you got your recordings. I also find it curious that only the "letter" DTMFs are being detected. Let us know if you actually hear those tones in the audio stream.
-MC
---------------------------------------------------- Alternatives:
---------------------------------------------------- _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it?
John Covici covici@ccs.covici.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com
ISDN -> TE121 -> FS -> PoE -> VoIP phone (LinkSys SPA942/962). Log states its coming IN from the card, not generated by the phones here. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of covici@ccs.covici.com Sent: 30 March 2012 12:59 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls but how are your phones connected to fs? Is it through any kind of equipment? Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk> wrote:
Afraid not, as per my first post we're using ISDN.
Daniel Knaggs Software Developer
Reality Solutions Ltd 1 Global Business Park Hamburg Road Kingston upon Hull East Yorkshire, HU7 0AE
Tel: 01482 373104 Mobile: 07932 408313 Email: mailto:Daniel.Knaggs@realitysolutions.co.uk http://
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of covici@ccs.covici.com Sent: 30 March 2012 12:11 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
Maybe its generated by an ata box if you have an analog phone?
Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk> wrote:
Any ideas, anyone?
[cid:imagefb5387.PNG@ca5d49be.4fa92b00]
Daniel Knaggs
Software Developer
Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________
Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire
[cid:image19a0f2.PNG@39ea781d.48900adc]
From: Daniel Knaggs Sent: 27 March 2012 10:22 To: 'FreeSWITCH Users Help' Subject: RE: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
OK, it does NOT appear in the recordings.
Here is a spectrum analysis of the call when it happened: -
Frequency (Hz) Level (dB) 15.625000 -59.445583 31.250000 -69.136353 46.875000 -71.569084 62.500000 -72.445877 78.125000 -67.142319 93.750000 -63.964447 109.375000 -61.157677 125.000000 -58.849174 140.625000 -62.083492 156.250000 -51.071819 171.875000 -48.957565 187.500000 -48.156109 203.125000 -48.908588 218.750000 -47.891460 234.375000 -46.257698 250.000000 -43.011139 265.625000 -48.706509 281.250000 -53.241238 296.875000 -52.513802 312.500000 -50.387054 328.125000 -53.275459 343.750000 -56.096489 359.375000 -54.788857 375.000000 -52.283993 390.625000 -50.975601 406.250000 -49.737530 421.875000 -49.870571 437.500000 -50.445431 453.125000 -50.647591 468.750000 -49.450035 484.375000 -48.767914 500.000000 -48.281902 515.625000 -49.419975 531.250000 -52.635048 546.875000 -52.856857 562.500000 -51.675240 578.125000 -50.667599 593.750000 -51.584862 609.375000 -48.992435 625.000000 -48.492191 640.625000 -49.701382 656.250000 -53.005512 671.875000 -54.269699 687.500000 -54.937397 703.125000 -53.922794 718.750000 -51.949009 734.375000 -52.763660 750.000000 -53.731155 765.625000 -54.977795 781.250000 -54.029835 796.875000 -54.375313 812.500000 -54.419693 828.125000 -54.796967 843.750000 -55.052872 859.375000 -53.625359 875.000000 -54.649513 890.625000 -56.736855 906.250000 -57.202946 921.875000 -56.587177 937.500000 -57.263260 953.125000 -56.744713 968.750000 -57.710808 984.375000 -58.118694 1000.000000 -60.595867 1015.625000 -60.736752 1031.250000 -57.966949 1046.875000 -58.101311 1062.500000 -59.093056 1078.125000 -59.889881 1093.750000 -59.972092 1109.375000 -59.728626 1125.000000 -58.060120 1140.625000 -56.506371 1156.250000 -55.109329 1171.875000 -54.278183 1187.500000 -56.115913 1203.125000 -57.535069 1218.750000 -58.304485 1234.375000 -58.614723 1250.000000 -58.873520 1265.625000 -61.268688 1281.250000 -62.702538 1296.875000 -63.828163 1312.500000 -63.712082 1328.125000 -65.020050 1343.750000 -64.481941 1359.375000 -62.652424 1375.000000 -61.640785 1390.625000 -61.719952 1406.250000 -61.451962 1421.875000 -58.490433 1437.500000 -57.193993 1453.125000 -56.973965 1468.750000 -57.940182 1484.375000 -59.935654 1500.000000 -61.829227 1515.625000 -63.259266 1531.250000 -62.169945 1546.875000 -61.958508 1562.500000 -62.018082 1578.125000 -60.562317 1593.750000 -59.146374 1609.375000 -58.868763 1625.000000 -60.028801 1640.625000 -59.241119 1656.250000 -60.101322 1671.875000 -60.429554 1687.500000 -60.538834 1703.125000 -61.073635 1718.750000 -60.375114 1734.375000 -60.152672 1750.000000 -59.529144 1765.625000 -59.783649 1781.250000 -61.850414 1796.875000 -63.506111 1812.500000 -63.869320 1828.125000 -62.442127 1843.750000 -62.519482 1859.375000 -63.814472 1875.000000 -63.300858 1890.625000 -61.998482 1906.250000 -62.199738 1921.875000 -61.745621 1937.500000 -61.611210 1953.125000 -61.174740 1968.750000 -60.504318 1984.375000 -60.277737 2000.000000 -61.696060 2015.625000 -61.693054 2031.250000 -62.755184 2046.875000 -63.983723 2062.500000 -63.584675 2078.125000 -62.943420 2093.750000 -63.238541 2109.375000 -62.929970 2125.000000 -62.243599 2140.625000 -60.967789 2156.250000 -60.915421 2171.875000 -61.997654 2187.500000 -63.702518 2203.125000 -64.316109 2218.750000 -63.577995 2234.375000 -63.250530 2250.000000 -63.107010 2265.625000 -62.953743 2281.250000 -62.933647 2296.875000 -61.956242 2312.500000 -62.948036 2328.125000 -64.375603 2343.750000 -64.296860 2359.375000 -63.552139 2375.000000 -62.556362 2390.625000 -62.979954 2406.250000 -64.505875 2421.875000 -65.626236 2437.500000 -65.732819 2453.125000 -66.130798 2468.750000 -65.920502 2484.375000 -64.183731 2500.000000 -63.387459 2515.625000 -63.110027 2531.250000 -64.085106 2546.875000 -64.269905 2562.500000 -64.181808 2578.125000 -64.600060 2593.750000 -63.998692 2609.375000 -63.854473 2625.000000 -65.015961 2640.625000 -65.751480 2656.250000 -66.293800 2671.875000 -66.494102 2687.500000 -66.300240 2703.125000 -66.383118 2718.750000 -66.466385 2734.375000 -65.733604 2750.000000 -65.110283 2765.625000 -65.537567 2781.250000 -66.125465 2796.875000 -65.979088 2812.500000 -64.833984 2828.125000 -63.773678 2843.750000 -64.419113 2859.375000 -64.800369 2875.000000 -64.710480 2890.625000 -64.088387 2906.250000 -64.790306 2921.875000 -65.160469 2937.500000 -65.285408 2953.125000 -66.030342 2968.750000 -65.027481 2984.375000 -64.623558 3000.000000 -65.082748 3015.625000 -63.680820 3031.250000 -62.836716 3046.875000 -62.210663 3062.500000 -61.578278 3078.125000 -62.397720 3093.750000 -63.185940 3109.375000 -62.439983 3125.000000 -62.382778 3140.625000 -63.123928 3156.250000 -64.276588 3171.875000 -65.444725 3187.500000 -65.891289 3203.125000 -65.480240 3218.750000 -64.761063 3234.375000 -65.140015 3250.000000 -66.010643 3265.625000 -66.964401 3281.250000 -67.296051 3296.875000 -66.430000 3312.500000 -66.564758 3328.125000 -67.878830 3343.750000 -67.748436 3359.375000 -68.965981 3375.000000 -70.426888 3390.625000 -71.400375 3406.250000 -72.067627 3421.875000 -71.944176 3437.500000 -72.285637 3453.125000 -71.983047 3468.750000 -72.565109 3484.375000 -72.350845 3500.000000 -72.335533 3515.625000 -72.608849 3531.250000 -72.417786 3546.875000 -73.100441 3562.500000 -73.461548 3578.125000 -73.558250 3593.750000 -73.218422 3609.375000 -73.994888 3625.000000 -74.379204 3640.625000 -74.896202 3656.250000 -74.944405 3671.875000 -74.958710 3687.500000 -75.029655 3703.125000 -74.314133 3718.750000 -74.855209 3734.375000 -76.021591 3750.000000 -76.441444 3765.625000 -77.122787 3781.250000 -77.733589 3796.875000 -79.138847 3812.500000 -80.206360 3828.125000 -80.391960 3843.750000 -81.214249 3859.375000 -81.434105 3875.000000 -82.234749 3890.625000 -82.529884 3906.250000 -82.929169 3921.875000 -83.735237 3937.500000 -84.770660 3953.125000 -84.203438 3968.750000 -84.455025 3984.375000 -85.116302
2012-03-27 09:50:40.412101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=320/320/2000 seq=38825 lw=28160 2012-03-27 09:50:40.433101 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=480/480/2000 seq=38826 lw=28320 2012-03-27 09:50:40.454100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=640/640/2000 seq=38827 lw=28480 2012-03-27 09:50:40.475100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=800/800/2000 seq=38828 lw=28640 2012-03-27 09:50:40.496100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=960/960/2000 seq=38829 lw=28800 2012-03-27 09:50:40.517100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1120/1120/2000 seq=38830 lw=28960 2012-03-27 09:50:40.538100 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1280/1280/2000 seq=38831 lw=29120 2012-03-27 09:50:40.559099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1440/1440/2000 seq=38832 lw=29280 2012-03-27 09:50:40.580099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1600/1600/2000 seq=38833 lw=29440 2012-03-27 09:50:40.601099 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1760/1760/2000 seq=38834 lw=29600 2012-03-27 09:50:40.622098 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=28000 dur=1920/1920/2000 seq=38835 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38836 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38837 lw=29760 2012-03-27 09:50:40.643098 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=28000 dur=2080/2080/2000 seq=38838 lw=29760
Any ideas?
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 26 March 2012 18:39 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls
On Mon, Mar 26, 2012 at 3:01 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: OK, call recording has been setup – waiting for it to happen now.
Interestingly, before I issue the “record_session” application (and of course the “RECORD_*” variables) I had to execute “ring_ready” then “pre_answer” otherwise the caller gets silence (changing the order of those two commands results in silence).
I find it odd that just doing a pre_answer wouldn't be sufficient. A pre_answer will send a 183 w/SDP whereas ring_ready simply sends a 180. In any case, I'm glad you got your recordings. I also find it curious that only the "letter" DTMFs are being detected. Let us know if you actually hear those tones in the audio stream.
-MC
---------------------------------------------------- Alternatives:
---------------------------------------------------- _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it?
John Covici covici@ccs.covici.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
-- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici covici@ccs.covici.com _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
On Fri, Mar 30, 2012 at 2:16 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
Any ideas, anyone?
I'll be honest. I haven't followed the thread because of the loud, in-your-face advertisement in the email footer. Nobody is going to make you remove it, but they might respond to more of your emails if you show them that you respect the list by not cluttering it with noise. Just my 2 cents. And of course good luck on the issue. Gabe
I appreciate your honesty, Gabe. But seriously, is that the reason no-one else is responding or is it because no-one has any ideas? Unfortunately, I don’t (and can’t) control what appears on my signature as it’s added by our e-mail gateway not my e-mail client (if it can’t see a signature on the e-mail it will add it). From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Gabriel Gunderson Sent: 31 March 2012 09:12 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls On Fri, Mar 30, 2012 at 2:16 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Any ideas, anyone? I'll be honest. I haven't followed the thread because of the loud, in-your-face advertisement in the email footer. Nobody is going to make you remove it, but they might respond to more of your emails if you show them that you respect the list by not cluttering it with noise. Just my 2 cents. And of course good luck on the issue. Gabe [cid:image92a6e6.PNG@a012bb36.4aabcf94] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:image3dcd97.PNG@2cd2cd92.4fa6ec40]
If all you wish is to purge the tones from your stream you can simply capture them in the dialplan, no need to mess with the source... Best, Wesley Akio Em 02/04/2012 05:17, "Daniel Knaggs" <Daniel.Knaggs@realitysolutions.co.uk> escreveu:
I appreciate your honesty, Gabe. But seriously, is that the reason no-one else is responding or is it because no-one has any ideas?****
** **
Unfortunately, I don’t (and can’t) control what appears on my signature as it’s added by our e-mail gateway not my e-mail client (if it can’t see a signature on the e-mail it will add it).****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Gabriel Gunderson *Sent:* 31 March 2012 09:12 *To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls****
** **
On Fri, Mar 30, 2012 at 2:16 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:****
Any ideas, anyone?****
** **
I'll be honest. I haven't followed the thread because of the loud, in-your-face advertisement in the email footer. Nobody is going to make you remove it, but they might respond to more of your emails if you show them that you respect the list by not cluttering it with noise.****
** **
Just my 2 cents. And of course good luck on the issue.****
** **
** **
Gabe****
Daniel Knaggs
Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk www.realitysolutions.co.uk ------------------------------ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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
Interesting, how would I do this? Can't use "bind_meta_app" since that only works with numbers... The tones appear from the caller not the callee (leg A). From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Wesley Akio Sent: 02 April 2012 12:57 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls If all you wish is to purge the tones from your stream you can simply capture them in the dialplan, no need to mess with the source... Best, Wesley Akio Em 02/04/2012 05:17, "Daniel Knaggs" <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> escreveu: I appreciate your honesty, Gabe. But seriously, is that the reason no-one else is responding or is it because no-one has any ideas? Unfortunately, I don't (and can't) control what appears on my signature as it's added by our e-mail gateway not my e-mail client (if it can't see a signature on the e-mail it will add it). From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Gabriel Gunderson Sent: 31 March 2012 09:12 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls On Fri, Mar 30, 2012 at 2:16 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Any ideas, anyone? I'll be honest. I haven't followed the thread because of the loud, in-your-face advertisement in the email footer. Nobody is going to make you remove it, but they might respond to more of your emails if you show them that you respect the list by not cluttering it with noise. Just my 2 cents. And of course good luck on the issue. Gabe [cid:image001.png@01CD10D4.AF0ABC80] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:image002.png@01CD10D4.AF0ABC80] _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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
Maybe bind_digit_action would capture these for you. You could try binding something simple, like a log function: <action application="bind_digit_action" data="rogue_dtmf,~\w+,exec:log,INFO Rogue digit(s): ${last_matching_digits}"/> <action application="digit_action_set_realm" data="rogue_dtmf"/> You'll need to experiment to make sure that regex works. If not you could possibly do each digit explicity, like this: <action application="bind_digit_action" data="rogue_dtmf,A,exec:log,INFO Rogue digit: DTMF 'A' received"/> <action application="bind_digit_action" data="rogue_dtmf,B,exec:log,INFO Rogue digit: DTMF 'B' received"/> <action application="bind_digit_action" data="rogue_dtmf,C,exec:log,INFO Rogue digit: DTMF 'C' received"/> <action application="bind_digit_action" data="rogue_dtmf,D,exec:log,INFO Rogue digit: DTMF 'D' received"/> I don't honestly know if this will work, but I'd like to see what happens in your case. FYI, you can read up on bind_digit_action (AKA 'bda') here: http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_bind_digit_action -MC On Mon, Apr 2, 2012 at 5:29 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
Interesting, how would I do this? Can’t use “bind_meta_app” since that only works with numbers… The tones appear from the caller not the callee (leg A).****
** **
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Wesley Akio *Sent:* 02 April 2012 12:57
*To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls****
** **
If all you wish is to purge the tones from your stream you can simply capture them in the dialplan, no need to mess with the source...****
Best,****
Wesley Akio****
Em 02/04/2012 05:17, "Daniel Knaggs" <Daniel.Knaggs@realitysolutions.co.uk> escreveu:****
I appreciate your honesty, Gabe. But seriously, is that the reason no-one else is responding or is it because no-one has any ideas?****
****
Unfortunately, I don’t (and can’t) control what appears on my signature as it’s added by our e-mail gateway not my e-mail client (if it can’t see a signature on the e-mail it will add it).****
****
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Gabriel Gunderson *Sent:* 31 March 2012 09:12 *To:* FreeSWITCH Users Help *Subject:* Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls****
****
On Fri, Mar 30, 2012 at 2:16 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:****
Any ideas, anyone?****
****
I'll be honest. I haven't followed the thread because of the loud, in-your-face advertisement in the email footer. Nobody is going to make you remove it, but they might respond to more of your emails if you show them that you respect the list by not cluttering it with noise.****
****
Just my 2 cents. And of course good luck on the issue.****
****
OK, I’ve added the BDA’s to the ISDN dialplan and removed my binding for parking calls (no-one uses that apart from me – I find it very useful!). Let’s see what happens… From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 02 April 2012 16:44 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Maybe bind_digit_action would capture these for you. You could try binding something simple, like a log function: <action application="bind_digit_action" data="rogue_dtmf,~\w+,exec:log,INFO Rogue digit(s): ${last_matching_digits}"/> <action application="digit_action_set_realm" data="rogue_dtmf"/> You'll need to experiment to make sure that regex works. If not you could possibly do each digit explicity, like this: <action application="bind_digit_action" data="rogue_dtmf,A,exec:log,INFO Rogue digit: DTMF 'A' received"/> <action application="bind_digit_action" data="rogue_dtmf,B,exec:log,INFO Rogue digit: DTMF 'B' received"/> <action application="bind_digit_action" data="rogue_dtmf,C,exec:log,INFO Rogue digit: DTMF 'C' received"/> <action application="bind_digit_action" data="rogue_dtmf,D,exec:log,INFO Rogue digit: DTMF 'D' received"/> I don't honestly know if this will work, but I'd like to see what happens in your case. FYI, you can read up on bind_digit_action (AKA 'bda') here: http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_bind_digit_action -MC On Mon, Apr 2, 2012 at 5:29 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Interesting, how would I do this? Can’t use “bind_meta_app” since that only works with numbers… The tones appear from the caller not the callee (leg A). From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Wesley Akio Sent: 02 April 2012 12:57 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls If all you wish is to purge the tones from your stream you can simply capture them in the dialplan, no need to mess with the source... Best, Wesley Akio Em 02/04/2012 05:17, "Daniel Knaggs" <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> escreveu: I appreciate your honesty, Gabe. But seriously, is that the reason no-one else is responding or is it because no-one has any ideas? Unfortunately, I don’t (and can’t) control what appears on my signature as it’s added by our e-mail gateway not my e-mail client (if it can’t see a signature on the e-mail it will add it). From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Gabriel Gunderson Sent: 31 March 2012 09:12 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls On Fri, Mar 30, 2012 at 2:16 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Any ideas, anyone? I'll be honest. I haven't followed the thread because of the loud, in-your-face advertisement in the email footer. Nobody is going to make you remove it, but they might respond to more of your emails if you show them that you respect the list by not cluttering it with noise. Just my 2 cents. And of course good luck on the issue. [cid:image5fa413.PNG@9c8709cb.4997c030] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:imagefa91bb.PNG@9afe2a85.4ea36f51]
Update, it would appear (so far) that this has worked. I can see in the log numerous “Rogue digit: DTMF 'A' received” entries (and also for “C”) and I’ve asked the users if they have heard any more tones and they haven’t. Thanks, Michael. So we’ve managed to work around it, but how can I track down what is generating these tones to begin with? Is my earlier spectrum analysis of a call any good? [cid:image83f6e1.PNG@df16e8b7.49bddf57] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:image6ddd5c.PNG@d6dd7aa3.468d7b5a] From: Daniel Knaggs Sent: 03 April 2012 11:23 To: 'FreeSWITCH Users Help' Subject: RE: [Freeswitch-users] Strange DTMF Tones On Inbound Calls OK, I’ve added the BDA’s to the ISDN dialplan and removed my binding for parking calls (no-one uses that apart from me – I find it very useful!). Let’s see what happens… From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org]<mailto:[mailto:freeswitch-users-bounces@lists.freeswitch.org]> On Behalf Of Michael Collins Sent: 02 April 2012 16:44 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Maybe bind_digit_action would capture these for you. You could try binding something simple, like a log function: <action application="bind_digit_action" data="rogue_dtmf,~\w+,exec:log,INFO Rogue digit(s): ${last_matching_digits}"/> <action application="digit_action_set_realm" data="rogue_dtmf"/> You'll need to experiment to make sure that regex works. If not you could possibly do each digit explicity, like this: <action application="bind_digit_action" data="rogue_dtmf,A,exec:log,INFO Rogue digit: DTMF 'A' received"/> <action application="bind_digit_action" data="rogue_dtmf,B,exec:log,INFO Rogue digit: DTMF 'B' received"/> <action application="bind_digit_action" data="rogue_dtmf,C,exec:log,INFO Rogue digit: DTMF 'C' received"/> <action application="bind_digit_action" data="rogue_dtmf,D,exec:log,INFO Rogue digit: DTMF 'D' received"/> I don't honestly know if this will work, but I'd like to see what happens in your case. FYI, you can read up on bind_digit_action (AKA 'bda') here: http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_bind_digit_action -MC On Mon, Apr 2, 2012 at 5:29 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Interesting, how would I do this? Can’t use “bind_meta_app” since that only works with numbers… The tones appear from the caller not the callee (leg A). From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Wesley Akio Sent: 02 April 2012 12:57 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls If all you wish is to purge the tones from your stream you can simply capture them in the dialplan, no need to mess with the source... Best, Wesley Akio Em 02/04/2012 05:17, "Daniel Knaggs" <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> escreveu: I appreciate your honesty, Gabe. But seriously, is that the reason no-one else is responding or is it because no-one has any ideas? Unfortunately, I don’t (and can’t) control what appears on my signature as it’s added by our e-mail gateway not my e-mail client (if it can’t see a signature on the e-mail it will add it). From: freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] On Behalf Of Gabriel Gunderson Sent: 31 March 2012 09:12 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls On Fri, Mar 30, 2012 at 2:16 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Any ideas, anyone? I'll be honest. I haven't followed the thread because of the loud, in-your-face advertisement in the email footer. Nobody is going to make you remove it, but they might respond to more of your emails if you show them that you respect the list by not cluttering it with noise. Just my 2 cents. And of course good luck on the issue.
On Tue, Apr 3, 2012 at 8:17 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
Update, it would appear (so far) that this has worked.****
** **
I can see in the log numerous “Rogue digit: DTMF 'A' received” entries (and also for “C”) and I’ve asked the users if they have heard any more tones and they haven’t.****
** **
** **
Thanks, Michael. So we’ve managed to work around it, but how can I track down what is generating these tones to begin with? Is my earlier spectrum analysis of a call any good?
I don't think we ever truly answered the question of whether or not these rogue digits are phantoms. Remind me: how did you capture the audio on which you did the spectrum analysis? I recommend using ftdm dump, which is nice because it captures raw audio in either direction, and if I understand correctly it is what's "on the line" - if those rogue digits are coming from the other end they'll show up in the raw dump. If those digits are not in the raw audio then most likely you're looking at a false positive from the DTMF detector, in which case you've got a bit of a conundrum because you've got hardware from Digium and software from Sangoma and you need to figure out where to begin looking... BTW, feel free to keep the BDA's in there and just add your transfer digits to the digit action realm and you can avoid using bind meta app. BDA is the preferred method nowadays. -MC
Audio was captured using “record_session” where it didn’t appear in the audio by “ear”. “ftdm dump” displays details about the span I tell it to: - span_id: 1 chan_id: 1 physical_span_id: 1 physical_chan_id: 1 physical_status: ok physical_status_red: 0 physical_status_yellow: 0 physical_status_rai: 0 physical_status_blue: 0 physical_status_ais: 0 physical_status_general: 0 signaling_status: UP type: B state: DOWN last_state: HANGUP_COMPLETE txgain: 0.00 rxgain: 0.00 cid_date: cid_name: cid_num: ani: aniII: dnis: rdnis: cause: NONE session: (none) etc… From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 03 April 2012 16:31 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls On Tue, Apr 3, 2012 at 8:17 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Update, it would appear (so far) that this has worked. I can see in the log numerous “Rogue digit: DTMF 'A' received” entries (and also for “C”) and I’ve asked the users if they have heard any more tones and they haven’t. Thanks, Michael. So we’ve managed to work around it, but how can I track down what is generating these tones to begin with? Is my earlier spectrum analysis of a call any good? I don't think we ever truly answered the question of whether or not these rogue digits are phantoms. Remind me: how did you capture the audio on which you did the spectrum analysis? I recommend using ftdm dump, which is nice because it captures raw audio in either direction, and if I understand correctly it is what's "on the line" - if those rogue digits are coming from the other end they'll show up in the raw dump. If those digits are not in the raw audio then most likely you're looking at a false positive from the DTMF detector, in which case you've got a bit of a conundrum because you've got hardware from Digium and software from Sangoma and you need to figure out where to begin looking... BTW, feel free to keep the BDA's in there and just add your transfer digits to the digit action realm and you can avoid using bind meta app. BDA is the preferred method nowadays. -MC [cid:image23c8a0.PNG@a0d20f22.44823835] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:imagee8ba2d.PNG@2a4e8ae6.4a92bc17]
Oops, mea culpa! I meant "ftdm trace" which will record the audio on a whole span or a single channel depending on the args. -MC On Tue, Apr 3, 2012 at 8:52 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
Audio was captured using “record_session” where it didn’t appear in the audio by “ear”.****
** **
“ftdm dump” displays details about the span I tell it to: -****
** **
span_id: 1****
chan_id: 1****
physical_span_id: 1****
physical_chan_id: 1****
physical_status: ok****
physical_status_red: 0****
physical_status_yellow: 0****
physical_status_rai: 0****
physical_status_blue: 0****
physical_status_ais: 0****
physical_status_general: 0****
signaling_status: UP****
type: B****
state: DOWN****
last_state: HANGUP_COMPLETE****
txgain: 0.00****
rxgain: 0.00****
cid_date:****
cid_name:****
cid_num:****
ani:****
aniII:****
dnis:****
rdnis:****
cause: NONE****
session: (none)****
** **
etc…****
OK, it’s now tracing on the entire span. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 03 April 2012 18:24 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Oops, mea culpa! I meant "ftdm trace" which will record the audio on a whole span or a single channel depending on the args. -MC On Tue, Apr 3, 2012 at 8:52 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Audio was captured using “record_session” where it didn’t appear in the audio by “ear”. “ftdm dump” displays details about the span I tell it to: - span_id: 1 chan_id: 1 physical_span_id: 1 physical_chan_id: 1 physical_status: ok physical_status_red: 0 physical_status_yellow: 0 physical_status_rai: 0 physical_status_blue: 0 physical_status_ais: 0 physical_status_general: 0 signaling_status: UP type: B state: DOWN last_state: HANGUP_COMPLETE txgain: 0.00 rxgain: 0.00 cid_date: cid_name: cid_num: ani: aniII: dnis: rdnis: cause: NONE session: (none) etc… [cid:imagece0f1a.PNG@964b0c37.4ba96b9a] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:image560aed.PNG@0dbfbf14.49bc30d0]
Hi, I am new to freeswitch. I am trying to accomplish the following - during registration our proprietary client sends a username and session id to freeswitch. Freeswitch then queries a webserver using xml_curl to authenticate the username and session id. Is this possible? Can we use mod_xml_curl to send a session id? If so how? Also, I am using a simple TCP server for a dummy webserver. Do XML responses from the TCP server have to be wrapped in HTTP POST? Regards, --Ashish
On Wed, Apr 4, 2012 at 4:17 AM, Ashish Lal <ashishlal.work@gmail.com> wrote:
Freeswitch then queries a webserver using xml_curl to authenticate the username and session id. Is this possible? Can we use mod_xml_curl to send a session id? If so how?
This should get you started: http://wiki.freeswitch.org/wiki/Mod_xml_curl#bindings.3D.22directory.22
Also, I am using a simple TCP server for a dummy webserver. Do XML responses from the TCP server have to be wrapped in HTTP POST?
It's FreeSWITCH doing an HTTP POST to a web server and then the web server responding with XML over HTTP. You're going to love it for its power and flexibility. Good luck, happy hacking and welcome to FreeSWITCH! Best, Gabe
Update, it’s happened while tracing on span 1:4 so I’ve copied the in-s1c4 and out-s1c4 files – trace is still running. The call was inbound. Also it appears we’re now seeing other DTMF tones in coming in as well (numbers when they haven’t been pressed on the remote end)… Which files do you want and where you want them? [cid:imagef33cff.PNG@b3127936.47b0e8b1] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:image2982b3.PNG@d5b7f3a2.42a6f2fb] From: Daniel Knaggs Sent: 04 April 2012 10:52 To: 'FreeSWITCH Users Help' Subject: RE: [Freeswitch-users] Strange DTMF Tones On Inbound Calls OK, it’s now tracing on the entire span. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 03 April 2012 18:24 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Oops, mea culpa! I meant "ftdm trace" which will record the audio on a whole span or a single channel depending on the args. -MC On Tue, Apr 3, 2012 at 8:52 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Audio was captured using “record_session” where it didn’t appear in the audio by “ear”. “ftdm dump” displays details about the span I tell it to: - span_id: 1 chan_id: 1 physical_span_id: 1 physical_chan_id: 1 physical_status: ok physical_status_red: 0 physical_status_yellow: 0 physical_status_rai: 0 physical_status_blue: 0 physical_status_ais: 0 physical_status_general: 0 signaling_status: UP type: B state: DOWN last_state: HANGUP_COMPLETE txgain: 0.00 rxgain: 0.00 cid_date: cid_name: cid_num: ani: aniII: dnis: rdnis: cause: NONE session: (none) etc…
On 04/04/2012 12:25 PM, Daniel Knaggs wrote: As has been hinted before, would you mind no longer sending that over the top email signature? Every time I see it I ignore or even delete the email. And I doubt I'm the only one. If it's your company's policy to insist on sending such a signature (so you can't disable it) then just get a Gmail account and subscribe to the list from your Gmail account. Easier on the eyes of the list subscribers and you might even get an answer to your question :-) Thanks, Patrick
On Wed, Apr 4, 2012 at 3:25 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
Update, it’s happened while tracing on span 1:4 so I’ve copied the in-s1c4 and out-s1c4 files – trace is still running. The call was inbound. ****
** **
Also it appears we’re now seeing other DTMF tones in coming in as well (numbers when they haven’t been pressed on the remote end)…****
** **
** **
Which files do you want and where you want them?****
**
I recommend that you open a ticket w/ Sangoma and ask them to analyze the traces. The critical thing is to find out if these are false positives, phantoms, or stuff actually coming down the line from the carrier. I think Sangoma is in the best position to help. -MC P.S. - Regarding the footer - yes, it is annoying, but if you can't turn it off then you can't turn it off. I recommend doing what Patrick suggests and getting a gmail account so that you can be free of the footer spam. If you *really* want to help us out, I'd say investigate the Mailman project and see if it has a feature that can auto-strip the junk off of the end of an email. :)
Michael, 1. Forgive my ignorance but why would I open a ticket with Sangoma when my card is made by Digium? Or have I missed something here? 2. Another user has contacted me directly with the same issue as we're getting, but he's using a Sangoma PRI card - I've asked him to post it on the mailing list. The only thing is common is that we're both using PRI and of course FreeSwitch. 3. As for my signature, I do find it a bit ridiculous that I'm being discriminated because of this. However, for a test I will reply to this e-mail in plain text rather than HTML to see what it does. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 04 April 2012 18:35 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls On Wed, Apr 4, 2012 at 3:25 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk> wrote: Update, it's happened while tracing on span 1:4 so I've copied the in-s1c4 and out-s1c4 files - trace is still running. The call was inbound. Also it appears we're now seeing other DTMF tones in coming in as well (numbers when they haven't been pressed on the remote end)... Which files do you want and where you want them? I recommend that you open a ticket w/ Sangoma and ask them to analyze the traces. The critical thing is to find out if these are false positives, phantoms, or stuff actually coming down the line from the carrier. I think Sangoma is in the best position to help. -MC P.S. - Regarding the footer - yes, it is annoying, but if you can't turn it off then you can't turn it off. I recommend doing what Patrick suggests and getting a gmail account so that you can be free of the footer spam. If you *really* want to help us out, I'd say investigate the Mailman project and see if it has a feature that can auto-strip the junk off of the end of an email. :) Daniel Knaggs Software Developer Reality Solutions Ltd 1 Global Business Park Hamburg Road Kingston upon Hull East Yorkshire, HU7 0AE Tel: 01482 373104 Mobile: 07932 408313 Email: mailto:Daniel.Knaggs@realitysolutions.co.uk http://
On Tue, Apr 10, 2012 at 12:54 AM, Daniel Knaggs < Daniel.Knaggs@realitysolutions.co.uk> wrote:
Michael,
1. Forgive my ignorance but why would I open a ticket with Sangoma when my card is made by Digium? Or have I missed something here?
Sangoma wrote and supports mod_freetdm and they have expertise to diagnose the issue
2. Another user has contacted me directly with the same issue as we're getting, but he's using a Sangoma PRI card - I've asked him to post it on the mailing list. The only thing is common is that we're both using PRI and of course FreeSwitch.
This is why I suspect something is amiss in FreeTDM - it seems to be happening regardless of the hardware mfg.
3. As for my signature, I do find it a bit ridiculous that I'm being discriminated because of this. However, for a test I will reply to this e-mail in plain text rather than HTML to see what it does.
I wouldn't put too much stock in this. The footer is a bit annoying but out of the thousands of people who read these emails only a few said something about it. I honestly don't believe that someone is holding a solution hostage until you find a workaround for the "footer spam." :) -MC
This isn't going to cause any problems is it, Brian? I've seen a few posts on the list stating a few problems recently when upgrading. I must say that we are running in a production environment. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian Foster Sent: 23 March 2012 17:33 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Strange DTMF Tones On Inbound Calls Please update to latest git. -BDF On Fri, Mar 23, 2012 at 7:19 AM, Daniel Knaggs <Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk>> wrote: Hello all, Got a bit of a strange one, we appear to be getting DTMF tones on incoming calls when the caller hasn't even pressed any keys. It normally happens with 10 seconds or so after the call has been answered. Here is the log of it happening earlier: - 2012-03-23 10:38:16.852654 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF A (debug = 0) 2012-03-23 10:38:16.852654 [DEBUG] mod_freetdm.c:799 Queuing DTMF [A] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:16.915653 [DEBUG] switch_rtp.c:2420 Send start packet for [A] ts=49440 dur=160/160/2000 seq=46803 lw=49440 2012-03-23 10:38:16.936653 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=320/320/2000<tel:320%2F320%2F2000> seq=46804 lw=49600 2012-03-23 10:38:16.957652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=480/480/2000<tel:480%2F480%2F2000> seq=46805 lw=49760 2012-03-23 10:38:16.978652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=640/640/2000 seq=46806 lw=49920 2012-03-23 10:38:16.999652 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=800/800/2000<tel:800%2F800%2F2000> seq=46807 lw=50080 2012-03-23 10:38:17.020651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=960/960/2000 seq=46808 lw=50240 2012-03-23 10:38:17.041651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1120/1120/2000 seq=46809 lw=50400 2012-03-23 10:38:17.062651 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1280/1280/2000 seq=46810 lw=50560 2012-03-23 10:38:17.083650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1440/1440/2000 seq=46811 lw=50720 2012-03-23 10:38:17.104650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1600/1600/2000 seq=46812 lw=50880 2012-03-23 10:38:17.125650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1760/1760/2000 seq=46813 lw=51040 2012-03-23 10:38:17.146650 [DEBUG] switch_rtp.c:2323 Send middle packet for [A] ts=49440 dur=1920/1920/2000 seq=46814 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46815 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46816 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2323 Send end packet for [A] ts=49440 dur=2080/2080/2000 seq=46817 lw=51200 2012-03-23 10:38:17.167661 [DEBUG] switch_rtp.c:2271 Queue digit delay of 40ms 2012-03-23 10:38:18.070638 [DEBUG] ftdm_io.c:3530 [s1c2][1:2] Queuing DTMF B (debug = 0) 2012-03-23 10:38:18.070638 [DEBUG] mod_freetdm.c:799 Queuing DTMF [B] in channel FreeTDM/1:2/000 device 1:2 2012-03-23 10:38:18.133637 [DEBUG] switch_rtp.c:2420 Send start packet for [B] ts=59040 dur=160/160/2000 seq=46864 lw=59040 2012-03-23 10:38:18.154637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=320/320/2000<tel:320%2F320%2F2000> seq=46865 lw=59200 2012-03-23 10:38:18.175637 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=480/480/2000<tel:480%2F480%2F2000> seq=46866 lw=59360 2012-03-23 10:38:18.196636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=640/640/2000 seq=46867 lw=59520 2012-03-23 10:38:18.217636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=800/800/2000<tel:800%2F800%2F2000> seq=46868 lw=59680 2012-03-23 10:38:18.238636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=960/960/2000 seq=46869 lw=59840 2012-03-23 10:38:18.259636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1120/1120/2000 seq=46870 lw=60000 2012-03-23 10:38:18.280636 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1280/1280/2000 seq=46871 lw=60160 2012-03-23 10:38:18.301635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1440/1440/2000 seq=46872 lw=60320 2012-03-23 10:38:18.322635 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1600/1600/2000 seq=46873 lw=60480 2012-03-23 10:38:18.343634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1760/1760/2000 seq=46874 lw=60640 2012-03-23 10:38:18.364634 [DEBUG] switch_rtp.c:2323 Send middle packet for [B] ts=59040 dur=1920/1920/2000 seq=46875 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46876 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46877 lw=60800 2012-03-23 10:38:18.385634 [DEBUG] switch_rtp.c:2323 Send end packet for [B] ts=59040 dur=2080/2080/2000 seq=46878 lw=60800 I'm very sure the caller isn't dialling "A" or "B"! Running on ISDN via a TE121 card using E1 (euroisdn). Freeswitch version is "FreeSWITCH Version 1.0.head (git-b9b7266 2012-02-10 12-23-58 -0600)". Currently there is a "bind_meta_app" in the config which binds a script on the B leg of the call which parks the call - I haven't tried turning this off yet to see if it's this. Wondering if anyone has any ideas or has come across this before? Thanks in advance. [cid:image001.png@01CD0B2D.0DE3D000] Daniel Knaggs Software Developer Reality Solutions Ltd, 1 Global Business Park, Hamburg Road, Kingston upon Hull, East Yorkshire, HU7 0AE Tel: 01482 828000 / Fax: 01482 373100 Daniel.Knaggs@realitysolutions.co.uk<mailto:Daniel.Knaggs@realitysolutions.co.uk> www.realitysolutions.co.uk<http://www.realitysolutions.co.uk/> ________________________________ Sage Accredited Business Partner serving businesses in Yorkshire & Lincolnshire [cid:image002.png@01CD0B2D.0DE3D000] _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: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 D. Foster Endigo Computer LLC Email: bdfoster@endigotech.com<mailto:bdfoster@endigotech.com> Phone: 317-800-7876 Indianapolis, Indiana, USA This message contains confidential information and is intended for those listed in the "To:", "CC:", and/or "BCC:" fields of the message header. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
participants (9)
-
Ashish Lal
-
Brian Foster
-
covici＠ccs.covici.com
-
curriegrad2004
-
Daniel Knaggs
-
Gabriel Gunderson
-
Michael Collins
-
Patrick Lists
-
Wesley Akio