Like omortimer says it looks suspicious. I'd pastebin your dialplan and the console log of a single call coming in (or going out) and let's see if you've got a sched_hangup in there somewhere. -MC On Tue, Feb 14, 2012 at 12:26 PM, Fraser Redmond <fraserredmond@gmail.com>wrote:

I've done a test call, and got a pcap of it, along with a sip debug. (I can email you files if you are willing to take a look.)

There's no sip traffic until it gets to the log lines I pasted before, which is followed by the server sending a BYE to the gateway and client.

I did a google search on "nat timeout", but the only thing relevant seemed to be the rtp-timeout and session-timeout which I mentioned before.

I really think there's a setting somewhere telling it to hangup. The logs have things like this as the call is being hung up (but before the BYE's are sent) which seem suspicious

...

Added task 4 switch_ivr_schedule_hangup (uuid) to run at 1329249352

...

ending bridge by request from read function

Cheers, Fraser

On 14 February 2012 14:08, Michael Collins <msc@freeswitch.org> wrote:

...

I would get pcaps of the calls that drop at 5 minutes, including media. If you need suggestions on how to collect pcaps then check out this page:

http://wiki.freeswitch.org/wiki/Packet_Capture

Lots of tools at your disposal! Don't forget that Wireshark has a really nice interface for exploring SIP calls and RTP streams.

-MC

On Tue, Feb 14, 2012 at 10:16 AM, Fraser Redmond <fraserredmond@gmail.com

...

wrote:

...

I've got calls that are getting disconnected after 5 minutes (.

There's some calls that don't, and we don't have many calls that last that long (which is why we hadn't noticed until now.)

I've had a look through the documentation, and the only thing I saw that looked likely was the rtp-timeouts which I changed to this without any change: <param name="rtp-timeout-sec" value="1800"/> <param name="rtp-hold-timeout-sec" value="1800"/> (changed in internal and external profiles)

Here's the log output for when the call ends:

9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.340991 [DEBUG] switch_core_session.c:1009 Send signal sofia/internal/ sip:12605@99.237.220.56:3907 [BREAK] 2012-02-14 17:42:58.340991 [DEBUG] switch_scheduler.c:214 Added task 4 switch_ivr_schedule_hangup (9d39d866-5732-11e1-b1a8-05fc5f64fa97) to run at 1329241378 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.361011 [DEBUG] switch_core_session.c:726 Send signal sofia/internal/ sip:12605@99.237.220.56:3907 [BREAK] 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] switch_ivr.c:589 sofia/internal/sip:12605@99.237.220.56:3907 Command Execute respond(603) 9d39d866-5732-11e1-b1a8-05fc5f64fa97 EXECUTE sofia/internal/ sip:12605@99.237.220.56:3907 respond(603) 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] mod_sofia.c:2363 Responding with 603 [Decline]

Any other settings I should be looking at?

Cheers, Fraser

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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

Hi Fraser, Your console output in pastbin isn't complete so of limited use. I'd really need to see you dialplan xml along with possibly your js - feel free to pm me. You dialplan seems overly complicated too, you should be able to all of that within a single js application. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Fraser Redmond Sent: 14 February 2012 21:26 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Calls ending after around 5min I thought that too, and had done a text-search my code for sched_hangup, and there's no mention of it anywhere. Is there anything else that would set it based on other variables being set? The closest things I have is I'm setting api_hangup_hook to run some javascript when the call is hung up, and hangup_after_bridge=false My dialplan is fairly complicated (several js files get run to do database logging, business logic, etc.) So the console output is probably more helpful: http://pastebin.freeswitch.org/18385 Cheers, Fraser On 14 February 2012 15:41, Michael Collins <msc@freeswitch.org> wrote: Like omortimer says it looks suspicious. I'd pastebin your dialplan and the console log of a single call coming in (or going out) and let's see if you've got a sched_hangup in there somewhere. -MC On Tue, Feb 14, 2012 at 12:26 PM, Fraser Redmond <fraserredmond@gmail.com> wrote: I've done a test call, and got a pcap of it, along with a sip debug. (I can email you files if you are willing to take a look.) There's no sip traffic until it gets to the log lines I pasted before, which is followed by the server sending a BYE to the gateway and client. I did a google search on "nat timeout", but the only thing relevant seemed to be the rtp-timeout and session-timeout which I mentioned before. I really think there's a setting somewhere telling it to hangup. The logs have things like this as the call is being hung up (but before the BYE's are sent) which seem suspicious

Added task 4 switch_ivr_schedule_hangup (uuid) to run at 1329249352

ending bridge by request from read function

Cheers, Fraser On 14 February 2012 14:08, Michael Collins <msc@freeswitch.org> wrote: I would get pcaps of the calls that drop at 5 minutes, including media. If you need suggestions on how to collect pcaps then check out this page: http://wiki.freeswitch.org/wiki/Packet_Capture Lots of tools at your disposal! Don't forget that Wireshark has a really nice interface for exploring SIP calls and RTP streams. -MC On Tue, Feb 14, 2012 at 10:16 AM, Fraser Redmond <fraserredmond@gmail.com> wrote: I've got calls that are getting disconnected after 5 minutes (. There's some calls that don't, and we don't have many calls that last that long (which is why we hadn't noticed until now.) I've had a look through the documentation, and the only thing I saw that looked likely was the rtp-timeouts which I changed to this without any change: <param name="rtp-timeout-sec" value="1800"/> <param name="rtp-hold-timeout-sec" value="1800"/> (changed in internal and external profiles) Here's the log output for when the call ends: 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.340991 [DEBUG] switch_core_session.c:1009 Send signal sofia/internal/sip:12605@99.237.220.56:3907 [BREAK] 2012-02-14 17:42:58.340991 [DEBUG] switch_scheduler.c:214 Added task 4 switch_ivr_schedule_hangup (9d39d866-5732-11e1-b1a8-05fc5f64fa97) to run at 1329241378 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.361011 [DEBUG] switch_core_session.c:726 Send signal sofia/internal/sip:12605@99.237.220.56:3907 [BREAK] 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] switch_ivr.c:589 sofia/internal/sip:12605@99.237.220.56:3907 Command Execute respond(603) 9d39d866-5732-11e1-b1a8-05fc5f64fa97 EXECUTE sofia/internal/sip:12605@99.237.220.56:3907 respond(603) 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] mod_sofia.c:2363 Responding with 603 [Decline] Any other settings I should be looking at? Cheers, Fraser _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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

Hi Fraser, Looking at the log you put in pastebin the call was good without the 5 minutes hangup. Can you put the complete log in pastebin where the call has this problem. The xml doesn't resemble the code snippet of the original 5 minute disconnect. As I said before, I strongly suspect it is something in one of the js files. What file is calling the bridge to 12605@.. As my guess is your issue is here. Cheers Oz From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Fraser Redmond Sent: 15 February 2012 16:16 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Calls ending after around 5min So the background is that we run a call-center with a lot of detailed tracking of the stages of calls for better monitoring of Rep's performance. Later I hope to shift that to the event socket where it ought to be, but for now, it's done inline in the dialplan using JS, often run asynchronously, so as to not hold up the call while making a database insert. We handle lots of different scenarios including inbound calls going to queues, attended transfer of calls, and several other things. Some of these are not implemented in the best manner due to the combination of 3 factors: - inexperience with telephony (a lot of the code was done 2 years ago, with bits upgraded since then. I had used asterisk for a couple of months before that, and come from a webapp development background) - lack of documentation for FS (most things are covered briefly, but many things are only covered briefly) - lack of time to work on implementing things properly (telephony is an important part of our business, but other areas have needed development more.) The steps happening in our dialplan: 1) Website: database insert for the call, with status set to initialised 2) Website runs this command via ESL: api originate {callId=$callId,personId=$_PERSONID,agentExtn=$fromNum,language=en-us,Outbou nd=Yes}user/$fromNum@$freeswitchDomain $toNumClean (This dial's the rep's extn, then once they pick up it starts the bridge to the external number.) 3) This hits the end of the attached dialplan (StaffeySwitchboard) which runs a JS file 4) MainMenuCallsIn.js: sets some variables, and in this case sets ${destinationNumber} then transfers to "outbound_call XML outbound_call" which then runs another JS file: 5) OutboundCall.js: does a manual version of LCR, by looking at the phonenumber prefix and choosing a gateway and setting the variable ${dial_string}, then the dialplan transfers to "ConnectBLeg XML DecideWhetherToCall" 6) That dialplan does several things: a) Runs BridgeBefore.js - in this scenario the only thing it really does is set api_hangup_hook b) Runs api_Call_Stage_Update_SP.js in background (non-blocking so it doesn't delay the call connection), which updates the database's call-status to pickup delay (ringing / early-media ) c) Exports some variables to the b-leg and start recording d) Sets api_Call_Stage_Update_SP.js to run when the call is connected to update the database call-status to spoke-to (call connected / answered) e) Bridge to ${dial_string} f) End recording and run BridgeEnded.js to set the database call-status g) In other scenarios another action might be needed after a call finishes, but in this case it doesn't do anything. I've attached the JS files for steps 4 and 5, but not any of the ones in (6), as they're all pretty small and simple. Feel free to let me know anything you think I ought to change, I'm happy to get any feedback you're willing to give. Though really I'm most interested in solving this problem with calls getting hungup after 5 minutes. Cheers, Fraser On 15 February 2012 03:39, Oz Mortimer <oz@o-tec.tv> wrote: Hi Fraser, Your console output in pastbin isn't complete so of limited use. I'd really need to see you dialplan xml along with possibly your js - feel free to pm me. You dialplan seems overly complicated too, you should be able to all of that within a single js application. From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Fraser Redmond Sent: 14 February 2012 21:26 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Calls ending after around 5min I thought that too, and had done a text-search my code for sched_hangup, and there's no mention of it anywhere. Is there anything else that would set it based on other variables being set? The closest things I have is I'm setting api_hangup_hook to run some javascript when the call is hung up, and hangup_after_bridge=false My dialplan is fairly complicated (several js files get run to do database logging, business logic, etc.) So the console output is probably more helpful: http://pastebin.freeswitch.org/18385 Cheers, Fraser On 14 February 2012 15:41, Michael Collins <msc@freeswitch.org> wrote: Like omortimer says it looks suspicious. I'd pastebin your dialplan and the console log of a single call coming in (or going out) and let's see if you've got a sched_hangup in there somewhere. -MC On Tue, Feb 14, 2012 at 12:26 PM, Fraser Redmond <fraserredmond@gmail.com> wrote: I've done a test call, and got a pcap of it, along with a sip debug. (I can email you files if you are willing to take a look.) There's no sip traffic until it gets to the log lines I pasted before, which is followed by the server sending a BYE to the gateway and client. I did a google search on "nat timeout", but the only thing relevant seemed to be the rtp-timeout and session-timeout which I mentioned before. I really think there's a setting somewhere telling it to hangup. The logs have things like this as the call is being hung up (but before the BYE's are sent) which seem suspicious

Added task 4 switch_ivr_schedule_hangup (uuid) to run at 1329249352

ending bridge by request from read function

Cheers, Fraser On 14 February 2012 14:08, Michael Collins <msc@freeswitch.org> wrote: I would get pcaps of the calls that drop at 5 minutes, including media. If you need suggestions on how to collect pcaps then check out this page: http://wiki.freeswitch.org/wiki/Packet_Capture Lots of tools at your disposal! Don't forget that Wireshark has a really nice interface for exploring SIP calls and RTP streams. -MC On Tue, Feb 14, 2012 at 10:16 AM, Fraser Redmond <fraserredmond@gmail.com> wrote: I've got calls that are getting disconnected after 5 minutes (. There's some calls that don't, and we don't have many calls that last that long (which is why we hadn't noticed until now.) I've had a look through the documentation, and the only thing I saw that looked likely was the rtp-timeouts which I changed to this without any change: <param name="rtp-timeout-sec" value="1800"/> <param name="rtp-hold-timeout-sec" value="1800"/> (changed in internal and external profiles) Here's the log output for when the call ends: 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.340991 [DEBUG] switch_core_session.c:1009 Send signal sofia/internal/sip:12605@99.237.220.56:3907 [BREAK] 2012-02-14 17:42:58.340991 [DEBUG] switch_scheduler.c:214 Added task 4 switch_ivr_schedule_hangup (9d39d866-5732-11e1-b1a8-05fc5f64fa97) to run at 1329241378 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.361011 [DEBUG] switch_core_session.c:726 Send signal sofia/internal/sip:12605@99.237.220.56:3907 [BREAK] 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] switch_ivr.c:589 sofia/internal/sip:12605@99.237.220.56:3907 Command Execute respond(603) 9d39d866-5732-11e1-b1a8-05fc5f64fa97 EXECUTE sofia/internal/sip:12605@99.237.220.56:3907 respond(603) 9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] mod_sofia.c:2363 Responding with 603 [Decline] Any other settings I should be looking at? Cheers, Fraser _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com 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

Ugh, sorry everyone. I did just address those details/attachments to Oz, but then gmail changed it back to being sent to the full list :-( Cheers, Fraser On 15 February 2012 11:16, Fraser Redmond <fraserredmond@gmail.com> wrote:

Thanks Oz, I'll take you up on that offer and send details and files in a separate email.

If anyone else can take a look let me know and I'll email it to you too.

Cheers, Fraser

On 15 February 2012 03:39, Oz Mortimer <oz@o-tec.tv> wrote:

...

Hi Fraser,****

Your console output in pastbin isn’t complete so of limited use. I’d really need to see you dialplan xml along with possibly your js – feel free to pm me. You dialplan seems overly complicated too, you should be able to all of that within a single js application.****

** **

** **

*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Fraser Redmond *Sent:* 14 February 2012 21:26 *To:* FreeSWITCH Users Help

*Subject:* Re: [Freeswitch-users] Calls ending after around 5min****

** **

I thought that too, and had done a text-search my code for sched_hangup, and there's no mention of it anywhere.****

** **

Is there anything else that would set it based on other variables being set? The closest things I have is I'm setting api_hangup_hook to run some javascript when the call is hung up, and hangup_after_bridge=false****

** **

My dialplan is fairly complicated (several js files get run to do database logging, business logic, etc.) So the console output is probably more helpful:****

http://pastebin.freeswitch.org/18385 ****

Cheers, Fraser

****

On 14 February 2012 15:41, Michael Collins <msc@freeswitch.org> wrote:*** *

Like omortimer says it looks suspicious. I'd pastebin your dialplan and the console log of a single call coming in (or going out) and let's see if you've got a sched_hangup in there somewhere.

-MC****

** **

On Tue, Feb 14, 2012 at 12:26 PM, Fraser Redmond <fraserredmond@gmail.com> wrote:****

I've done a test call, and got a pcap of it, along with a sip debug. (I can email you files if you are willing to take a look.)****

** **

There's no sip traffic until it gets to the log lines I pasted before, which is followed by the server sending a BYE to the gateway and client.* ***

** **

I did a google search on "nat timeout", but the only thing relevant seemed to be the rtp-timeout and session-timeout which I mentioned before. ****

** **

I really think there's a setting somewhere telling it to hangup. The logs have things like this as the call is being hung up (but before the BYE's are sent) which seem suspicious****

** **

...

Added task 4 switch_ivr_schedule_hangup (uuid) to run at 1329249352****

** **

...

ending bridge by request from read function****

Cheers, Fraser

****

On 14 February 2012 14:08, Michael Collins <msc@freeswitch.org> wrote:*** *

I would get pcaps of the calls that drop at 5 minutes, including media. If you need suggestions on how to collect pcaps then check out this page:

http://wiki.freeswitch.org/wiki/Packet_Capture

Lots of tools at your disposal! Don't forget that Wireshark has a really nice interface for exploring SIP calls and RTP streams.

-MC****

On Tue, Feb 14, 2012 at 10:16 AM, Fraser Redmond <fraserredmond@gmail.com> wrote:****

I've got calls that are getting disconnected after 5 minutes (.****

** **

There's some calls that don't, and we don't have many calls that last that long (which is why we hadn't noticed until now.)****

** **

I've had a look through the documentation, and the only thing I saw that looked likely was the rtp-timeouts which I changed to this without any change: <param name="rtp-timeout-sec" value="1800"/>****

<param name="rtp-hold-timeout-sec" value="1800"/>****

(changed in internal and external profiles)****

** **

Here's the log output for when the call ends:****

** **

9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.340991 [DEBUG] switch_core_session.c:1009 Send signal sofia/internal/ sip:12605@99.237.220.56:3907 [BREAK]****

2012-02-14 17:42:58.340991 [DEBUG] switch_scheduler.c:214 Added task 4 switch_ivr_schedule_hangup (9d39d866-5732-11e1-b1a8-05fc5f64fa97) to run at 1329241378****

9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.361011 [DEBUG] switch_core_session.c:726 Send signal sofia/internal/ sip:12605@99.237.220.56:3907 [BREAK]****

9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] switch_ivr.c:589 sofia/internal/sip:12605@99.237.220.56:3907 Command Execute respond(603)****

9d39d866-5732-11e1-b1a8-05fc5f64fa97 EXECUTE sofia/internal/ sip:12605@99.237.220.56:3907 respond(603)****

9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] mod_sofia.c:2363 Responding with 603 [Decline]****

Any other settings I should be looking at?****

** **

Cheers, Fraser

****

** **

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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****

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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****

** **

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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****

** **

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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****

** **

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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

Yes, the server and client are both behind a NAT (not sure about the gateway it's connecting through.) Seems like it only occasionally happens with internal calls, but almost always with external calls. So, if it is a NAT timeout, what would I do about that? I'll try the pcap that Michael suggested, and see if that sheds any light on it. Cheers, Fraser On 14 February 2012 14:31, <peder@networkoblivion.com> wrote:

Is it only external calls? And is NAT involved anywhere? 5 mins sounds like a NAT timeout. Try making an internal call and see if it drops after 5 mins. That would give you a clue if there is a firewall/NAT issue.****

** **

** **

*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Fraser Redmond *Sent:* Tuesday, February 14, 2012 12:17 PM *To:* FreeSWITCH Users Help *Subject:* [Freeswitch-users] Calls ending after around 5min****

** **

I've got calls that are getting disconnected after 5 minutes (.****

** **

There's some calls that don't, and we don't have many calls that last that long (which is why we hadn't noticed until now.)****

** **

I've had a look through the documentation, and the only thing I saw that looked likely was the rtp-timeouts which I changed to this without any change: <param name="rtp-timeout-sec" value="1800"/>****

<param name="rtp-hold-timeout-sec" value="1800"/>****

(changed in internal and external profiles)****

** **

Here's the log output for when the call ends:****

** **

9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.340991 [DEBUG] switch_core_session.c:1009 Send signal sofia/internal/ sip:12605@99.237.220.56:3907 [BREAK]****

2012-02-14 17:42:58.340991 [DEBUG] switch_scheduler.c:214 Added task 4 switch_ivr_schedule_hangup (9d39d866-5732-11e1-b1a8-05fc5f64fa97) to run at 1329241378****

9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.361011 [DEBUG] switch_core_session.c:726 Send signal sofia/internal/ sip:12605@99.237.220.56:3907 [BREAK]****

9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] switch_ivr.c:589 sofia/internal/sip:12605@99.237.220.56:3907 Command Execute respond(603)****

9d39d866-5732-11e1-b1a8-05fc5f64fa97 EXECUTE sofia/internal/ sip:12605@99.237.220.56:3907 respond(603)****

9d39d866-5732-11e1-b1a8-05fc5f64fa97 2012-02-14 17:42:58.521032 [DEBUG] mod_sofia.c:2363 Responding with 603 [Decline]****

Any other settings I should be looking at?****

** **

Cheers, Fraser

****

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

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