#30 presence: NOTIFY to tel: URI fails

closed-rejected
modules (454)
5
2009-02-19
2008-10-17
Kim Vandry
No

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.

Discussion

  • Kim Vandry

    Kim Vandry - 2008-10-17

    patch against opensips-1.4.1-tls

     
  • Nobody/Anonymous

    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ñaki Baz Castillo

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

     
  • Kim Vandry

    Kim Vandry - 2008-10-19

    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

     
  • Anca Vamanu

    Anca Vamanu - 2008-10-22
    • assigned_to: nobody --> anca_vamanu
    • status: open --> closed-invalid
     
  • Anca Vamanu

    Anca Vamanu - 2008-10-22

    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

     
  • Klaus Darilion

    Klaus Darilion - 2008-10-22

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

     
  • Iñaki Baz Castillo

    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ñaki Baz Castillo

    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.

     
  • Kim Vandry

    Kim Vandry - 2008-10-22
    • status: closed-invalid --> open-invalid
     
  • Kim Vandry

    Kim Vandry - 2008-10-22

    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ñaki Baz Castillo

    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

     
  • Iñaki Baz Castillo

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

     
  • Anca Vamanu

    Anca Vamanu - 2009-02-19
    • status: open-invalid --> closed-rejected
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks