[OpenSIPS-Devel] [ opensips-Bugs-2305451 ] active_watchers table: presentity_uri correction

[SourceForge.net]

Bugs item #2305451, was opened at 2008-11-17 13:26
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2305451&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: active_watchers table: presentity_uri correction

Initial Comment:
In the active_watchers table, the presentity_uri appears to have been calculated from incorrect headers.

Page 16 of RFC3856 states:

The address-of-record in the registration (the To header field) identifies the presentity.

For example, in pua/send_subscribe.c, the presentity in the pua table (pres_uri column) appears to be built properly from the "To header" as shown below:

memcpy(presentity->pres_uri->s, pto->uri.s, pto->uri.len);

However, in presence/subscribe.c, the presentity in the active_watchers table (presentity_uri column) appears to be build improperly from a combination of the R-RUI and From domain as shown below:

if(uandd_to_uri(uri.user, subs->from_domain, &subs->pres_uri)< 0)

Attached is a patch that updates presence/subscribe.c so that the presentity is build from the To header as follows:

if(uandd_to_uri(subs->to_user, subs->to_domain, &subs->pres_uri)< 0)

Regards,
Norm

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-17 15:36

Message:
Without looking into the code:

When sending a SUBSCRIBE, the presentity is addressed in the request URI.
This is defined in RFC 3265: 

   The Request URI of a SUBSCRIBE request, most importantly, contains
   enough information to route the request to the appropriate entity per
   the request routing procedures outlined in SIP [1].  It also contains
   enough information to identify the resource for which event
   notification is desired.

I think in this case the pua module tries to find out the presentity from
the tm callback - which does not have an RURI anymore and thus maybe the to
header is used instead - this is fine as long the pua module always puts
into the to header the same URI as into the RURI.

The code in presence module you refer to handles the BLA functionality.
The BLA is totally crap and breaks with standard SIP methodology and
requires such weird behavior.

Resume: With the exception of the REGISTER request, the To: header is
unimportant.

klaus


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2305451&group_id=232389