Subject: Re: [drinks] Comment on the NAPTR question

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 13 Aug 2009 15:56:42 -0400

See responses inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Otmar Lendl
Sent: Monday, July 27, 2009 11:13 AM
To: [email-masked]
Subject: [drinks] Comment on the NAPTR question

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.

KJC> Agree, I think.  NAPTRs are well suited to give LUF responses, depending on how one described the role of the LUF.  Given that the LUF will return "ownership/responsibleParty" data for a given lookup key (e.g. a TN), NAPTRs can hold that in the form of a URI whose domain name portion dictates the current "owner/responsibleParty".  However, the phrasing in speermint arch draft does not quite read this way.  It describes the LUF as returning a domain name, while others in the WG meetings have described it as returning a URI.  The latter seems to be more accurate and more amenable to NAPTRs.  And this seems to just be a wording problem with the architecture draft rather than a structural problem.

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.

KJC>  The key part of this question is of course "independently of any actual call".  On the surface at least the answer seems to be "Yes".  However, at least two caveats are necessary.  (1) The "NAPTR" data referred to above that holds some portion of the SED data necessary to complete the call may need to be supplemented with additional SED data derived locally by other means.  So if the receptacle for sending SED data is NAPTRs then those NAPTRs *may* have to be locally "massaged" to complete that specific call. (2) The case of source based routing needs to be recognized here.  If the source of each individual call can impact the routing decision, wich it certainly can, then the "source identifiers" associated with any given RouteGroup must also be sent down.  And the granularity to which source based routing must be supported (caller's domain name, callers TN Prefix, queriers IP address, etc) will impact the amount of data sent down.

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.

KJC> Good Point.  Your "background" draft from last October also described this.  However, this assumes that SSPs are willing to make routing queries to services residing *outside* their local network, incurring the resulting propagation delay.  This is not always acceptable.

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

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.

KJC>  Agree that a better data structure could be devised to hold and to communicate SED than NAPTRs.

/ol
--
// Otmar Lendl <[email-masked]>, 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
_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.