[Freeswitch-users] help! DTMFs disappearing in mod_conference

[Dale Trub]

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/20090214/5051ba09/attachment-0002.html