[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] Overlap dialing user experience
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