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,Outbound=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:


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