[OpenSIPS-Users] presentity and multiple locations

[Iñaki Baz Castillo]

El Martes, 9 de Febrero de 2010, Chris Maciejewski escribió:
> Hi Anca,
> 
> Thanks for your reply.
> 
> What I would like to do is:
> 
> 1. There is a subscriber sip:user1 at exampe.com
> 
> 2. He has two endpoints registered:
>    a) sip:user1 at 10.10.0.1:43431 (UA1) - presence "online"
>    b) sip:user1 at 10.10.0.2:23433 (UA2) - presence "away"
> 
> 3. When incoming MESSAGE request is processed by opensips, I would
> like to relay it ONLY to UA1, and not to UA2 (since it is "away").
> 
> But I understand the above is not possible at the moment?

I understand what you mean but this is not how SIMPLE is designed.


> Would it not be useful to add "contact" column to "presentity" table,
> so we could map presence status to particular contact?

No, this is not possible. "presentity" is sent by users by sending a PUBLISH. 
PUBLISH doesn't establish a SIP dialog so "Contact" header is not required.

And more important. PUBLISH and REGISTER could arrive from different sources 
(i.e. when using presence user agents). So it's not true that a PUBLISH comes 
from an address from which a registration exists, not at all.


> And relay
> messages only to contacts with "OPEN" ("online") presence ?

What is "online"? if you mean the "<status><basic>open</basic></status>" then 
I inform you that the meaning of this field is not well defined by RFC's 
(nothing in SIMPLE related RFC's is well defined so specifications in top of 
them, as OMA's ones, are required to give some "consistency").

Also, there are clients implementing MESSAGE but not presence, so they don't 
publish a presence status and you shouldn't rely on such status to decide 
where to deliver a MESSAGE.

IMHO the proxy or application server should NEVER take a routing decission 
based on the presence status of a user, as this status is just informative, 
never required.


BTW note that a MESSAGE doesn't establish a dialog so the proxy would send 
each MESSAGE to every registered location of the destination user. This is not 
very cool of course, in fact MESSAGE is more like a painful SMS in mobiles 
world.

A good choice would be using MSRP sessions (which allows rich IM and file 
transfer).
In this way alice sends an INVITE offering a MSRP session in the SDP, and the 
proxy forkes the INVITE as usual to both locations of bob. Both phones receive 
the INVITE but in order to start the MSRP one of them must accept the MSRP 
session (the same as in a "normal" INVITE with just audio/video SDP). So the 
MSRP session would be "answered" by the human user rather than the device.

Of course, MSRP is not widely adopted yet but there are some working 
implementations (take a look to AG Blink softphone or its library 
sipsimpleclient).


My Conclusion: the future of SIP/SIMPLE is amazing. The present is a terribe 
hack.



-- 
Iñaki Baz Castillo <ibc at aliax.net>