Dequeue DTMF from FreeTDM Channel
Hi all, I have a freeswitch configured with freetdm and wanpipe.My problem is with dtmf. When calling from an external pstn number to freeswitch, dtmf seems to be detected properly and enqueued it in the channel consistently. But when call came to same channel again, dtmf which is stored in the buffer for the previous call is used in the current call.So when i am done with previous call i want to dequeue the dtmf in the channel .So the problem seems to be something I've misconfigured with the Sangoma card. Can anyone point me in the right direction? Thanks, Subhash.
Can you get a FS console log of this occurring? Also, what are the endpoints that are being connected? -MC On Wed, Jan 16, 2013 at 4:59 AM, Subhash <gvvsubhashkumar@gmail.com> wrote:
Hi all,
I have a freeswitch configured with freetdm and wanpipe.My problem is with dtmf. When calling from an external pstn number to freeswitch, dtmf seems to be detected properly and enqueued it in the channel consistently. But when call came to same channel again, dtmf which is stored in the buffer for the previous call is used in the current call.So when i am done with previous call i want to dequeue the dtmf in the channel .So the problem seems to be something I've misconfigured with the Sangoma card. Can anyone point me in the right direction?
Thanks, Subhash.
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
Hi Michael, Below is the snippet of the freeswitch log. Success Call : 2013-01-16 00:58:58.314163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:58:58.314163 [DEBUG] ftdm_io.c:3038 [s4c1][4:1] Created DTMF buffer 2013-01-16 00:58:58.314163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:58:58.314163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:06.414163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 1:640 2013-01-16 00:59:06.414163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:06.414163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [1] 2013-01-16 00:59:06.774163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:06.774163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:06.774163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:09.214164 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.254162 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.254162 [DEBUG] ftmod_wanpipe.c:1547 [s4c1][4:1] Queuing wanpipe DTMF: 7 2013-01-16 00:59:09.254162 [DEBUG] ftdm_io.c:3783 [s4c1][4:1] Queuing DTMF 7 (debug = 0) 2013-01-16 00:59:09.254162 [DEBUG] mod_freetdm.c:811 Queuing DTMF [7] in channel FreeTDM/4:1/2001 device 4:1 2013-01-16 00:59:09.254162 [DEBUG] switch_ivr_bridge.c:393 Send signal sofia/VOIPBRD1/2001@**.**.**.** [BREAK] 2013-01-16 00:59:09.514163 [DEBUG] switch_rtp.c:2589 Queue digit delay of 40ms 2013-01-16 00:59:09.594164 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.654166 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.654166 [DEBUG] ftmod_wanpipe.c:1547 [s4c1][4:1] Queuing wanpipe DTMF: 1 2013-01-16 00:59:09.654166 [DEBUG] ftdm_io.c:3783 [s4c1][4:1] Queuing DTMF 1 (debug = 0) 2013-01-16 00:59:09.674165 [DEBUG] mod_freetdm.c:811 Queuing DTMF [1] in channel FreeTDM/4:1/2001 device 4:1 2013-01-16 00:59:09.674165 [DEBUG] switch_ivr_bridge.c:393 Send signal sofia/VOIPBRD1/2001@**.**.**.** [BREAK] 013-01-16 00:59:09.934163 [DEBUG] switch_rtp.c:2589 Queue digit delay of 40ms 2013-01-16 00:59:11.234163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:11.234163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:11.234163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:11.394163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:11.394163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:11.394163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] Failed DTMF call : 2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 01:02:32.834164 [INFO] ftmod_sangoma_isdn_stack_rcv.c:232 [s4c1][4:1] Received DISCONNECT (suId:1 suInstId:2 spInstId:2) 2013-01-16 01:02:32.834164 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:543 [s4c1][4:1] Processing DISCONNECT (suId:1 suInstId:2 Thanks, Subhash. On Thu, Jan 17, 2013 at 6:48 AM, Michael Collins <msc@freeswitch.org> wrote:
Can you get a FS console log of this occurring? Also, what are the endpoints that are being connected? -MC
On Wed, Jan 16, 2013 at 4:59 AM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Hi all,
I have a freeswitch configured with freetdm and wanpipe.My problem is with dtmf. When calling from an external pstn number to freeswitch, dtmf seems to be detected properly and enqueued it in the channel consistently. But when call came to same channel again, dtmf which is stored in the buffer for the previous call is used in the current call.So when i am done with previous call i want to dequeue the dtmf in the channel .So the problem seems to be something I've misconfigured with the Sangoma card. Can anyone point me in the right direction?
Thanks, Subhash.
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org <http://www.freeswitch.org/> http://www.ClueCon.com <http://www.cluecon.com/> http://www.OSTAG.org <http://www.ostag.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
On Thu, Jan 17, 2013 at 4:41 AM, Subhash <gvvsubhashkumar@gmail.com> wrote:
Hi Michael,
Below is the snippet of the freeswitch log.
Success Call :
2013-01-16 00:58:58.314163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:58:58.314163 [DEBUG] ftdm_io.c:3038 [s4c1][4:1] Created DTMF buffer 2013-01-16 00:58:58.314163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:58:58.314163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:06.414163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 1:640 2013-01-16 00:59:06.414163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:06.414163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [1] 2013-01-16 00:59:06.774163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:06.774163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:06.774163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:09.214164 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.254162 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.254162 [DEBUG] ftmod_wanpipe.c:1547 [s4c1][4:1] Queuing wanpipe DTMF: 7 2013-01-16 00:59:09.254162 [DEBUG] ftdm_io.c:3783 [s4c1][4:1] Queuing DTMF 7 (debug = 0) 2013-01-16 00:59:09.254162 [DEBUG] mod_freetdm.c:811 Queuing DTMF [7] in channel FreeTDM/4:1/2001 device 4:1 2013-01-16 00:59:09.254162 [DEBUG] switch_ivr_bridge.c:393 Send signal sofia/VOIPBRD1/2001@**.**.**.** [BREAK] 2013-01-16 00:59:09.514163 [DEBUG] switch_rtp.c:2589 Queue digit delay of 40ms 2013-01-16 00:59:09.594164 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.654166 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.654166 [DEBUG] ftmod_wanpipe.c:1547 [s4c1][4:1] Queuing wanpipe DTMF: 1 2013-01-16 00:59:09.654166 [DEBUG] ftdm_io.c:3783 [s4c1][4:1] Queuing DTMF 1 (debug = 0) 2013-01-16 00:59:09.674165 [DEBUG] mod_freetdm.c:811 Queuing DTMF [1] in channel FreeTDM/4:1/2001 device 4:1 2013-01-16 00:59:09.674165 [DEBUG] switch_ivr_bridge.c:393 Send signal sofia/VOIPBRD1/2001@**.**.**.** [BREAK] 013-01-16 00:59:09.934163 [DEBUG] switch_rtp.c:2589 Queue digit delay of 40ms 2013-01-16 00:59:11.234163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:11.234163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:11.234163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:11.394163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:11.394163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:11.394163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] Failed DTMF call :
2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 01:02:32.834164 [INFO] ftmod_sangoma_isdn_stack_rcv.c:232 [s4c1][4:1] Received DISCONNECT (suId:1 suInstId:2 spInstId:2) 2013-01-16 01:02:32.834164 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:543 [s4c1][4:1] Processing DISCONNECT (suId:1 suInstId:2
This looks like incoming DTMF from the RTP leg going out in the TDM leg? if so, the problem would be why switch_rtp.c is "detecting" received DTMF when there is none? Please post in pastebin the full debug log (from call start, bridge, to hangup etc) for one success call followed by the call with the dtmf problem. *Moises Silva **Manager, Software Engineering*** msilva@sangoma.com Sangoma Technologies 100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada t. +1 800 388 2475 (N. America) t. +1 905 474 1990 x128 f. +1 905 474 9223 **<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email+signatures> Products<http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Solutions<http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Events<http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Contact<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Wiki<http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Facebook<http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Twitter<http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`| | YouTube<http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
Yes,we are trying to bridge PSTN and VOIP call. We posted the log in pastebin.Please use the below URL to access the freeswitch log. http://pastebin.freeswitch.org/20461 Thanks, Subhash. On Thu, Jan 17, 2013 at 10:25 PM, Moises Silva <moises.silva@gmail.com>wrote:
On Thu, Jan 17, 2013 at 4:41 AM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Hi Michael,
Below is the snippet of the freeswitch log.
Success Call :
2013-01-16 00:58:58.314163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:58:58.314163 [DEBUG] ftdm_io.c:3038 [s4c1][4:1] Created DTMF buffer 2013-01-16 00:58:58.314163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:58:58.314163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:06.414163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 1:640 2013-01-16 00:59:06.414163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:06.414163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [1] 2013-01-16 00:59:06.774163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:06.774163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:06.774163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:09.214164 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.254162 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.254162 [DEBUG] ftmod_wanpipe.c:1547 [s4c1][4:1] Queuing wanpipe DTMF: 7 2013-01-16 00:59:09.254162 [DEBUG] ftdm_io.c:3783 [s4c1][4:1] Queuing DTMF 7 (debug = 0) 2013-01-16 00:59:09.254162 [DEBUG] mod_freetdm.c:811 Queuing DTMF [7] in channel FreeTDM/4:1/2001 device 4:1 2013-01-16 00:59:09.254162 [DEBUG] switch_ivr_bridge.c:393 Send signal sofia/VOIPBRD1/2001@**.**.**.** [BREAK] 2013-01-16 00:59:09.514163 [DEBUG] switch_rtp.c:2589 Queue digit delay of 40ms 2013-01-16 00:59:09.594164 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.654166 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.654166 [DEBUG] ftmod_wanpipe.c:1547 [s4c1][4:1] Queuing wanpipe DTMF: 1 2013-01-16 00:59:09.654166 [DEBUG] ftdm_io.c:3783 [s4c1][4:1] Queuing DTMF 1 (debug = 0) 2013-01-16 00:59:09.674165 [DEBUG] mod_freetdm.c:811 Queuing DTMF [1] in channel FreeTDM/4:1/2001 device 4:1 2013-01-16 00:59:09.674165 [DEBUG] switch_ivr_bridge.c:393 Send signal sofia/VOIPBRD1/2001@**.**.**.** [BREAK] 013-01-16 00:59:09.934163 [DEBUG] switch_rtp.c:2589 Queue digit delay of 40ms 2013-01-16 00:59:11.234163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:11.234163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:11.234163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:11.394163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:11.394163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:11.394163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] Failed DTMF call :
2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 01:02:32.834164 [INFO] ftmod_sangoma_isdn_stack_rcv.c:232 [s4c1][4:1] Received DISCONNECT (suId:1 suInstId:2 spInstId:2) 2013-01-16 01:02:32.834164 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:543 [s4c1][4:1] Processing DISCONNECT (suId:1 suInstId:2
This looks like incoming DTMF from the RTP leg going out in the TDM leg? if so, the problem would be why switch_rtp.c is "detecting" received DTMF when there is none?
Please post in pastebin the full debug log (from call start, bridge, to hangup etc) for one success call followed by the call with the dtmf problem.
*Moises Silva **Manager, Software Engineering***
msilva@sangoma.com
Sangoma Technologies
100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada
t. +1 800 388 2475 (N. America)
t. +1 905 474 1990 x128
f. +1 905 474 9223
**<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email+signatures>
Products<http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Solutions<http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Events<http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Contact<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Wiki<http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Facebook<http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Twitter<http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`| | YouTube<http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
_________________________________________________________________________ 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
Michael, Did you see any problem in our Freeswitch configuration after you gone through the logs. Thanks, Subhash. On Fri, Jan 18, 2013 at 11:57 AM, Subhash <gvvsubhashkumar@gmail.com> wrote:
Yes,we are trying to bridge PSTN and VOIP call.
We posted the log in pastebin.Please use the below URL to access the freeswitch log.
http://pastebin.freeswitch.org/20461
Thanks, Subhash.
On Thu, Jan 17, 2013 at 10:25 PM, Moises Silva <moises.silva@gmail.com>wrote:
On Thu, Jan 17, 2013 at 4:41 AM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Hi Michael,
Below is the snippet of the freeswitch log.
Success Call :
2013-01-16 00:58:58.314163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:58:58.314163 [DEBUG] ftdm_io.c:3038 [s4c1][4:1] Created DTMF buffer 2013-01-16 00:58:58.314163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:58:58.314163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:06.414163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 1:640 2013-01-16 00:59:06.414163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:06.414163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [1] 2013-01-16 00:59:06.774163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:06.774163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:06.774163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:09.214164 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.254162 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.254162 [DEBUG] ftmod_wanpipe.c:1547 [s4c1][4:1] Queuing wanpipe DTMF: 7 2013-01-16 00:59:09.254162 [DEBUG] ftdm_io.c:3783 [s4c1][4:1] Queuing DTMF 7 (debug = 0) 2013-01-16 00:59:09.254162 [DEBUG] mod_freetdm.c:811 Queuing DTMF [7] in channel FreeTDM/4:1/2001 device 4:1 2013-01-16 00:59:09.254162 [DEBUG] switch_ivr_bridge.c:393 Send signal sofia/VOIPBRD1/2001@**.**.**.** [BREAK] 2013-01-16 00:59:09.514163 [DEBUG] switch_rtp.c:2589 Queue digit delay of 40ms 2013-01-16 00:59:09.594164 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.654166 [DEBUG] ftmod_wanpipe.c:1678 [s4c1][4:1] read wanpipe event 3 2013-01-16 00:59:09.654166 [DEBUG] ftmod_wanpipe.c:1547 [s4c1][4:1] Queuing wanpipe DTMF: 1 2013-01-16 00:59:09.654166 [DEBUG] ftdm_io.c:3783 [s4c1][4:1] Queuing DTMF 1 (debug = 0) 2013-01-16 00:59:09.674165 [DEBUG] mod_freetdm.c:811 Queuing DTMF [1] in channel FreeTDM/4:1/2001 device 4:1 2013-01-16 00:59:09.674165 [DEBUG] switch_ivr_bridge.c:393 Send signal sofia/VOIPBRD1/2001@**.**.**.** [BREAK] 013-01-16 00:59:09.934163 [DEBUG] switch_rtp.c:2589 Queue digit delay of 40ms 2013-01-16 00:59:11.234163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:11.234163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:11.234163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 00:59:11.394163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 00:59:11.394163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 00:59:11.394163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] Failed DTMF call :
2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] 2013-01-16 01:02:32.834164 [INFO] ftmod_sangoma_isdn_stack_rcv.c:232 [s4c1][4:1] Received DISCONNECT (suId:1 suInstId:2 spInstId:2) 2013-01-16 01:02:32.834164 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:543 [s4c1][4:1] Processing DISCONNECT (suId:1 suInstId:2
This looks like incoming DTMF from the RTP leg going out in the TDM leg? if so, the problem would be why switch_rtp.c is "detecting" received DTMF when there is none?
Please post in pastebin the full debug log (from call start, bridge, to hangup etc) for one success call followed by the call with the dtmf problem.
*Moises Silva **Manager, Software Engineering***
msilva@sangoma.com
Sangoma Technologies
100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada
t. +1 800 388 2475 (N. America)
t. +1 905 474 1990 x128
f. +1 905 474 9223
**<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email+signatures>
Products<http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Solutions<http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Events<http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Contact<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Wiki<http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Facebook<http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Twitter<http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`| | YouTube<http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
_________________________________________________________________________ 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, Jan 18, 2013 at 1:27 AM, Subhash <gvvsubhashkumar@gmail.com> wrote:
Yes,we are trying to bridge PSTN and VOIP call.
We posted the log in pastebin.Please use the below URL to access the freeswitch log.
1. 013-01-16 01:02:26.954165 [INFO] ftmod_sangoma_isdn_stack_rcv.c:144 [ s4c1][4:1] Received CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 2. 2013-01-16 01:02:26.954165 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:285 [s4c1][4:1] Processing CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 3. 2013-01-16 01:02:26.974165 [DEBUG] switch_rtp.c:3596 Correct ip/port confirmed. 4. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:1002 [s4c1][4:1] First packet read stats: Rx queue len: 4, Rx queue size: 10 5. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:938 [s4c1][4:1] First packet write stats: Tx queue len: 1, Tx queue size: 5, Tx idle: 10 6. 2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9: 640 7. 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 8. 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9] The DTMF comes from the RTP side, not FreeTDM (as shown by the log above). You have to verify using tcpdump/wireshark if there is any real DTMF being received. I'd do exactly the same test again, but this time I would also start a wireshark trace. Then please pastebin the trace again and upload the pcap trace to cloudshark (http://www.cloudshark.org/) and paste the link here. Moy
But we don't see any problem when both endpoints are SIP. Thanks, Subhash. On Mon, Jan 21, 2013 at 7:12 AM, Moises Silva <moises.silva@gmail.com>wrote:
On Fri, Jan 18, 2013 at 1:27 AM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Yes,we are trying to bridge PSTN and VOIP call.
We posted the log in pastebin.Please use the below URL to access the freeswitch log.
1. 013-01-16 01:02:26.954165 [INFO] ftmod_sangoma_isdn_stack_rcv.c:144 [s4c1][4:1] Received CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 2. 2013-01-16 01:02:26.954165 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c: 285 [s4c1][4:1] Processing CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 3. 2013-01-16 01:02:26.974165 [DEBUG] switch_rtp.c:3596 Correct ip/port confirmed. 4. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:1002 [s4c1][4:1] First packet read stats: Rx queue len: 4, Rx queue size: 10 5. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:938 [s4c1][4:1] First packet write stats: Tx queue len: 1, Tx queue size: 5, Tx idle: 10 6. 2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9 :640 7. 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 8. 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9]
The DTMF comes from the RTP side, not FreeTDM (as shown by the log above). You have to verify using tcpdump/wireshark if there is any real DTMF being received.
I'd do exactly the same test again, but this time I would also start a wireshark trace. Then please pastebin the trace again and upload the pcap trace to cloudshark (http://www.cloudshark.org/) and paste the link here.
Moy
_________________________________________________________________________ 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
That may be the case, but that doesn't actually supply the information you need to find out where the DTMFs are coming from. I would recommend doing the test that Moy suggested. At least find out where FreeSWITCH thinks this DTMF is coming from. -MC On Sun, Jan 20, 2013 at 6:43 PM, Subhash <gvvsubhashkumar@gmail.com> wrote:
But we don't see any problem when both endpoints are SIP.
Thanks, Subhash.
On Mon, Jan 21, 2013 at 7:12 AM, Moises Silva <moises.silva@gmail.com>wrote:
On Fri, Jan 18, 2013 at 1:27 AM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Yes,we are trying to bridge PSTN and VOIP call.
We posted the log in pastebin.Please use the below URL to access the freeswitch log.
1. 013-01-16 01:02:26.954165 [INFO] ftmod_sangoma_isdn_stack_rcv.c:144 [s4c1][4:1] Received CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId: 2 ces:0) 2. 2013-01-16 01:02:26.954165 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c: 285 [s4c1][4:1] Processing CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 3. 2013-01-16 01:02:26.974165 [DEBUG] switch_rtp.c:3596 Correct ip/port confirmed. 4. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:1002 [s4c1][4:1] First packet read stats: Rx queue len: 4, Rx queue size: 10 5. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:938 [s4c1][4:1] First packet write stats: Tx queue len: 1, Tx queue size: 5, Tx idle: 10 6. 2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 7. 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 8. 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9]
The DTMF comes from the RTP side, not FreeTDM (as shown by the log above). You have to verify using tcpdump/wireshark if there is any real DTMF being received.
I'd do exactly the same test again, but this time I would also start a wireshark trace. Then please pastebin the trace again and upload the pcap trace to cloudshark (http://www.cloudshark.org/) and paste the link here.
Moy
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
Ok. We did the test again,pasted the freeswitch log and uploaded the wireshark of the both success and failed call traces.Please let me know if you have problem in accessing the URLs . http://pastebin.freeswitch.org/20484 http://www.cloudshark.org/captures/6dc99dc2f68c -- Success http://www.cloudshark.org/captures/27b88b2c8ca4--- Failure Thanks, Subhash. On Tue, Jan 22, 2013 at 12:06 AM, Michael Collins <msc@freeswitch.org>wrote:
That may be the case, but that doesn't actually supply the information you need to find out where the DTMFs are coming from. I would recommend doing the test that Moy suggested. At least find out where FreeSWITCH thinks this DTMF is coming from.
-MC
On Sun, Jan 20, 2013 at 6:43 PM, Subhash <gvvsubhashkumar@gmail.com>wrote:
But we don't see any problem when both endpoints are SIP.
Thanks, Subhash.
On Mon, Jan 21, 2013 at 7:12 AM, Moises Silva <moises.silva@gmail.com>wrote:
On Fri, Jan 18, 2013 at 1:27 AM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Yes,we are trying to bridge PSTN and VOIP call.
We posted the log in pastebin.Please use the below URL to access the freeswitch log.
1. 013-01-16 01:02:26.954165 [INFO] ftmod_sangoma_isdn_stack_rcv.c: 144 [s4c1][4:1] Received CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 2. 2013-01-16 01:02:26.954165 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:285 [s4c1][4:1] Processing CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 3. 2013-01-16 01:02:26.974165 [DEBUG] switch_rtp.c:3596 Correct ip/port confirmed. 4. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:1002 [s4c1][4: 1] First packet read stats: Rx queue len: 4, Rx queue size: 10 5. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:938 [s4c1][4:1 ] First packet write stats: Tx queue len: 1, Tx queue size: 5, Tx idle: 10 6. 2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 7. 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 8. 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9]
The DTMF comes from the RTP side, not FreeTDM (as shown by the log above). You have to verify using tcpdump/wireshark if there is any real DTMF being received.
I'd do exactly the same test again, but this time I would also start a wireshark trace. Then please pastebin the trace again and upload the pcap trace to cloudshark (http://www.cloudshark.org/) and paste the link here.
Moy
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org <http://www.freeswitch.org/> http://www.ClueCon.com <http://www.cluecon.com/> http://www.OSTAG.org <http://www.ostag.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
Moy, Did you get time to look into this issue? Thanks, Subhash. On Tue, Jan 22, 2013 at 6:19 PM, Subhash <gvvsubhashkumar@gmail.com> wrote:
Ok. We did the test again,pasted the freeswitch log and uploaded the wireshark of the both success and failed call traces.Please let me know if you have problem in accessing the URLs .
http://pastebin.freeswitch.org/20484
http://www.cloudshark.org/captures/6dc99dc2f68c -- Success
http://www.cloudshark.org/captures/27b88b2c8ca4--- Failure
Thanks, Subhash.
On Tue, Jan 22, 2013 at 12:06 AM, Michael Collins <msc@freeswitch.org>wrote:
That may be the case, but that doesn't actually supply the information you need to find out where the DTMFs are coming from. I would recommend doing the test that Moy suggested. At least find out where FreeSWITCH thinks this DTMF is coming from.
-MC
On Sun, Jan 20, 2013 at 6:43 PM, Subhash <gvvsubhashkumar@gmail.com>wrote:
But we don't see any problem when both endpoints are SIP.
Thanks, Subhash.
On Mon, Jan 21, 2013 at 7:12 AM, Moises Silva <moises.silva@gmail.com>wrote:
On Fri, Jan 18, 2013 at 1:27 AM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Yes,we are trying to bridge PSTN and VOIP call.
We posted the log in pastebin.Please use the below URL to access the freeswitch log.
1. 013-01-16 01:02:26.954165 [INFO] ftmod_sangoma_isdn_stack_rcv.c: 144 [s4c1][4:1] Received CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 2. 2013-01-16 01:02:26.954165 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:285 [s4c1][4:1] Processing CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 3. 2013-01-16 01:02:26.974165 [DEBUG] switch_rtp.c:3596 Correct ip/port confirmed. 4. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:1002 [s4c1][4 :1] First packet read stats: Rx queue len: 4, Rx queue size: 10 5. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:938 [s4c1][4: 1] First packet write stats: Tx queue len: 1, Tx queue size: 5, Tx idle: 10 6. 2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 7. 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 8. 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9]
The DTMF comes from the RTP side, not FreeTDM (as shown by the log above). You have to verify using tcpdump/wireshark if there is any real DTMF being received.
I'd do exactly the same test again, but this time I would also start a wireshark trace. Then please pastebin the trace again and upload the pcap trace to cloudshark (http://www.cloudshark.org/) and paste the link here.
Moy
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org <http://www.freeswitch.org/> http://www.ClueCon.com <http://www.cluecon.com/> http://www.OSTAG.org <http://www.ostag.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
Moy, Any update on this? Thanks, Subhash. On Jan 24, 2013 12:30 PM, "Subhash" <gvvsubhashkumar@gmail.com> wrote:
Moy,
Did you get time to look into this issue?
Thanks, Subhash. On Tue, Jan 22, 2013 at 6:19 PM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Ok. We did the test again,pasted the freeswitch log and uploaded the wireshark of the both success and failed call traces.Please let me know if you have problem in accessing the URLs .
http://pastebin.freeswitch.org/20484
http://www.cloudshark.org/captures/6dc99dc2f68c -- Success
http://www.cloudshark.org/captures/27b88b2c8ca4--- Failure
Thanks, Subhash.
On Tue, Jan 22, 2013 at 12:06 AM, Michael Collins <msc@freeswitch.org>wrote:
That may be the case, but that doesn't actually supply the information you need to find out where the DTMFs are coming from. I would recommend doing the test that Moy suggested. At least find out where FreeSWITCH thinks this DTMF is coming from.
-MC
On Sun, Jan 20, 2013 at 6:43 PM, Subhash <gvvsubhashkumar@gmail.com>wrote:
But we don't see any problem when both endpoints are SIP.
Thanks, Subhash.
On Mon, Jan 21, 2013 at 7:12 AM, Moises Silva <moises.silva@gmail.com>wrote:
On Fri, Jan 18, 2013 at 1:27 AM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Yes,we are trying to bridge PSTN and VOIP call.
We posted the log in pastebin.Please use the below URL to access the freeswitch log.
1. 013-01-16 01:02:26.954165 [INFO] ftmod_sangoma_isdn_stack_rcv.c:144 [s4c1][4:1] Received CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 2. 2013-01-16 01:02:26.954165 [DEBUG] ftmod_sangoma_isdn_stack_hndl.c:285 [s4c1][4:1] Processing CONNECT/CONNECT ACK (suId:1 suInstId:2 spInstId:2 ces:0) 3. 2013-01-16 01:02:26.974165 [DEBUG] switch_rtp.c:3596 Correct ip/port confirmed. 4. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:1002 [s4c1] [4:1] First packet read stats: Rx queue len: 4, Rx queue size: 10 5. 2013-01-16 01:02:26.974165 [DEBUG] ftmod_wanpipe.c:938 [s4c1][ 4:1] First packet write stats: Tx queue len: 1, Tx queue size: 5, Tx idle: 10 6. 2013-01-16 01:02:27.694163 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 9:640 7. 2013-01-16 01:02:27.694163 [DEBUG] switch_ivr_bridge.c:393 Send signal FreeTDM/4:1/2001 [BREAK] 8. 2013-01-16 01:02:27.694163 [DEBUG] ftdm_io.c:3979 [s4c1][4:1] Generating DTMF [9]
The DTMF comes from the RTP side, not FreeTDM (as shown by the log above). You have to verify using tcpdump/wireshark if there is any real DTMF being received.
I'd do exactly the same test again, but this time I would also start a wireshark trace. Then please pastebin the trace again and upload the pcap trace to cloudshark (http://www.cloudshark.org/) and paste the link here.
Moy
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org <http://www.freeswitch.org/> http://www.ClueCon.com <http://www.cluecon.com/> http://www.OSTAG.org <http://www.ostag.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
On Tue, Jan 22, 2013 at 6:19 PM, Subhash <gvvsubhashkumar@gmail.com>wrote:
Ok. We did the test again,pasted the freeswitch log and uploaded the wireshark of the both success and failed call traces.Please let me know if you have problem in accessing the URLs .
http://pastebin.freeswitch.org/20484
I don't see anything wrong in the traces. First call (the one you flagged as success), is an incoming call on the ISDN link, almost immediately after the call is connected to the SIP end, FreeSWITCH receives 9199 from the RTP stream, and 71 from the TDM end. Those DTMF digits are passed from RTP to TDM and viceversa as expected. The call is then finally hung up Second call (the one you flagged as failed) is pretty much the same, the DTMF 9 that you see is in the RTP wireshark trace, so there is nothing wrong here. That DTMF is there. The other end is sending that 9, the only difference is that this time the far end of the TDM side hangs up the call almost immediately after re-generating that 9 received in the RTP side into the TDM side. *Moises Silva **Manager, Software Engineering*** msilva@sangoma.com Sangoma Technologies 100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada t. +1 800 388 2475 (N. America) t. +1 905 474 1990 x128 f. +1 905 474 9223 **<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email+signatures> Products<http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Solutions<http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Events<http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Contact<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Wiki<http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Facebook<http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | Twitter<http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`| | YouTube<http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
participants (3)
-
Michael Collins
-
Moises Silva
-
Subhash