[Freeswitch-users] help! DTMFs disappearing in mod_conference

[Dale Trub]

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]
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090215/05fe60da/attachment-0002.html