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 <dalet...@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/xxphonenu...@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/xxphonenu...@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/xxphonenu...@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/xxphonenu...@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/xxphonenum...@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/xxphonenum...@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/xxphonenum...@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/xxphonenum...@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/xxphonenum...@172.16.250.4 entering state [ready]
_______________________________________________
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
_______________________________________________
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
