Re: Send-N draft: draft-bellis-enum-send-n-02 published

Brian Rosen said:
> In your example, the enum client is in a proxy server.  The proxy server is
> trying to route a call.  Your solution is to hit enum with some query (not
> clear to me how you decide when to start trying, since you at least need to
> decode the country code, and may be decoding more than that).  You then get
> back send-n.  That tells you how many digits to get, but it's very likely
> that you will have to repeat it i.e., you start with the country code, you
> get back the minimum number of digits.  You query again, and you probably
> get back the right number.

Perhaps. See below.

> Worst case is you are really dumb and you send a single digit.  You get back
> "send 10" for CC1 or send 1 for nearly every other case.  You then send 2
> digits and then you would get some number of digits for a minimal TN in a 2
> digit country code, or you would get send 1 (for a 3 digit country code).
> For the 3 digit case, you query again with one more digit and you get the
> minimum number of digits (as with the second call in the 2 digit CC).  You
> query again with that number of digits and you either get an answer or some
> more send-n.  This continues, each time you have to query the database.

Yes, modulo cacheing of DNS records.

However, if you're calling a number in Oxford from the US, there will be
four lookups for a 5-digit number (+4, +44, +441865xxx, +441865xxxxx), and
five for a 6-digit number. If you're calling London, Cambridge, or much of
the UK, there will be four lookups.

I actually expect the proxy to have a *very* simple dial plan built in to
it. For the UK, this would be something like:

(1) Same-area call (first digit is 2 to 9): collect N digits, prefix the
local area code, and do a lookup. The value of N will depend on the area
that the proxy is located in, but will be between 4 and 8. In most areas
this will collect the correct number of digits for the call; in some, it
will require another digit or two.

(2) National call (first two digits are 01 to 09): collect N digits,
replace the 0 by +44, and do a lookup. N is either always 8 or is
{9, 11, 11, -, 10, -, 11, 8, 11} based on the second digit. In most cases
this will be the correct length or will give a SEND-N record giving the
correct length; in a few cases it might be necessary to fetch a second
SEND-N record on the way.

(3) International call (first two digits are 00): collect 5 digits (or
possibly more; is there a minimum length for E.164 numbers?). Replace 00 by
+ and do a lookup. How many more fetches are done will depend on the number
plan and database contents for the destination country.

> I claim there is no significant difference between the two solutions for an
> overlapped dialing device.  They get to the same result with about the same
> amount of effort.

Huh? How is 4 lookups "about the same" as 11?

> Probably my solution uses more memory, but so what.  I
> claim that my solution is much better for a non-overlapped dialing device.

I wonder if I'm misunderstanding your solution. Perhaps you can explain it
fully.

> You came here with a problem many of us recognize as a real problem: how
> does any entity know how many digits it takes to get a routable TN?  We
> agree; that's a problem worth solving.

Good.

> You have a solution in mind to that
> problem.  I'm arguing it's not a good solution for everyone with the
> problem.  You seem to agree, but you like your solution for the overlapped
> dialing case.  I'm suggesting that we are better off solving this problem
> for both overlapped and non-overlapped dialing devices using one mechanism.

I'm not clear what the problem is for non-overlapped devices.

-- 
Clive D.W. Feather  | Work:  <[email protected]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email protected]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |