9 Oct
2007
9 Oct
'07
2:55 p.m.
Iñaki Baz Castillo wrote:
El Tuesday 09 October 2007 13:19:40 Anca Vamanu
escribió:
Pua_usrloc is meant to be independent from presence server, there isn't
the need for the two to be collocated on the same machine. So,
pua_usrloc can not access the presentity table. Therefore, to deduce if
some other record exists in presentity_table the Subscribe- Notify
mechanism should be used and this makes the problem quit complicated.
regards,
Anca
Hi,
After reading the thread, I also came to your conclusion, that by
sending Publish with no bodies for refresh the problem should be solved-
thus I made the commit. Unfortunately, I soon realized that there was a
mistake in the reasoning.
The rewriting does not happen. If the pua_usrloc and the client itself
send each an initial Publish messages with no Sip-If-Match header, it
will result in 2 records inserted in presentity table- two different
etags and no rewriting. And then, the Notifies send will have as a body
the aggregation of this two. In presence module, the method of
aggregation used is: most recent, first. Most clients look only at the
first tuple (xlite, for example, does so). So, the notified state
alternates according to the Publish message received last.
Now I don't see a means to make pua_usrloc and the client send Publish
messages work. I will do some more thinking though.
The best is probably, to find a fairly good method to deduce for which
clients to call pua_set_publish.
Just in this moment I've open a report for this wish:
http://sourceforge.net/tracker/index.php?func=detail&aid=1810097&gr…
As I say in the report, couldn't be possible pua_usrloc to include a tag in
its PUBLISH's to discard them in "presentity" table if other entries
exist?