Opened 12 years ago

Closed 10 years ago

#16 closed defect (fixed)

Section 4.2

Reported by: Ray.Bellis@… Owned by: jon.peterson@…
Priority: major Milestone: milestone1
Component: draft-iab-dns-applications Version: 1.0
Severity: Active WG Document Keywords:
Cc: ray.bellis@…

Description (last modified by bernard_aboba@…)

From: Ray Bellis Ray.Bellis@…
Sent: Wednesday, October 20, 2010 3:28 AM
Cc: ietf@…
Subject: draft-iab-dns-applications - clarification re: Send-N


Re: §4.2 of your IAB Draft draft-iab-dns-applications-00:


Send-N is not only intended for open number plans, it's intended for use in _any_ plan with variable length telephone numbers. It came out of the proposed specifications for the UK local number portability database, where E.164 numbers vary from 8 to 12 digits in length.

A typical application for Send-N might be where an analogue phone is attached to a CP-managed SIP ATA - this will be a common setup in "Next Generation Networks".

It is a solution to the problem of gatewaying between the 100s of millions of dumb handsets that use overlapped dialling[*] and the SIP world where overlapped dialling is not currently feasible. As an analogue phone has no "dial" button the ATA must listen for DTMF digits, and somehow figure out for itself when the user has finished dialling before initiating the SIP call over the ATA's SIP trunk.

A common (but unreliable) method is to use inter-digit timeouts, but the end user experience is poor - it might take the ATA a few seconds to start the SIP session after the last digit is dialled. Assuming that the ATA doesn't do ENUM dips itself, the existing alternative would be for the ATA to establish a brand new SIP session after each digit is dialled, receiving a "484 Address Incomplete" error from the CP switch until the number is complete.

With Send-N metadata available, the definition of the SIP "484 Address Incomplete" could be extended to return the Send-N data so that an ATA can benefit from this information and omit unnecessary SIP session establishments.

Regarding this sentence:

"Maintaining that synchronization, however, requires that the

DNS have semi-real time updates that may conflict with scale
and caching mechanisms."

As Jon pointed out during the ENUM session at Maastricht there is indeed a need to synchronise the metadata with the underlying data. However number plans are not generally prone to sudden unexpected changes. In any event with Send-N the only identified synchronisation issue is when a Send-N record indicates that _more_ digits are required than is actually the case. Since it is very rare (if not unheard of) for number blocks to get smaller I don't consider this a significant risk.

The assertion therefore appears to be unjustified.

And finally, regarding:

"It is unclear why this data is better maintained by the DNS

than in an unrelated application protocol."

If a device is performing an ENUM dip hoping to find a contactable SIP URI, it is simply most efficient for the ENUM response to directly include the Send-N metadata when needed rather than have separate queries using a different network protocol. Also, the hierarchical and distributed nature of the DNS protocol makes it an _ideal_ structural fit for this meta data.

I believe the onus should be on your draft to explicitly identify valid technical reasons why the DNS protocol should _not_ be used, rather than make vague hand-waving assertions which appear to have little or no justification.

kind regards,


[*] the draft misdescribes overlapped dialling - it's the practise of sending digits to the network as they're received rather than "en bloc" at the end of dialling. It's what analogue phones do, and is completely separate from "open number plans".

Change History (5)

comment:1 Changed 12 years ago by bernard_aboba@…

  • Component changed from dns-applications to draft-iab-dns-applications
  • Description modified (diff)

comment:2 Changed 12 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from new to closed

replied to this on ietf main at some length, see

also discussed with the author of the comments and other interested parties. discussion of the issue on ietf main was fairly unfocused. adding some text to further emphasize that send-n presents an optimization, and the value of that optimization must be weighed against alternative approaches, per the response mail cited above. Adding text.

ray is also correct that the current text describes overlap dialing as a "variable-length numbering plan" rather than a practice for dialing in the presence of same; will fix that

comment:3 Changed 11 years ago by ray.bellis@…

  • Cc ray.bellis@… added
  • Resolution fixed deleted
  • Status changed from closed to reopened

"overlap" dialing, a practice which compensates for variable-length numbering plans.

Actually I believe it's a hangover from physical telephone exchanges where paths through the telephone network were established as each digit was (pulse) dialled. As written the text suggests that overlap dialling only exists because of variable-length numbering plans, and I believe that to be incorrect.

as only the terminating customer premise equipment (typically a private branch exchange) knows how long a telephone number needs to be.

No, that's still describing an open numbering plan (i.e. as they have in DE and AT) and not a generic "variable-length" numbering plan where the numbering plan is a network level plan (e.g. as we have here in the UK where the numbering plan is managed by OFCOM).

The "send-n" proposal offloads to the DNS the responsibility for informing the telephone switch

"Responsibility" is too strong a word here - it's a hint, and the system continues to work without it.

As an optimization, this practice thus saves the resources of the DNS server

And the SIP servers, which can avoid creating new SIP dialogs for each and every dialled digit.

though it does not result in faster call set-up, as the call cannot complete until all digits are collected

For end-user devices without a 'dial now' button (i.e. most POTS phones) this is incorrect - overlapped dialling can place the call _immediately_ the last valid digit is dialled, without waiting for the typical 2 - 4 seconds interdigit timeout to elapse.

Maintaining that synchronization, however, requires that the DNS have semi-real time updates that may conflict with scale and caching mechanisms

Which DNS? My draft was primarily targeted at private ENUM-like trees where synchronisation can be tightly controlled. It does not require any changes to the DNS protocol.

in send-n, different leaf zones might want to populate different information in a common parent


An application protocol designer who wants to manage identifiers in this fashion would be better served to implement this mechanism outside the DNS.

Why? The preceding paragraphs in this section IMHO provide exactly zero sound technical reasons why that would be the case.

comment:4 Changed 11 years ago by jon.peterson@…

Thanks for the comments.

To your first three points, I've fixed the text describing variable length numbering plans a bit, hopefully to your satisfaction. Traded "responsibility" for "hint," with some rephrasing. I'm not sure so sure about this saving the cycles of the SIP server - what is the request-URI of the dialog the SIP server would create if an ENUM lookup failed, exactly? I'll rephrase the bit about post-dial delay.

For the meat of it, however, the changes are pretty big. Mostly, I moved the metadata discussion under the "administrative structures misaligned with the DNS" section. I've tried to amplify a bit that the issues with send-n/void are largely about getting the DNS to operate on partial or unassigned names. You probably won't be happy to hear I compare this to Sitefinder at one point. The core points here are that although metadata doesn't change resolver behavior - neither send-n nor unused is a technical problem is that sense - it does change how an application interacts with resolvers, and what the zone administrators needs to provision in the DNS to support that change. It is really that last point that makes this a question about "administrative structures." I did expand a bit about the question of how far up the tree a hint needs to appear for it to optimize (which is what I was trying to get at where you say "huh?" above).

I'll try to rephrase the conclusion into something that sounds more like it follows from the preceding.

comment:5 Changed 10 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from reopened to closed

This was fixed back in -02, and while I know that the send-n draft is no longer being advanced, I think the guidance here is currently pretty generic, and captures the points above.

Note: See TracTickets for help on using tickets.