[asterisk-dev] Call is lost when Parking lot is full

Mert Yazgart 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... 
> Thanks, 
> Mert 
> 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 mailing list