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
ibc(a)in.ilimit.es