[OpenSIPS-Devel] ENUM lookups, q-value, and serialize_branches()

[Phil Vandry]

[For e164.org-discuss: email thread about OpenSIPS's
 interpretation of the NAPTR RFC for ENUM, how you should
 handle order&preference and whether you should consider just
 one record or several when they have the same order. Your
 comments are welcome. See below.]

On Fri, Oct 17, 2008 at 10:07:02AM +0200, Klaus Darilion wrote:
> According to the RFC you are only allowed to use a single NAPTR.

Hi Klaus, thank you for your feedback.

I thought you could use additional NAPTR records for failover in
case the first one failed (serial forking) as long as you never
move up to the next "order" value. But I reread section 4 of the
RFC and I think you are correct.

Yet I think the standard contradicts itself:

According to section 4 there is no difference between order and
preference except that order is more significant than preference:
you retrieve, discard what you do not understand, sort, and take
only the first match. But then what's the point of having both an
order and preference field if they do the same thing?

In section 2 where the meaning of Order and Preference are
defined it says you "MAY process records with the same Order
but different Preferences". So you MAY process more than one
record as long as it is all within the same Order?

The same section also says "A client MAY look at records with
higher preference values if it has a good reason to do so such as
not understanding the preferred protocol or service" and they seem
to suggest with this comment that you MAY do that for Preference
but never for Order. Actually, if you follow the algorithm in section
4 "those [records] with unknown Flags or inappropriate Services are
discarded" before you even sort them so if you do not understand
the preferred protocol or service you will always consider the
next records regardless of order or preference.

So I am just not sure anymore! I don't see much help from RFC 3761
either.

On Fri, Oct 17, 2008 at 12:49:05PM +0200, Klaus Darilion wrote:
> Thus, the standard does not talk about parallel forking, just use one of 
> the NAPTRs. Thus, I am not sure it doing parallel forking is greaking 
> the RFC or just something which is not covered int he RFC.

My first config that used enum_query() followed by serialize_branches()
got me into trouble because of unexpected parallel forking. Here is an
example of the issue which is found in a public ENUM database:

;; QUESTION SECTION:
;2.2.2.2.2.2.2.7.7.8.1.e164.org.        IN      NAPTR

;; ANSWER SECTION:
2.2.2.2.2.2.2.7.7.8.1.e164.org. 60 IN   NAPTR   200 10 "u" "E2U+SIP" "!^\\+1877(.*)$!sip:1877\\1 at tollfree.sip-happens.com!" .
2.2.2.2.2.2.2.7.7.8.1.e164.org. 60 IN   NAPTR   200 10 "u" "E2U+SIP" "!^\\+1877(.*)$!sip:1877\\1 at tf.voipmich.com!" .
2.2.2.2.2.2.2.7.7.8.1.e164.org. 60 IN   NAPTR   200 10 "u" "E2U+SIP" "!^\\+1877(.*)$!sip:1641641877\\1 at sip.tollfreegateway.com!" .

All those records have identical order and preference so they would fork
in parallel. The URIs point to three different toll-free VoIP-to-PSTN
gateways. So the called party gets three calls coming in at the same
time. Obviously that's wrong and the e164.org folks didn't mean for
it to happen like that. I guess they just expect you to choose one
and either discard the others or try them serially after if the chosen
one fails.

I have copied e164.org's mailing list to see if they have any comment on
how they expect their database to be used.

-Phil