[ opensips-Bugs-2173727 ] presence: NOTIFY to tel: URI fails

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[ opensips-Bugs-2173727 ] presence: NOTIFY to tel: URI fails

SourceForge.net
Bugs item #2173727, was opened at 2008-10-17 06:45
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2173727&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: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Phil Vandry (vandry)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: presence: NOTIFY to tel: URI fails

Initial Comment:
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.

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

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-10-24 16:24

Message:
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.
-------------

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

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-10-24 15:13

Message:
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


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

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-10-22 19:31

Message:
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.

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

Comment By: Phil Vandry (vandry)
Date: 2008-10-22 18:22

Message:
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

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

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-10-22 16:24

Message:
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.

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

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-10-22 16:19

Message:
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.

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

Comment By: Klaus Darilion (klaus_darilion)
Date: 2008-10-22 13:35

Message:
IMO this is an unnecessary limitation in RFC 3856. We should discuss this
on the SIP list.



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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-10-22 13:05

Message:
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



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

Comment By: Phil Vandry (vandry)
Date: 2008-10-20 02:53

Message:
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

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

Comment By: Iñaki Baz (ibc_sf)
Date: 2008-10-19 01:42

Message:
I agree with Klaus. A cleaner solution would be to store also the protocol
in the table.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-17 11:12

Message:
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

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2173727&group_id=232389

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel