[OpenSER-Devel] Question about presence service and OpenSer Presence Module

[Anca Vamanu]

Hi Luca,

Great to know that there is research on how to improve OpenSer presence 
server.
I prefer you send me these e-mails on the devel list. They are quite 
technical, but they might do good to someone else looking into extending 
presence server.

Luca Foschini wrote:
> Dear Anca,
>     I'm a post-doc at the University of Bologna, and I'm
> actually working on IMS and presence
> Sorry for contacting you directly and not through the mailing
> list, but as you see the question is on a specific technical
> choice rather than on the module itself.
>
>
> I'm taking advantage of your excellent work on Openser
> presence module, and I'm using it to do some experiments
> on a multidomain IMS environment.
> In particular, I'm exploring the possibility to limit inter-domain
> NOTIFY traffic. The idea is to aggregate NOTIFY messages
> due to a publish of a presentity subscribed and publishing in
> domain B (to presence server B), to subscribed watchers in
> domain A.
> The idea is that the presence server in domain B relays this
> aggregated NOTIFY message to presence server A.
> Hence, I was wondering which is the best way to achieve this
> with your presence server implementation. In particular, I've
> already modified the notify.c file to gather watchers' contacts,
> but I found it difficult to pass this information from presence
> server B to presence server A and to (re-)generate NOTIFY
> messages on presence server A (since watchers are actually
> subscribed on presence server B). For instance, is it possible
> to generate a NOTIFY message for a watcher that is actually
> not subscribed to the presence server? Otherwise, are there
> other possibilities to realize this? For example, is it possible to
> subscribe presence server A to presence server B and to keep
> it updated with watcher list changes?
>
>
> Thanks in advance for your time.
>
> Best Regards,
>     Luca Foschini
>
Let me explain the how presence server works now. Consider we have userA 
from domain A and and userB from domain B  publishing their presence 
state subscribing to each other. Then , the normal message flow will be 
like this:
userA  --------->  presence server A
             Publish

user B ----------> presence server B
             Publish

userA ----------> presence server B
          Subscribe
           userB

userB ----------> presence server A
          Subscribe
           userA


The subscribe from userA to userB will be forwarded by the proxy server 
in domain A to the  proxy and then the presence server of domain B, 
because R-URI (meaning the final destination) will point to domainB.

So, what you want is to have the proxy direct all Subscribe messages to 
the local presence server. Ok.
Now , having the presence servers exchange information in an efficient way.
There are 2 issues to consider here.
2. Respecting the privacy rules. (If you have 5 users subscribing to the 
same contact in a remote domain, it is possible to receive different 
Notifies.)
3. Minimize the the traffic

I see two ways of doing this.
I. Sending one Subscribe for each remote domain Subscribe received. So 
if there are 3 users from domain A subscribing to one user from domain 
B,  3 Subscribe messages , from behalf of all the users will be sent to 
domain B.
This is enough to solve point 1. At presence server B, the presence 
server will do the handling and decide the subscription state. However, 
it should not send one notify each since it will break 3.
When a Publish comes for a presentity, only one notify should be sent 
for the entire list of watchers from a certain domain. Here you need to 
decide upon a format of the body and not forget to include the 
authorization state also. You can choose any of the active dialogs to 
send this Notify.
And about how you should do this aggregation, I must insist on not 
changing the current presence server files but as little as possible. 
This should be designed as a configurable option or better as a module 
coming on top of presence module to monitor the lists and stop Notifies 
and aggregate.
And of course, at domain A there should be a way to interpret and devise 
this Notify. Here again I suggest a module on top, probably the same , 
to handle in coming Subscribes and sending aggregate Notifies to remote 
domain. In fact you will have the presence server of the local domain 
know nothing about the Subscribes to remote domain, as it happens now, 
and have only this module on top, store the dialogs and then send the 
notifies.
A good example on how to do this can be found in the RLS module. What 
this module does, is to receive Subscribe messages directed to a list, 
and then send a Subscribe message to the presence server of each contact 
in the list. It then captures and processes the received Notifies. This 
is sort of like what you need.

II. The second option requires more additions but less traffic.
Sending one Subscribe for a list of watchers. Here you need to decide 
upon a body for the subscribe - to hold the uri s for the watchers and 
means to signal an update of the list.
Again the best way to implement this is with a module on top. Capture 
subscribes to remote domain and transform them, and the send one 
Subscribe to the remote domain. The improvement here is that when 
refreshing Subscriptions, only one is sent, while in the first scenario 
one for each watcher.
There should be an application knowing how to process this Subscribes at 
the remote domain. One option is again to transform them in one 
Subscribe for each contact and to send them locally to the local 
presence Server and then capture the Notifies as in the first scenario. 
Most probably the easiest way. The second is to find authorization 
status for each watcher inside that application and monitor Publish 
messages. But the authorization part is quite complicated(with Notifies 
for presence.winfo).

There other ways to do this. You can choose any other. There are just 
some issues that you must keep in mind, make this an optional feature 
and be careful at presence authorization rules.
I hope my explications will help you.


regards,
Anca Vamanu


> -- 
> _________________________________________
>
> Luca Foschini, Ph.D.
> DEIS-LIA - Università degli Studi di Bologna
> Viale Risorgimento, 2 - 40136 Bologna (ITALY)
> Ph.: (+39) 051 20 93541 Fax: (+39) 051 20 93073
> E-mail: lfoschini at deis.unibo.it
> Web: http://lia.deis.unibo.it/Staff/LucaFoschini/
> _________________________________________