[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] 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:richard at stastny.com]
> Sent: Thursday, April 10, 2008 11:43 AM
> To: Brian Rosen
> Cc: 'Jay Daley'; enum at ietf.org
> 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:richard at stastny.com]
>> Sent: Thursday, April 10, 2008 1:17 AM
>> To: Brian Rosen
>> Cc: 'Jay Daley'; enum at ietf.org
>> 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: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