Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00)

["Brian Rosen" <br at brianrosen.net>]

You are missing the point.

The number of digits need to route the call to the correct domain is
determined by a more static database which is not subject to public enum
implementations.  If we can solve the entire route-to-the-domain problem
simply, without requiring deployment of user enum, that is, in my opinion, a
better answer.

Once you get to the domain, there is more routing to do.  I would prefer
that the domain handle that directly.  That is, after all, how SIP works.
We route to the domain using one set of mechanisms.  Then the domain uses
another set of mechanisms to route to the device.

Right now, route to the device with variable length TNs is .001% of the
problem.  The other 99.999% is route to the domain.  I think a simple
solution to that would be great.  I don't think that is an ENUM solution.

Brian




-----Original Message-----
From: Jay Daley [mailto:jay at nominet.org.uk] 
Sent: Wednesday, April 09, 2008 5:25 PM
To: Brian Rosen
Cc: enum at ietf.org
Subject: RE: [Enum] Overlap dialing user experience (Re: I-D Action: New
draft - draft-bellis-enum-send-n-00)

Brian

> I think the mechanism needed by carriers to route calls is a heck of a 
lot
> easier to solve then a mechanism needed by a phone to dial a hotel that
> decided on its own how long it's numbers are.
> 
> If you want to generalize to "needed by originators" instead of 
carriers, it
> doesn't change the problem.
> 
> The number of digits needed to route to the termination domain is 
determined
> by a block assignment by a number administrator.  There is one per 
country
> of them.  Creating a system where we define a way for them to 
communicate
> block assignments seems to be a pretty tractable problem.

There is an assumption there that the number structure created by the 
national number administrator is the same as the structure within the ENUM 
tree.  This is only true in the pathological case of a fully populated 
tree.  In User ENUM that simply will not be the case.

What this draft does is allow the manager of a part of an ENUM tree to 
describe the structure of that part of the tree and thereby make the 
dialling process more efficient. 

In the case of User ENUM this could be the T1 registry.  As numbers are 
registered with them they would create and/or modify send-n records higher 
up the tree from where the numbers are provisioned.  These send-n records 
would therefore be quite dynamic, responding to the local growth in user 
ENUM.

Jay

_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum