Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00)

["Brian Rosen" <br at brianrosen.net>]

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.

The number of digits needed to complete a call where the termination domain
chooses the number length is a bigger problem, with a much more difficult
delegation problem.  Essentially it requires something on the order of user
enum, with small groups of numbers delegated to the termination domain.
User enum has not been an unqualified success.  We can manage delegation
down to small units (I have 3 domains I manage, how about you?, but it's
messy, and takes a lot of work, and costs $10 a year in the marketplace.  In
fact it probably works where user enum doesn't because it is a marketplace,
and there is choice of TLDs.  In this case, we really are down to managing a
single root, which implies monopolies, and we get all the problems we have
with user enum.

So, I'd rather come up with a solution to the route-to-the-domain problem,
and come up with a sip solution for the route-to-the-phone problem.

Brian


-----Original Message-----
From: Jay Daley [mailto:jay at nominet.org.uk] 
Sent: Wednesday, April 09, 2008 3:44 AM
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

> So, there is indeed a pretty substantial problem to do something 
sensible
> for a SIP version of this.  The network could complete its processing of 
the
> call as soon as it has sufficient digits to route.  The originating end
> however needs to know how many more digits there will be in order to
> actually send a complete INVITE, and the receiving end can't issue an 
200
> until it has all the digits.

You appear to have narrowed the case to solely the German/Austrian example 
where there is a nationally known prefix and the rest of the digits are 
variable.  This draft is not solely about that but primarily for those 
countries where the prefix length is different for different prefixes (if 
you see what I mean!).

> 2) Have the originating side send an INVITE when it has at least the 
prefix
> number of digits, and then let the receiving end collect DTMF to 
determine
> the rest of the digits using early media.  To get the right user 
experience,
> you can't complete the call until all the required digits are entered.

Assuming you try to apply this to that stated use case of this draft (as 
explained above) then this only works where the SIP URI can be determined 
from insufficient digits.  This is highly unlikely to be the case in user 
ENUM since each provisioned user number will have chosen their own SIP 
termination.  In infrastructure ENUM it might be possible when a carrier 
has not lost any numbers from its block allocation to number porting, but 
those cases will be rare.

This draft addresses the issue of determining where to send the INVITE to, 
so trying to solve this by the way the INVITE process works is 
contradictory.

Jay

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