Subject: tel URL or SIP URL, was: RE: [SIP] Using sip or tel scheme in URI s with SIP-T

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Mar 2001 03:08:30 -0500

-----Original Message-----
>From: Mark Watson [mailto:[email-masked]]
>Sent: Friday, March 23, 2001 6:22 AM
>To: 'sean.olson'; 'Yu, James'; sip
>Subject: RE: [SIP] Using sip or tel scheme in URIs with SIP-T
>
>
>All, 
>Sorry if I'm missing something, but why do we need two formats for
signalling the same 
>thing  (sip: and tel: URLs) ? 
>
>Wouldn't it halve the amount of testing if we specified that SIP-T used
sip: URLs ? 
>Perhaps this is a stupid question - let me know! 

A SIP URL and a tel URL are quite different. The difference is that in one
case, the number is managed by the domain in the hostport portion of the URL
(sip), and in the other case, it is a phone number without a domain of
ownership.

WHen it doesn't matter (or you don't know), what domain to route the call to
for this phone number, its a tel URL. When it does matter, or you do know,
use a sip URL.

Example. My work number is +1 973-952-5000. This unambigously defines my
phone as a resource. If I want someone to call me, and I don't know (or
don't care), whose gateways or whose termination services are used, its a
tel URL. Generally, its a tel URL you'll want to embed in your vCards and
other things to point to your phone number. I'll put a tel URL in my web
page. The guy who clicks on it, his UA can figure out how to route this.
Perhaps he sends to a proxy that uses TRIP to figure out where to terminate
the call. Perhaps he sends to a proxy that first uses enum to resolve it,
and if its a miss, then uses TRIP. Maybe the proxy has private routing
policies. Whatever. I personally don't care.

Example. A gateway receives a call from the PSTN, targeted for +1
973-952-5000. The gateway is owned by foo.com. The gateway wants to use a
proxy that figures out where to route the phone number. In this case, we
don't want to use any random domain to route the call, the gateway WANTS to
use foo.com. So, it formualtes the INVITE using a SIP URL in the INVITE,
sip:[email-masked].

So, which to use in SIP-T? Well, since From and To are *logical*
identifiers, i.e., names, this would argue that they should be tel URLs. A
litmus test is this: if you want to call back the user using the URL in the
From field, does it matter that the callback go through the same domain that
the call came from? In this case, certainly not. The phone number could be
routed to any number of other domains or gateways.

Request URI, however, will generally be a SIP URL, since its addressing a
next hop server to resolve it. I think the main case when its not a SIP URL
is when the gateway has no capability to resolve the tel URL (and PS, to
correct myself, tel URL is *not* a URL, since the resource is not identified
by its location. I would argue that despite the fact that it didn't use the
urn naming conventions, it is a URN. The fact that we resolve it in enum
with NAPTR, which is used for urn resolution, helps validate this claim). 

I ran into these same issues and questions when figuring out how to handle
the im: and pres: URLs defined by IMPP, for usage in SIP. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message----- 
> From: Sean Olson [mailto:[email-masked]] 
> Sent: 22 March 2001 20:36 
> To: 'Yu, James'; sip 
> Subject: RE: [SIP] Using sip or tel scheme in URIs with SIP-T 
> 
> 
> 
> >If a redirect/proxy server invokes the ENUM process and 
> >retrieves the URLs 
> >in the NAPTR RRs associated with a telephone number (assume 
> >the telephone 
> >number is in the user part of the sip URL or in the tel URL in 
> >the INVITE 
> >received by the server). 
> 
> I assume that an ENUM query would be unnecessary for a sip: 
> URL, even if the user portion contained a telephone number. 
> But this should probably be handled in a separate thread. 
> 
> >There is a need to return the list 
> >of URLs in the 
> >Contact header of the 3xx response from the redirect server to 
> >the proxy/UAC 
> >or from the proxy server to the UAC (reason is explained 
> >later).  
> 
> This is fine by me. I think a 3xx response should be able 
> to carry any URL scheme in the Contact: header for the very 
> reason that the Contact: header in a 3xx response has 
> slightly different usage than in say a INVITE request. 
> 
> For the record, I am also happy to carry a non-SIP URL in 
> the Contact: header of an INVITE request, but I understand 
> why that bothers most people so I am happy to disallow it 
> as well. 
> 
> >So from the service point of view, it seems that we should 
> >allow non-sip 
> >URLs in the Contact header of the 3xx response.  When a proxy 
> >receives a 3xx 
> >response that contains URLs or retrieves the URLs through the 
> >ENUM or other 
> >process that it does not know how to route further (e.g., no 
> sip or tel 
> >URL), it should relay the 3xx response back to the UAC so that 
> >proper action 
> >may be taken there.  We'll need to define how a proxy handles 
> >the mixed URL 
> >cases.  
> 
> This is one possible behaviour (and a sensible one), but 
> I would be hesitant to add any verbage to the SIP spec 
> stating this. I think this is very service specific and 
> you may very well have some intelligent proxies that are 
> able to "do the right thing" with non-sip URLs. I think 
> the same comment applies to a list of Contact:s of 
> varying priority with a non-SIP URL possibly having 
> higher precedence than a SIP URL. 
>  
> >James 
> 
> /sean 
> 
> 
> _______________________________________________ 
> This list is for continuing development of the SIP protocol. 
> The sip-implementor's list is the place to discuss implementation, 
> and to receive advice on understanding existing sip. 
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body. 
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.