Add a timeout to the example dialplan

[k4ml]

One issue I noticed with park-only dialplan is that if for some reason the inbound socket process fail or die, then the parked calls will remained in freeswitch db (show calls) will list out the calls, filling out freeswitch internal db until it max out and freeswitch not accepting any new calls.

Is there something can be done in the dialplan other than just calling park, so that if there's no inbound server to process the call, it will just terminate the channel similar to outbound socket ?

[goodboy]

@k4ml yes you can set a timeout using the park_timeout channel variable.

I think that's the way I've normally handled it in the past; if it doesn't work let me know and I'll make a test with a working solution. Actually we should probably document that in the dialplan example stuff.

In general I'd like to ship a production grade example dialplan with switchio. @k4ml if you come up with a good working version we'll gladly take a PR for it.

[goodboy]

@k4ml btw have you noticed that the socket dies with switchio in particular?
If that is the case we likely have a bug.

[k4ml]

@tgoodlet I haven't try switchio yet but this is what I notice when using park-only dialplan + inbound socket in general. Even the socket didn't die, you must be explicitly hanging up the call somewhere in your app.

[k4ml]

So with park_timeout set, I guess we also need to unpark the call if we manage to handle it in channel_park, otherwise the call will be terminated half the way. Looking here we have to do that with uuid_transfer but that will bring back the call into the dialplan, which mean we need at least 2 extensions in the dialplan, one to handle new incoming call (put into park) and another one to handle unpark call, otherwise we will get into infinite loop ?

[goodboy]

which mean we need at least 2 extensions in the dialplan, one to handle new incoming call (put into park) and another one to handle unpark call, otherwise we will get into infinite loop ?

No I don't believe this is true. Using any other call mgmt cmd should take the session out of the CHANNEL_PARK state/app afaik. In the wiki section you linked to uuid_transfer is just used as the typical command to be used within an XML dialplan that would accomplish this. If you've found this is not true that would be a problem but I'd find it hard to believe as I've never experienced it and the the inbound socket approach is the recommended approach according to the wiki - including the use of a park app.

Actually on top of ^ outbound mode parks calls in the same way before transferring control.

[goodboy]

@k4ml if this build passes it should prove my point as there are calls during some of the stress tests in the suite that are kept up longer then 3 seconds (the timeout I added).

[goodboy]

Yep just verified it manually as well. As soon as you do anything else with the session the park timeout is cancelled. I'm going to write a formal test to demonstrate this.