Re: [OpenSIPS-Users] New features in BLF and presence

2010-04-20 Thread Anca Vamanu
Iñaki Baz Castillo wrote:
 Let me a question:

 In case the INVITE has a SDP just containing a MSRP path (without
 audio/video), would also the pua_dialog generate a ringing
 dialog-info Publish?
 This is, if Alice starts a MSRP messaging session with Bob, would
 Carol see both Alice and Bob with activity On the phone?  :)


   
Hi Inaki,

Yes, it will.
In fact what happens is that the dialog module will trigger the 
pua_dialoginfo callback for created dialog and pua_dialoginfo will 
generate a Publish with state trying. The dialoginfo - presence 
translation feature in presence module will then generate a presence 
publish with substatus ringing.
The pua_dialoginfo doesn't do any check of the SIP message and assumes 
that if the dialoginfo_set function has been called from the script, 
then it should generated dialog publications for that dialog.The problem 
is that the MSRP offers are also carried in SDP bodies so it is hard to 
check this from the script and not call dialoginfo_set for those Invites.
I think that somewhere in this path a check should be added to prevent 
generating dialog info and presence publications for MSRP Invites. 
Probably either by writing a function to be called from script like 
is_msrp() or doing the check in pua_dialoginfo.


Regards,

-- 
Anca Vamanu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] New features in BLF and presence

2010-04-15 Thread Anca Vamanu
Iñaki Baz Castillo wrote:
 2010/4/14 Anca Vamanu a...@opensips.org:
   
 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.
 

 Hi, this feature sounds really reasonable for the real world in which we live 
 :)
 Could I see how such NOTIFY (mixing presence and dialog information)
 looks? (just an example).

 Thanks.

   
Hi Inaki,

The mixing is done as until now, no changes in this part. The presence 
info extracted from dialog is considered to have the greatest priority 
and is inserted the first. Here is an example:

?xml version=1.0 encoding=UTF-8?
presence xmlns=urn:ietf:params:xml:ns:pidf 
xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model 
xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid 
xmlns:c=urn:ietf:params:xml:ns:pidf:cipid entity=sip:a...@192.168.2.132
tuple xmlns=urn:ietf:params:xml:ns:pidf id=tuple_mixingid
status
basicopen/basic
/status
/tuple
note xmlns=urn:ietf:params:xml:ns:pidfOn the phone/note
dm:person xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model 
xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid id=pers_mixingid
rpid:activities
rpid:on-the-phone/
/rpid:activities
dm:noteOn the phone/dm:note
/dm:person
tuple id=tab31c654
status
basicopen/basic
/status
/tuple
dm:person id=p9e054e30
rpid:activities
rpid:busy/
/rpid:activities
dm:noteBusy/dm:note
/dm:person
/presence


Regards,

-- 
Anca Vamanu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] New features in BLF and presence

2010-04-14 Thread 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


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] New features in BLF and presence

2010-04-14 Thread Olle E. Johansson
Anca,
This sounds like a very good start. My experience is that this is something 
that different people will want to use in different ways. Some people don't 
want phone calls to affect presence, where others say differently In the 
future, there might be need for a per-uri configuration option or something 
like that.

Cheers,
/O
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] New features in BLF and presence

2010-04-14 Thread Iñaki Baz Castillo
2010/4/14 Anca Vamanu a...@opensips.org:
 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.

Hi, this feature sounds really reasonable for the real world in which we live :)
Could I see how such NOTIFY (mixing presence and dialog information)
looks? (just an example).

Thanks.

-- 
Iñaki Baz Castillo
i...@aliax.net

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users