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

Reply via email to