Subject: RE: [Sipping] Do Phones Have Dial Plans, or do Proxies map? was RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 10 Jan 2003 08:27:20 -0500

Actually, I'm happy with a "Dial" button.

I'll note most existing SIP phones don't do this (or at least don't
have a physical "Dial" button, I've seen some with softkeys).

However, the issue remains.  If I dial 6744 on my sip phone (and press
dial), the sipphone on my admin's desk should ring.  I should not have
to dial +17247426744.  The fact that I dialed a 4 digit number with
a 6 as the starting digit tells my system that it is an internal
extension.  A dial plan is the thing that "knows" this.

What do you want to have happen:
1) tel:6744; context=+1724742
2) tel:6744; context=marconi-pittsburgh-local-extension
3) tel:+17247426744

Note the last is problematic.  As Mike Pierce points out, not all
extensions have E.164s

And, to amplify the thread that started this, how many identities does
my admin's UA have to understand? 

Again, I'm not opposed to making dial string expansion be a requirement
of the UA, as long as we standardize the form of the expansion, and the
mechanism by which the UA learns it.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 9:07 PM
> To: Adam Roach
> Cc: Rosen, Brian; 'Paul Kyzivat'; [email-masked]'
> Subject: Re: [Sipping] Do Phones Have Dial Plans, or do 
> Proxies map? was
> RE: [Sipping] Re: draft-schulzrinne-sipping-sos-04.txt
> 
> 
> In case there's doubt: I was not suggesting that we do this. I was 
> trying to find out from Brian what he meant, since the two 
> problem have 
> very different solution sets. The 'abbreviated dialing' case requires 
> nothing except a suitable URI scheme and the translation 
> services of an 
> outbound proxy.
> 
> Adam Roach wrote:
> >>- Recognizing patterns so that one can keep the old 
> >>"no-need-to-hit-dial" user interface.
> > 
> > 
> > AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!! AAAAAUUUUGGGHHHHH!!!
> > 
> > No!
> > 
> > Cell phones have sufficiently trained the public that it's
> > okay to hit something like "OK" or "YES" or "DIAL" or "ENTER"
> > after a phone number. It makes life so much easier for user
> > interface designers and users alike. For the love of all that
> > is good, let's not encourage backsliding.
> > 
> > /a
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Fri, 10 Jan 2003 17:52:01 -0500

There is actually a third reason to have dial plans on the UA.  The
first two have already been brought up:

1) To know when the user is done dialing
2) To know how to form a canonical URL (tel , sip or sips)
3) To know how to route the INVITE to the correct outbound proxy

On the first one, knowing when the user is done dialing,  I am afraid, as
Cullen pointed out, the market (at least in North America) wants a phone
that knows when the user is done dialing.  There are too many people
who still like the pre-cell phone metaphor. Sorry but the people on this
list do not buy enough phones to decide this one ;-).

The UA needs to know how it is going to form a cannonical URL from
the mess of characters and digits the user entered.  So as Brian pointed
out you need some regexp to transform the entered characters into a
URL.   Well guess what, every proxy vendor wants this to be a little
different.   Some want short strings (AKA extensions) transformed
differently
than long strings (AKA E.164 numbers).  So call it what you want you
end up with the equivalent of a dial plan.  The best we can do here is
to come of with a standardized (or call it BCP) way to write the
transforms.  We can write a standard that says this is the one and
only transform, but no phone vendor that has a dial plan mechanism
will be able to drop their dial plan support because they have customers
using it.  However I am sure the market would be happy to push
vendors to support a standardized dial plan description mechanism.

The third use of dial plans is for routing purposes.  I know!  That is
what the proxy is supposed to do.  However there are several uses
for doing some simple routing from the phone base upon the "dialed
string":

a) Functional routing: where based upon the purpose of the call the
user wants the call routed differently.  For example I have a phone
at home from which I make personal calls via my favorite service
provider and from which I make business calls via my enterprise
IP PBX.  I want my private/personal calls private and my business
does not want to pay for my personal calls.   A simple, familiar
metaphor for this is to use a dialing prefix (e.g. dial 9 and number
for business call, dial 8 and number for personal calls).  The alternatives

would be to sell home/office users two phones (I wish that would fly)
or put a proxy in every home/office (I would not mind selling that
many proxies if that would fly as well).

b) Load balancing routing:  based upon my dialed string I may
want to use a different out bound proxy.   Domestic US calls
go to one proxy, international calls go to another, 911/emergency
calls go directly to the local emergency gateway.  Can this be
done by the proxy? Sometimes, if I can get to it, but once you
have a dial plan on the phone, this is just about free from
both an implementation and compute cost perspective (e.g.
loose routing with a Route header in the regexp/transform).

I am happy to remove functionality from the UA and not support
it, but I am afraid the dial plan is here to stay in the UA.  I  think
our best path forward is with a standard way to specify the dial plan
transforms.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 11 Jan 2003 11:37:29 -0500

Daniel G. Petrie wrote:
> 1) To know when the user is done dialing 2) To know how to form a
> canonical URL (tel , sip or sips) 3) To know how to route the INVITE
> to the correct outbound proxy
> 

I wrote up a five-minute skeleton of a proposal at
http://www.cs.columbia.edu/sip/draft/dialplan/dialplan.txt so that we
have something concrete to talk about, in the "provide text" spirit.

Another syntactic rendition would follow the XML example of DML, as in
draft-rosenberg-sipping-markup, as in

<dialstring>
<d>xxxx</>
<t>sip:+1-859-555-\[email-masked]</>
</>

DML itself doesn't quite seem to fit, given the need for substitution,
but maybe it can be extended.

> provider and from which I make business calls via my enterprise IP
> PBX.  I want my private/personal calls private and my business does
> not want to pay for my personal calls.   A simple, familiar metaphor
> for this is to use a dialing prefix (e.g. dial 9 and number for
> business call, dial 8 and number for personal calls).  The
> alternatives
> 

This is roughly equivalent to the 'route' entries that we have for IPv4
routing on Unix and Windows machines.

> 
> b) Load balancing routing:  based upon my dialed string I may want to
> use a different out bound proxy.   Domestic US calls go to one proxy,
> international calls go to another, 911/emergency calls go directly to
> the local emergency gateway.  Can this be done by the proxy?
> Sometimes, if I can get to it, but once you have a dial plan on the
> phone, this is just about free from both an implementation and
> compute cost perspective (e.g. loose routing with a Route header in
> the regexp/transform).
> 
> I am happy to remove functionality from the UA and not support it,
> but I am afraid the dial plan is here to stay in the UA.  I  think

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 11 Jan 2003 11:40:48 -0500

I should note that 'routing' functionality is implicit in the 
translation mechanism I proposed. I would prefer to call it a 
translation functionality, to avoid the notion that it has to be as rich 
as the proxy routing capabilities. I don't want to encode things like

"Between 9 and 5, translate some-LD-number to @sprint.com, otherwise to 
@mci.com."

Least-cost routing should not be part of the dialplan... (Obviously, 
nothing prevents a local admin from updating the dialplan accordingly.)

---

From: "Cullen Jennings" <[email-masked]>
Date: Sat, 11 Jan 2003 15:22:58 -0800

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Rosen, Brian
> 

I think this is a path worth exploring.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 13 Jan 2003 13:48:07 -0500

I have a preference for the XML container for the digit maps,
though either works for me. In either case I agree we should
use the RFC 3015 style digit map representation as opposed
to inventing another one.

I would generalize the rfc 3015 syntax to handle non-DTMF
characters as follows:
"x" represents any single character (not just digits)
"." represents any number of  characters (not just digits)

It also requires some sort of escaping mechanizm to be
able to explicitly include "x", ".", "T", etc.  in the digit map
(e.g. \x,  \., \T, etc.).

Is the grouping by curly backet {} neccessary?  There is
implicitly a fixed and variable part of the dial plan.  Why not
just have a verbs that represents the entire or variable part
of the dial plan?  Any part of the fix part of the dial plan
can easily be put back in the URL transform (e.g.
91xxxxxxxxxx tel:+\11 as opposed to 9{1xxxxxxxxxx} tel:+\1)

Also just to be explicit I am assuming that the range (e.g. [1-6])
and or (e.g.  911|9911) constructs of the RFC 3015 are intended to
be included, though not shown in your examples.  I feel they
at least SHOULD supported.

Is there any reason to exclude other URL types in the transfrom
that might result in non-SIP requests like HTTP?  I am not sure
this would make sense on all UAs, but it might on some.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Jan 2003 23:09:32 -0500

Slightly old thread here, but I wanted to add my own two cents.

Firstly, I too support the development of some kind of dial plan 
document that can be downloaded into a UA. I think such a mechanism 
should be incorporated into some kind of BCP that describes the 
construction of enterprise phoen systems with SIP; I believe Brian 
mentioned he is working on such a thing.

More inline.

> 2) tel:6744; context=marconi-pittsburgh-local-extension

The notion of an identity that exists within a local context is exactly 
what a SIP URI is for. I always thought that if the user entered 6744, 
the most likely result would be the following URI:

sip:[email-masked]

where example.com is the local domain, configured into the phone. Unlike 
the tel URI, which has no clear way to determine where to go to resolve 
a number with a local context, the SIP URI does.

-Jonathan R.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 Jan 2003 19:53:06 -0500

> a number with a local context, the SIP URI does.

I don't think there is any single right answer to this.

But if the device has the form factor of a phone, with only a number pad 
rather than a full keyboard for entering the address, then I think

	sip:[email-masked];user=phone

would be a better choice than omitting the user=phone. This makes 
explicit a request to have the address interpretted (and probably 
expanded) as a phone number.

And I think another choice that is at least as good is:

	tel:6744;phone-context=example.com

It expresses the same intent more explicitly, and is not overtly 
dependent on the sip protocol. This doesn't matter a great deal in the 
request uri, but it might matter in the From address, because that might 
be captured by the recipient and saved for use in other contexts.

The definition of the tel: uri specifies that a local number should only 
be used if there is no global number. (This is of course helpful because 
it maximizes the number of contexts in which the address may be 
successfully used.) So ideally,

	tel:+17247426744

would really be preferred. It requires that the phone contain the dial 
plan expansion. All these other possibilities are when there are good 
reasons why that can't or shouldn't be done.

There is a lot to be said for canonical forms for addresses too. If a 
non-canonical form is used in the To address, it might not be understood 
by the recipient. For instance, suppose Alice calls Bob, but Bob has his 
calls forwarded to Charlie. Perhaps Charlie's phone checks the To 
address to see if the call was intended for him. If not it puts up a 
special indicator of a forwarded call and attempts to show who the call 
was actually for. If the To header has the full global form of the 
number called, then it is easy to figure out it is Bob's address. But if 
the To address has some local short form that makes sense only in 
Alice's domain, then Charlie's phone can't do much more than display it, 
and Charlie himself may be equally unlikely to recognize it.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Jan 2003 09:42:16 -0500

> I don't think there is any single right answer to this.

But we may be able to avoid many of the fruitless discussions by 
recommending easier alternatives in certain cases. Let me try to 
summarize and see if we can agree on this:

- For web pages and other non-SIP contexts such as address books, global 
tel URIs are preferred since they avoid extraneous information. Local 
tel URIs would be used only in exceptional cases, but the context is 
extremely important here in case a web page "leaks" to another context.

- For SIP phones, local dialplans should translate dialed digits into 
either global tel URIs or SIP URIs within either the local SIP domain 
(if the dialing plan is local) or the user's AOR domain. This affords 
maximum flexibility - users can decide whether they want to take their 
dialing plan with them or use the local one in places they visit.

One way to learn about the dialing plan is to send OPTIONS to the 
outbound proxy (found via DHCP, say), either directly or via content 
indirection.

- If there is no dialing plan, a translation into a SIP URI with the 
digits + local domain seems safest.

- Local tel URIs without context MUST NOT be used in From and Reply-To, 
Local tel URIs with context SHOULD NOT be used in that context.

- Local tel URIs without context are a bad idea in To headers. My 
inclination is MUST NOT. (This is nothing new, since context is required 
anyway.)

- There may be cases for a context-based local tel URI in SIP phones, 
but I'm having a hard time seeing the advantage compared to the SIP URI 
with user=phone. The SIP URI allows much more flexibility in terms of 
who does the resolution, rather than just rejecting out-of-context URIs.

- Given the above, I can't see a case for a context-free local tel URI 
(tel:1234). Using a SIP URI seems much less likely to cause trouble and 
requires no more configuration beyond knowing the outbound proxy server.

I'm considering adding a non-normative annex to 2806bis to capture these 
guidelines.