5 Oct
2007
5 Oct
'07
6:55 a.m.
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
8 Oct
8 Oct
3:43 a.m.
El Friday 05 October 2007 14:21:41 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
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
ibc(a)in.ilimit.es
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? 
4:07 a.m.
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
4:54 a.m.
El Monday 08 October 2007 10:07:08 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
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
ibc(a)in.ilimit.es
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.
5:08 a.m.
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
5:40 a.m.
El Monday 08 October 2007 11:08:57 Juha Heinanen escribió:
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.
Iñaki Baz Castillo writes:
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?
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?
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. -- juha
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
6:37 a.m.
Iñaki Baz Castillo writes:
it is better that anca comments on this.
-- juha
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?
6:48 a.m.
El Monday 08 October 2007 12:37:59 Juha Heinanen escribió:
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ñaki Baz Castillo
ibc(a)in.ilimit.es
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? 
9 Oct
9 Oct
7:19 a.m.
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:
i meant that it is better that anca who has written presence modules,
comment on this.
-- juha
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
it is
better that anca comments on this.
Sorry, I don't understand what you mean. Could you repeat please?
7:37 a.m.
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&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?
Regards.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
7:55 a.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?
8:57 a.m.
El Tuesday 09 October 2007 13:55:14 Anca Vamanu escribió:
Ok, it seems a complex isue to solve then.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
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.
9:52 a.m.
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:
i meant that it is better that anca who has written presence modules,
comment on this.
-- juha
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
it is
better that anca comments on this.
Sorry, I don't understand what you mean. Could you repeat please?
10:20 a.m.
El Tuesday 09 October 2007 15:52:28 Juha Heinanen escribió:
Anca Vamanu 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).
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
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.
10:28 a.m.
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
11:19 a.m.
El Tuesday 09 October 2007 16:28:53 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
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.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
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.
6155
days inactive
6159
days old
17 comments
3 participants
participants (3)
-
Anca Vamanu -
Iñaki Baz Castillo -
jh＠tutpro.com