[OpenSIPS-Users] presentity and multiple locations

[Iñaki Baz Castillo]

El Miércoles, 10 de Febrero de 2010, Chris Maciejewski escribió:

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


Yes, good point. Unfortunatelly you are not 100% right when quoting the above 
text: As I understand you expect that when a softphone publishes "away" or 
"busy" or "don't disturb" its <basic> field is "closed". Not true (check for 
example Eyebeam presentity sent when setting "away" status).

These status ("away", "busy"...) are values for <activities> field defined in 
RFC 4480 for the <person> section of the presentity (rather than the <tuple> 
section in which <status><basic> appears).

<person> section represents the human status, while <tuple> section represents 
service status. Check RFC 4479 section-3.3.

So, if I leave my table for a while, my softphone will publish "away" but 
<basic> is still "open" (the *device* *can* receive messages).



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

Understood. But will they really publish <basic>close</basic>?


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

Easier: the proxy routes the MESSAGE to such client and the client itself 
rejects the request with 480 as the user enabled DND mode.

 

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

Right. I just meant that the "called" human must reply the MSRP sessions prior 
te receive the messages, so the operator would never find it PC desktop full 
of IM windows :)



> > 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 agree with you totally. THe problem is that SIMPLE is not mature enough and 
the specifications are *too wide* so interoperability is very difficult.

Regards.



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