As tempting as it is to join the cries of "imminent death of the PSTN
predicted," I wanted to drill down at some length into Ray's question on send-n
and some of Rich's comments.
Regarding send-n, the argument made by the dns-applications draft today is that
the synchronization required to coordinate different levels in the DNS tree
with the state of resources in the telephone network creates a fundamental
brittleness in this architecture. It is presented in those terms to try to
abstract out the architecture principle rather than staying strictly within the
particulars of the send-n proposal, since the guidance on that subject did seem
generalizable to proposals other than send-n. It is not intended to be a sole
and decisive refutation of the send-n proposal. Certainly we don't want to
"just say no" to the overlap dialing problem space, but it does hope to
encourage thinking about alternate ways of satisfying the send-n requirements
that don't suffer from this problem. When importing this overlap dialing from
the PSTN to the Internet, we have a number of architectural alternatives we can
explore to mirror this functionality which may or may not map directly onto the
processes of the PSTN. It is, as the dns-applications draft says, unclear why
DNS is necessarily the best of them.
I agree that the distributed and hierarchical nature of the DNS makes it
potentially applicable to overlap dialing, since it does allow you to traverse
a tree which can ultimately delegate to the entity that sets the length of a
telephone number. What you don't mention here, however, is that there are a
number of fundamentally different approaches to overlap dialing. Many native
VoIP handsets, much like mobile phones, do not provide a "dial tone" experience
but instead wait for a user to press a "send" or "call" button before
attempting to reach a number. For those entities that do get numbers piecemeal
(like ATAs, or VoIP gateways receiving a possibly incomplete IAM from the
PSTN), I understand some implementations have a collection timer that waits
until the stream of digits has concluded before attempting to reach a number.
However, if we assume that the delay incurred by that timer is intolerable,
we're then left with the problem that these ATA-like VoIP endpoint won't know
that an address is complete until they've tried to place a call or sent an ENUM
query that may fail. An ATA that supports ENUM might therefore make several
queries, some which will be unsuccessful, before it collects all the digits and
makes a query that returns a useful response. The motivation of send-n is to
reduce the number of those ENUM queries. It proposes an optimization, and one
that is scoped to a particular segment of the PSTN that supports overlap
dialing, and furthermore to those use cases like dial-tone simulation or
certain gatewaying architectures where timers or "send" buttons don't address
the problems. In those cases, it prevents DNS servers from enduring the load of
some of these futile queries by piggybacking onto preliminary ENUM responses a
minimum number or digits that must be collected before launching a query. As an
optimization, that reduction in queries has a certain architectural value, but
we do need to assess that value objectively - I'd say it is a bit much to
construe skipping those queries in those cases as an "essential function in the
transition from analog POTS to SIP based communication." Supporting overlap is
essential - optimization is nice.
If we grant that this problem of futile queries is onerous enough to require
optimization, the question then becomes whether the optimal way for one of
these endpoints to learn the minimum number of digits is by asking the DNS a la
ENUM, in real-time as the endpoint is setting up a call. Is there a way
endpoints could acquire a picture of the numbering plan not in real-time during
call set-up, but through some prior procedure like periodically querying for
(or subscribing to) a picture of the dialing plan when the endpoint is idle;
i.e. If it is possible to reduce even further the number of queries that need
to be made in real-time while an endpoint is setting up a call? What about
endpoints that don't use ENUM - would they also care about that minimum number
of digits (say, when an endpoint just dumps a call to a PSTN gateway for want
of ENUM), and if so would it make sense to make this information available
outside of ENUM? And finally, is the stated functionality really a good fit for
the DNS? How do entities that have been delegated numbers get the permission to
provision records (for "partial" numbers) outside of their zone of authority?
Do the records require synthesis? What happens when you try to resolve a
partial number that might in fact be a prefix for blocks of numbers in distinct
administrative domains? Are there any analogous cases like this for ordinary
domain name resolution (maybe Google autocomplete will be the overlap dialing
of the future...)?
I wouldn't say that the message of the dns-applications draft is "do not
charter E2MD," in so far as it does not reject the problem space. It does try
to capture arguments that had previously only been presented anecdotally, and
it moreover intends in the future to capture the ongoing discussions we've now
begun about these subjects. I do however maintain that the previous E2MD chater
is a collection of problems that have different underlying requirements, and
that bringing them under a common architectural umbrella may obscure their
individual problem spaces rather than illuminating them. Also, the insistence
of the charter on DNS-based solutions, as opposed to solutions that might not
involve the DNS, seemed unnecessarily confining, for send-n and other
mechanisms under consideration.
Jon Peterson
NeuStar, Inc.
On 10/20/10 3:25 PM, "Richard Shockey" <richard(_at_)shockey(_dot_)us> wrote:
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.
RS> Precisely, What is unclear is why the IETF and the IAB is suddenly
trying to block a perfectly legitimate extension of RFC 3761 that is in
various forms of global deployment, proven to work, scale and more
importantly provides a valuable and essential function in the transition
from analog POTS to SIP based communication.
Just saying no is not a solution to the real issues of number translation in
carrier networks.
Ok a lot of people hate phone numbers including, it seems, 50% of RAI
directorate but they are not going away anytime soon.
So just say it .. is this the message? Don't even try to charter E2MD?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf