[OpenSIPS-Users] New features in BLF and presence
anca at opensips.org
Wed Apr 14 11:20:12 CEST 2010
Recently OpenSIPS had two important improvements in BLF (dialog info)
and presence. The first one gives more flexibility and makes it
adaptable to more platform architectures. The second one transforms
dialog information into presence, mixing the two and making the presence
server more powerful as it will be able to notify the watchers not only
about the state that it received in Publish messages but also if the
user is currently in a call.
First, BLF was given more configuration options. Until now, if you
wanted dialog info support you had to call a function ( dialoginfo_set )
on an initial INVITE and the server would have generated Publish
messages for dialog event for every new event in that call ( ringing,
established, terminated, etc. ) for both the caller and callee and using
the URI's in From and To header. This fixed behavior is not sufficient
in many cases.
The first problem was with the fact that it generated publications for
both the caller or callee if the domain was considered to be local. In
some cases it can be obvious that the server should not generate dialog
info for a party. For example, if you determine that the caller or
callee is a PSTN number, then there is no reason the generate dialog
info for it. And this deductions and decisions can only be made from the
scrips so it is normal to be able to control from the script for which
party the server should generate dialog Publications. To enable this, we
allowed dialoginfo_set function to receive a parameter through which the
script writer can tell for which of the call parties it wants dialog
The second problem was with the URIs used as presentity URI when
generating the Publish messages. In most cases the real callee URI is
obtained in RURI after a series of transformations done in the script.
Therefore, we changed the default source for the callee URI to the RURI
( until now it was the URI in From header). The RURI to be used is the
one found in the message at the time when dialoginfo_set function is
called. More than this, we allowed for the two URI's caller and callee
to be set to custom values by completing some pseudo variables. The
specs for these pseudovariables must be specified in two module
parameters. If a pseudovariable is set at the moment when dialoginfo_set
function is called, its content is used as presentity uri, otherwise the
default values are used ( RURI for caller and To uri for callee).
These two improvements make BLF adaptable to any needs.
The second important feature is the possibility to mix dialog
information with presence. Until now, dialog and presence were two
different things. If you wanted to know if someone is currently in a
call, your phone had to support BLF and send Subscribes for dialog
event. Knowing if someone is in a call is quite a demanded feature. The
simplest example is with the assistant manager that first answer the
calls and needs to know if the manager line is idle and she can transfer
the call to him. The reality is that few phones have support for dialog
event notifications, but more have support for presence.
Therefore, we decided to mix the dialog information with presence at the
presence server. Now, the presence server is able to tell you if a buddy
is in a call through presence Notifications even if his phone did not
send a presence Publish with this information. The mixing in fact
generates presence from dialog info when a call is in progress and mixes
this with the presence information received from his phone through
Publish. The result is that when a buddy is in a call you will see a
status indicating this and in the rest of the time you will see the
presence state that the buddy set in his client.
This behavior is enabled by setting a module parameter
This is a very nice feature that gives more power to the presence server
making it able to satisfy the needs of the end users even if their
phones are less capable.
Hope you will find these features useful.
More information about the Users