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

Matt Hamilton mistral9999 at hotmail.com
Mon Nov 4 18:50:47 CST 2013


> 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





Date: Mon, 4 Nov 2013 17:39:59 -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 2:04 PM, Mert Yazgart <efes9999 at hotmail.com> wrote:




I'm relatively new to Asterisk, and not familiar with the inner workings
 of the code. It was recommended that I post here (instead of the users 
list) - I appreciate it if a developer with experience with Asterisk 
parking can shed some light on the issue I'm having.

I'm basically letting Asterisk (1.8.23) handle all of the parking process:


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


On the Cisco phone, I programmed one of the soft keys to park the calls:
Key: fnc=sd;ext=700 at 10.0.1.103;vid=1;nme=Park

I can either press this key or dial #700 to park the call. Both work smoothly.


The problem happens when I try to park a call when the parking lot is full:

-
 if I try to park it with dialing #700,I get a warning message saying 
that it can't be done. The existing call (that I tried to park) stays on
 as intended. This is the desired behavior.

- On the other hand, 
if I try to park it via using the Key (which sends a REFER), Asterisk 
responds with a SIP 503 message (which the phone processes correctly 
telling me that its an invalid transfer). However, the existing call is 
gone - both caller and callee's phones show as if there is a call, but 
they are not connected to each other.  There is no SIP BYE. Asterisk CLI
 says :
Spawn extension (callee) exited non-zero on 'Parking\SIP\caller'...

Is there something that can be done not to lose the call?

I noticed that parking with dialing #700 and parking with the key button seem to be handled differently in the Asterisk code with different results in this case:


#700 goes thru xfer_park_call_helper and eventually masq_call_transfer in features.c.
Key method (REFER) goes thru sip_park_thread in chan_sip.c, ast_park_call_exten and park_call_full in features.c.

Thanks,

Mert
 		 	   		  

--

_____________________________________________________________________

-- Bandwidth and Colocation Provided by http://www.api-digital.com --



asterisk-dev mailing list

To UNSUBSCRIBE or update options visit:

   http://lists.digium.com/mailman/listinfo/asterisk-dev

Out of morbid curiosity, could you test the same type of transfer against Asterisk 12's parking system?


Also, is this a blind or attended transfer? As in, does the person transferring the call hear the parking failed message, and does that person then get hung up on, or is it the transferee the one that actually attempted parking and failed?

-- 
Jonathan R. Rose
Digium, Inc. | Software Engineer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
direct +1 256 428 6139 

Check us out at: http://digium.com & http://asterisk.org





-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131104/e44739c2/attachment.html>


More information about the asterisk-dev mailing list