Menu
▾
▴
#30 presence: NOTIFY to tel: URI fails
The presence module must remember the URI in the To: header of a SUBSCRIBE request and copy it to the From: header of an outgoing NOTIFY request. This works for sip URIs but fails for tel URIs.
Actually it parses the URI as user@domain and stores the user & domain seperately in the database so it looks like it was not designed to work with tel: URIs.
The attached patch implements a workaround: a tel: URI will be saved with the telephone number in the username field and a blank domain; when this information needs to be converted back to a URI, a blank domain signals that a tel: URI should be generated. Actually this is OK since a sip: URI can never contain a blank domain.
With this patch, it is possible to subscribe to a presentity for presence using a tel: URI.
patch against opensips-1.4.1-tls
I wonder why the URI is split into userpart and domain at all.
Your patch is a workaround for tel URIs, but not a generic solution (what about http URIs :-)
klaus
I agree with Klaus. A cleaner solution would be to store also the protocol in the table.
OK, I will change this to handle and type of URI by saving the original URI verbatim instead of breaking it up into username & password. However, this will cause the database schema to change.
-Phil
Hi Phil,
I have looked through the SIP Presence Event Package RFC( 3856 ) and it seems that in fact, the to and from of a Subscribe request can not be tel uri's.
Section 5.
SUBSCRIBE messages also contain logical identifiers that define the
originator and recipient of the subscription (the To and From header
fields). These headers can take either a pres or SIP URI.
This still lets the pres uri problem, which will not work. Our presence module in fact does not have support for pres uri's neigther in RURI's. I will open a bug report to remind me to fix this.
regards,
Anca Vamanu
IMO this is an unnecessary limitation in RFC 3856. We should discuss this on the SIP list.
It's logical to subscribe to a SIP/SIPS uri, but what does it mean subscribing to a TEL URI?
A SIP/SIPS URI means an user that is locates somewhere while a TEL URI means a telephony destination, not an user.
I'm not 100% sure of what I've said, but I think there can be good reasons to disallow abstract URI's as TEL in subscriptions. Perhaps we should ask in sip-implementors maillist since I read a thread about it some weeks ago.
It's logical to subscribe to a SIP/SIPS uri, but what does it mean subscribing to a TEL URI?
A SIP/SIPS URI means an user that is locates somewhere while a TEL URI means a telephony destination, not an user.
I'm not 100% sure of what I've said, but I think there can be good reasons to disallow abstract URI's as TEL in subscriptions. Perhaps we should ask in sip-implementors maillist since I read a thread about it some weeks ago.
I am surprised to learn about the limitation in RFC 3856. Please note however the following:
- subscribing to tel: URIs for presence is done in practice despite this limitation and works fine. Relaxing this limitation is required to interoperate with clients and RLS servers that do this. I agree with Klaus that that the limitation is unnecessary.
- The issue I raised with OpenSIPS is actually in the generic subscription handling module, not in the presence event package. I am not aware of anything in RFC 3265 that restricts the kind of URIs that may appear in From: and To:.
Regarding Iñaki's comment, I am not sure why you imply that it is illogical to subscribe to a TEL URI. If I would like to subscribe to someone's presence and all I have is their telephone number then why should I not subscribe to it? Actually the average end-user is more likely to know telephone numbers for their friends than SIP URIs.
I will still point out the limitation in RFC 3856 to some people here.
-Phil
I've sent a mail to SIP-implementors about TEL URI in SUBSCRIBE:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-October/020744.html
Let's wait for replies and explanations.
A reply in SIP-implementors:
--------
IMO "pres" uri is meant for presentity/watchers participants for
"presence" and related event packages.
"sip" scheme is more generic and may include "sip protocol"
participants including call and "presence".
All these schemes are meant for IP domain. TEL scheme is defined to
accommodate E.164 numbers from non-IP domain and SUBSCRIBE/NOTIFY
framework is not defined for these entities unless you have some ENUM
mapping available
I am not sure whether this is convincing enough.
---------
Thread: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-October/020744.html
A new reply:
-------------
I can think of no reason why a TEL should not be permitted. Presumably it would be routed the same way an INVITE would. Eventually that should lead to some UA, perhaps a GW, perhaps a native sip device. Either way the SUBSCRIBE *might* be supported. If the subscribe isn't supported then an error is reported.
So I consider this a bug in the spec.
-------------