Hi Juha!
I think you are right.
If a SUBSCRIBE is processed, for looking up the presentity, the R-URI
must be used. To-URI/tag is used for copying it in the NOTIFY's From-header.
When processing a PUBLISH, the R-URI "...contains enough
information to identify the resource whose event state is to be
published..."
.
Thus:
received PUBLISH:
R-URI --> [EMAIL PROTECTED]
received SUBSCRIBE:
use R-URI to lookup in presentity table
use From/To header to create NOTIFY To/From header
use Contact for R-URI of NOTIFY (loose router)
use R-URI/From-URI for watchers and active-watchers lookup
Thus, I guess the active_watchers table also need ruri_user and
ruri_domain columns.
regards
klaus
Juha Heinanen wrote:
i sent yesterday privately an email to anca about this, but thought that
perhaps a broader discussion is appropriate, because it looks to me that
there is a fundamental flaw in current presence implementation.
while testing presence, i noticed that when processing subscribe
requests, presence module seems to take presentity uri from to uri and
not from the request uri. for example, when twinkle sends subscribe
SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0
To: "Juha Heinanen" <sip:[EMAIL PROTECTED]>
openser does not find presentity with username jh/domain vm.test.fi
although it does exists.
also, if state of presentity changes, twinkle does not get notification
of it, i guess, because in active_watchers table twinkle is listed with
to_user +358442345670/to_domain test.fi and there is no field in
active_watchers table that would include presentity uri
sip:[EMAIL PROTECTED] that twinkle subscribed to.
RFC 3265 is clear on how target of subscribe is determined:
3.1.2. Identification of Subscribed Events and Event Classes
Identification of events is provided by three pieces of information:
Request URI, Event Type, and (optionally) message body.
it makes never (except in register request) sense by presence server or
proxy to examine to header, because to header has only local meaning.
for example, my proxy may accept subscribe request where r-uri and to
uri are both sip:my_mailbox and then rewrite request uri to
sip:[EMAIL PROTECTED]
another (minor) thing that i noticed while reading presence source code
is that it uses parse_uri functions to parse to header. these should
be changed to more efficient parse_to_uri, which checks if the uri has
already been parsed.
-- juha
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel