Re: Overlap dialing user experience

Brian,

 > I know of very few number portability databases where every number ever
 > issued is in the database.  Having access, in one form or another, to the
 > database only gets you so far.
 >
 > However, I'd like to keep this discussion on track, which is 
determining the
 > number of digits in a number needed to route.

Infrastructure ENUM is a replacement for All Call Queery (ACQ)
It only makes sense if a certain country or number range
is fully implemented.

The simplest and easiest way to do so is to
implement only a Tier 1 datebase (contrary to
User ENUM), where all E.164 numbers of the
number range are entered and are pointing to
the carrier hosting the number.

The problem I see here with send-n is that
you cannot use this simple structure here
and have to make zone delegations below to
hold the send-n NAPTRs.

In DE and AT, the whole thing does
not work anyway, because e.g.
you may have +43 1 9793321
and          +43 1 97933221
and          +43 1 97933222
and this is a carriers choice.

regards

Richard

Brian Rosen wrote:
> Richard
> 
> Nice to hear from you, hope you are enjoying your retirement and numbering
> blocks still have great relevance 30 years later.
> 
> Nearly every country has number block assignments.  The information we are
> trying to extract is the length of a number, although it does turn out that
> the carrier assignment data is also useful, and as long as we're providing a
> mechanism to extract the number plan from the number administrator, we might
> as well get the assignment data.  Even in the U.S., which has a single
> length, knowledge of the block assignments is useful to know:
> 1) What is a valid number
> 2) Which carrier owns the number when the number has not been ported.
> 
> I know of very few number portability databases where every number ever
> issued is in the database.  Having access, in one form or another, to the
> database only gets you so far.
> 
> However, I'd like to keep this discussion on track, which is determining the
> number of digits in a number needed to route.
> 
> Brian
> 
> -----Original Message-----
> From: Richard Stastny [mailto:[email protected]] 
> Sent: Thursday, April 10, 2008 1:17 AM
> To: Brian Rosen
> Cc: 'Jay Daley'; [email protected]
> Subject: 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:[email protected]] 
>> Sent: Wednesday, April 09, 2008 5:25 PM
>> To: Brian Rosen
>> Cc: [email protected]
>> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/enum
>>
>>
>>
> 
> 
> 
>