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

[Klaus Darilion]

Bogdan-Andrei Iancu schrieb:
> Hi Klaus,
> 
> So, you say that the ENUM module breaks the RFC ? because it is loading 
> the additional records as parallel branches.

order: the enum resolver has to choose the matching NAPTR with the 
lowest order

if there are multiple NAPTRs with the same order, then the resolver may 
choose which one to use (it can use the hints (preference) but it need to).

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.

regards
klaus

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