Subject: [SIP] Using sip or tel scheme in URIs with SIP-T

From: Doug Hurtig <[email-masked]>
Date: Wed, 21 Mar 2001 19:15:03 -0600

Hi,

 The  "SIP  Call Flows Examples" document uses the "sip" scheme for URIs.
  The "Mapping of ISUP Parameters to SIP headers in SIP-T" draft
  shows that either the sip or tel scheme is valid.

  This is no problem to handling on the incoming side. However, can I assume
that
   if I send either tel or sip in the URI that the receiving end will understand
this?

  What if  I receive a message which uses one scheme to identify the URI, is it
allowed
   that my response contain URIs with the other scheme?

   It seems that if the "tel" scheme is used it is implied that the value is
   a telephone number and there is no need to ever include the "user=phone"
parameter.  Have
   I missed something here?

--
Regards,
Doug Hurtig

Tekelec
2425 N. Central Expressway
Richardson, Texas 75080

[email-masked]
972.301.1203

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

---

From: [email-masked]
Date: Wed, 21 Mar 2001 19:20:37 -0700

RFC2543bis (section 2.2) lists some headers (notably Contacts) in which only
the SIP URI can be used. The protocol permits other schemes (like the tel
URL) to be used elsewhere. So presumably it is legal for a UA to use schemes
in the URIs within responses other than those schemes which have been
received in a request (with the Contact caveat, etc). I cannot speak to the
existence of UAs which do not 'support' the tel URL (frankly, I'm not sure
what failures a UA might experience as a result of receiving an unfamiliar
URI scheme), but I think generally you can assume that the sorts of entities
to which you would be likely to send a tel URL in a SIP message probably
support the tel scheme. Also note that it is unlikely that any entity that
understands SIP URIs will have substantial trouble parsing tel URLs
considering that (to plagarize a recent mail on this subject)

"... the user portion of a sip URI can be a
telephone-subscriber. The BNF for telephone-subscriber is defined by the tel
URL, and is anything that can be after the tel: in the tel URL."

And yes, the ';user=phone' for the tel URL example in the "Mapping" draft is
a typo. That was meant to be a SIP URI example in which the presence of the
'user=phone' would differentiate the user portion of the URI from a
non-telephony username (like old Compuserve email addresses or something).

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Doug Hurtig [mailto:[email-masked]]
Sent: Wednesday, March 21, 2001 6:15 PM
To: [email-masked]
Subject: [SIP] Using sip or tel scheme in URIs with SIP-T

Hi,

  This is no problem to handling on the incoming side. However, can I assume
that
   if I send either tel or sip in the URI that the receiving end will
understand
this?

  What if  I receive a message which uses one scheme to identify the URI, is
it
allowed
   that my response contain URIs with the other scheme?

--
Regards,
Doug Hurtig

Tekelec

[email-masked]
972.301.1203

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 23 Mar 2001 11:22:13 -0000

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!

...Mark

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

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 23 Mar 2001 11:17:29 -0600

I apologize. It seems as if two streams of discussion
got intertwined in this e-mail. I am not suggesting
any recommendations for the type or number of
URL formats to support for SIP-T. I was just 
throwing my two cents in on the applicability of
non-SIP URLs in various fields in a SIP message.
Sorry for the confusion.
 
/sean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark Watson
Sent: Friday, March 23, 2001 5:22 AM
To: Sean Olson (EUS); '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 ? 

...Mark 

> From: Sean Olson [ mailto:[email-masked] <mailto:[email-masked]> ]

---

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

> Sent: Thursday, March 22, 2001 3:36 PM
> To: 'Yu, James'; [email-masked]

That is not true. An enum dip for sip URLs does make sense. 

TO understand why, take a step back and think carefully about what the
meaning of a sip URL is. Hostname is not just a way to represent the IP
address of the server to send the request to. The host portion represents
the owner of the namespace of the names in the user portion of the request
URI. This is a potentially vast namespace, covering names of subscribers
known to that domain, but also covering OTHER namespaces, such as the set of
all telephone numbers. Furthermore, how a domain chooses to resolve the
namespace it owns, is its own choice. It might segment the space, resolving
using a local database for some names, or some other mechanism for others.
IN fact, if the namespace of that domain contains an entire other namespace
within it, well, you would probably need to use some other resolution
mechanism.

As an example, I might send an INVITE like:

INVITE sip:[email-masked] SIP/2.0

Now, this number is NOT for a registered user in foo.com. The + sign in
front of the number says its a fully qualified E.164 number, so its actually
another namespace mapped into the namespace of foo.com, using the + as an
identifier to indicate this mapping. A reasonable thing for a proxy to do is
use enum to resolve this.

If the number DIDN'T have a +, that might indicate a locally significant
number, and then the foo.com proxies would use a location service to find
the user.

> why that bothers most people so I am happy to disallow it

I think its a bad idea. For all the same reasons we decided to use sip URLs
in record-routes, they must be sip URLs in INVITE/200/OPTIONS, and there
must be just one.

Christer Holmberg writes:
> >My original mail on this subject was intended to refer only 
> to UA call
> >set-up behavior (the subject that kicked off this thread); bis 2.2
> >explicitly forbids non-SIP URIs in the Contact headers of 
> INVITE, OPTIONS,
> >BYE, and 2xx messages, -not- 3xx messages nor REGISTER. 
> Sorry for my lapse
> >of precision; didn't mean to start a panic here.
> 
> I think the proposal I wrote in my other mail (by specifying the
> supported URI in an Accept-XXX header) would solve also this. In my
> initial INVITE I add a Contact with ANY URI, and if the 
> receiver doesn't
> support it he will send some 4xx response, and a header 
> indicating which
> URIs he supports. An idea could be to even allow multiple 
> Contacts, all
> with different URIs, in the INVITE, and the UAS can choose the one he
> wants and/or supports...

Absolutely not.

I can think of no better road to interoperability nightmares and call setup
failures than to allow anything but a sip URL in INVITE/200 Contact. Even
worse is allow multiple ones, and even worse is to implement some kind of
negotiation mechanism, and for what purpose? We have already achieved
consensus that record-route has to be a SIP URL. THE SAME ARGUMENTS hold for
Contact. 

Remember, redirects are different. Indeed, the caller preferences spec
already has an attribute, scheme-param, which allows me to specify, in an
INVITE, which URL schemes its ok for me to be *redirected* to:

INVITE sip:[email-masked] SIP/2.0
Accept-Contact: *;scheme="tel,http"

-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

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 27 Mar 2001 13:25:08 -0600

>That is not true. An enum dip for sip URLs does make sense. 

... <snip> ...

I think we are talking about ENUM queries in two different
spots. I was stating that doing an ENUM query for 
sip:[email-masked] was not necessary for the *previous* hop.
A SRV query for cow.com is all that is necessary. Of course, when
the request arrives at cow.com, that proxy can choose to do an
ENUM query. The key point is that previous hops shouldn't have
to do an ENUM query themselves and in general won't.

Sorry for the confusion
/sean