Copyright 2010-2017 Obihai Technology, Inc.
94
</identity>
</bw:parked>
</bw:callpark>
</dialog>
</dialog-info>
BLF With OBiTALK Service
While most BLF implementation requires the soft switch to act as the state aggregator, OBiTALK service offers a peer-
to-peer version of BLF that can be quite handy. Every OBi1000 Phone can notify its phone status to a configured OBi
number that is configure in the
OBiTALK Service
–
Calling Features
::
CallStatusAggregator
parameter. The
notified phone monitors each notifying phone with a BLF function key that is configured with the Voice Service field set
to OBiTALK and number set to the monitored 9-digit OBi number.
The following phone status can be monitored:
-
Offline
-
Idle
(no calls)
-
Ringing
(at least 1 call ringing)
-
Holding
(at least 1 call holding)
-
Connected
(at 1 call connected)
On the monitoring phone, the following operations can be applied to the monitored OBi Number:
-
Call
(Call the monitored OBi Number)
-
(Directed) Pick Up
(Pick up the oldest ringing call on the monitored phone)
-
Barge-In
(Barge in a connected call on the monitored phone)
-
Coach
(Coach the monitored phone on a connected call)
Note: The call on the monitored phone to be picked up, barged in, or coached does not need to be on OBiTALK service.
If the call is not on OBiTALK service, the monitored phone briges the call with the OBiTALK call leg with the monitoring
phone that initiates the operation.
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.
