#538 active_watchers table: presentity_uri correction

[Norm Brandinger]

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

[Norm Brandinger]

Patch to create create presentity from To header

[Anca Vamanu]

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@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:sa@stateagent.example.com>
CSeq: 1 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
Contact: <sip:alice@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@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa1371c3f65A21C98
From: <sip:bob@example.com>;tag=410F7345-F7EBA89C
To: <sip:alice@stateagent.example.com>
CSeq: 1 SUBSCRIBE
Call-ID: 42fed01-850cb203-de12767a@ua2.example.com
Contact: <sip:alice@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

[Nobody/Anonymous]

see my comment on the opensips tracker.

btw: do you experience any problems?

[Iñaki Baz Castillo]

Hi, in SUBSCRIBE message the "To" URI is not important. The user (From URI) subscribes to the presentity of the RURI. So I think this path is invalid.