Skip to main content

Presence Service for Mobicents

16 replies [Last post]
eduardomartins
Offline
Joined: 2005-10-10
Points: 0

Hello to all, my name is Eduardo and i'm working @ PT Inovação, my main task will be to produce a Presence Service for Mobicents that will "talk" with two RAs, the existing SIP RA and a XMPP RA that is being finished.

We are still discussing the right architecture but the idea is to have a SBB for each RA and another SBB that will implement the generic Presence Service.

Any help or contribution will be appreciated, if you have interest please contact me in this topic or mail me @ est-e-martins@ptinovacao.pt

Best Regards,

Eduardo Martins

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ivelin
Offline
Joined: 2003-07-13
Points: 0

Eduardo,

Very good diagram. It illustrates one possible solution.

I think that your original argument for independent protocol handlers will result in better architecture though.

Instead of having one root SBB for the presence service, that works with all protocol events, it would be cleaner if there are two independent "translating" services. One for SIP and another for XMPP. Plus another Presence Service with its own root SBB which understands higher level events. Protocol specific services will talk to the generic presence service via this higher level API (as think Norbert suggests).

Ranga illustrated this design as having each protocol dependent SBB put a higher level event on a named activity context that actually does the presence processing.

Am I making sense? If so, can you please update your diagram to verify that we are on the same page?

Now that you have developer access, feel free to upload to the files&docs section.

Ivelin

parryfogat
Offline
Joined: 2007-08-22
Points: 0

Hi Eduardo,

I also got the similar assignment i.e. developing a Presence server but using XCAP.

In the XDM architecture, I could see a "Subscription Manager" (https://openxdm.dev.java.net/servlets/ProjectProcess?tab=2) , which I hope will do some of the processing of Presence stuff.

May I know what will be the role of Subscription Manager and how it can be used in making the presence service using XCAP.

Regards,
Parvinder

ivelin
Offline
Joined: 2003-07-13
Points: 0

Eduardo says:
> Well, I thought to separate the actual protocol differences because if someone wants to add a new protocol it would need only to build a SBB that deals with that particular protocol RA and with the generic presence service SBB.

This is a very important advantage. I can see why there would be interest for integrating RAs for legacy protocols such as SS7 or H.323. These should be possible to build and plug in optionally without affecting the generic presence server.

Ivelin

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

Ok, I made a new diagram regarding Ivelin's ideas, which breaks the Presence Service to 3 *components*. You can check it out @

https://mobicents.dev.java.net/files/documents/1075/22680/Mobicents_Pres...

This possibility for the final architecture is close to what I first thought but some people argue that one service - presence - should have *only* one Root SBB. The way I see is this are 2 services, the generic presence service and the specific presence protocol translator, the first can be reached from SLEE directly and from network, using the service the second provides.

Please tell us your opinion.

Regards,

Eduardo

ivelin
Offline
Joined: 2003-07-13
Points: 0

Looks perfect.

mranga
Offline
Joined: 2003-06-06
Points: 0

Looks great. What tool do you use for these diagrams? I've been using Magic Draw (when the spirit moves me to make such diatams that is ).

Ranga

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

I have been using an old version of Sparx Enterprise Architect, you can try a trial at http://www.sparxsystems.com.au it's not a diagram draw tool, it's a full developer tool.

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

Ok, check this diagram @

https://mobicents.dev.java.net/files/documents/1075/22679/Mobicents_Pres...

This is my idea for the architecture, it supports all parts (User Agent, Wacther and Presence Service) to be in or out of SLEE. The agent's root SBBs decide (based on configuration or self discovery) if they use RA or the SLEE SBB child for the service.

I will implement, at least, the Presence Service and Watcher parts.

Let me know of your thoughts :)

Regards,

Eduardo

hoichin
Offline
Joined: 2004-12-03
Points: 0

Just some comments. I would of thought create a JCC/JCAT RA that is able to handle both SIP and XMPP. Not sure where JCC/JCA RA is at right now, but that would bridge the two protocols.

mranga
Offline
Joined: 2003-06-06
Points: 0

Hi and welcome,

Why not a single Sbb for both RA? With two event handlers - one for each RA.

i.e. onXMPPEvent and onNotify ( for SIP )

Dont know if that makes sense but I thought I'd throw it in as food for thought.

Ranga

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

Well, I thought to separate the actual protocol differences because if someone wants to add a new protocol it would need only to build a SBB that deals with that particular protocol RA and with the generic presence service SBB.

Regards,

Eduardo

mranga
Offline
Joined: 2003-06-06
Points: 0

Just want to flesh things out a bit more.... What do you envision the root sbb of the presence service looing like in this case ( what would be its convergence name)?

Ranga

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

Presence Service?

Eduardo

Message was edited by: eduardomartins

mobid
Offline
Joined: 2005-08-30
Points: 0

Hello I have to deal with a similar problem.
(Please note I am relatively new to SLEE area)
There will be a service which has to handle different "legs" with different protocols. Approach is to have one service SBB controlling the whole thing and which uses childSBBs for the different "legs" protocols. So there is one protocol SBB per leg, which means one childSBB per RA. The protocol SBBs have to deal with all protocoll messages and communicate with the service SBB via a "higher level" API, here I hope application defined events could be used or also the local interfaces of the SBBs. The protocol SBBs should be potentially used by differrent service SBBs too.
In my service example the initial event is a SIP INVITE. To make the service SBB the root SBB my idea is the following:
The service SBB assigns for the INVITE, but delegates further processing of the incoming SIP leg to a SIP childSBB (creating SIB child, attach childSBB to incoming AC, childSBB will get then INVITE too, and then informs the service SBB via the "higher level" API about the service incarnation). It is up to the service SBB then to create further child SBB(s) and RA for outgoing legs then.
So basically this approach is in line with eduardomartins approach.
Any comment is appreciated.
Regards Norbert

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

Well actually I was thinking in a diferent base SBB for each RA and then a common Child SBB using a high level API (PAM?) for the service.

Eduardo

mranga
Offline
Joined: 2003-06-06
Points: 0

You would need a common root sbb. That common root sbb can have a custom convergence name that returns the same string whether it sees an XMPP event or a SIP presence event. Then delegate to the appropriate child sbb for handling each protocol.

Rough thoughts... maybe another approach will work better.

Ranga.