there is another issue concerning SIMPLE presence. The published state
is not explicitely removed from the presence server once we set our
state to offline (i.e., unregister). The subscriptions are removed in
this case, but the published state remains on the server until it
expires (it is correctly set to "closed" in the pidf presence document,
A problem arises if SC is closed and restarted thereafter, and publishes
its new presence (once connected to the SIP server again). In this case,
we get a new etag assigned by the server, so the presence server
contains two contraditory tuples for the same contact address (which
itself is not necessarily a problem yet, and is allowed according to RFC
3863). However, the presence server now (until the old state expires)
sends these two tuples in the notify messages for the same contact
address, one containing the old closed state and another one containing
the open status of our newly started SC instance.
In my tests this results in my SIP account being displayed offline in
other SC clients (in my own client as well, since I've got myself in my
contact list, too). I'm certain though that whether I am shown as online
or offline here only depends on the order in which these tuples occur in
the pidf document.
So now I'm wondering if there shouldn't be an explicit removal of our
publication state (PUBLISH with Expires:0, which AFAIK currently never
happens). For testing purposes, I modified the code so that this
unpublication is done every time we set our status to offline. In case
you're interested, I attached a patch containing this modification. I'm
not sure what you think of this solution though, because this makes the
"closed" state in the pidf <basic> element almost obsolete. On the other
hand, the "closed" state could still make sense for something like an
"invisible" mode, in which our pidf state is set to closed but we're
still registered to the SIP server...
However this is dealt with, I would vote for at least sending an
explicit PUBLISH removal request whenever SC is closed (given that we
did publish our state with a presence server before and this publication
has not expired yet).
Apart from this, the real problem IMO is once more the pidf processing
(hope I'm not bugging you, Ben ;)). The processing there should be
adapted so that the order of (conflicting) tuples doesn't matter
anymore. I think the best solution to deal with this is to collect the
state information of all contacts, tuples, etc. contained in a pidf
document *before* actually promoting any state changes on to the Contact
objects. By this way, we could easily first sort the resulting state
list accordingly (e.g., to prefer an online over an offline status for
conflicting contacts). As a side effect, this would make it very easy to
additionally implement support for the priority attribute of the contact
I did not make any changes to the code reflecting this yet, because I
first wanted to get another opinion.
@Joel: if you read this - I think that the presence problem you
described earlier today stems from this issue.
sip-presence-unpublish.patch (1.83 KB)
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.