VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
abalashov at evaristes... Guest
|
Posted: Wed Feb 13, 2008 12:14 am Post subject: [asterisk-users] LCR in Asterisk |
|
|
Rizwan Hisham wrote:
Quote: | Hi all,
I am planning to implement LCR routing on my already running asterisk
server. Uptill now i have found out that asterisk has no support for
lcr, i have to do something about it myself, for example using the AGI.
Im looking for ideas here. Whats the best way to start implementing lcr
in asterisk. Should i use agi and start implementing my own lcr script
or is there any plugin available which can be used with asterisk.
|
If you are interested in prebuilt solutions, you may consider
TransNexus's NexOSS product (www.transnexus.com). The Open Settlement
Protocol (OSP) they implemented can be used with Asterisk - they have a
module. In fact, I am not sure about the commercial status of the OSP
module as such; it may be possible to get it free of charge. Not sure.
But OSP is an open protocol, so perhaps it's possible.
Otherwise, I would think that the best way to approach this would be to
make it fully outboard and divest it of Asterisk. Implement a SIP proxy
that forwards to providers using LCR decisionmaking, and just have
Asterisk send calls to it. OpenSER can be used for this - and indeed,
there is an OSP module for it as well, if you wanted to go that route.
If you're dead-set on doing it in Asterisk and don't want to do OSP, I
would suggest FastAGI. Definitely don't implement the logic in the dial
plan, at any cost.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599 |
|
Back to top |
|
|
tilghman at mail.jeffa... Guest
|
Posted: Wed Feb 13, 2008 10:18 am Post subject: [asterisk-users] LCR in Asterisk |
|
|
On Tuesday 12 February 2008 23:14:58 Alex Balashov wrote:
Quote: | Rizwan Hisham wrote:
Quote: | Hi all,
I am planning to implement LCR routing on my already running asterisk
server. Uptill now i have found out that asterisk has no support for
lcr, i have to do something about it myself, for example using the AGI.
Im looking for ideas here. Whats the best way to start implementing lcr
in asterisk. Should i use agi and start implementing my own lcr script
or is there any plugin available which can be used with asterisk.
|
If you are interested in prebuilt solutions, you may consider
TransNexus's NexOSS product (www.transnexus.com). The Open Settlement
Protocol (OSP) they implemented can be used with Asterisk - they have a
module. In fact, I am not sure about the commercial status of the OSP
module as such; it may be possible to get it free of charge. Not sure.
But OSP is an open protocol, so perhaps it's possible.
Otherwise, I would think that the best way to approach this would be to
make it fully outboard and divest it of Asterisk. Implement a SIP proxy
that forwards to providers using LCR decisionmaking, and just have
Asterisk send calls to it. OpenSER can be used for this - and indeed,
there is an OSP module for it as well, if you wanted to go that route.
If you're dead-set on doing it in Asterisk and don't want to do OSP, I
would suggest FastAGI. Definitely don't implement the logic in the dial
plan, at any cost.
|
Uh, why not? You can do LCR quite easily in the dialplan, by using func_odbc
for each of the provider lookups, then use SORT() to get the lowest cost.
It's quite easy, and you do not need to resort to AGI.
--
Tilghman |
|
Back to top |
|
|
abalashov at evaristes... Guest
|
Posted: Wed Feb 13, 2008 10:57 am Post subject: [asterisk-users] LCR in Asterisk |
|
|
Tilghman Lesher wrote:
Quote: | Uh, why not? You can do LCR quite easily in the dialplan, by using func_odbc
for each of the provider lookups, then use SORT() to get the lowest cost.
It's quite easy, and you do not need to resort to AGI.
|
You can do almost anything in the dial plan with enough spiritual
commitment in about the same way that you can do just about anything you
need to do with a bash script, as opposed to Perl, Python, or any
toolkits or frameworks.
It's not syntactically terse, balloons quickly in semantic complexity,
is objectively less efficient as the dial plan *is not a programming
language* (despite having variables, control structures and other things
characteristic of an execution environment of such), and otherwise
unnecessarily complicated. In implementing and extending the logic
going forward (beyond naive "lookups") in accordance with evolving
requirements in the business rules, you will find that you run into the
limits of the algorithmic complexity that the dial plan can provide, and
that whatever the approach, it's overly obfuscated. The dial plan
limits meaningful modularisation and functional decomposition that is
available with outboard runtime environments.
So, it's not that you couldn't - it's that you shouldn't.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599 |
|
Back to top |
|
|
tilghman at mail.jeffa... Guest
|
Posted: Wed Feb 13, 2008 12:33 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
On Wednesday 13 February 2008 09:57:59 Alex Balashov wrote:
Quote: | Tilghman Lesher wrote:
Quote: | Uh, why not? You can do LCR quite easily in the dialplan, by using
func_odbc for each of the provider lookups, then use SORT() to get the
lowest cost. It's quite easy, and you do not need to resort to AGI.
|
You can do almost anything in the dial plan with enough spiritual
commitment in about the same way that you can do just about anything you
need to do with a bash script, as opposed to Perl, Python, or any
toolkits or frameworks.
It's not syntactically terse, balloons quickly in semantic complexity,
is objectively less efficient as the dial plan *is not a programming
language* (despite having variables, control structures and other things
characteristic of an execution environment of such), and otherwise
unnecessarily complicated. In implementing and extending the logic
going forward (beyond naive "lookups") in accordance with evolving
requirements in the business rules, you will find that you run into the
limits of the algorithmic complexity that the dial plan can provide, and
that whatever the approach, it's overly obfuscated. The dial plan
limits meaningful modularisation and functional decomposition that is
available with outboard runtime environments.
|
Like any other language, you certainly can write in an obfuscated way, and
the dialplan does not discourage it. That said, you certainly can write in a
modularized way. I would guess that you simply aren't familiar with the
dialplan enough to make those decisions, but it is quite possible and doable.
Quote: | So, it's not that you couldn't - it's that you shouldn't.
|
In the same way that a PHP programmer should not attempt write Python the
way she writes PHP, I would agree with you. However, if you're willing to
adapt to the ways the dialplan works, you can create dialplans which aren't
obfuscated at all. Tcl and Lisp are close cousins to the dialplan in terms of
how they do things. Not everybody is a Lisp programmer, and some people
absolutely detest it. That doesn't make it any less of a good language.
--
Tilghman |
|
Back to top |
|
|
jra at baylink.com Guest
|
Posted: Wed Feb 13, 2008 12:45 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
On Wed, Feb 13, 2008 at 11:33:19AM -0600, Tilghman Lesher wrote:
Quote: | On Wednesday 13 February 2008 09:57:59 Alex Balashov wrote:
Quote: | Tilghman Lesher wrote:
Quote: | Uh, why not? You can do LCR quite easily in the dialplan, by using
func_odbc for each of the provider lookups, then use SORT() to get the
lowest cost. It's quite easy, and you do not need to resort to AGI.
|
You can do almost anything in the dial plan with enough spiritual
commitment in about the same way that you can do just about anything you
need to do with a bash script, as opposed to Perl, Python, or any
toolkits or frameworks.
It's not syntactically terse, balloons quickly in semantic complexity,
is objectively less efficient as the dial plan *is not a programming
language* (despite having variables, control structures and other things
characteristic of an execution environment of such), and otherwise
unnecessarily complicated. In implementing and extending the logic
going forward (beyond naive "lookups") in accordance with evolving
requirements in the business rules, you will find that you run into the
limits of the algorithmic complexity that the dial plan can provide, and
that whatever the approach, it's overly obfuscated. The dial plan
limits meaningful modularisation and functional decomposition that is
available with outboard runtime environments.
|
Like any other language, you certainly can write in an obfuscated way, and
the dialplan does not discourage it. That said, you certainly can write in a
modularized way. I would guess that you simply aren't familiar with the
dialplan enough to make those decisions, but it is quite possible and doable.
Quote: | So, it's not that you couldn't - it's that you shouldn't.
|
In the same way that a PHP programmer should not attempt write Python the
way she writes PHP, I would agree with you. However, if you're willing to
adapt to the ways the dialplan works, you can create dialplans which aren't
obfuscated at all. Tcl and Lisp are close cousins to the dialplan in terms of
how they do things. Not everybody is a Lisp programmer, and some people
absolutely detest it. That doesn't make it any less of a good language.
|
Having programmed in about 8 different languages over the last 25
years, I can see both points of view. And admittedly, I haven't tried
to do non-trivial things with dialplan.
That said, my view of this interaction is that Tilghman has drunk the
Kool-Aid<tm>, and that Alex's view of the situation is much closer to
objective.
dialplan appears to have "jes' growed", and that never makes for a good
language design. Ask the Python 3 team.
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra at baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Joseph Stalin) |
|
Back to top |
|
|
dougmig33 at yahoo.com Guest
|
Posted: Wed Feb 13, 2008 1:17 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
----- Original Message ----
From: Jay R. Ashworth <jra at baylink.com>
To: asterisk-users at lists.digium.com
Sent: Wednesday, February 13, 2008 9:45:34 AM
Subject: Re: [asterisk-users] LCR in Asterisk
On
Wed,
Feb
13,
2008
at
11:33:19AM
-0600,
Tilghman
Lesher
wrote:
On
Wednesday
13
February
2008
09:57:59
Alex
Balashov
wrote:
Tilghman
Lesher
wrote:
Uh,
why
not?
You
can
do
LCR
quite
easily
in
the
dialplan,
by
using
func_odbc
for
each
of
the
provider
lookups,
then
use
SORT()
to
get
the
lowest
cost.
It's
quite
easy,
and
you
do
not
need
to
resort
to
AGI.
You
can
do
almost
anything
in
the
dial
plan
with
enough
spiritual
commitment
in
about
the
same
way
that
you
can
do
just
about
anything
you
need
to
do
with
a
bash
script,
as
opposed
to
Perl,
Python,
or
any
toolkits
or
frameworks.
Is that nasty little problem of no local variables in macros fixed yet? That's a pretty big pain in the ass. You have to prefix your variables with the name of the macro it's in to avoid stepping all over yourself.
Doug.
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080213/b7e035d0/attachment.htm |
|
Back to top |
|
|
ira at extrasensory.com Guest
|
Posted: Wed Feb 13, 2008 1:38 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
At 09:33 AM 2/13/2008, you wrote:
Quote: | In the same way that a PHP programmer should not attempt write Python the
way she writes PHP, I would agree with you. However, if you're willing to
adapt to the ways the dialplan works, you can create dialplans which aren't
obfuscated at all. Tcl and Lisp are close cousins to the dialplan in terms of
how they do things. Not everybody is a Lisp programmer, and some people
absolutely detest it. That doesn't make it any less of a good language.
|
Look, I've done lots of cool stuff in the dial plan and other have
done stuff way beyond me, but I defy you to call the dial plan
language good or well designed. It works, it gets the job done but
it's always harder than it needs to be.
Ira |
|
Back to top |
|
|
tilghman at mail.jeffa... Guest
|
Posted: Wed Feb 13, 2008 1:49 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
Doug-
Please fix your email client. One line per word in quoting is a little
excessive. Better yet, turn off HTML.
On Wednesday 13 February 2008 12:17:30 Douglas Garstang wrote:
Quote: | Is that nasty little problem of no local variables in macros fixed yet?
That's a pretty big pain in the ass. You have to prefix your variables with
the name of the macro it's in to avoid stepping all over yourself.
|
Macros are deprecated. Gosubs are the way forward, and yes, they have
local variables. Simply define them once as Set(LOCAL(foo)=bar) and foo
will be gone when the innermost stack is removed (either by Return or
StackPop).
--
Tilghman |
|
Back to top |
|
|
philipp.kempgen at amo... Guest
|
Posted: Wed Feb 13, 2008 1:49 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
Douglas Garstang wrote:
Quote: | ----- Original Message ----
From: Jay R. Ashworth <jra at baylink.com>
To: asterisk-users at lists.digium.com
Sent: Wednesday, February 13, 2008 9:45:34 AM
Subject: Re: [asterisk-users] LCR in Asterisk
On
Wed,
Feb
13,
2008
at
11:33:19AM
-0600,
Tilghman
Lesher
wrote:
On
Wednesday
13
February
2008
09:57:59
Alex
Balashov
wrote:
Tilghman
Lesher
wrote:
Uh,
why
not?
You
can
do
LCR
quite
easily
in
the
dialplan,
by
using
func_odbc
for
each
of
the
provider
lookups,
then
use
SORT()
to
get
the
lowest
cost.
It's
quite
easy,
and
you
do
not
need
to
resort
to
AGI.
You
can
do
almost
anything
in
the
dial
plan
with
enough
spiritual
commitment
in
about
the
same
way
that
you
can
do
just
about
anything
you
need
to
do
with
a
bash
script,
as
opposed
to
Perl,
Python,
or
any
toolkits
or
frameworks.
|
Could you fix your e-mail client please?
Regards,
Philipp Kempgen |
|
Back to top |
|
|
tilghman at mail.jeffa... Guest
|
Posted: Wed Feb 13, 2008 1:52 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
On Wednesday 13 February 2008 11:45:34 Jay R. Ashworth wrote:
Quote: | Having programmed in about 8 different languages over the last 25
years, I can see both points of view. And admittedly, I haven't tried
to do non-trivial things with dialplan.
That said, my view of this interaction is that Tilghman has drunk the
Kool-Aid<tm>, and that Alex's view of the situation is much closer to
objective.
|
Or maybe I'm just the architect of the dialplan moving forward, which is why
I advocate that if you really don't need to use AGI, you don't.
Quote: | dialplan appears to have "jes' growed", and that never makes for a good
language design. Ask the Python 3 team.
|
I'm specifically working on removing misfeatures from the dialplan, to make
it much easier to use and more predictable. 1.6 will be a huge improvement
towards this goal.
--
Tilghman |
|
Back to top |
|
|
jra at baylink.com Guest
|
Posted: Wed Feb 13, 2008 2:03 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
On Wed, Feb 13, 2008 at 12:52:42PM -0600, Tilghman Lesher wrote:
Quote: | On Wednesday 13 February 2008 11:45:34 Jay R. Ashworth wrote:
Quote: | Having programmed in about 8 different languages over the last 25
years, I can see both points of view. And admittedly, I haven't tried
to do non-trivial things with dialplan.
That said, my view of this interaction is that Tilghman has drunk the
Kool-Aid<tm>, and that Alex's view of the situation is much closer to
objective.
|
Or maybe I'm just the architect of the dialplan moving forward, which is why
I advocate that if you really don't need to use AGI, you don't.
|
I'm not sure those aren't equivalent.
Quote: | Quote: | dialplan appears to have "jes' growed", and that never makes for a good
language design. Ask the Python 3 team.
|
I'm specifically working on removing misfeatures from the dialplan, to make
it much easier to use and more predictable. 1.6 will be a huge improvement
towards this goal.
|
"Well, this should be interesting."
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra at baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Joseph Stalin) |
|
Back to top |
|
|
jra at baylink.com Guest
|
Posted: Wed Feb 13, 2008 2:04 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
On Wed, Feb 13, 2008 at 07:49:36PM +0100, Philipp Kempgen wrote:
Quote: | Douglas Garstang wrote:
| [ ... ]
Quote: | Quote: | do
with
a
bash
script,
as
opposed
to
Perl,
Python,
or
any
toolkits
or
frameworks.
|
Could you fix your e-mail client please?
|
I dunno; his message comes out fine here, though Mutt and lynx --dump.
I grow less impressed with T-bird by the day...
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra at baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Joseph Stalin) |
|
Back to top |
|
|
abalashov at evaristes... Guest
|
Posted: Wed Feb 13, 2008 2:18 pm Post subject: [asterisk-users] LCR in Asterisk |
|
|
Tilghman Lesher wrote:
Quote: | Like any other language, you certainly can write in an obfuscated way, and
the dialplan does not discourage it. That said, you certainly can write in a
modularized way. I would guess that you simply aren't familiar with the
dialplan enough to make those decisions, but it is quite possible and doable.
|
The dial plan certainly does lend itself to this to some degree, no
argument, but not to the extent that fully developed programming /
scripting languages do.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599 |
|
Back to top |
|
|
digium at sanguinarius... Guest
|
Posted: Sun Feb 17, 2008 4:41 am Post subject: [asterisk-users] LCR in Asterisk |
|
|
Tilghman Lesher wrote:
Quote: |
Macros are deprecated. Gosubs are the way forward, and yes, they have
local variables. Simply define them once as Set(LOCAL(foo)=bar) and foo
will be gone when the innermost stack is removed (either by Return or
StackPop).
| Yeah, but I like macros.
<stamps feet>.
Still nice to know that the , | () nonesense is being cleaned up. |
|
Back to top |
|
|
tilghman at mail.jeffa... Guest
|
Posted: Sun Feb 17, 2008 10:52 am Post subject: [asterisk-users] LCR in Asterisk |
|
|
On Sunday 17 February 2008 03:41:09 Thomas Kenyon wrote:
Quote: | Tilghman Lesher wrote:
Quote: | Macros are deprecated. Gosubs are the way forward, and yes, they have
local variables. Simply define them once as Set(LOCAL(foo)=bar) and foo
will be gone when the innermost stack is removed (either by Return or
StackPop).
|
Yeah, but I like macros.
<stamps feet>.
|
Not that I would ever encourage such dialplan abuse, but Gosub will permit
going far deeper, even in recursion than Macro. With Macro, you are limited
from anywhere from 5 to 10 levels deep, because it exhausts the call stack,
whereas Gosub will permit something like 100,000 nested calls deep.
Quote: | Still nice to know that the , | () nonesense is being cleaned up.
|
Thank you. I realize this is going to be painful initially, but it's quite
necessary to build even more complexity into the dialplan in the future.
--
Tilghman |
|
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
|