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

[SourceForge.net]

Bugs item #2305451, was opened at 2008-11-17 15:26
Message generated for change (Comment added) made by anca_vamanu
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: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
>Assigned to: Anca Vamanu (anca_vamanu)
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: Anca Vamanu (anca_vamanu)
Date: 2008-11-18 13:06

Message:
Hi Norm,

Unfortunately I can not accept your patch and I will explain why.
The draft after which BLA is implemented:
"http://tools.ietf.org/html/draft-anil-sipping-bla-03" breaks all rules
in
presence information - message headers correlation. It does not respect
RFC
3856, but gives some examples in which headers have some very strange
values so that it makes very difficult extracting the presentity uri.  

This message is from the draft, at page 11, when a phone sends a
SUBSCRIBE
to the server:

 F9 Alice ----> State Agent

   SUBSCRIBE sip:sa at stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
   From: <sip:alice at example.com>;tag=925A3CAD-CEBB276E
   To: <sip:sa at stateagent.example.com>
   CSeq: 1 SUBSCRIBE
   Call-ID: ef4704d9-bb68aa0b-474c9d94 at ua1.example.com
   Contact: <sip:alice at ua1.example.com>
   Event: dialog;sla
   User-Agent: ABC-UA/1.2.3
   Accept: application/dialog-info+xml
   Max-Forwards: 70
   Expires: 3700
   Content-Length: 0

You can see here that you can not use the uri in the To header. The
phones
puts in the TO header what he has received in the Contact header of the
SUBSCRIBE sent by the server. And this is in fact exactly the behaviour
of
the Polycom phones.

You can not use the uri in From header either, because when there is a
third party registration, it does not contain the uri of the list. Also
from the draft, page 16:

SUBSCRIBE sip:sa at stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa1371c3f65A21C98
   From: <sip:bob at example.com>;tag=410F7345-F7EBA89C
   To: <sip:alice at stateagent.example.com>
   CSeq: 1 SUBSCRIBE
   Call-ID: 42fed01-850cb203-de12767a at ua2.example.com
   Contact: <sip:alice at ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Accept: application/dialog-info+xml
   Max-Forwards: 70
   Expires: 3700
   Content-Length: 0

The solution that I arrived at was to construct the presentity uri from:
- username in Contact
- domain in From 
Not as you said, R-URI username and from domain, but contact username and
from domain.

And I suppose this does not work with aastra. You can send me a SUBSCRIBE
message sent by astra to analyse how it puts the info and see if there is
a
solution to satisfy aastra also. 
This troubles are caused by the bad draft, but since there are phones
that
implement it, we implemented it also and we have to stick to it.

On the other hand, regarding the extract from RFC 3856 that you printed:
it does not apply to this case. It is a suggestion on how to  use
REGISTER
information to construct presence information. RFC 3856 says in fact that
the presentity_uri uri should be taken from R-URI of the initial request.

I will close your report as invalid. 

regards,
Anca   


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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-17 17: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