[Asterisk-Dev] ENUM multiple records handling

[Klaus Darilion]

Hi Edwin!

Edwin Groothuis wrote:
  > I have changed asterisk/enum.c a little bit and it now supports
> multiple NAPTR records and takes the order and preference into
> account. It works as follows: The first time EnumLookup() is called,
> it loads all NAPTR records in a linked list and returns the first
> entry (order and preference wise). Every next call to EnumLookup()
> returns the next one (order and preference wise).
> 
> How long does this linked list exist? Each element in the list has
> the PID of the thread which asked for the lookup first and it has
> a timer and after 15 minutes they get cleaned up. Is 15 minutes a
> lot? Yes/No. Yes because if you do a lot of lookups, it can grow a
> bit. No because you have to take timeouts into account, so if you
> have four phone numbers in it, you need a timeout of say 4x45 seconds
> which already makes 3 minutes. I can probably set it to 5 minutes
> or so, it just has to be determined later.

If I understand correctly, you are implementing serial forking (hunt 
group) using multiple NAPTRs with different preference/order. AFAIK this 
is not the correct handling proposed in RFC 3761 - usually you only take 
the matching NAPTR with best preference/order. Services like serial 
forking should be done in the SIP proxy.

By putting the various destinations into ENUM, serial forking only works 
if the caller uses asterisk as ENUM client and the proper extensions.conf.

ENUM was not desigend to implicit a service logic - how will you know 
that having several matching NAPTRs means "serial forking"?

Conclusion: It might be dangerous to implicit a service logic by using 
serveral NAPTRs.

regards,
klaus

PS: Nevertheless, interpreting the preference/order is a good thing! 
Thanks for your patch.