[Asterisk-Dev] ENUM multiple records handling

[Conroy, Lawrence (SMTP)]

Hi Klaus, folks,

I beg to differ.

Your SIP proxy is no damn good if one of the NAPTRs is voice:X-iax2
(or voice:X-skype :), so it's a dangerous to assume that SIP is the
answer, now what was the question? In particular, I *strongly*
disagree with the argument that one should only having a single entry
in ENUM; this is poor advice.

Check out +878108781087810 for example (I'll let you argue with him :).

Some history:
----
The restriction - returning a single entry for each ENUM query - was
inserted by the SIP cult at the IETF, in conjunction with the guy who
specified DDDS in RFCs 3401, 2, 3, and 4, and told readers they need
to understand all of these documents before they can understand any
one of them - True but not useful for folk who don't come from Mars.

The sophistic answer is that the caller has a policy that is considered,
as well as the callee's policy (as specified by the order/priority 
values).
Thus if the caller's policy is that they won't handle the best priority
entry, then a single entry is returned, with the "next best". Repeat 
until
someone answers or you run out of NAPTRs that the ENUM client machine 
can
handle. Looks like a perfectly valid caller policy to me.

However, that was in the IETF - This is the real world.

(Hence, that "not the correct handling" comment is beginning to make
  me wonder if you too go off into a room with the rest of the members
  for a session of chanting "Skype is evil, H.323 is bad" :)p
----

Seriously:
It is perfectly possible to do exactly what has been proposed; send a
sequence of queries, returning the "next best" each time. This is caller
logic, in the same way that the listed contacts (and their 
order/priority)
is callee logic. Both count, as otherwise we'd be forced to place a call
to a premium rate number if that was order 1, priority 1 in an ENUM 
zone.

Strictly, ENUM isn't supporting logic - the application that requests 
the
ENUM queries is supporting it - but the application needs hooks that it
can use "to specify its policy".

But:
There are some genuine issues here that folk should consider.
[Full disclosure here - ages ago, I did a prototype ENUM.c replacement
for internal testing that did just this, only it stored all of the 
entries
in a single "super-string" that was converted into an * variable for 
further
extension processing "outside" the single Enumlookup query]

(i)   Sorting on order/priority is A Good Thing - most DNS servers 
return
       NAPTRs in a random order in the response, so the ENUM client ** 
MUST **
       at least sort them.
       Dropping the first N entries (where N goes from 0 upwards) is a 
perfectly
       valid thing, BUT beware  - the data may become stale - see also 
(iii).

(ii)  The timers are waaayyyyy toooo loooong at 15/45 Minutes - you 
would
       be better setting them at a couple of minutes or so. Remember, 
the DNS
       data may have changed in the interim, and you will hold "stale" 
processed
       data in the linked list. Strictly, you could argue that once the 
call has
       finally been set up successfully, the linked list can be cleared 
then.

(iii) Should you do one ENUM query and store the state in a linked 
list, or
       instead do a set of ENUM queries, keeping only a "skip the best N 
entries"
       counter (decrementing that each time you call Enumlookup)?
       Strictly, the latter is closer to the RFC-friendly approach, as 
the
       counter is processed "outside" the Enumlookup call, so it's not 
part of
       the ENUM logic itself.

       If the NAPTRs have a TTL of (say) 300 seconds (or more), then 
when your
       client does an ENUM query, the response will be put into the DNS 
cache.
       Until it expires, any subsequent query will come back pretty much
       immediately - it won't go over the 'Net. Hence, subsequent ENUM 
queries
       are very cheap.

       As I said, in my "knock off" version I did exactly the same thing 
as you
       have (i.e. process everything once and don't re-query), but since 
then our
       testing has shown that this may not be a good plan if folk change 
their
       ENUM data often.

(iv)  For Asterisk, there's also the little issue that you may support 
outcalls
       using IAX2, H323, SIP, PSTN, or any combination of these. You 
need to know
       what channel types you support, as the NAPTRs are no use if your 
machine
       can't handle them. Enumlookup might as well dump them rather than 
return
       something (like, say, web:http) that is just going to get dumped 
by the
       Extension processing.

I really appreciate someone actually doing this in * (and supporting 
it).
Please consider these issues as well - there are some real subtleties
apart from the usual religious arguments.

all the best,
   Lawrence

On 10 Feb 2005, at 22:19, Klaus Darilion wrote:
> 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.
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>

-- 

Visit our website at www.roke.co.uk

Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.

The information contained in this e-mail and any attachments is proprietary to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.