Re: a new RRype instead of send-n NAPTRs

> Mobile devices have been mentioned as where latency matters, but then
> I wonder why overlap dialling would appear with those devices in the
> first place, since we're usually used to press the "green" button on
> handhelds anyway.

Indeed - modern "smart" devices with dial buttons are not expected to be 
the issue - dumb DTMF phones are.

> The figures I've seen so far re: query volume have neither been 
frightening
> nor convincing, so I'd like to re-issue my plea to first agree on the
> size of the problem before designing or even standardizing a solution.

I don't have any absolute volume figures available - call establishment 
volume data is very hard to come by.  Paul Rosbotham may be able to help 
there.

We can however model the relative saving the Send-N might achieve, 
although that in itself is country specific and also depends on how much 
base logic you're prepared to put in your switch.

For +44 we know that a completely naive implementation of overlapped 
dialling without Send-N would do up to 12 lookups (it would be less if 
they got to a part of the tree that didn't exist and hence returned 
NXDOMAIN).

A smart implementation with Send-N for +44 can do just two lookups.  The 
first is done after the first 9 digits, and because of the properties of 
+44 will get either a full NAPTR or a final Send-N.  If that Send-N is 
followed the next lookup will be a full NAPTR or NXDOMAIN.  This is 
because the +44 number length table does not change beyond the 9th digit.

There's probably a middle ground in benefit somewhere between the two, 
because nobody would use the completely naive method.

> What I'd also like to learn during the Dublin discussion is whether 
"send-n"
> is envisioned for private I-ENUM only or also for other applications and
> whether the envisioned scenario (in case of private I-ENUM) would or
> would not involve a "normal" DNS server and resolver 
infrastructure,including
> delegations and caching, that is.

It has its origins in a private I-ENUM scenario, but should multiple 
private I-ENUM trees become interconnected it would have uses too.

The current proposal works with completely "normal" DNS server software 
and infrastructure, including caching.  Delegation (i.e. of blocks to 
carriers) would work, but isn't proposed for the UK database.

I don't personally have any use-cases for public ENUM in mind, but that's 
not to say that there aren't any.  I happened to be talking to a VoIP 
operator yesterday who was saying that using "Address Incomplete" in SIP 
to try and implement overlapped dialling was anything but satisfactory 
because of the massive performance load caused by each new SIP dialog.

Ray