Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in commonpolicy

From: "Brian Rosen" <[email-masked]>
Date: Mon, 22 Aug 2005 11:27:45 -0400

Henry

This is waay to much hand waving.

"Designers of enterprise communications systems" aren't any different from
designers of residential communications systems.  While there are firms who
plan to provide both phones and servers, and hope their customers choose
them for both tasks, there are many others who want the phone choice and the
server choice to be independent.  To do that, the phones and the servers
have to follow standards, and that includes dial plans.

The residential case is exactly the same.  The phone vendors and the server
vendors are more typically different, but you have some significant
exceptions.

I like presence and click to call, but don't think it's going to supplant
dialing completely for some long time.  If you dial, even occasionally,
these issues arise.

We need standards if we want dial plan interpretation in phones, and we need
a fairly substantial change in existing phone code to get it.  That applies
to both residential and enterprise.  I'm sanguine about that happening.

Brian

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Monday, August 22, 2005 11:01 AM
To: 'Brian Rosen'; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in
commonpolicy

>However, there are very, very few phones that do dialplan interpretation,
>especially one suitable for an enterprise.  We either have to change that
>behavior, or support dialstrings.
 
This is true and best left to implementers of enterprise communication
systems where there is a different design space altogether. Enlightened
enterprises may prefer presence anyhow to PBX-style dialing or just use
mobile phone style click to call based on presence and SIP events.

What goes over the net should be only E.164 addresses or SIP URIs.

Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, August 22, 2005 9:51 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in
commonpolicy

FWIW, I agree with you; phones should do dialplan interpretation.  That begs
the issue of how you download a dialplan into a phone.

However, there are very, very few phones that do dialplan interpretation,
especially one suitable for an enterprise.  We either have to change that
behavior, or support dialstrings.

Brian

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Monday, August 22, 2005 10:42 AM
To: 'Brian Rosen'; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in
commonpolicy

Brian,

I agree with both you and Richard Stastny how you formulate the problem with
dial plans. 

The fact however that so many IETF contributors have taken a stab at solving
the dial plan problem and are still trying after all these years, makes me
think the dial plan complexities should best left to the endpoints who
should know what to do. Dial plans should be left to the implementers of
endpoints and not with the IETF. I have only given in previous mail the
example of endpoints that know what to do, to prove that endpoints can do
it.

So unless it is an E.164 PSTN phone number or a SIP URI, SIP services should
not ever be burdened with anything else. Nor should users be burdened to
know anything else.

I bet however that in spite of this, there will be more engineering attempts
to solve the dial plans in the IETF and will look forward with interest...

My two cents.

Thanks, Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, August 22, 2005 9:19 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in
commonpolicy

Henry

You've been around enough to know that what you said is not the issue.
Dialplans, and dialstrings, arise because you don't generally know how long
a dialstring is, and phones don't know how to render a dialstring into a
telephone number or service indication.  Either you allow dialstrings in
which case some entity, the phone or a proxy, interprets digits according to
a dial plan to know when the terminal digit has been entered, adding
appropriate prefixes, or you use the wireless mechanism of not having "dial
tone", entering digits, and having a key press that indicates end of dialed
number and forcing the user to put in all the prefixes, or some combination.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henry Sinnreich
Sent: Sunday, August 21, 2005 12:57 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in
commonpolicy

Folks,

I have followed the discussions on dial plans for a while, and it has been
going on actually for several years. Since the dial plan topic is so complex
even for the experts in the IETF, how can anyone hope that developers or
even more, users will get it right?

KISS and use only one of the three:

1. E.164 numbers for the Internet challenged,
2. SIP URIs for everyone else, or the best of all
3. Hide any type of CA in the AO and use Presence. Just click to call.

Thanks, Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Otmar Lendl
Sent: Thursday, August 18, 2005 5:33 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [voipeer] Re: [Geopriv] Re: [Simple] tel URIs in common policy

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peter Williams" <[email-masked]>
Date: Mon, 22 Aug 2005 09:08:11 -0700

Concerning recharter,

We have to ensure that ENUM stays on an ENUM-specific mission: while voice
service issues are an important driver, their impact on ENUM must be
compartmentalized within the supporting enumservices. Our mission (here) is
high-level: "Internet convergence with the PSTN"; its not "routing phone
calls".

Let me put it another way - as a program manager, who strategically vouched
for carrier ENUM in the debate.

Because of the class of management requirement (mostly security) that such
as regulated voice services will bring, we needed a _provider-based_
management model, in addition to the user-based management model for data
provisioning. The adoption of carrier ENUM in the charter (if it happens)
convinces me that ENUM may have the architecture to succeed in the intended
operating environments.

Now that the religious phase of WG argument is over, we can perhaps get back
down to Internet engineering. If ENUM leads DNS evolution in practice to
(optionally) adopt just some of the most critical provider-centric
management practices learned other name server infrastructure efforts, we
will have made a big contribution to the Internet's evolution. Small,
incremental infrastructure changes are what we are all about, after large
amounts of email.

..showing that ENUM has all the necessary elements to support regulated
voice was an academic exam that ENUM had to pass: but it's not actually the
goal.

In our charter reformulation, we focus on the infrastructure goals (now that
we have the experience of discussion to better formulate them), not the
particular (but critical) predictor of success.

Peter.