Re: [asterisk-users] better enumlookup handler
On Thu, 2008-05-08 at 10:51 -0500, Russell Bryant wrote: Have you taken a look at the ENUMQUERY() and ENUMRESULT() functions that are a part of Asterisk 1.6? The ENUMQUERY() function lets you do a single enum query From a single zone it seems. So that means a for zone in $ZONES type of wrapper around ENUMQUERY/ENUMRESULT which means they have the same limitation that my implementation currently has which is that you get a (I'm assuming) priority ordered set of results for each zone rather than a priority ordered list taken and sorted from all zones. for a number. Then, the ENUMRESULT() function lets you access and iterate through all of the records received from the query. What does ENUMRESULT return? A single URI suitable for use in a Dial command? Are the results in ENUMRESULT() ordered per the NAPTR ordering/priority specification? i.e. so item 1 has the highest NAPTR priority and n-1 the lowest? svn co http://svncommunity.digium.com/svn/russell/asterisk-1.4/ It applies cleanly to 1.4.17, so that is awesome. 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
Re: [asterisk-users] better enumlookup handler
To this end, I have taken a first pass at a Perl AGI script to look up and return a list of URIs for a given phone number. I will not pretend that I have read the relevant RFCs but have implemented based on the knowledge I have gathered about ENUM lookups from various sources. Given my dialplan macro (included as a comment in the AGI script) it seems to work here, including rolling over (in order of preference) to alternate URIs if there is a failure to make a connection on any previous URIs. The code can be found at http://brian.interlinx.bc.ca/enumlookup.agi Constructive criticism appreciated. About the only TODO I can think of right now is to sort by preference of the records gathered from all of the domains searched rather than sorting by order of preference within each domain. Additionally, I could use the search value in the /etc/asterisk/enum.conf file rather than hard coding them into the AGI script I suppose. Cheers, 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
Re: [asterisk-users] better enumlookup handler
Brian J. Murrell wrote: Does anyone have a better ENUM lookup handler than the built-in ENUMLOOKUP() function? The built-in function does not properly handle multiple return values such as: 8.9.9.3.2.8.8.6.6.8.1.e164.org has NAPTR record 200 10 u E2U+SIP !^\\+1866(.*)$!sip:[EMAIL PROTECTED] . 8.9.9.3.2.8.8.6.6.8.1.e164.org has NAPTR record 200 10 u E2U+SIP !^\\+1866(.*)$!sip:[EMAIL PROTECTED] . Have you taken a look at the ENUMQUERY() and ENUMRESULT() functions that are a part of Asterisk 1.6? The ENUMQUERY() function lets you do a single enum query for a number. Then, the ENUMRESULT() function lets you access and iterate through all of the records received from the query. Then, you can use dialplan logic to try each one without having to actually do the lookup over and over ... I have an unsupported 1.4 backport of these functions available. svn co http://svncommunity.digium.com/svn/russell/asterisk-1.4/ -- Russell Bryant Senior Software Engineer Open Source Team Lead Digium, Inc. ___ -- 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
Re: [asterisk-users] better enumlookup handler
On Thu, 2008-05-08 at 10:51 -0500, Russell Bryant wrote: Have you taken a look at the ENUMQUERY() and ENUMRESULT() functions that are a part of Asterisk 1.6? I have not even entertained thinking of 1.6 yet. :-/ The ENUMQUERY() function lets you do a single enum query for a number. Then, the ENUMRESULT() function lets you access and iterate through all of the records received from the query. Then, you can use dialplan logic to try each one without having to actually do the lookup over and over ... Dude! Where were you yesterday, before I spent a few hours last night writing my AGI? :-) I have an unsupported 1.4 backport of these functions available. svn co http://svncommunity.digium.com/svn/russell/asterisk-1.4/ Now that's what I want to hear. Back port. Woohoo! I wonder how hard a backport from your 1.4 to my 1.4.17 will be. I might just have to take a whack at it. :-) Thanx Russell! 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
Re: [asterisk-users] better enumlookup handler
Brian J. Murrell wrote: I have not even entertained thinking of 1.6 yet. :-/ Fair enough. That's why I pointed out the feature. Dude! Where were you yesterday, before I spent a few hours last night writing my AGI? :-) Sorry. I have trouble keeping up with this list. :) Now that's what I want to hear. Back port. Woohoo! I wonder how hard a backport from your 1.4 to my 1.4.17 will be. I might just have to take a whack at it. :-) Thanx Russell! You're quite welcome. It should be as simple as dropping the func_ module into the funcs directory. The Asterisk build system should see it, compile it, and install it as usual. -- Russell Bryant Senior Software Engineer Open Source Team Lead Digium, Inc. ___ -- 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
Re: [asterisk-users] better enumlookup handler
There is a enumlookup.agi that is included with FreePBX and thus trixbox, PBX in a flash, etc. etc. If you have trouble finding it let me know and I can send you it. I can;t really vouch for its quality, but I do use it and it does work... but i;m not sure how well it handles multiple results. I know it will successfully connect to systems that give multiple results, i;m just not sure if it does infact failover if the first one doesn;t work. -- Matt From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Brian J. Murrell [EMAIL PROTECTED] Sent: Tuesday, May 06, 2008 10:34 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: [asterisk-users] better enumlookup handler Does anyone have a better ENUM lookup handler than the built-in ENUMLOOKUP() function? The built-in function does not properly handle multiple return values such as: 8.9.9.3.2.8.8.6.6.8.1.e164.org has NAPTR record 200 10 u E2U+SIP !^\\+1866(.*)$!sip:[EMAIL PROTECTED] . 8.9.9.3.2.8.8.6.6.8.1.e164.org has NAPTR record 200 10 u E2U+SIP !^\\+1866(.*)$!sip:[EMAIL PROTECTED] . And thus does not handle roll-over should one be unavailable for whatever reason. There is this voip-info.org wiki page: http://www.voip-info.org/tiki-index.php?page=Asterisk+and+multiple+ENUM +entries but the downloads that it's pointing to seem to be dead. Sure I could take to writing an AGI script and probably be done it in a few hours, but why re-invent the wheel? Thanx, b. ___ -- 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
Re: [asterisk-users] better enumlookup handler
7 maj 2008 kl. 04.34 skrev Brian J. Murrell: Does anyone have a better ENUM lookup handler than the built-in ENUMLOOKUP() function? The built-in function does not properly handle multiple return values such as: 8.9.9.3.2.8.8.6.6.8.1.e164.org has NAPTR record 200 10 u E2U+SIP !^\\+1866(.*)$!sip:[EMAIL PROTECTED] . 8.9.9.3.2.8.8.6.6.8.1.e164.org has NAPTR record 200 10 u E2U+SIP !^\\+1866(.*)$!sip:[EMAIL PROTECTED] . And thus does not handle roll-over should one be unavailable for whatever reason. 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. Behavior for parallel and sequential forking in SIP, for example, is better managed in SIP than in a set of ENUM records. There's a long section later on in this RFC about how to make it work if you still want to have multiple SIP records... We look forward to source code improvements! /O ___ -- 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
Re: [asterisk-users] better enumlookup handler
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:[EMAIL PROTECTED] .
sip:[EMAIL PROTECTED] .
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/[EMAIL PROTECTED]) 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.
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
Re: [asterisk-users] better enumlookup handler
On Wed, 2008-05-07 at 08:21 -0400, Matt Watson wrote: There is a enumlookup.agi that is included with FreePBX and thus trixbox, PBX in a flash, etc. etc. Yeah, I had gotten that impression somewhere too. If you have trouble finding it let me know and I can send you it. If you would be so kind, I will take you up on this offer. Saves me from having to download the whole FreePBX/trixbox, etc. just to get the one script. I wonder if the asterisk project would consider hosting that script as a contrib in the distribution. I can;t really vouch for its quality, I guess a code audit will tell. :-) Although I got an impression that it was written in PHP. I'm not much of a fan of PHP. Don't really see the point for something so simple. Bash, Perl (without the overhead of PHP) or even an executable-from-C seems more appropriate for something as relatively simple. Maybe I should also take up Johansson's suggestion and fix ENUMLOOKUP. :-) but I do use it and it does work... but i;m not sure how well it handles multiple results. I will test/audit for that specifically. Thanx! 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
Re: [asterisk-users] better enumlookup handler
Slightly off-topic: On Wed, May 07, 2008 at 10:29:47AM -0400, Brian J. Murrell wrote: I guess a code audit will tell. :-) Although I got an impression that it was written in PHP. I'm not much of a fan of PHP. Don't really see the point for something so simple. Bash, Perl (without the overhead of PHP) or even an executable-from-C seems more appropriate for something as relatively simple. Shell scripts are often very inefficient with respect to execution time. They often use subprocesses and other programs for relatively simple tasks. While running a simple bash (or better: dash) is faster than running perl or php, running a modestly complex shell script is often slower than running the same thing with perl. The shell has also relatively poor handling of bad input. If someone can sneak in '`' or such in the wrong place at the input, the results can sometimes be, well, interesting. -- Tzafrir Cohen icq#16849755 jabber:[EMAIL PROTECTED] +972-50-7952406 mailto:[EMAIL PROTECTED] http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir ___ -- 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
Re: [asterisk-users] better enumlookup handler
On Wed, 2008-05-07 at 22:54 +0300, Tzafrir Cohen wrote: Slightly off-topic: Yeah. On Wed, May 07, 2008 at 10:29:47AM -0400, Brian J. Murrell wrote: I guess a code audit will tell. :-) Although I got an impression that it was written in PHP. I'm not much of a fan of PHP. Don't really see the point for something so simple. Bash, Perl (without the overhead of PHP) or even an executable-from-C seems more appropriate for something as relatively simple. Shell scripts are often very inefficient with respect to execution time. Indeed. They often use subprocesses and other programs for relatively simple tasks. Agreed. While running a simple bash (or better: dash) is faster than running perl or php, running a modestly complex shell script is often slower than running the same thing with perl. Right. Execve() and library loading and so forth. Understood completely. All of that is why I did mention executable-from-C though. :-) 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
Re: [asterisk-users] better enumlookup handler
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:[EMAIL PROTECTED] .
sip:[EMAIL PROTECTED] .
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/[EMAIL PROTECTED]) 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
Re: [asterisk-users] better enumlookup handler
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
