Copyright 2010-2015 Obihai Technology, Inc.
81
It is possible to reserve a block of BLF keys to members of a group of extensions without hard-coding the extension for
each reserved key. The idea is to SUBSCRIBE to a single resource that includes a list of extensions to monitor, instead of
subscribing to each individual extension. Upon receiving a NOTIFY from the server with the list of extensions, the OBi
assigns each extension to a BLF key reserved to the subscribed group using an internal algorithm. To reserve a BLF key
to a member of the group, specify the Number parameter of a BLF key as:
Number
= {
group-name
}
/
For example:
Number
=
sales-team/
The slash (
/
) at the end indicates the key is reserved to a member of the group named
sales-team
. You may also
specify a preferred extension to use that key with the syntax:
Number
= {
group-name
}
/
{
preferred-extension
}
?
For example:
Number
=
sales-team/1003?
The question-mark (?) at the end indicates that 1003 is merely a suggestion and will be used to monitor extension only
if it is present in the list of extensions returned by the server in a NOTIFY message body. If 1003 is not in the extension
list from the server, the OBi1000 is free to assign this reserved BLF to another key when it is running out of free keys to
assign. So, if all the BLF keys are floating without specifying they are a suggestion, the order of extension assignment
follows precisely the order of the extensions in the list received from the server.
Note that the block of BLF keys reserved for a group does not necessarily come from a continuous range of feature keys
- the keys can be any combination of line keys, side car keys, and programmable keys.
SIP for BLF
For each BLF extension that does not belong to any group, the OBi1000 subscribes to the dialog event package for each
extension in the context of the SP service specified in the
Service
parameter of the corresponding feature key. For
extensions belonging to the same group, the OBi only maintains one subscription to the group-name and none for the
individual extensions in the group. In the subscribe request, the OBi indicates (in an Accept header) support for the
following content-types in NOTIFY message bodies to be returned by the server
-
application/multipart/related
-
application/rlmi+xml
-
application/dialog-info+xml
For floating key assignment, the OBi expects the NOTIFY message body to include a resource list (Content-Type:
application/rlmi+xml) that is compatible with RFC4662. Here is an example with two extensions specified in the
resource list:
<?xml version="1.0" encoding="UTF-8"?>
<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:[email protected]"
version="0" fullState="true">
<resource uri="sip:[email protected]">
<name>Obihai User2 </name>
<instance id="DNAbROacM9" state="active" cid="7jTC13@broadworks"/>
</resource>
<resource uri="sip:[email protected]">
<name>Test User</name>
<instance id="MT8FRckGPc" state="active" cid="cJ489p@broadworks"/>
</resource>
</list>
To notify the call states of a monitored extension, the OBi expects the NOTIFY message body to include a dialog-info
XML (Content-Type: dialog-info+xml) that is compatible with RFC4235. Here is an example:
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1"
state="full" entity="sip:[email protected]">
<dialog id="Y2FsbGhhbGYtNjI4MjM4NzU6MA==" direction="recipient">
<state>proceeding</state>
<local>
Содержание OBi1062
Страница 136: ...Copyright 2010 2015 Obihai Technology Inc 136...
