[OpenSIPS-Users] New features in BLF and presence

[Anca Vamanu]

Hi all,

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 
publications. 
(http://www.opensips.org/html/docs/modules/devel/pua_dialoginfo.html#id227160)

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 
(http://www.opensips.org/html/docs/modules/devel/presence.html#id228554).
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.

Regards,

-- 
Anca Vamanu
www.voice-system.ro