[asterisk-users] better enumlookup handler

[John Todd]

At 10:04 AM -0400 2008/5/7, Brian J. Murrell wrote:
>On Wed, 2008-05-07 at 14:26 +0200, Johansson Olle E wrote:
>>
>>  Quoting RFC 3824:
>>
>>  "Only one SIP URI, ideally, appears in an ENUM record set for a
>>         telephone number.  While it may initially seem attractive to
>>         provide multiple SIP URIs that reach the same user within ENUM, 
>>  if
>>         there are multiple addresses at which a user can be contacted,
>>         considerably greater flexibility is afforded if multiple URIs are
>>         managed by a SIP location service that is identified by a single
>>         record in ENUM.
>
>There are several problems with that.  In my use case, it's toll-free
>handling by separate SIP providers being enumerated (generically -- i.e.
>they return NAPTRs for any 18{00,66,88,etc.}* numbers) for all providers
>registered to handle toll-free) by e164.org.  I'm not sure how feasible
>it is to return a single SIP location service (I take that to mean a SRV
>record) in that situation given that different providers have different
>formats.  See from my previous e-mail, that for a given number, say,
>18668823998 the following two SIP urls can be used:
>
>sip:18668823998 at tollfree.sip-happens.com!" .
>sip:16416418668823998 at sip.tollfreegateway.com!" .
>
>I fail to see how something like that could be coded into a single
>location service record.
>
>Additionally, I'm not even sure multiple SRV records would be any
>better.  Where is the handling of the fact that there is(/are multiple)
>SRV records for a given SIP address done and how does rollover happen
>when one of them returns CONGESTION, say?
>
>>    Behavior for parallel and sequential forking in
>>         SIP, for example, is better managed in SIP than in a set of ENUM
>>         records."
>
>Does this imply that if there are multiple SRV records for a resource,
>say:
>
>$ORIGIN mydomain.com
>_sip._udp 3600 IN SRV 10 0 5060 asterisk1
>_sip._udp 3600 IN SRV 10 0 5060 asterisk2
>
>that Dial(SIP/2001 at mydomain.com) will in fact iterate over the SRV
>records in the case of connection failure of one of them?
>
>If so, I'm not sure how/if e164.org can translate their generic
>toll-free NAPTR mapping into a working SRV service instead.
>
>>  We look forward to source code improvements!
>
>I didn't really intend to bash ENUMLOOKUP() but was simply looking for
>something more robust.  I am sure for the case of single NAPTR records,
>ENUMLOOKUP() is just fine.  Sure I would like it more robust, but other
>solutions exist so I'm willing to exercise them.
>
>Well my understanding is that the enumlookup AGI script that I'm looking
>for does what I want (and would like ENUMLOOKUP() to do) and that's
>return all of the values from a single lookup (i.e. in an array or list)
>rather than calling ENUMLOOKUP() iteratively for however many objects
>exist.
>
>Even the existing single record/iterative behaviour of ENUMLOOKUP()
>would not be so bad if it kept state for each caller and actually did
>return the successive records found from a single lookup rather than
>doing a new lookup every time, possibly getting records in a different
>order than it did last time (which of course results in handing back the
>same record it did last time even though the record number counter has
>been incremented).
>
>Cheers,
>b.


1) The ENUMLOOKUP function is currently being "fixed" for TRUNK. 
Take a look at http://bugs.digium.com/view.php?id=8089 for the 
current status.  Testing would be appreciated.

2) I will generate a dialplan subroutine that will hand back an array 
of SIP URIs for a given number, and I'll post it here and on the 
voip-info.org wiki - that's pretty easy.  I agree that one query 
should result in a static and ordered set of URIs for that particular 
attempt cycle.

3) Your last comment about "keeping state" is difficult to square 
with the intent of NAPTR lookups.  The point is to have dynamic NAPTR 
replies in case the distant system wishes to change the inbound 
behavior towards their systems, so caching that data is almost always 
a Bad Idea for more than a few seconds.  Creating an array of results 
and then having that variable follow the caller through a very short 
timeframe of cascading attempts makes sense to avoid re-ordering 
confusion, but I would say that a completely new lookup to the DNS 
should happen after the interval described by the last-attempted set 
of responses.  In other words, if we get back three SIP URIs from the 
NAPTR lookup, then try each in turn until they all fail.  Each 
failure (depending on how your SIP timers are set) may take 20 
seconds.  Therefore, for that particular user session, don't do 
another DNS query for 60 seconds, which is how long it takes all 
three current URIs time out.

4) SRV records are an entirely different story, and unrelated to 
NAPTR queries, even though it seems they are very similar.  I can't 
say I know precisely how SRV records are currently handled by 
Asterisk, but I suspect they are not "cascaded" as per the RFC in the 
event of failures, or "load-shared" as per the RFC.  Can someone else 
comment on this?  Olle?

5) AGI scripts for DNS lookups: This makes me feel like I need a shower.

JT