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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
