Parking – Why Doesn’t This Work?

Home » Asterisk Users » Parking – Why Doesn’t This Work?
Asterisk Users 4 Comments

I’m trying to implement parking with only one button to park and unpark a call.

Scenario:
Call is answered, I press the button (on a Cisco SPA504) to park the call, it comes to [from-office] context where the call is parked successfully (there is no parking lot number announcement though).

To unpark, I press the same button, it comes to [from-office] context, and the call is picked up/unparked successfully. (I know there is no need to check the device state, since Park will go to the next line if it fails, but this is only for testing.)

The problem happens when I try to park the same call to the same parking lot space AGAIN by pressing the same button. This time I hear the announcement, but something else happens which I’m not sure how to describe – the incoming call seems to be put on hold and parked at the same time (to end the call, you need to press “end call” twice).

This is my first attempt at parking, and I know this is not the common way to do this, but would like to know why this is failing.

Here is my config:

[from-office]
exten => _70X,1,SET(devstate=${DEVICE_STATE(park:${EXTEN}@parkedcalls)})
same => n,GotoIf($[“${devstate}”=”INUSE”]?unpark)
same => n,Set(PARKINGEXTEN=${EXTEN})
same => n,Park() ;

4 thoughts on - Parking – Why Doesn’t This Work?

  • Hmmm, do I understand you correctly that you park and unpark a call using the same phone?

    If yes, why does simply “holding” the call does not work? The SPA504 has an extra large button on the right for this and you don’t need any support in the dialplan.

    jg

  • Parking/unparking will be done from multiple phones so that someone else can pickup/unpark the call from their phone that I parked on mine. I’m just testing it on one phone now.

    I’m trying to simulate the SLA functionality (which Asterisk has, but it’s not very scalable and they haven’t really been doing much development/improvement on that lately). We have been using SLA for a while, but we are also looking at other options. Unfortunately, conventional parking (pressing #700 and announcing the parking space) is not suitable for our very fast paced environment.

    ————————————–

  • You can hack together a way with custom device states and manual use of the Park() and ParkPickup() functions, but it won’t be particularly pretty. A rough dialplan might look like the following (adjust to match your requirements, especially if a park fails or something similar):

    exten => _70[1234],1,Verbose(5,Park pickup or park call for slot ${EXTEN})
    same => n,GotoIf($[${DEVICE_STATE(park:${EXTEN}@parkinglot)} = NOT_INUSE]?park,pickup)
    ; Currently no call parked – park call same => n(park),Set(__PARKINGEXTEN=${EXTEN})
    same => n,Set(__RETURNTO=${CALLERID(num)})
    same => n,Dial(Local/s@park,)
    ; Park failed, clear the device state and return same => n,Goto(parking-return,${RETURNTO},1)
    ; Currently a call parked – pick up same => n(pickup),ParkedCall(${EXTEN}@parkinglot)
    same => n,Hangup()

    [park]
    exten => s,1,Verbose(5,Park call)
    same => n,Park(,parking-return,${RETURNTO},1,s,parkinglot)

    [parking-return]
    exten => _X.,1,Verbose(5,Return parked call to internal phone)
    same => n,Set(CALLERID(name)=PK:${CALLERID(name))
    same => n,Dial(Local/${EXTEN}@users,)
    same => ; some fallback for if the return user doesn’t answer

    Basically, the idea is, check to see if the parking space is occupied. If it is occupied, someone is trying to pickup the parked call, so connect them with the ParkedCall() application. If it is not occupied, someone is trying to park a call, so set up the PARKINGEXTEN variable with “where to park it” (e.g. 701), and set up the RETURNTO variable with “where to return if the park fails or times out” (in my example, based on the caller ID number of the parking channel – make sure it’s set to something that will return either via a local channel like I have in my example or a direct dial to a SIP/ or other channel).

    By putting the double underscore (__) in front of the variable name when we set it, we tell Asterisk to automatically set that variable on any channel spawned as a descendant of this channel (necessary for parking via a Local channel).

    I’m suggesting parking via local channel so that the RETURNTO variable survives on an attended transfer. Also, the specific example I have above will not work properly with unattended (blind) transfers to the parking extension. If you want to support a blind transfer to the parking space, you need to find a way to use the BLINDTRANSFER and BLIND_XFER_PEER channel variables to set RETURNTO correctly.

    There’re plenty of other ways to do it, but the core of what you’ll need to investigate for “SLA parking” is to use ${PARKINGEXTEN} to tell Asterisk where to park the call, and use the features.conf settings for the parking lot to prevent Asterisk from automatically hunting into additional spaces (if you allow Asterisk to hunt into a new slot, and two people try to park on 701 at the same time, one of the two calls will wind up on 702 and the ,s, option in the Park() application means Asterisk won’t be reading back parking slots to the Parker, so you won’t know which call lost the race. Practically speaking, it’s not a huge problem, but the best practice would be to prevent the auto-hunting and avoid the race condition altogether).

    Thank you,

    Noah Engelberth MetaLINK Technologies

    From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Matt Hamilton Sent: Monday, October 14, 2013 10:28 AM
    To: Asterisk Users Mailing List – Non-Commercial Discussion Subject: Re: [asterisk-users] parking – why doesn’t this work?

    Parking/unparking will be done from multiple phones so that someone else can pickup/unpark the call from their phone that I parked on mine. I’m just testing it on one phone now.

    I’m trying to simulate the SLA functionality (which Asterisk has, but it’s not very scalable and they haven’t really been doing much development/improvement on that lately). We have been using SLA for a while, but we are also looking at other options. Unfortunately, conventional parking (pressing #700 and announcing the parking space) is not suitable for our very fast paced environment.

    ————————————–

  • Thanks Noah.

    I thought my dialplan did that: Check to see if the parking space is occupied, if so, pickup the call in the parking space, if not, park the call to that space.

    This works fine for the first time around, but the second time the phone/asterisk behaves differently. Still not clear why it’s failing. Device states are updated correctly btw. I assumed when you unpark a call, that space becomes available/free, and you can park the same call to the same parking space more than once; e.g. park it to 701, unpark/pick it up from 701, park it to 701 again, unpark it, etc.

    I’m only using one phone (in the lab) – the race condition is not an issue for now, but thanks for reminding that because my approach might not work the way I thought it would. I will look into your solution. In any case, it might be better to let Asterisk pick a random spot (4 lines, 4 parking spots). The good thing is, we don’t need to know where it is (anyone can pick it up) as long as BLF works properly and we know there is a call parked.

    Matt

    From: nengelberth@team-meta.net To: asterisk-users@lists.digium.com Date: Mon, 14 Oct 2013 20:31:06 +0000
    Subject: Re: [asterisk-users] parking – why doesn’t this work?

    You can hack together a way with custom device states and manual use of the Park() and ParkPickup() functions, but it won