[Kamailio-Devel] [ openser-Bugs-2305495 ] active_watchers table: presentity_uri correction

[SourceForge.net]

Bugs item #2305495, was opened at 2008-11-17 15:40
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2305495&group_id=139143

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: None
Group: None
Status: Open
Resolution: None
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-17 16:57

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.

regards,
Anca   




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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2305495&group_id=139143