Hi, pua_usrloc has an issue with SIP device that publish their state, since the PUBLISH is generated twice:
1) With the REGISTER by pua_usrloc module. 2) With the PUBLISH sent by the device.
If for example the user sets "Online" - "Away" status and after that the device refreshes the REGISTER, then its state will just be "Online" (the state pua_usrloc generates).
In order to avoid this issue it could be nice to query a BD table looking for the "User-Agent" and just exec "pua_set_publish()" if the device doesn't support presence PUBLISH.
The query could be done by regular expressions in order to allow different versions of same device, all of them supporting presence.
A doubt I have is: Would be easier store user-agents of devices supporting presence? or not supporting presence? which one list will be shorter?
Because it, I'd like to start a page in the wiki containing all the devices "User-Agent" (with regular expression) supporting (or not) presence PUBLISH, and a small script to generate the table after copy&paste the whole list from the web.
What do you think about it?
Regards.
El Friday 05 October 2007 14:21:41 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
In order to avoid this issue it could be nice to query a BD table looking for the "User-Agent" and just exec "pua_set_publish()" if the device doesn't support presence PUBLISH.
why cannot methods field of usrloc table be used?
I don't understand what you mean. "methods" field in "usrloc" table just means allowed receiving methods for that the device, but not which methods it can generate.
For example, Twinkle 1.1 that support presence sends this "Allow" header:
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
And Linksys PAP2, that doesn't support presence, sends this one:
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Maybe devices which send PUBLISH allow always a received SUBSCRIBE, but having "SUBSCRIBE" in "Allow" header dones't mean supporting PUBLISH. Does it?
Regards.
Iñaki Baz Castillo writes:
Maybe devices which send PUBLISH allow always a received SUBSCRIBE, but having "SUBSCRIBE" in "Allow" header dones't mean supporting PUBLISH. Does it?
sorry, i guess i didn't understand what the problem was. usually only presence servers allow publish.
could you clarify what you were after.
-- juha
El Monday 08 October 2007 10:07:08 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Maybe devices which send PUBLISH allow always a received SUBSCRIBE, but having "SUBSCRIBE" in "Allow" header dones't mean supporting PUBLISH. Does it?
sorry, i guess i didn't understand what the problem was. usually only presence servers allow publish.
could you clarify what you were after.
Handling "pua_usrloc" with devices supporting PUBLISH is a little pain since there is a "race condition" with periodical REGISTER and PUBLISH sending by the device send.
As I said in my first mail, if a device supporting presence publishes "Online - Away" and after a minute it generates a REGISTER (to refresh the "expire" in the server), then this REGISTER will generate a new PUBLISH (made by "pua_usrloc" module), but this PUBLISH will just indicate "Online", so watchers will see "Online". After a while, when the device sends a refresh PUBLISH this will contain "Online - Away", and that is what watchers will see then.
That's what I mean a "little pain".
In order to avoid htis issue I plan to use "pua_set_publish()" only if the device doesn't support presence PUBLISH. But there is no a cool way to know which device support it or not.
Theorically there is: RFC 3840 - Indicating User Agent Capabilities in SIP
In this you can read things like:
------------------------------------------------------------------------------------------ Contact: sip:user@pc.example.com ;mobility="fixed";events="!presence,message-summary" ;language="en,de";description="<PC>" ;+sip.newparam;+rangeparam="#-4:+5.125"
"Examples of typical use: Choosing to communicate with a presence application on a PC, instead of a PC phone application." ------------------------------------------------------------------------------------------
But in fact I've never seen a device indicating this.
So I need a way to determine if a device does PUBLISH or not, that is the reason I plan to have a DB table with PUBLISH capable (or not capable) "user-agent" list.
And I'd like to know your opinions about this. ;)
Regards.
Iñaki Baz Castillo writes:
As I said in my first mail, if a device supporting presence publishes "Online - Away" and after a minute it generates a REGISTER (to refresh the "expire" in the server), then this REGISTER will generate a new PUBLISH (made by "pua_usrloc" module), but this PUBLISH will just indicate "Online", so watchers will see "Online". After a while, when the device sends a refresh PUBLISH this will contain "Online - Away", and that is what watchers will see then.
why doesn't pua_usrloc generate a publish that corresponds to current published status of the device?
why does pua_usrloc need to generate a publish are result of register?
So I need a way to determine if a device does PUBLISH or not, that is the reason I plan to have a DB table with PUBLISH capable (or not capable) "user-agent" list.
a device may be capable of generating a publish, but if may not have been configured to do so.
-- juha
El Monday 08 October 2007 11:08:57 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
As I said in my first mail, if a device supporting presence publishes "Online - Away" and after a minute it generates a REGISTER (to refresh the "expire" in the server), then this REGISTER will generate a new PUBLISH (made by "pua_usrloc" module), but this PUBLISH will just indicate "Online", so watchers will see "Online". After a while, when the device sends a refresh PUBLISH this will contain "Online - Away", and that is what watchers will see then.
why doesn't pua_usrloc generate a publish that corresponds to current published status of the device?
That's good idea. In fact, why to generate a new PUBLISH if already exists a "real" PUBLISH? why not just modify "expires" and "received_time" in "presentity" table?
why does pua_usrloc need to generate a publish are result of register?
Sorry, I think you mean "a publish **as** result of register", is it?
In that case I don't understand the question, pua_usrloc aim is exactly that, generate an "online" status for devices that don't support presence.
So I need a way to determine if a device does PUBLISH or not, that is the reason I plan to have a DB table with PUBLISH capable (or not capable) "user-agent" list.
a device may be capable of generating a publish, but if may not have been configured to do so.
True, anyway IMHO is worse the actual issue with REGISTER and PUBLISH race condition in devices supporting presence.
Maybe I should report a wish for this module with the suggestion in this thread?
Regards.
-- juha
Iñaki Baz Castillo writes:
why doesn't pua_usrloc generate a publish that corresponds to current published status of the device?
That's good idea. In fact, why to generate a new PUBLISH if already exists a "real" PUBLISH? why not just modify "expires" and "received_time" in "presentity" table?
it is better that anca comments on this.
-- juha
El Monday 08 October 2007 12:37:59 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
why doesn't pua_usrloc generate a publish that corresponds to current published status of the device?
That's good idea. In fact, why to generate a new PUBLISH if already exists a "real" PUBLISH? why not just modify "expires" and "received_time" in "presentity" table?
it is better that anca comments on this.
Sorry, I don't understand what you mean. Could you repeat please?
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.
regards, Anca Vamanu
Juha Heinanen wrote:
Iñaki Baz Castillo writes:
it is better that anca comments on this.
Sorry, I don't understand what you mean. Could you repeat please?
i meant that it is better that anca who has written presence modules, comment on this.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
El Tuesday 09 October 2007 13:19:40 Anca Vamanu escribió:
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&gro...
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?
Regards.
Iñaki Baz Castillo wrote:
El Tuesday 09 October 2007 13:19:40 Anca Vamanu escribió:
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&gro...
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?
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
El Tuesday 09 October 2007 13:55:14 Anca Vamanu escribió:
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?
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.
Ok, it seems a complex isue to solve then.
Anca Vamanu writes:
The best is probably, to find a fairly good method to deduce for which clients to call pua_set_publish.
how about returning from radius a reply item to register authentication query telling if registering ua wants pua_set_publish done.
-- juha
regards, Anca Vamanu
Juha Heinanen wrote:
Iñaki Baz Castillo writes:
it is better that anca comments on this.
Sorry, I don't understand what you mean. Could you repeat please?
i meant that it is better that anca who has written presence modules, comment on this.
-- juha
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
El Tuesday 09 October 2007 15:52:28 Juha Heinanen escribió:
Anca Vamanu writes:
The best is probably, to find a fairly good method to deduce for which clients to call pua_set_publish.
how about returning from radius a reply item to register authentication query telling if registering ua wants pua_set_publish done.
But how to know that? how to know if it wants or not "pua_set_publish"? there is no info in REGISTER message about that (except the "User-Agent" that involves a query and a painful maintenance).
Iñaki Baz Castillo writes:
But how to know that? how to know if it wants or not "pua_set_publish"? there is no info in REGISTER message about that (except the "User-Agent" that involves a query and a painful maintenance).
the owner of the phone will decide if he/she wants to publish phone's presence info as side effect of registration. then you enter that info into your radius reply table.
-- juha
El Tuesday 09 October 2007 16:28:53 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
But how to know that? how to know if it wants or not "pua_set_publish"? there is no info in REGISTER message about that (except the "User-Agent" that involves a query and a painful maintenance).
the owner of the phone will decide if he/she wants to publish phone's presence info as side effect of registration. then you enter that info into your radius reply table.
Humm, it seems too manually mehtod, and what about if the user want to use two devices or more with same account? I think it would be faster and more realiable to mantain a table with "User-Agents" supporting presence.
Regards.
-
Anca Vamanu -
Iñaki Baz Castillo -
jh＠tutpro.com