Copyright 2010-2015 Obihai Technology, Inc.
82
<identity display="ObihaiUser2 ObihaiUser2">
sip:[email protected]
</identity>
<identity display="ObihaiUser2 ObihaiUser2">
tel:+12404982562;ext=2562
</identity>
</local>
<remote>
<identity display="ObihaiUser1 ObihaiUser1">
sip:[email protected];user=phone
</identity>
</remote>
</dialog></dialog-info>
When the soft-switch is capable of notifying call park status for the monitored extension, it is expected the status is
reported inside a dialog-info XML as well. Here is an example:
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
xmlns:bw="http://schema.broadsoft.com/callpark"
version="3" state="partial"
entity="sip:[email protected]">
<dialog id="Y2FsbGhhbGYtMzM6MA==">
<state>confirmed</state>
<bw:callpark>
<bw:parked>
<identity display="Alice south">
sip:[email protected];user=phone
</identity>
</bw:parked>
</bw:callpark>
</dialog>
</dialog-info>
Call Park and Call Pickup
(SIP/SP only.) Call Park and Call Pickup (or Call Retrieval) are complementary operations not unlike call hold and call
resume, except the pickup (vs. resume) operation can be carried out on extensions other than the one that parks (vs.
holds) the call. Generally speaking, a “parking lot” for calls with many slots can be setup at the Soft Switch such that a
call may be parked at an unoccupied slot from one extension and picked up by the same or another extension from the
same slot. In some implementations the parking slot is referred to as a
park orbit
.
Each parking slot can hold one call and is uniquely identified with a numeric ID (the slot-id or orbit), such as 001, 1234,
88912, etc. While a user is talking to someone on the phone, they can choose to park the call at an unoccupied slot, and
later they (or someone else) can pick up the call from the same slot. From a usability standpoint, it may be inconvenient
for the user to first find out which parking slots are available before parking a call. A simple solution is to let the system
pick an available slot to park the call, in a certain pre-defined range when requested by a certain user. The latter case
can be refereed to as “valet parking”, while the former “self parking”. The problem with valet parking is that the system
still needs to communicate back to the user the parking slot ID that has been chosen, so that the call may be picked up
later from that slot. In some systems, this is done by showing the parking slot ID on the phone screen, which obviously
only works for phones with a display. Another strategy of choosing a parking slot is to use the parking phone's
extension number as the parking slot identifier, for easy memorization. You can think of each extension as having an
associated parking slot, such that one call can be
parked against one extension
that has this resource enabled. When
the user attempts to park a call, you can park against the current extension the call is on by default, or against another
extension by explicitly entering the target extension. Similarly you can pick up a call that is parked against your current
extension, or against another extension by explicitly entering the target extension. In applications where most users
normally park no more than one call at a time, a user can just park against his own extension; thus avoiding parking slot
collisions. With this approach, some BLF implementations also include parking slot monitoring when monitoring an
extension.
Call Park Methods
