VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
mwatson at becon.org
Guest
|
 Posted: Wed May 07, 2008 7:21 am Post subject: [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: asterisk-users-bounces at lists.digium.com [asterisk-users-bounces at lists.digium.com] On Behalf Of Brian J. Murrell [brian at interlinx.bc.ca]
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:1866\\1 at tollfree.sip-happens.com!" .
8.9.9.3.2.8.8.6.6.8.1.e164.org has NAPTR record 200 10 "u" "E2U+SIP" "!^\\+1866(.*)$!sip:1641641866\\1 at sip.tollfreegateway.com!" .
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. |
|
| Back to top |
|
 |
oej at edvina.net
Guest
|
| Posted: Wed May 07, 2008 7:26 am Post subject: [asterisk-users] better enumlookup handler |
|
|
7 maj 2008 kl. 04.34 skrev Brian J. Murrell:
| Quote: | 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:1866\\1 at tollfree.sip-happens.com!" .
8.9.9.3.2.8.8.6.6.8.1.e164.org has NAPTR record 200 10 "u" "E2U+SIP"
"!^\\+1866(.*)$!sip:1641641866\\1 at sip.tollfreegateway.com!" .
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 |
|
| Back to top |
|
|
tzafrir.cohen at xorco...
Guest
|
| Posted: Wed May 07, 2008 2:54 pm Post subject: [asterisk-users] better enumlookup handler |
|
|
Slightly off-topic:
On Wed, May 07, 2008 at 10:29:47AM -0400, Brian J. Murrell wrote:
| Quote: | 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:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir |
|
| Back to top |
|
|
jtodd at loligo.com
Guest
|
| Posted: Wed May 07, 2008 3:40 pm Post subject: [asterisk-users] better enumlookup handler |
|
|
At 10:04 AM -0400 2008/5/7, Brian J. Murrell wrote:
| Quote: | On Wed, 2008-05-07 at 14:26 +0200, Johansson Olle E wrote:
| Quote: |
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?
| Quote: | 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.
| Quote: | 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 |
|
| Back to top |
|
|
russell at digium.com
Guest
|
| Posted: Thu May 08, 2008 10:51 am Post subject: [asterisk-users] better enumlookup handler |
|
|
Brian J. Murrell wrote:
| Quote: | 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:1866\\1 at tollfree.sip-happens.com!" .
8.9.9.3.2.8.8.6.6.8.1.e164.org has NAPTR record 200 10 "u" "E2U+SIP" "!^\\+1866(.*)$!sip:1641641866\\1 at sip.tollfreegateway.com!" .
|
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. |
|
| Back to top |
|
|
russell at digium.com
Guest
|
| Posted: Thu May 08, 2008 12:18 pm Post subject: [asterisk-users] better enumlookup handler |
|
|
Brian J. Murrell wrote:
| Quote: | I have not even entertained thinking of 1.6 yet. :-/
|
Fair enough. That's why I pointed out the feature.
| Quote: | 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.
| Quote: | 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. |
|
| Back to top |
|
|
brian at interlinx.bc.ca
Guest
|
| Posted: Fri May 09, 2008 12:55 pm Post subject: [asterisk-users] better enumlookup handler |
|
|
On Thu, 2008-05-08 at 10:51 -0500, Russell Bryant wrote:
| Quote: |
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.
| Quote: | 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?
It applies cleanly to 1.4.17, so that is awesome.
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/20080509/3b28b59b/attachment.pgp |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
