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

[Klaus Darilion]

Phil Vandry wrote:
> [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?

The difference is recognizable if you use multiple service types. The 
order is mandatory for the resolver. E.g. you have a client which 
supports H323 and SIP.

There are 2 NAPTRs:
order  preference    service .....
0         10         E2U+sip
10        10         E2U+h323

In this case the client must use SIP to setup the call.

If you have NAPTRs like:
order  preference    service .....
10        20         E2U+sip
10        10         E2U+h323

This means that both NAPTRs are equivalent, but the caller wishes to be 
contacted via h323. NEvertheless the client is also allowed to use SIP.


> 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?

hmmm

> 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.

Yes. 3761 leaves many questions open. Also the support for non-terminal 
NAPTRs makes everything very complicated.


Probably we can't tell of serial/parallel forking based on ENUM NAPTRs 
is against the RFC. Nevertheless, as people use it, the proxy should 
support both methods.

regards
klaus


> 
> 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