[asterisk-users] better enumlookup handler

[Brian J. Murrell]

On Wed, 2008-05-07 at 13:40 -0700, John Todd wrote:
> 
> 1) The ENUMLOOKUP function is currently being "fixed" for TRUNK. 

Ahhh.  Sweet.  I wonder how difficult a backport will be.

> Take a look at http://bugs.digium.com/view.php?id=8089 for the 
> current status.  Testing would be appreciated.

Will do.  I'm afraid I don't have any way to test TRUNK however.  I only
have my production system and taking the phone offline just does not fly
here.  :-(

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

Cool.  But one need not be limited to SIP of course.  IAX2, and even
others depending on what one might want to allow their users to do.
i.e. a mailto could even be used to send a mail with a voice attachment.

> I agree that one query 
> should result in a static and ordered set of URIs for that particular 
> attempt cycle.

Great.

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

Ahhh.  Yes.  I failed to explain that part correctly.  I only meant
caching the data long enough to iterate through a list of ENUMLOOKUP()s
as a single "transaction".  Clearly returning an array makes more sense.
I was just trying to make a suggestion that would appease a desire to
not disturb the API of ENUMLOOKUP().

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

Agreed.

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

Right.  I still like an array of all URIs returned from one lookup
better though.

> 4) SRV records are an entirely different story, and unrelated to 
> NAPTR queries, even though it seems they are very similar.

Yeah, I think the spirit was there in suggesting SRV records, but the
technicalities of this use case make it impossible to use SRV records.

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

Agreed.  But it's the shortest distance between point A and B for a
price.  In my installation I'm willing to pay it.  Other installations
might not.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20080507/33d30ecf/attachment.pgp