Re: Overlap dialing user experience

Brian,

 > I would expect that if I
 > found the equivalent number plan in the ITU bulletin for Austria, I would
 > find that there was a block something like 1 979 XXXX with a min of 8 and
 > max of 9 digits.

in the ITU bulletin for AT you only find for
NDC 1 (Vienna)
N(S)N max length 13
N(S)N min length  4

e.g. for NDC 664 (a mobile operator)
N(S)N max length 13
N(S)N min length  7

If you search for assigned number blocks
http://www.rtr.at/de/tk/Rufnummernsuche
you find only the 3 digit blocks and the carrier
e.g.
(0)1 200 Verizon Austria GmbH

I do not think this helps
The data has to be derived from the carriers
and you cannot build a flat T1.

 > I would need access to the number portability
 > database to route the call if this block was
 > subject to portability.

I am confused, I thought I-ENUM IS the NP database.

Richard

Brian Rosen wrote:
> Richard
> 
> Staying on track, the problem I want solve is to determine how many digits
> are needed to route to the terminal domain.  In DE and AT, you have this
> variable length capability.  I understand that.  I would expect that if I
> found the equivalent number plan in the ITU bulletin for Austria, I would
> find that there was a block something like 1 979 XXXX with a min of 8 and
> max of 9 digits.  That is enough information to figure out when there are
> enough digits to query ENUM, and is enough information to construct a T1
> that works.  I would need access to the number portability database to route
> the call if this block was subject to portability.
> 
> Brian
> 
> -----Original Message-----
> From: Richard Stastny [mailto:[email protected]] 
> Sent: Thursday, April 10, 2008 11:43 AM
> To: Brian Rosen
> Cc: 'Jay Daley'; [email protected]
> Subject: Re: [Enum] 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
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
>