[asterisk-dev] Parked calls feature request

Wed Jul 1 08:49:05 CDT 2009

One of my clients requested that I implement a car hop feature for their
parked calls.  I have implemented the functionality using existing
dialplan functions, but I think it could be improved if the Park
implementation was updated to more directly support this sort of
feature.  My implementation is as follows:

-          Asterisk plays back a recorded message to the parked caller,
and listen for DTMF input from the caller.  The specific message we have
recorded is to the effect of "Your representative is still unavailable.
To continue holding, press 1 or remain on the line.  To return to the
operator or leave a voice message, press 0."

-          Asterisk then waits a few seconds for input, and puts the
call back into the original parking slot if no input was received (or if
a 1 was received).  If a 0 was received, the call is sent to my
operators hunt group, and the operator can put the caller into a
voice-mail queue if the caller requests it.

What I would like to request is that some sort of similar behavior is
directly implemented into Asterisk (in an optional way, so that if
someone doesn't want it, they don't get it), and if possible in a way
that the call remains accessible in the parking lot until they push the
button to return to the operator.

The dialplan code I am using to effect my car hop currently is as
follows:

[macro-bryan-parked]

exten => s,1,NoOp()

exten =>
s,n,GotoIf($[$[${DEVICE_STATE(park:1071 at bryan-parked)}=NOT_INUSE] &
$[!$[${DEVICE_STATE(Custom:park1071)}=INUSE]]]?park1071,1)

exten =>
s,n,GotoIf($[$[${DEVICE_STATE(park:1072 at bryan-parked)}=NOT_INUSE] &
$[!$[${DEVICE_STATE(Custom:park1072)}=INUSE]]]?park1072,1)

-snip- continue for my other parking extensions

exten => s,n,Playback(all-outgoing-lines-unavailable)

exten => park1071,1,Set(PARKEDAT=1071)

exten => park1071,n,Set(PARKINGEXTEN=1071)

exten => park1071,n,Park(,parkedcallstimeout,s,1)

exten => park1072,1,Set(PARKEDAT=1072)

exten => park1072,n,Set(PARKINGEXTEN=1072)

exten => park1072,n,Park(,parkedcallstimeout,s,1)

-snip- continue for my other parking extensions

; end [macro-bryan-parked]

[parkedcallstimeout]

exten => s,1,NoOp("Parked call timed out - ${PARKEDAT} - CID:
"${CALLERID(all)})

exten => s,n,Set(DEVICE_STATE(Custom:park${PARKEDAT})=INUSE)

exten => s,n,Background(custom/aol-to-continue-holding)

exten => s,n,WaitExten(5)

exten => s,n,Goto(1,1)

exten => 0,1,Set(CALLERID(name)="Park: "${CALLERID(name)})

exten => 0,n,Set(DEVICE_STATE(Custom:park${PARKEDAT})=NOT_INUSE)

exten => 0,n(dial),Dial(SIP/1010,20,wW)

exten => 0,n,Dial(SIP/1010&SIP/1028&SIP/1016&SIP/1015,20,wW)

exten => 0,n,Goto(0,dial) ; dial failed - retry

exten => 1,1,Set(PARKINGEXTEN=${PARKEDAT})

exten => 1,n,Set(DEVICE_STATE(Custom:park${PARKEDAT})=NOT_INUSE)

exten => 1,n,Park(,parkedcallstimeout,s,1,s)

exten => i,1,Goto(0,1)

exten => t,1,Goto(1,1)

exten => h,1,Set(DEVICE_STATE(Custom:park${PARKEDAT})=NOT_INUSE)

; end [parkedcallstimeout]

So, the changes from the normal logic are as follows:

-          My function overrides the default parking slot selection
logic for two reasons.  First, if a parked call has timed out and the
caller is still listening to the "would you like to keep waiting?"
message, the parking slot they were in will show as available and could
be chosen by a new parked call.  Alternately, if 1071 is in use when a
call is initially parked (thus putting the call on 1072), but then is
available after the call has timed out and automatically re-parks, the
default logic would "move" the call up to 1071 (since the default logic
sees the re-park as a new parked call).  As this causes much confusion
and consternation when parked calls move around, I need some way to know
which parking slot a time-out comes from, and I need a way to lock that
parking slot while the timed-out caller is determining whether or not he
wants to keep holding.

-          Since I couldn't find a way to get the parking slot a timed
out call was coming from, I went ahead and set a custom channel variable
(PARKEDAT) prior to parking the call.  This variable is then available
when the call times out to tell me where it came from.

-          In order to lock the parking slot that the timed out call is
coming from, I set a Custom device state for park1071, park1072, or
whichever slot was timed out.  The hangup extension ensures that if the
caller should hang up while listening to the "would you like to keep
waiting?" message, the custom device state gets unlocked, thus
preventing the parking slot from getting stuck closed.

-          If the user chooses to return to the operator, I pre-pend the
Park: information to the caller ID name of the call, so that the
operator is able to distinguish the call from a normal incoming call and
answer it appropriately.

What I would like to see is a way (within features.conf or something
similar) to have Asterisk enter a car hop mode for a timed-out parked
call, so that Asterisk jumps to a specified dialplan priority which
would allow the system admin (me) to configure a message to be played
and logic to handle any input I might expect.  There should be a
function that allows me to re-park the call on the same slot
(effectively resetting the parked call timeout timer), and the parked
call should remain in the parking slot while the car hop logic is
executing if at all possible, so that if the representative becomes
available while the caller is listening to the "would you like to keep
waiting" message, the representative can pick up the call.  If the car
hop must remove the call from the parking lot in order to handle it, it
should at least lock the parking lot to any other calls until the timed
out call has chosen to leave the parking lot (either via hanging up or
by using one of our specified "leave the parking lot" methods).

I'd definitely help with the testing, and I'd be willing to help with
the coding if someone can give me an idea where to start digging; I find
the prospect of digging through to find where the parking features are
implemented a little daunting.

Thank you,

Noah Engelberth

Direct Link Computer Systems

noah at directlinkcomputers.com

419-636-0999 ext 100

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090701/bb59e6ed/attachment-0001.htm 