[OpenSIPS-Users] presentity and multiple locations

[Chris Maciejewski]

Hi Iñaki,

Thanks for your reply. Please see my comments below.

> 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.

Yes, very good point. I failed to notice "Contact" header is not
required in PUBLISH messages.

> 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").

Actually RFC 3863 - 4.1.4 defines the meaning of
"<status><basic>open</basic></status>" quite precisely:

open: In the context of INSTANT MESSAGES, this value means that the
      associated <contact> element, if any, corresponds to an INSTANT
      INBOX that is ready to accept an INSTANT MESSAGE.

> 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.

Well, of course if there is a client not PUBLISHing any presence
information, the proxy should rely all MESSAGEs. What I am looking for
is, not to relay MESSAGEs *only* when client explicitly publishes
"<status><basic>close</basic></status>".

> 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.

Hmm, I would argue here. For example if a human operator selects
"away" or "do not disturb" from a drop down list , INHO the proxy
should not route MESSAGEs to such a client.

> 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.

But is not MSRP just a better way of handing chat session (with a
proper dialog established etc.)
It doesn't solve presence problem discussed here? Does it?

> 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).

Thanks for suggestion, I will take a look.

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

Well, maybe current implementation of presence is a terrible hack, but
IMHO we definitely need some form of presence in SIP. It might not be
so important in the context of voice calls, but any form of Instant
Messaging will hugely benefit from it.

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

Best regards,
Chris