[Freeswitch-users] help! DTMFs disappearing in mod_conference

Sun Feb 15 12:09:50 PST 2009

Yes this issue has already been fixed in SVN Trunk. I recommend you  
update.

/b

On Feb 15, 2009, at 10:29 AM, Dale Trub wrote:

> 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 172.16.250.4 entering state [ready]
>
>
>
>
>
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090215/4dafd255/attachment-0002.html 