[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enum] Overlap dialing user experience



 > 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.

Folks,

I am watching this discussion since some time and
I am wondering.

There seems to be an understanding of numbering
from 30 years in the past:

one uses number blocks to route to the
domain (= operator) and then the operator does
rest

Never heard about number portability ?

Regardless of User or Infrastructure ENUM
the routing to the domain has to be
per number finally. The domain has to
find out where the user really is connected.

The Rwanda example is nice and  was discussed
in Austria 1985 when new carriers are introduced,
because the routing was simple, but never implemented
because it does not support NP, beside other drawbacks.

Richard



Brian Rosen wrote:
> 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
> 
> 
> 

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