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

[Bogdan-Andrei Iancu]

Hi Klaus,

So, you say that the ENUM module breaks the RFC ? because it is loading 
the additional records as parallel branches.

Regards,
Bogdan

Klaus Darilion wrote:
> 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
>>     
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
>