[Devel] presence and to uri

[Klaus Darilion]

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 --> presentity.username at presentity.domain

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:jh at vm.test.fi SIP/2.0
> To: "Juha Heinanen" <sip:+358442345670 at test.fi>
> 
> 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:jh at vm.test.fi 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:jh at vm.test.fi.
> 
> 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 at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel