[drinks] Comment on the NAPTR question

[Otmar Lendl <lendl at nic.at>]

This is too long to be asked on the Jabber channel, but let me
bring it up here:

The question was whether we can capture all information needed
in NAPTR records.

I think that is definitetly the case for the Number->DestinationGroup
mapping.

Stupid Question: Would it be possible to have the Registry push the
relevant DestinationGroup/RouteGroup/NAPTR data to its customer's SIP
devices independently of any actual call? This is basically a routing
table dump. This is the merged with local internal routing data to
build the local data structures needed to generate full SED (internal
routing to get to the egress element, next external hop, SIP parameters,
security parameters, ...) based on a DestGroup as input.

Only the TN/PI -> DestGroup mapping is done by a live, on-demand query
to the Registry (or a locally cached copy). This is the only time when
we actually need to transmit NAPTRs on the wire between the registry and
the querying party.

-------------

What I'm fearing is that we try to use ENUM/NAPTRs as a SIP-Proxy
control protocol. It was never designed for that. It can be coaxed to
support simple scenarions. More complexity can be supported in the answers
(the ugly: URI mentioned today), but it ENUM just can't support complextity
in the quesion. See 
http://tools.ietf.org/html/draft-lendl-speermint-background-02#section-6.2
for a more verbose explanation.

All the latest perversions suggested as feature for ENUM (source-dependent
lookups, Trunk-groups) stem from this mistake.

/ol
-- 
// Otmar Lendl <lendl at nic.at>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg