[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:

features.conf:
parkext => 700
parkpos => 701-702
context => parkedcalls

extensions.conf:
[from-office]
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.

Thanks,
Mert 		 	   		  


More information about the asterisk-dev mailing list