[asterisk-dev] Call is lost when Parking lot is full
efes9999 at hotmail.com
Thu Nov 7 13:20:25 CST 2013
> Date: Thu, 7 Nov 2013 12:30:34 -0600
> From: jrose at digium.com
> To: asterisk-dev at lists.digium.com
> Subject: Re: [asterisk-dev] Call is lost when Parking lot is full
> On Mon, Nov 4, 2013 at 6:50 PM, Matt Hamilton
> <mistral9999 at hotmail.com<mailto:mistral9999 at hotmail.com>> wrote:
> > Out of morbid curiosity, could you test the same type of transfer
> against Asterisk 12's parking system?
> I can do that in the next couple of days and let you know.
> > Also, is this a blind or attended transfer?
> There is no parking failed message, Asterisk only sends SIP 503.
> In sip_park function in chan_sip.c, it seems like the original
> transferer and transferee channels are masqueraded, the sip_park_thread
> is run, but the parking fails because the parking lot is full. Can it
> be because of this masquerading that Asterisk cannot restore the
> original call? I hope I'm making sense...
> Well, under normal circumstances, I think one of two things would
> happen when using the transfers feature from a SIP phone...
> Blind transfer (where the device will hang up as soon as you push
> transfer) - The parking would fail, the transferee would have nowhere
> to go, and then the channel would get terminated because it isn't
> connected to anyone anymore.
> Attended transfer (the device dials the extension, listens for a while,
> and then completes the transfer) - Parking would fail. If the transfer
> button is pushed while the parked call failure message would play, the
> call is effectively over after the transferee finishes hearing the
> parked call failure message.
> Either way, both channels should eventually get hung up. Throw me some
> sample configs (just the relevant parking lots in features.conf and any
> extensions from extensions.conf you may be using) and I'll take a peek.
> Jonathan R. Rose
> Digium, Inc. | Software Engineer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> direct +1 256 428 6139
For testing purposes, I'm using the default parking lot:
parkext => 700
parkpos => 701-702
context => parkedcalls
include => parkedcalls
> Either way, both channels should eventually get hung up.
That's what happens in Asterisk 12beta release (I posted that under "Asterisk 12.0.0-beta1 Call is hung up when Parking lot is full").
We have a fast-paced environment with multiple agents, it's better for us if the parker gets a SIP 503 or a transfer/park failed recording while keeping the call intact.
I noticed that there are two different ways to park a call in Asterisk:
masq_park_call and park_call_full in features.c
masq_park_call behaves exactly the way we want it - if there is no parking space left, it plays a failure message and hangs up the masqueraded chan keeping the original channels intact.
In the other way (which covers our case), this doesn't happen.
More information about the asterisk-dev