The bug I describe sure looks a lot like: http://jira.freeswitch.org/browse/FSCORE-266 We have a direct Metaswitch-> FS connection, and both machines in the same LAN/location. It's 64-bit CentOS btw. Bug also occurred on a 32-bit CentOS dev machine. On Sat, Feb 14, 2009 at 9:15 PM, Dale Trub <daletrub@gmail.com> wrote:
Hey folks, I'm having a very odd issue and I'm wondering if anyone else has seen this, or if there's a setting to change etc.
I should mention that if anyone by chance helps THIS WEEKEND, it could SAVE my butt. We are doing an important demo monday morning and honestly this stops us in our tracks.
We are listening for DTMFs from mod_conference and passing that via the socket on to a separate display layer (in development).
It works perfectly, but at a certain point in a conference, it seems the switch stops sensing the DTMFs on most (but not all) lines.
FYI, we saw this before with FS 1.0 running on a VPS slice and thought maybe it was somehow related to that box, or that DID provider. We've now switched to a full server and a different DID provider, and are getting the exact same behavior.
Today, here was the deal:
- 10 people called in (practice walkthrough of our demo this monday) - all lines: DTMFs displayed - tried them several times - 6= mute/unmute also works (doesn't go through our display layer) - about 30 minutes in, again asked everyone to hit 1 (which again we pass to display layer) - and now most lines do not pass DTMFs - a couple lines still do pass them - (the "6" which we trap within FS as "mute/unmute" also stops working on those lines that stopped passing others) - the FS logs STOP reflecting DTMFs from the lines where we don't see them - so, we know it's FS and not our application - some time passes - keep trying the working ones -- eventually they stop working - one caller (with DTMFs non functional) hangs up and calls back - that caller now does have DTMFs working - we hung up and called back in - this time DTMFs worked ~100 times, and then again stopped - switched logs from INFO to DEBUG - below are some log file entries
We're on CENT-OS and FS 1.0.2
Besides the obvious question ("how do I fix this")
Non-obvious Questions:
- Is there any way to tell if the DID provider is trapping the DTMFs and sending them out of band, or is sending them in-band? - Is there any reasonably easy way to get in and see/sniff/visualize/measure the SIP packets to see what is coming in? - Could this be related to this? http://wiki.freeswitch.org/wiki/RTP_Issues - Any other thoughts on how to debug?
Thanks!!
-Dale
Here's the last working DTMF, and then some events I don't know ... through a place where this definitely wasn't working.
2009-02-14 22:26:03 [DEBUG] switch_rtp.c:1701 switch_rtp_dequeue_dtmf() RTP RECV DTMF 5:2000 2009-02-14 22:37:06 [DEBUG] sofia.c:2542 sofia_handle_sip_i_state() Channel sofi a/external/xxphonenumxx@172.16.250.4 entering state [received] 2009-02-14 22:37:06 [DEBUG] sofia.c:2546 sofia_handle_sip_i_state() Remote SDP: v=0 o=FreeSWITCH 8044373728746667485 7321340529655007764 IN IP4 172.16.250.4 s=FreeSWITCH c=IN IP4 172.16.3.13 t=0 0 m=audio 33440 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=ptime:20
2009-02-14 22:37:06 [DEBUG] sofia_glue.c:2447 sofia_glue_negotiate_sdp() Our exi sting sdp is still good [PCMU 172.16.3.13:33440], let's keep it. 2009-02-14 22:37:06 [DEBUG] sofia_glue.c:2473 sofia_glue_negotiate_sdp() Set 283 3 dtmf payload to 101 2009-02-14 22:37:06 [DEBUG] sofia_glue.c:1880 sofia_glue_activate_rtp() Audio pa rams are unchanged for sofia/external/xxphonenumxx@172.16.250.4. 2009-02-14 22:37:06 [DEBUG] sofia.c:2896 sofia_handle_sip_i_state() Processing R einvite 2009-02-14 22:37:06 [DEBUG] sofia.c:2542 sofia_handle_sip_i_state() Channel sofi a/external/xxphonenumxx@172.16.250.4 entering state [completed] 2009-02-14 22:37:06 [DEBUG] sofia.c:2542 sofia_handle_sip_i_state() Channel sofi a/external/xxphonenumxx@172.16.250.4 entering state [ready] 2009-02-14 22:38:34 [DEBUG] sofia.c:2542 sofia_handle_sip_i_state() Channel sofi a/external/xxphonenumxx2@172.16.250.4 entering state [received] 2009-02-14 22:38:34 [DEBUG] sofia.c:2546 sofia_handle_sip_i_state() Remote SDP: v=0 o=FreeSWITCH 934104982290142318 4836750446264379897 IN IP4 172.16.250.4 s=FreeSWITCH c=IN IP4 172.16.1.21 t=0 0 m=audio 35356 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=ptime:20
2009-02-14 22:38:34 [DEBUG] sofia_glue.c:2447 sofia_glue_negotiate_sdp() Our exi sting sdp is still good [PCMU 172.16.1.21:35356], let's keep it. 2009-02-14 22:38:34 [DEBUG] sofia_glue.c:2473 sofia_glue_negotiate_sdp() Set 283 3 dtmf payload to 101 2009-02-14 22:38:34 [DEBUG] sofia_glue.c:1880 sofia_glue_activate_rtp() Audio pa rams are unchanged for sofia/external/xxphonenumxx2@172.16.250.4.
2009-02-14 22:38:34 [DEBUG] sofia_glue.c:1880 sofia_glue_activate_rtp() Audio pa rams are unchanged for sofia/external/xxphonenumxx2@172.16.250.4. 2009-02-14 22:38:34 [DEBUG] sofia.c:2896 sofia_handle_sip_i_state() Processing R einvite 2009-02-14 22:38:34 [DEBUG] sofia.c:2542 sofia_handle_sip_i_state() Channel sofi a/external/xxphonenumxx2@172.16.250.4 entering state [completed] 2009-02-14 22:38:34 [DEBUG] sofia.c:2542 sofia_handle_sip_i_state() Channel sofi a/external/xxphonenumxx2@172.16.250.4 entering state [ready]