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 _______________________________________________ Devel mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
