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: [EMAIL PROTECTED]
> Web: http://lia.deis.unibo.it/Staff/LucaFoschini/
> _________________________________________
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
