Subject: proxy-based dialing plan problem

From: "Rick Dean" <[email-masked]>
Date: Thu, 16 Dec 1999 18:30:49 -0600

I hear debate on whether to put a dialing plan inside my
SIP phone.  If the phone has a dialing plan, the phone would
internationalize numeric entries, making them look like
<sip:+18472621415;user=phone> or preferably <tel:+18472621415>.
I don't like this.

The alternative is a proxy-based dialing plan.  The phone
has a default-dialing domain (DDD), which is appended
to numeric entries.

For example, my DDD could be 1847.x.com, which would allow
me to dial 2621415 generating <sip:[email-masked]>, which
ultimately means the example above.  Similarly, 8472621415
and +18472621415 would also work though my smart
proxy.  BTW, for those of  you who have not played with
my phone, it has an end-of-dialing (Ok) key.

Now my problem is to ensure that all services work with the
proxy-based dialing plan.  I appears to work for me but this
one tough example, a transfer with PSTN gateway authorization.

In the following example phone1 again has a DDD of 1847.x.com,
and is in a call with phone2.  Phone1 attempts a blind transfer to
5551234, (which phone1 means tel:+18475551234, but only the
proxy knows it).  The call does not have a route, so the
BYE passes end to end without a proxy.

phone1      1847.x.com                      phone2
  |             |                              |
  | BYE         |                              |
  | Also:<sip:[email-masked]>              |
  |------------------------------------------->|
  |    200 OK                                  |
  |<-------------------------------------------|
  |             |                              |

The problem now is that x.com bills for gateway service and
does not have an agreement with phone2, but isn't sure.
I have two possible solutions, which expect unobvious behavior.

One solution is to include an Also in the 401 Unauthorized,
so phone2 uses his own PSTN gateway.  This is new behavior.

  |             | INVITE sip:[email-masked]|
  |             |<-----------------------------|
  |             | 401 Unathorized              |
  |             | Also:<tel:+18472621415>      |
  |             |----------------------------->|INVITE tel:
  |             |                              |---------->
  |             |                              |

Another solution is to suggest SIP phones try again at least
once when all credentials have failed.  This way the proxy has
a chance to redirect.

  |             | INVITE sip:[email-masked]|
  |             |<-----------------------------|
  |             | 401 Unathorized              |
  |             |----------------------------->|
  |             | INVITE sip:[email-masked]|
  |             | Authorization: blah          |
  |             |<-----------------------------|
  |             | 401 Unathorized              |
  |             |----------------------------->|
  |             | INVITE sip:[email-masked]|
  |             |<-----------------------------|
  |             | 302 moved                    |
  |             | Contact:<tel:+18472621415>   |
  |             |----------------------------->|

People have suggested that the dialing-plan capable proxy
insert a record-route.  He doesn't have to keep state and
the BYE could hit a different box in the farm, but all boxes
would know how to internationalize the Also.  This fails for
many reasons, one of which is PGP signed/encrypted responses.

Feedback?

--
Rick
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Dec 1999 09:31:39 -0500

> <sip:+18472621415;user=phone> or preferably <tel:+18472621415>.

I believe there are clearly pros and cons. The function can just as
easily live within a UA or a proxy. In the end, service providers that
deploy these things will make the decision about where they want it
done. My sneaking suspicion is that this is best done in a UA, however,
so that we consistently pass around numbers in messages which have
meaning globally. Its a similar argument for domain names. Would your UA
send an INVITE to its local proxy in the form:

INVITE sip:joe@host SIP/2.0

from within domain foo.com, and then expect the proxy to fill in the
foo.com within the request URI? 

> my phone, it has an end-of-dialing (Ok) key.

I don't like this at all. Domain names are not meant to convey dial
plans. Rather, the UA should send:

INVITE tel:2621415 SIP/2.0

and then the proxy uses its local configuration to determine that this
number is a local number, and in fully qualified form is
tel:+18472621415. It may then invoke enum and or TRIP services, and
forward an INVITE to the next hop proxy, perhaps of the form:

INVITE tel:+18472621415 SIP/2.0

or

INVITE sip:[email-masked]

I am beginning to lean towards the tel form.

What is debatable is whether the tel URL from the UA to the proxy
contains some kind of dialing plan indicator as a URL parameter, or
whether the dialing plan is known by configuration.

>   | Also:<sip:[email-masked]>              |

Your problem is that you should not transfer to the SIP URL. What you
really want is to transfer to a tel URL. Furthermore, in the case of
these transfers (and redirects as well), I think it is essential that
the tel URL be a complete E.164 number. With normal SIP URLs, if a UA
was in domain foo.com, it would never do a transfer like:

BYE
Also: sip:joe@host

when it really meant:

BYE
Also: sip:[email-masked]

You'll get yourself in all kinds of horrible troubles by passing around
URLs that don't have complete domain names in them. Same for phone
numbers. You are only safe in using incomplete numbers in INVITE
messages passed to *local* proxies. If your UA is already configured to
know to send calls to 1847.x.com, why can't it rather be configured to
know that it should BYE/Also to tel:18475551234?

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Dec 1999 16:56:47 -0500

[email-masked] wrote:

> I don't like URL parameters.  I don't want to show one to a
> novice user, nor expect him enter one.  Please make them go away.

Who said anything about showing them to users? Make whatever UI you
like. We are talking about how the software in the phone formats the SIP
messages.

> > If your UA is already configured to
> My point is to keep the numbering plan which knows
> how to globalize numbers, out of the UA.  I want users to
> be able to perform 7-digit, 10-digit, 11-digit, centrex, etc dialing
> just like my cell phone.

My point here was that you're initial approach already had numbering
plan information in the UA. Your UA is configured to know to take the
dialed number, and add the 1847 as part of the domain. Isn't this
knowledge of a numbering plan? I was arguing that since you already know
this, add this 1847 in front of the digit string rather than at the end.

-Jonathan R.

---

From: [email-masked]
Date: Fri, 17 Dec 1999 14:06:41 -0600 (CST)

From: [email-masked]
> foo.com within the request URI? 

My point is to not send around local dial-plan numbers 
without a FQDN context.  

> INVITE tel:2621415 SIP/2.0

Yeah, great. I agree send the actual digits dialed to the local 
proxy, but it doesn't help me if I (as the UA) still have to internationalize
the "also" anyway.  Omiting the context of
the numbering plan is less clear.  Do you have a better choice
to convey dial plan than a domain name?

I want non-globalized numbers to look like SIP URI's.   Additional
syntax complexity is undesireable.  

> <stuff deleted>

BTW, this is unusual for me to favor a smart netowrk.  The server
guys should take advantage of me while they can.  :-)

--
Rick 
[email-masked]

---

From: [email-masked]
Date: Sat, 18 Dec 1999 12:27:00 -0600 (CST)

> From [email-masked]  Fri Dec 17 15:51:08 1999
> 

Are you suggesting everyone derive their own user representation?  
IMHO, "friendly" URL's of MSIE suck.
If we are not designing a protocol to be human readable, then
why not use ASN.  :-)   Whatever we specify will
be shown to users and will be printed in advertisements.
What do I enter in my palm?

I am running out of memory inside my phone.   I have a
two line display of 16 characters each.  People don't read
documentation.  They insist they already know how to work a
phone, or the phone is broken.  Let us please keep this 
simple without additional URL parameters.

> this, add this 1847 in front of the digit string rather than at the end.

Sorry, it was a bad example.  In Germany it is not possible to 
globalize a number simply by its length.  Similarly, I fear the Y2K problem
when we add another digit to the North American numbering plan.

I fear constructing (yet another) syntax for representing the
dialing plan.  Appending @1847.x.com, when @ is missing, is
my kind of algorithm.  

To extend your DNS analogies, putting a PSTN numbering plan inside
a SIP phone is akin to forsaking DNS for host files.

Sorry, but I am in a bit of a hurry to get this solved.  

--
Rick
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 19 Dec 1999 22:23:25 -0500

> simple without additional URL parameters.

SIP already has URL parameters. Would you suggest we move them into the
domain name to be more "friendly" as well? If you think phone context is
ugly, then split it out of the URL and present it in some other way to
the user if this is needed.

However, the phone context parameter, or something like that, is likely
to be something that is only inserted by a UA before a call is made, and
not present in URLs in billboards. HTTP has URL parameters, as does
mailto, but usually they are not needed when printed in ads. Any URLs in
billboards or advertisements really better be globally significant
telephone numbers, in which case:

tel:+1-516-555-1212

couldn't get much more human friendly.

> when we add another digit to the North American numbering plan.

I'm not following you here. What has length got to do with it? 

> a SIP phone is akin to forsaking DNS for host files.

In fact, this already exists in DNS, but it has nothing to do with host
files. If I do something like:

telnet myhost

at my machine, it automatically appends my domain (dynamicsoft.com)
which has been pre-configured in my machine, and then looks for
myhost.dynamicsoft.com in DNS. This is exactly what we are talking
about. 

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 19 Dec 1999 22:32:11 -0500

> In fact, this already exists in DNS, but it has nothing to do with host

Actually, to be picky, it's not a protocol feature, but rather a
resolver feature. In the context of this discussion, this distinction
may need to be kept in mind, since we are talking about adding things to
SIP rather than just a UI.

> myhost.dynamicsoft.com in DNS. This is exactly what we are talking
This is also an example why this type of abbreviation needs to be done
very carefully. These "local" URLs mess up cookies, for example (since
the browser doesn't know that www.local.com is the same as www.) In the
SIP context, allowing ambiguity is likely to make call-matching
difficult, as well as various UI and script functions such as call logs,
histories and call processing scripts.

If we are not careful, we are heading towards the same NAT problems of
local name spaces that are causing no end of grief a few layers below.

UIs filling in the high-order parts of an address is much preferable, in
my book, since then the whole application sees the same, complete
address.

Henning

---

From: [email-masked]
Date: Mon, 20 Dec 1999 10:45:05 -0600 (CST)

Johnathan & Henning,

Thankyou for your insights.   

Have we agreed on a solution to 
the numbering plan problem?  That is,
how should a UA globalize a phone number when
the user does not enter it that way?  

To recap, my proposal would allow the UA not to know
about the PSTN numbering plan, but choose
to send it as a SIP URI to a default proxy/gateway. 
This makes building the UA 
much easier, and IMHO the protocol more intuitive.  
I contend this system will work
as long as that gateway can redirect to a globalized
PSTN number in 401 unathorized, while still accepting
credentials.  I think this is best performed with
an "also" in the 401 unauthorized, but from looking
back though HTTP, maybe a "Location:" would do.

For example dialing in Chicago though my PSTN gateway
service provider of x.com might produce invites like
  INVITE [email-masked] SIP/2.0
When I forward people who use y.com to this number they
might receive 
  BYE sip:[email-masked] SIP/2.0
  Also: <[email-masked]>
from me and 401 Unauthorized which might look like
  401 Unauthorized
  Also: <tel:+18472621415>
from the PSTN gateway which they could act accordingly with.

How do we go from here?  I am willing to write
this up as an Internet Draft if you think that
is best.  Maybe with a longer explaination
of how the system works people would implement
it more consistently, or make a more informed
decision not to.

If you are still opposed to this architecture, I 
am willing to build it such that 1847.x.com always redirects
everyone to the globalized PSTN number.  The UA
would receive additional logic which sends numbers beginning
with a "+" to a different gateway, which my solultion
requires anyway.  This requires no
standards changes, but adds an additional transaction
to the normative case.  Hmmm.  

My compliments on building a protocol which is general
enough to handle this unplanned case even without 
changes.

--
Rick

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Dec 1999 00:34:16 -0500

> back though HTTP, maybe a "Location:" would do.

I still have problems with this. They are:

1. the domain name is not the right place to be putting phone contexts
and dialing prefixes
2. you rely on deploying lots of servers at these addresses
corresponding to dial plans; 1847 is just one example. You'll need one
for each area code for each domain.
3. it involves an extra jump to this 1847.x.com server with which the
transferred party has no relationship. This extra jump can be avoided by
Also:ing to the tel URL right away.

Your UA apparently is configured to append 1847.x.com in the domain part
of every number dialed. All I'm saying is, instead of appending it to
the right, append it to the left of the dialed number, and make that a
tel URL. This solves all these problems, and is absolutely no more
complex than what you are doing now.

I'm still looking for an answer on why its so bad to have the UA
globalize, as is done today with hosts filling in their domains when a
user types 'telnet somehost'. How many entries in the dial plan are we
talking about? How much compute complexity? Having these managed in a
central place, but distributed to UA's, still allows the provider to
control them, but ensures only globally significant numbers are passed
around. I'll note that this model of downloading dial plans into the UA
is more or less what megaco does also. Much headaches in the PSTN occur
since non-globally defined numbers are passed around all over the place.
IP has avoided this headache so far. I'd like to keep with this model.

> it more consistently, or make a more informed

You are always welcome to write up an I-D on any subject you like.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Tue, 21 Dec 1999 00:36:38 -0600

> IP has avoided this headache so far. I'd like to keep with this model.

Well, I have about 35,000 different private dialing plans, some of which
have upwards of 100,000 numbers, MOST OF WHICH DO NOT MAP TO GLOBALLY
SIGNIFICANT NUMBERS. Many are variable length, or have synonyms of different
lengths such as four-digit dialing to a number that could also be reached by
8+7digits. Some of the dialing plans actually vary by time-of-day or
who-is-placing-the-call or in other bizarre and nondisclosable ways.

I'd personally much rather have a client that knows it knows nothing about
the dialing plans, and have it just forward the dialed digits to a proxy.

We expect to be able to configure a phone with a "default proxy" the same
way one configures a PC mail client with a "default SMTP host". The behavior
of the phone should be to send all the dialed digits to the proxy, either in
	sip:digits@proxy;user=phone
		or
	tel:digits
formats, or to send dialed names in
	sip:name@host
format

If somebody wants to build a phone that can use multiple "default" proxies
under user control, that's fine. Note that Qualcomm and Microsoft have built
mail clients that allow multiple accounts to be configured, with the result
that mail sent from one account may go to a different SMTP smarterhost than
mail originating from a different account within the same client. One might
call this a "multiuser" or "multiprofile" phone. One might even build a
phone to download its "account" information, or get it from NIS tables, or
whatever. But it had better be configurable to send INVITES to my proxy, or
it's not making calls on my network.

How about we define a limited set of contexts,
{"unknown","public","private","global","local"} such that a phone that knows
it doesn't know anything about the dialing plan can indicate a
"phone-context=unknown" and a phone that "knows" it has a global number can
indicate that as well? We can combine this with a translation identfier
("trans="token), and a "numbering plan" identifier ("plan="token), and I
believe we have all the semantics necessary to describe a dialed number and
any information knwon about it rather completely as it is processed through
every transformation I can think of.

So, a dumb phone receiving digits 1234567 could send:
INVITE <tel:1234567;phone-context=unknown>
To: <tel:1234567;phone-context=unknown>
 or the equivalent
INVITE <sip:1234567@service;phone-context=unknown>
To: <sip:1234567@service;phone-context=unknown>

which "proxy" might rewrite as
INVITE <tel:+19871234567;phone-context=global;trans=lnp>
or
INVITE <tel:1234567;phone-context=private;plan=mci-23;trans=isn45>
or
INVITE <sip:[email-masked]>

Homework:
---------------------

Question: If a phone-context is not specfied, what value do we assume it
has?

Proposals:

1) "unknown".

2) "global" or "unknown" based on the presence/absence of a leading "+".

Homework:
---------------------

Question: phone-context can clearly apply only to tel: URLs and SIP URLs
with user=phone. SIP URLS with a "name" are given context by the hostport
field. Can we simplify this further?

Proposals:

1) Deprecate the SIP: url with user=phone. It is confusing to have context
information in the phone-context and in the hostport component of the
grammar. Use a tel:URL for all destinations "expected to be" phones, ie.
consisting of dialed digits with no "@".

or

2) Deprecate the phone-context syntax and the tel:URL. Always indicate
dialed numbers in sip: URLs, with the context expressed on the RHS of the @,
as in "sip:digits@context", where "context" is a token (or compound string)
understood by UAS and proxy. The "context" expressed here is not expected to
be a name present in DNS or a valid IP address (it might be one by accident,
but we would not expect it to be and it would not be treated as a name or
address). I believe this is what Rick is proposing.

or

3) Deprecate tel: amd phone-context as in #2, but concatenate the context
with the dialed dgits on the LHS of the @ and present the hostport of the
default proxy or service on the rhs, as in
"sip:[email-masked]". I believe Jonathan suggested this.

or

4) No, this can not be simplified further along these lines. The "tel:" URL
expresses an direct phone number, whereas the "sip:" url with "user=phone"
expresses a phone number which is indirected to a particular service or
provider, and both are believed to be necessary.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 21 Dec 1999 12:03:13 -0500

Comments below:

> who-is-placing-the-call or in other bizarre and nondisclosable ways.

I would argue that for these cases one should use a SIP url as opposed to the
tel url.
Using the sip url, these then become globally significant as they are in the
context of
the SIP server after the @.  This may not indicate the final destination, but it
provides
context in which it it is unique and resolvable.

> it's not making calls on my network.

I think that there is a need for two levels of "dial plan" configuration.  I
would vote
that this information is provided to the phone via Registration response as
opposed
to proprietary configuration in the phone.

1) The default simple dialing plan or digit collection method using a timer,
fixed length
and/or "send" button to determine end of digits.  The phone constructs a sip url
by
appending a @<sip-server>... onto the digits.  The tel url should not be used as

the digits are not globalized.  When the phone does a tranfer (blind or other
wise)
it constructs a sip rul for the Also in the same way.  The default SIP server
(i.e. "@<sip-server>") must be willing to resolve the Also url for the
transfered
party, minimally redirecting.

2) A more advanced dialing plan is also needed, with pattern matching and
assocated
SIP server through which to route the INVITE.  The idea here is to
internationalize
the collected digit string through pattern matching and provide a recommended
SIP server to
send the INVITE.  For example digits matching pattern: "555...." should be
inserted
into the url: "tel:+1617[yourDigitsHere]" and send to the server
myCarrier.com:5060.
So dialing "5551234" constructs: "tel:+16175551234" and the INVITE is sent to
myCarrier.com:5060.  There is no reason to restrict this approach to tel url's,
however
it is probably the more likely scenario.  The patterns should also support the
ability
to indicate how the end of digits is determined (i.e.  timer, fixed length
and/or "send" button).

In both of these methods you end up with a url which is globally unique.  The
tel url
has the issue of needing context as Adam and Dean pointed out.  This can be
handled
by the url string which the matched digit pattern is inserted into. (i.e.
"tel:1214[yourDigitsInsertedHere];phone-context=global;numbering-plan=isdn"

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Dec 1999 15:52:05 -0500

> who-is-placing-the-call or in other bizarre and nondisclosable ways.

In these cases, I believe the tel URL is not the right form, and rather,
you should use a SIP URL. The left hand side is *whatever you want*,
since the name only has meaning within the context of the domain to the
right, which is wcom.com. So, if some gateway receives a call for 333
and this is some private numbering plan, identified as plan 34, its
perfectly reasonable to construct a URL which is:

sip:[email-masked]

or

sip:[email-masked]

or whatever you like. The construction of the name to the left DOES NOT
HAVE TO BE STANDARDIZED. It has meaning only within wcom.com. The only
server that needs to understand its semantic is wcom.com.

> every transformation I can think of.

I think we can avoid any extensions to the url forms by allowing each
vendor to include the information it needs in the user portion of the
SIP URL. This way, each SP can generate the information it needs. This
does require cooperation between the gateway and the proxy, in the sense
that the gateway must generate the user names in the form the proxy is
expecting to understand. We could then write a separate document, if
people like, standardizing formatting of the user portion to convey this
kind of information. Multiple specs could even be defined for this, and
which one is needed would basically be part of the RFP put out by an
service provider that wants to deploy a service.

In the case of globally significant numbers, I believe the tel URL form
is better, and that the tel URL form should be globalized.

> Homework:

I'm suggesting the context be part of the user portion of the SIP URL.

> "sip:[email-masked]". I believe Jonathan suggested this.

Almost. Keep tel URL, but use them only with globally significant
numbers. 

-Jonathan R.

---

From: [email-masked] (Henning Schulzrinne)
Date: Sun, 26 Dec 1999 12:16:11 +0100

In the spirit of (semi)intelligent end system, having a configuration
option for an end system (possibly conveyed via DHCP or some REGISTER
response) as a "rewrite rule" such as 

/([1-8][0-9]+)/[email-masked]/
/9([0-9]+)/tel:&/

may allow building generic software that can be configured for local
needs.

This is similar to what sendmail does. It's not quite an MGCP dialing
plan, since some digits are not passed to the proxy. I'm assuming here
that VPNs are regular expressions. This seems likely, given the necessar
prefix properties.