[Users] NEW FEATURE: NAPTR lookup

[Bogdan-Andrei Iancu]

Greg,

this is the happy case where parallel forking is involved. The serial 
forking works by keeping in AVPs the next uris to be tried (in case of 
negative replies). But the AVPs are per transaction and you cannot say 
on which specific branch to be used (in case of parallel forking).

Also, from performance reasons, the best approach will be to try to 
perform the sequential queries only if the previous tried failed...

I will try to put tougher a plan about how to have failover in the resolver.

regards and nice weekend to you also,
bogdan


Greg Fausak wrote:

> Bogdan,
>
> Thanks for the reply.
>
> Will this work:
>
> here are some examples of how to uses this new functionality:
>     1) enum doing serial forking:
>        {
>           .....
>           enum_query("e164.arpa.","voice");
>           serialize_branches(1);
>           if (!next_branches()) {
>               sl_send_reply(...no enum found...);
>               exit;
>           }
>           t_on_failure("1");
>           t_relay();
>        }
>
>        failure_route[1] {
>           if (next_branches()) {
>               t_relay();
>           }
>        }
>
>
> I haven't tried it yet.  But I think it is an example
> of serial forking using naptrs.
>
> Have a great weekend!
>
> ---greg
>
> On Feb 4, 2006, at 4:01 AM, Bogdan-Andrei Iancu wrote:
>
>> Hi Greg,
>>
>> at the moment there is no retry support for neither NAPTR nor SRV.  
>> The resolver loops through all NAPTR/SRV records and looks for the  
>> first NAPTR|SRV|A pair of records that can be successfully resolved  
>> to IP address.
>>
>> The biggest problem with having retry support for the resolve is  the 
>> combination between parallel and serial forking. Lets supposed  the 
>> following scenario:
>>    uriA parallel forks to uriX and uriY
>>    both uriX and uriY leads to distinctive sets of NAPTR/SRV records.
>>
>> in such a case, even if it's a single transaction, you have to keep  
>> the state of the resolver for each branch to be able to do serial  
>> forking independently on each of them.
>>
>> Another problem is detecting the failures. According to "4.3  Details 
>> of RFC 2782 Process" specifies usage on ICMP for UDP  failures...and 
>> ICMP support is not reliable (depends on OS) and  tricky to implement.
>>
>> Do not get me wrong, I am not saying it's impossible, but it will  
>> take some time to get to it... :)
>>
>> regards,
>> Bogdan
>>
>>
>> Greg Fausak wrote:
>>
>>> Bogdan,
>>>
>>> This is great news!  Thank you!  I've got
>>> a questions about retries.
>>>
>>> I'm curious if retries are built in, or do I employ t_on_failure?
>>> What I mean is...
>>>
>>> How do I get the t_relay() to try subsequent naptrs and/or srvs in  the
>>> event the current one fails?  Is all of that automatic, or do I need
>>> a t_on_failure?
>>>
>>> I think I understand that you skip ones that don't resolve, but,  
>>> what if
>>> they resolve but the transaction times out either on the naptr or  
>>> on the srv?
>>>
>>> Best,
>>>
>>> -g
>>>
>>>
>>>
>>> -- 
>>> Greg Fausak
>>> greg at thursday.com
>>>
>>
>