Subject: [Sip] Open Issue #366: sip v. tel URL

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Jan 2002 01:04:12 -0500

THe spec is silent on what to do when a user enters just a telephone 
number at a
SIP UA. Does the UA generate a SIP URL using the default domain of the 
UA, or
does it generate a tel URL? Do we even need to say anything about this? We
might, since otherwise, a UA that always uses tel won't interoperate with a
proxy which doesn't support tel at all.

I would probably argue that when a user enters an unqualified name to be 
called,
the UA generates a SIP URL, filling in the domain with its domain of
administration. This means that no matter what is entered, it is the 
domain of
the UA which is the one that needs to figure out how to interpret it. 
This makes
it work for things beyond phone numbers.

Either way, the spec should talk about this.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 02 Jan 2002 07:44:54 -0500

> proxy which doesn't support tel at all.

I don't expect users to actually enter "tel:", so the UA is likely to
make the choice based on implementation heuristics. One problem is that
the UA may have very limited knowledge as to where it is. If I carry my
PDA SIP phone to a new domain (say, a hotel), it knows its home domain
(say, cs.columbia.edu), the IP address of its local "outbound" proxy
(via DHCP) and that's it. 

In that case, both possible choices seem reasonable when entering
939-7000:

- make it [email-masked], meaning that the number is
interpreted in my home domain
- make it tel:9397000, meaning the number is interpreted in my visited
domain, by the outbound proxy

Clearly, the results are going to be rather different if I'm outside
Manhattan.

For 911 and 411-style phone numbers, the latter is the only viable
option until we have a better infrastructure in place. In any event, UAs
should probably be prepared to deal with proxies that can't handle tel
URLs. Currently, our ability to say unambiguously "URL scheme not
supported" is rather weak. 404 doesn't quite fit. This may suggest
either a new status code or Warning header value.

The best we can probably do is to allow users to choose and have the UA
deal with the error case by switching to home resolution.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 13:30:16 +0200

Hi,

If we "convert" telephone numbers into SIP URLs, do we need to support
TEL URLs in the first place? 

For URLs which are used for the message "routing" we would allow only
SIP URLs (EMAIL/HTTP/whatever URLs would still be allowed in headers
where we eg indicate where information/announcements/tones etc etc can
be found).

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 09:19:44 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 02 Jan 2002 15:33:41 +0200

Hi,

I guess the next question could then be: should that outgoing proxy be
allowed to "map" the tel-URL from the PDA to a SIP-URL, and insert its
domain name in the host part? I KNOW that is not currently allowed by
the spec, and it would require some extra (NAT alike) functionality in
the proxy to map between the URLs, but then the receiver(s) would know
from which domain the message comes.

PDA          outbound proxy                            UAS

---tel:1234--->          -sip:[email-masked]>

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 02:36:32 -0500

Henning G. Schulzrinne wrote:

>>does it generate a tel URL? Do we even need to say anything about
>>
> this? We
> 
>>might, since otherwise, a UA that always uses tel won't interoperate
>>
> with a
> 
> I don't expect users to actually enter "tel:", 

Agreed.

> so the UA is likely to

The problem is that, just because its digits, doesn't mean anything 
about whether its really a phone number. My domain may simply have 
handed out numeric usernames. Or, for me, "11" may be a speed dial 
group. Only my domain can properly interpret the username, which is why 
I don't see how the tel URL would work in general.

Also, it seems odd that if I enter:

a123

this results in one URL (a SIP URL), but if I enter:

123

this results in a tel URL.

I see it much like what happens when you enter an unqualified domain 
name into a local resolver; the remainder of the name is filled in at 
the local host with the configured domain. Seems like the same logic 
should apply here.

> option until we have a better infrastructure in place. 

For 411, I don't see why its wrong to do sip:[email-masked], which 
would then realize that its information service and do whats needed. 
ARguably, 911 needs to be processed immediately, but I would think that 
the right way to do this is for the UA to recognize 911 and use a 
special emergency SIP URL that may not be scoped to EITHER 
cs.columbia.edu or be a tel URL... but I've not been following the 911 
work too closely so I could be wrong here.

> In any event, UAs
> URLs.

It just seems like another opportunity for interop failures and complexity.

> Currently, our ability to say unambiguously "URL scheme not

I was hoping for one mechanism rather than two...

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Jan 2002 08:46:19 -0500

> this results in a tel URL.

The basic problem is that the UA has to guess, in order to be compatible
with common usage, what different text strings mean. This is somewhat
analogous to the way that web browsers work: typing in "google" in IE
will lead to a search site (run by MSN), which will lead to
"google.com". Typing "google.de" will lead to a very different site.

To me, this is a UI issue - the UA can use heuristics, explicit
configuration ("always use tel") or some explicit switch ("check this
box to make calls in your home domain"). I don't see why we need to tell
UI designers what to do.

> the local host with the configured domain. Seems like the same logic

And this behavior, as far as I know, isn't standardized anywhere. Some
would even argue that default domains have caused a fair amount of
grief. (I recall reading as much in some of the recent DNS performance
papers.)

> For 411, I don't see why its wrong to do sip:[email-masked], which

If I'm staying in Houston, 411 in Houston in very different than 411 in
New York. I won't be able to get local Texas numbers from my Manhattan
directory number. Even worse, calling 511 (repair) in Manhattan when my
phone line in Texas isn't working isn't likely to help.

> work too closely so I could be wrong here.

The current proposal is that dialing 911 would become sos@home-domain,
but be intercepted by the outbound proxy if possible, so it's kind of a
hybrid.

> It just seems like another opportunity for interop failures and complexity.

Unless you completely rule out tel: URLs in SIP requests, the
possibility that your outbound proxy can't handle tel URLs always
exists, even if you disallow UI guessing. (Not sure how a protocol spec
could do that in any event.)

Thus, I think this should be phrased as a wider issue - should we allow
tel URLs at all? If not, I can save a lot of effort by just ditching
work on 2806bis, since SIP seems to be the major (only?) customer.

> I was hoping for one mechanism rather than two...

Thus, you're saying no tel URLs at all?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 3 Jan 2002 09:54:28 -0800 (PST)

I find Henning's arguments pretty persuasive,
but one side nit bothers me:

 > but be intercepted by the outbound proxy if possible, so it's kind of a

   My outbound proxy may never move, so this is
   not in any way generalizable. I understand that
   some people want to deploy proxies that way,
   but I strenuously object to this hack being the 
   mechanism by which we localize 911.

		Mike

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 03 Jan 2002 12:59:21 -0500

>    mechanism by which we localize 911.

I wouldn't, either. However, I'm trying to find heuristics that are more
likely to work in the short term. I've made proposals (and will spell
them out in more detail soon) on how to make it possible for any entity
to locate the appropriate PSAP. However, this requires a database that
somebody needs to build and maintain.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 14:57:00 -0500

> box to make calls in your home domain"). I don't see why we need to tell

True, it is always possible for UI to allow the user to be explicit 
about tel URL.

> grief. (I recall reading as much in some of the recent DNS performance

Do you remember what the specific problem is?

>>For 411, I don't see why its wrong to do sip:[email-masked],
>>
> which
> 

Good point.

>>>In any event, UAs
>>>should probably be prepared to deal with proxies that can't handle
>>>
> tel
> 
>>>URLs.
>>>
>>It just seems like another opportunity for interop failures and
>>
> complexity.
> 

No, I don't want to ditch them. I am just searching for the right things 
to say in the spec to avoid interop issues.

For example, if I enter in 123 into my sip phone (targeted for extension 
123 in my domain), and the phone sends out tel:123, and my home proxy 
thinks its a pstn number, and thus sends it to a gateway, which fails 
since its not a PSTN number, thats bad. Now, what element has done the 
wrong thing here? Did the UA do the wrong thing by using a tel URL? Did 
the proxy do the wrong thing by interpreting the tel URL as a PSTN 
number? Looking at either element individually, it doesn't seem like 
either did the wrong thing, which would lead me to believe that the spec 
has to say something here so it doesn't happen.

The issue is similar with inclusion or not of the + sign.

These COULD be configured, but it seems like an undue configuration 
burden...

-Jonathan R.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 03 Jan 2002 15:12:40 -0500

Jonathan Rosenberg wrote:

> Do you remember what the specific problem is?

http://cider.caida.org/~evi/sigcomm/paper.html

"This last example is typical of a bug in the DNS data files at the
local site. If a name that should end in a dot and therefore be absolute
has no dot, the local nameserver will add the local domain to complete
the name. A bug in at least one nameserver implementation
adds the local domain recursively until it is 256 characters long (the
limit). The WSCOOPER example has been truncated to fit the
page!"

I'm not arguing that this is a big deal, particularly since for SIP
URLs, it's easier to tell if you need to add the domain or not.

> has to say something here so it doesn't happen.

I just don't see how we can mandate the translation of user input into
protocol elements. If anything, this belongs in more informal documents
such as "Suggestions for IP phones" that Henry Sinnreich and others are
putting together.

I'm not aware of any equivalent description for, say, email addresses
(what happens if I type "postmaster" - in my particular UI case, it
checks whether there is a match in the address book by nickname and
fills in the rest. Not always appropriate, needless to say, but I can't
think of a better heuristic beyond requiring a "did I guess right"
confirmation user interface.)

I'm not sure how cell phones handle this - if my cell home area code is
201, but I'm roaming in 415, and then type a 7-digit number, will it be
treated as a 201 number or a 415 number?

> These COULD be configured, but it seems like an undue configuration

I agree, but don't see a good solution that doesn't rule out valid UA
behavior. Unfortunately, this is hardly the only item that needs to be
configured, hopefully automatically.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 15:44:29 -0500

> URLs, it's easier to tell if you need to add the domain or not.

Yeah, this one seems like a non-issue.

> Did
>>either did the wrong thing, which would lead me to believe that the
>>spec has to say something here so it doesn't happen.
>>
> 

Its hard to argue with this point. I'll back off some. I still think 
something is needed in the base spec; possibly a statement that all 
proxies need to support the tel URL, along with a reasonable definition 
of what the semantics of a particular tel URL are when used with SIP.

So long as we have a clear definition of what sip:123 v. tel:123 v. tel:+123 means,

then the UI can do whatever it wants to construct a URL.

-Jonathan R.

---

From: Jay Batson <[email-masked]>
Date: Thu, 03 Jan 2002 16:51:51 -0500

>treated as a 201 number or a 415 number?

Don't quote me on this, 'cause: a) I'm not a technical expert on PSTN 
wireless, and b) I'm trying to dredge up cell phone behaviors from memory.

But I've accidentally dialed 7-digit numbers enough times while roaming to 
be burned by this more than once.  (No, I'm not a bozo user.... I don't 
consciously dial 7 digits, but occasionally am on mental auto-pilot and use 
speed-dials programmed into my cell phone that are just 7 digits....)

My recollection of the behavior is that the "wireless network switch" (or 
something similar) plays me some kind of error message saying "To complete 
this call, you must dial the area code before the phone number," or 
something of the like.

(Completely uninformed suppositions follow).  One could hypothesize that it 
works this way because the "wireless switch" knows that the originating 
phone is "roaming," presumably because the phone had to do some kind of 
registration when it got powered on, and that calls coming from that phone 
thusly have to be fully resolved when dialed.  The wireless switch thus 
knows enough to know that I'm roaming, but not enough to know where my home 
Area Code is, or whether the Area Code rules in my home area require 
mandatory 10 digit dialing, etc.  It just knows that it needs me to dial a 
fully-resolved number with Area Code.  (Is this because the CDR handed back 
to "my" wireless provider uses the fully-resolved Area Code info to help my 
provider know whether my call was "long distance" or not?  I dunno.)

I think.
-jb

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jan 2002 17:35:29 -0500

Here is the concrete proposal on this issue:

1. how a UA renders user input to a URL is local policy, of course
2. in the absence of any specific policy or indications on how to 
interpret an address, it is RECOMMENDED that it be used to generate a 
SIP URL, with that value in the user part, and the domain equal to that 
of the provider for the UA. This allows the information to be 
interpreted by the user's provider.

I think a statement along the lines of 2 is still needed, since 
otherwise, we will have to mandate tel URLs everywhere, or otherwise add 
additional configuration about the policy of the domain. We need more 
configuration like we need a hole in the head. I think the above 
proposal provides sufficient flexibility while still allowing for 
configuration-less flexibility.

Unless I hear something on this by next Tuesday, this resolution is in 
bis-06.

-Jonathan R.

Jonathan Rosenberg wrote:

>>local site. If a name that should end in a dot and therefore be
>>
> absolute
> 
>>protocol elements. If anything, this belongs in more informal
>>
> documents
> 
>>such as "Suggestions for IP phones" that Henry Sinnreich and others
>>
> are
> 
>>putting together.
>>
> 
> 
> 

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 18 Jan 2002 08:22:22 +0200

> interpreted by the user's provider.

it is not clear to me what "domain of the provider of the ua" means.
one could interpret it to mean the domain of the ip host of the ua.  i
would rather like to interpret it to mean the domain of the identity
that i used when i configured the ua or, in case of soft ua, when i
started the ua.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 18 Jan 2002 08:11:39 -0600

We have here something like the default domain on DNS lookups, or the
default domain added by mail systems when one sends mail to an address which
doesn't have a host part.

Why shouldn't the default domain to added by a SIP phone be a piece of local
configuration information, just as it is for mail and DNS?

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 18 Jan 2002 16:18:53 +0200

> configuration information, just as it is for mail and DNS?

because i can log in to a anybodies sip "phone" sitting in some ip
subnet with whatever sip url i hapens to have.

-- juha

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 18 Jan 2002 09:41:37 -0500

> doesn't have a host part.

Note that these two are typically different if you travel outside your
home domain.

> configuration information, just as it is for mail and DNS?

I think it would be more precise to simply have one home domain. This
domain is used for registrations and, where needed, as the default
domain for numbers entered. As Jonathan said, we should keep the number
of configuration options that are needed as small as possible. (I'm less
worried about parameters that are rarely changed, such as timer values.)

In that vain, do we have any notion in the spec as to the list of things
that would need to be configured to set up a UA, beyond the home domain?
It might be helpful to document this.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 18 Jan 2002 09:59:09 -0500

> subnet with whatever sip url i hapens to have.

To make my proposal more concrete: If I log in as [email-masked], my
home domain is example.com and this home domain will be used for
registrations and default domain for E.164 numbers (and maybe for
preloaded routes, if that matters). Does that work?

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 18 Jan 2002 17:05:44 +0200

> preloaded routes, if that matters). Does that work?

this would be fine.  the text that somone posted didn't make it so
clear and that is why i made my comment.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 18 Jan 2002 10:47:30 -0600

Depends on how they're configured. My email client never changes the default
domain it appends. The default domain for lookups only changes if I set my
dhcp client to overwrite /etc/resolv.conf.

--
Dean

----- Original Message -----
From: "Henning G. Schulzrinne" <[email-masked]>
To: "Dean Willis" <[email-masked]>
Cc: "Juha Heinanen" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>; <[email-masked]>
Sent: Friday, January 18, 2002 8:41 AM
Subject: Re: [Sip] Open Issue #366: sip v. tel URL

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 18 Jan 2002 10:51:26 -0600

No, because quite probably if you're visiting someone else's corporate SIP
phone, the gateway that will (perhaps MUST) be used for PSTN termination is
the local gateway, not the one back in your home domain.

--
Dean

----- Original Message -----
From: "Henning G. Schulzrinne" <[email-masked]>
To: "Juha Heinanen" <[email-masked]>
Cc: "Dean Willis" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>; <[email-masked]>
Sent: Friday, January 18, 2002 8:59 AM
Subject: Re: [Sip] Open Issue #366: sip v. tel URL

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 18 Jan 2002 19:05:54 +0200

> the local gateway, not the one back in your home domain.

that is not true at all.  i have a linux sip ua which, when i start it,
asks as whom i want to identify myself (my sip from url).  i can choose
from a list or create a new one.  with each identity is associated its
own username/password and a sip proxy, which will be used when i
register or place a call using that identify.  the domain name of the
host nor a local gateway has nothing to do with any of this.

-- juha

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Fri, 18 Jan 2002 11:55:13 -0500

> the local gateway, not the one back in your home domain.

Why is that? In most cases, I would certainly prefer to use my own phone
service, rather than the hotel phone service, for example.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jan 2002 11:48:18 -0500

Henning G. Schulzrinne wrote:

> Dean Willis wrote:
> 
>>No, because quite probably if you're visiting someone else's corporate
>>
> SIP
> 
>>phone, the gateway that will (perhaps MUST) be used for PSTN
>>
> termination is
> 

First off, I agree with Hennings proposed text, which read:

> preloaded routes, if that matters).
> 

With the caveat that I believe this should apply NOT just for numbers, 
but for any entered data which is not otherwise qualified. That is, if I 
enter "bob", and the UA doesn't know what else to do with it (no match 
in address book, etc.), it uses example.com. This mirrors my email 
client behavior exactly.

Now, I should also point out that this rule ONLY applies when the UA 
doesn't have policy to specify otherwise. I see nothing wrong with 
having a button that says "resolve this in my visited domain", or an 
explicit policy at the UA which prefers tel URL. The point of this 
requirement is to define behavior in the absence of any explicitly 
defined policy. You can still have policies to support local resolution 
of addresses if you want (and indeed, you do want that for things like 411).

-Jonathan R.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 22 Jan 2002 11:09:32 -0500

Jonathan Rosenberg wrote:

> in address book, etc.), it uses example.com. This mirrors my email

We should, I believe, formalize the notion of a 'home domain' in the
spec, so that we can easily make such statements and so that
configuration profiles know what this is. Maybe people will even use the
same terminology and everybody knows what to put there...

> of addresses if you want (and indeed, you do want that for things like 411).

I suspect that some of this is probably better codified in a
"implementation recommendations for SIP UA" document being written in
the SIP Forum, rather than a protocol spec. I would see such
recommendations as "here's something to think about - you can do
something different, but be aware of the trade-offs".

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Jan 2002 14:56:54 -0600

Dial "7" to reach housekeeping . . . 

It's the old local-versus-home services question.

I would argue that if I really want home services, I should explicitly 
qualify the URL to indicate that I wanted it evaluated only in my home 
domain. An unqualified URL should get evaluated the first place that 
feels capabale of evaluating it . . .

This makes things like 911, 411,  and 112 services much easier to deal 
with. 

--
Dean

On Friday 18 January 2002 10:55 am, you wrote:
> Dean Willis wrote:
> > No, because quite probably if you're visiting someone else's
> > corporate SIP phone, the gateway that will (perhaps MUST) be used
> > for PSTN termination is the local gateway, not the one back in your
> > home domain.
>
> Why is that? In most cases, I would certainly prefer to use my own
> phone service, rather than the hotel phone service, for example.

---

From: Jay Batson <[email-masked]>
Date: Thu, 24 Jan 2002 10:34:30 -0500

Though the moment is a bit past, I'd add my support to the suggestion 
Henning makes.

One interesting parallel-behavior:  I use Eudora for email, and can set up 
"personalities" -- a feature I use a lot.  There's a root personality 
containing defaults, and other named personalities that permit me to set 
alternate values for various config parameters, e.g. what my reply-to 
address should be, etc.  Oddly enough, one thing I *can't* set 
per-personality is my outbound SMTP server, and that drives me nuts!  I'd 
like to associate my "home" personality with my broadband provider, since 
when I send email there I want it to go through their SMTP server.  (As it 
is, I have to manually change the outbound SMTP server when I move around.)

So I know that I really *want* the outbound (SMTP) server to be a 
configurable element of my mail user agent.

In the same way, I like Henning's idea of a root/default for a user agent, 
and a provision for registrations/invites/... to be sent to a different 
server based on user agent capabilities & configurations.  This sounds 
exactly like something I'd want from an end-user standpoint.

-jb

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jan 2002 21:16:24 -0500

> It's the old local-versus-home services question.

Yup.

OK, here is the latest thought. We can't specify what to put, or not to
put, in the URI. A UA should be able to implement a UI however it likes
to make a decision about what the user meant. All we can do, is to give
guidelines about what the URLs mean. Specifically, we should discuss the
following:

1. when the user enters unqualified data, you can build a sip url or a
tel url, and the sip url can be at a variety of domains (home or
visited, for example)
2. a SIP URL means that you wish for the LHS to be interpreted at the
domain in the RHS. So, if a user is visiting, this means that if the RHS
is their home network, the home proxy would interpret it. Thats useful
for things like group lists, speed dials, etc. which are in the home
domain. You can also put a SIP URL with a domain in the RHS that is the
visited domain, and then its interpreted there. For exmaple "touch 7 for
housekeeping" could be sip:[email-masked].
3. a tel URL doesn't specify who should interpret it. Each domain that
receives the request, as it is forwarded, would have the ability to
assign meaning to it. For example, tel:7 could be interpreted by the
visited domain as "housekeeping", but if its not a number it knows, it
could also do nothing with it.

A discussion like that should provide implementors with sufficient
guidance about what URL to put in there. NOW, the big problem remains,
is that tel URL support is not mandatory in proxies, so if a UA decides
to do (3), they are SOL. I am ready to simply say that proxies need to
support the tel URL....

Here's an interesting question. How does "dial 7 for housekeeping"
interact with loose routing? Presumably, when I'm visiting, I will have
a loose route set to deliver the initial INVITE to my home domain. Lets
say I dial 7, and this results in a tel:7 URL. That INVITE would look
like:

INVITE tel:7 SIP/2.0
Route: sip:homedomain.com

THis goes to the hotel proxy, which rewrites tel:7 to
sip:[email-masked], but also obeys the route, sending it there
(it better not rewrite the r-uri):

INVITE sip:[email-masked] SIP/2.0

my home proxy does its outbound features, and sends it right back to the
hotel proxy, which connects it to housekeeping. 

So, looks like things work, as long as the visited proxy does the right
thing (rewrite the tel URL, pop the top route, use it, but don't rewrite
the r-uri).

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Jan 2002 22:49:40 -0500

I agree, except that "support" may simply mean to return 606 or 486.
There is no obligation for every proxy to have a PSTN gateway. The user
can then specify a suitable sip:@domain to place the call. I don't know
if we need an explicit status code or Warning code for this case. I
think a status code (URI scheme not supported) would be useful to make
this case explicit. This may turn out to be useful for other things,
such as IMPP.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Jan 2002 00:50:27 -0500

> I agree, except that "support" may simply mean to return 606 or 486.

That won't help, unless we mandate that clients retry with a SIP URL. 

> There is no obligation for every proxy to have a PSTN gateway.

It has nothing to do with PSTN; consider Dean's "7 for housekeeping
scenario", where the UA inserts tel:7.

> The user
> can then specify a suitable sip:@domain to place the call.

The user, or the UA? This seems a burden for the user. I think they will
view it as a system failure if they type something into their SIP phone
and it never works, because their proxy doesn't support tel URL.

> I don't know

Sounds here like you are proposing that the UA retry with a SIP URL this
time. Is it better for the proxy to support tel URL, so it succeeds the
first time, or for the UA to have to try tel, fail, then try SIP, and
have to figure out what domain to put in the SIP URL?

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Jan 2002 10:43:44 -0500

> That won't help, unless we mandate that clients retry with a SIP URL.

There are only two choices that I can see:

1) The proxy at hotel.com translates tel:7 into sip:[email-masked]
and then routes it.

2) The proxy knows that it can't handle telephone numbers, and has to do
something. One alternative is to say that the proxy should do a
mechanical translation into sip:<tel URL>@localdomain and then normal
behavior (404) kicks in if this is not a valid entry. The other is to
return an error and it would be up to the user or UA implementation to
try the sip variant.

> scenario", where the UA inserts tel:7.

I suppose if the hotel has SIP phones and says "dial 7", it has the
necessary plumbing in place to make this happen. If the number is
printed on the bedside phone, but Dean dials it from the SIP phone he
carries in his pocket, the rules above might rationalize the behavior.
From a guest phone, some amount of surprise is unavoidable - after all,
dialing 7 on my mobile phone when in the hotel doesn't get me
housekeeping, either.

> and it never works, because their proxy doesn't support tel URL.

That's why we need either automatic translation (which is easy enough to
support so that there's no excuse) or an explicit error code. 

> have to figure out what domain to put in the SIP URL?

As long as it is clear that this can indeed do something useful. What
does "support" a tel URL mean? Forward the (non-housekeeping) call to a
carrier?

---

From: Dean Willis <[email-masked]>
Date: Fri, 25 Jan 2002 14:04:27 -0600

On Thursday 24 January 2002 11:50 pm, Jonathan Rosenberg wrote:
> The user, or the UA? This seems a burden for the user. I think they
> will view it as a system failure if they type something into their
> SIP phone and it never works, because their proxy doesn't support tel
> URL.

no different than dialing direct for a calling-credit-card call, 
getting a reorder tone, and trying the 800-number access mode for the 
calling card service as an alternative.  Happens to me weekly in random 
hotels.

Ofcourse, if the hotel has a sign that says "Dial tel:7 for room 
service", I expect the local proxy will understand tel: URLs. 

> > think a status code (URI scheme not supported) would be useful to
> > make this case explicit. This may turn out to be useful for other
> > things, such as IMPP.
>
> Sounds here like you are proposing that the UA retry with a SIP URL
> this time. Is it better for the proxy to support tel URL, so it
> succeeds the first time, or for the UA to have to try tel, fail, then
> try SIP, and have to figure out what domain to put in the SIP URL?

An explicit code would make the user experience better than is 
currently supported for access-mode errors on PSTN.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 27 Jan 2002 13:52:25 -0500

> return an error and it would be up to the user or UA implementation to

If its doing this mechanism translation already, that to me is the same
as understanding what to do with a tel URL.

> dialing 7 on my mobile phone when in the hotel doesn't get me

The problem, more likely, is in an enterprise or service provider
network, where people use whatever sip phone they like. Some phones may
always use tel URL, other sip, and an arbitrary sip proxy would not work
for those UA which use the tel URL.

> will

OK. Since we are out of time, and this is a minor point now, I will add
an explicit error code for "URI Scheme Not Supported", so that the UA
can retry with an alternate scheme. I'll add the appropriate discussion
as well.

-Jonathan R.