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

[Klaus Darilion]

Hi!

Yes, ENUM does not define the concept of serial/parallel forking. 
According to the RFC you are only allowed to use a single NAPTR.

But I think you can make the standard behavior by dropping all branches 
except the current RURI.

klaus


Phil Vandry schrieb:
> Hello,
> 
> I noticed that when the enum_query() function received more than one
> result from DNS, it appends branches and sets the q-value for each
> branch based on the order and preference values from the DNS result.
> But I do not think that the way it does this is correct.
> 
> EXISTING BEHAVIOUR:
> 
> Basically, it does the equivalent of sorting the records first by order
> and then by preference, and assigning q-values in decreasing order with
> DNS records having identical order&preference receiving identical q.
> 
> If you combine enum_query() with serialize_branches(), the effect is
> that the DNS results are tried in order of order&preference and results
> with identical order&preference use parallel forking.
> 
> CORRECT BEHAVIOUR (RFC 2915):
> 
> The DNS results must be considered in order of NAPTR "order". Once a
> result is found whose rule "matches" the target, the client MUST NOT
> consider any NAPTRs with a higher value for order. In order words,
> once we find a record of the correct form with the service we want and
> the flags we expect, all lesser-order records are discarded, *not*
> added as later branches.
> 
> Next, for records with identical preference, the records must be chosen
> in round-robin fashion (load balancing between them). ENUM does not
> provide any mechanism for parallel forking.
> 
> I have a patch that changes the behaviour of the enum module to be
> compliant to the standard but obviously it will break any script that
> relies on the current behaviour. What solution would you suggest? Does
> anybody depend on the current behaviour?
> 
> -Phil
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel