12 Feb
2018
12 Feb
'18
3:52 p.m.
Hello,
I am configuring a Kamailio node that will interface with 3 carriers and will implement
Least Cost Routing for around 900 destinations.
I have already implemented a quick prototype with the LCR module and I have been reading
the CarrierRoute doc and the CGrates site.
I don't really need advanced functionality, just:
- Re-routing to a backup carrier when the main one is not available.
- Ping with OPTIONS to all carriers so I can detect if any of them is not
available (à la Dispatcher)
- Translate prices from a central DB to routing priorities.
- Get some accounting post-call info about the routing decision (acc module)
So far, while testing the LCR module I have had some issues with the rule IDs being
integers that auto-increment, so the LCR rules need to be referenced from the rule_target
table using this numeric ID. I can see some issues when scaling this to 900 lcr_rules and
2700 lcr_rule_targets with 3 priorities.
In addition to that, I think the OPTIONS mechanism is just used by the lcr module when a
gateway is marked as defunct, but the gateways are not actively monitored in the normal
status. Is this correct?
I have been considering CarrierRoute, which has a slightly simpler table structure, but I
can't find any other advantage for my use case. Regarding CGrates, it looks great but
it looks like it exceeds my current needs.
For those who have implemented LCR in your kamailios, am I missing something regarding
performance, scalability, etc?
Are there any newer modules that can implement this, or maybe just a
dispatcher-on-steroids setup will do the trick?
Cheers,
Francisco.
12 Feb
12 Feb
4:22 p.m.
Hello,
On 12.02.18 13:52, Francisco Valentin Vinagrero wrote:
Hello,
I am configuring a Kamailio node that will interface with 3 carriers
and will implement Least Cost Routing for around 900 destinations.
I have already implemented a quick prototype with the LCR module and I
have been reading the CarrierRoute doc and the CGrates site.
I don’t really need advanced functionality, just:
- Re-routing to a backup carrier when the main one is not
available.
- Ping with OPTIONS to all carriers so I can detect if any of
them is not available (à la Dispatcher)
- Translate prices from a central DB to routing priorities.
- Get some accounting post-call info about the routing
decision (acc module)
So far, while testing the LCR module I have had some issues with the
rule IDs being integers that auto-increment, so the LCR rules need to
be referenced from the rule_target table using this numeric ID. I can
see some issues when scaling this to 900 lcr_rules and 2700
lcr_rule_targets with 3 priorities.
In addition to that, I think the OPTIONS mechanism is just used by the
lcr module when a gateway is marked as defunct, but the gateways are
not actively monitored in the normal status. Is this correct?
I have been considering CarrierRoute, which has a slightly simpler
table structure, but I can’t find any other advantage for my use case.
Regarding CGrates, it looks great but it looks like it exceeds my
current needs.
For those who have implemented LCR in your kamailios, am I missing
something regarding performance, scalability, etc?
Are there any newer modules that can implement this, or maybe just a
dispatcher-on-steroids setup will do the trick?
Look also at drouting module, the latest version should do OPTIONS keep
alives using keepalive module, otherwise it is a lcr implementation as
well -- I haven't tested myself the keep alive feature, though.
As for me, typically I go in this case for a combination of mtree +
dispatcher. I have mtree translating from longest prefix to a dispatcher
group id, inside dispatcher group you can use priority based routing.
This works just fine even when you end up in several dispatcher groups
with same destinations but different order based on priority per group.
You can even map the prefix in mtree to dispatcher group + dispatching
algorithm, latest version supports having many columns loaded in the
value and then you can use script operations to split.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
6:58 p.m.
Thanks Daniel,
Mtree + Dispatcher makes a lot of sense for my use case. I will try to implement the LCR
with that.
Cheers, Francisco.
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: Monday, February 12, 2018 14:22
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; Francisco
Valentin Vinagrero <francisco.valentin.vinagrero(a)cern.ch>
Subject: Re: [SR-Users] LCR options as of 2018
Hello,
On 12.02.18 13:52, Francisco Valentin Vinagrero wrote:
Hello,
I am configuring a Kamailio node that will interface with 3 carriers and will implement
Least Cost Routing for around 900 destinations.
I have already implemented a quick prototype with the LCR module and I have been reading
the CarrierRoute doc and the CGrates site.
I don't really need advanced functionality, just:
- Re-routing to a backup carrier when the main one is not available.
- Ping with OPTIONS to all carriers so I can detect if any of them is not
available (à la Dispatcher)
- Translate prices from a central DB to routing priorities.
- Get some accounting post-call info about the routing decision (acc module)
So far, while testing the LCR module I have had some issues with the rule IDs being
integers that auto-increment, so the LCR rules need to be referenced from the rule_target
table using this numeric ID. I can see some issues when scaling this to 900 lcr_rules and
2700 lcr_rule_targets with 3 priorities.
In addition to that, I think the OPTIONS mechanism is just used by the lcr module when a
gateway is marked as defunct, but the gateways are not actively monitored in the normal
status. Is this correct?
I have been considering CarrierRoute, which has a slightly simpler table structure, but I
can't find any other advantage for my use case. Regarding CGrates, it looks great but
it looks like it exceeds my current needs.
For those who have implemented LCR in your kamailios, am I missing something regarding
performance, scalability, etc?
Are there any newer modules that can implement this, or maybe just a
dispatcher-on-steroids setup will do the trick?
Look also at drouting module, the latest version should do OPTIONS keep alives using
keepalive module, otherwise it is a lcr implementation as well -- I haven't tested
myself the keep alive feature, though.
As for me, typically I go in this case for a combination of mtree + dispatcher. I have
mtree translating from longest prefix to a dispatcher group id, inside dispatcher group
you can use priority based routing. This works just fine even when you end up in several
dispatcher groups with same destinations but different order based on priority per group.
You can even map the prefix in mtree to dispatcher group + dispatching algorithm, latest
version supports having many columns loaded in the value and then you can use script
operations to split.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda<http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - March 5-7, 2018, Berlin -
www.asipto.com<http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 -
www.kamailioworld.com<http://www.kamailioworld.com>
19 Feb
19 Feb
12:17 p.m.
Hello,
So far, the mtree + dispatcher option is working perfectly.
Is there any AVP to retrieve the prefix that was matched when querying the mtree table?
I'd like to have a record of this to identify missing prefixes in my table or wrong
configurations for longest-prefix matches.
I have had a look at the documentation but I couldn't find if this is stored in an
AVP.
Cheers, Francisco.
From: Francisco Valentin Vinagrero
Sent: Monday, February 12, 2018 16:59
To: 'miconda(a)gmail.com' <miconda(a)gmail.com>om>; Kamailio (SER) - Users Mailing
List <sr-users(a)lists.kamailio.org>
Subject: RE: [SR-Users] LCR options as of 2018
Thanks Daniel,
Mtree + Dispatcher makes a lot of sense for my use case. I will try to implement the LCR
with that.
Cheers, Francisco.
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: Monday, February 12, 2018 14:22
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>; Francisco
Valentin Vinagrero
<francisco.valentin.vinagrero@cern.ch<mailto:francisco.valentin.vinagrero@cern.ch>>
Subject: Re: [SR-Users] LCR options as of 2018
Hello,
On 12.02.18 13:52, Francisco Valentin Vinagrero wrote:
Hello,
I am configuring a Kamailio node that will interface with 3 carriers and will implement
Least Cost Routing for around 900 destinations.
I have already implemented a quick prototype with the LCR module and I have been reading
the CarrierRoute doc and the CGrates site.
I don't really need advanced functionality, just:
- Re-routing to a backup carrier when the main one is not available.
- Ping with OPTIONS to all carriers so I can detect if any of them is not
available (à la Dispatcher)
- Translate prices from a central DB to routing priorities.
- Get some accounting post-call info about the routing decision (acc module)
So far, while testing the LCR module I have had some issues with the rule IDs being
integers that auto-increment, so the LCR rules need to be referenced from the rule_target
table using this numeric ID. I can see some issues when scaling this to 900 lcr_rules and
2700 lcr_rule_targets with 3 priorities.
In addition to that, I think the OPTIONS mechanism is just used by the lcr module when a
gateway is marked as defunct, but the gateways are not actively monitored in the normal
status. Is this correct?
I have been considering CarrierRoute, which has a slightly simpler table structure, but I
can't find any other advantage for my use case. Regarding CGrates, it looks great but
it looks like it exceeds my current needs.
For those who have implemented LCR in your kamailios, am I missing something regarding
performance, scalability, etc?
Are there any newer modules that can implement this, or maybe just a
dispatcher-on-steroids setup will do the trick?
Look also at drouting module, the latest version should do OPTIONS keep alives using
keepalive module, otherwise it is a lcr implementation as well -- I haven't tested
myself the keep alive feature, though.
As for me, typically I go in this case for a combination of mtree + dispatcher. I have
mtree translating from longest prefix to a dispatcher group id, inside dispatcher group
you can use priority based routing. This works just fine even when you end up in several
dispatcher groups with same destinations but different order based on priority per group.
You can even map the prefix in mtree to dispatcher group + dispatching algorithm, latest
version supports having many columns loaded in the value and then you can use script
operations to split.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda<http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - March 5-7, 2018, Berlin -
www.asipto.com<http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 -
www.kamailioworld.com<http://www.kamailioworld.com>
6:07 p.m.
Hello,
not aware of such option in mtree to get the matched prefix. Someone has
to write some C code to get it.
Cheers,
Daniel
On 19.02.18 10:17, Francisco Valentin Vinagrero wrote:
Hello,
So far, the mtree + dispatcher option is working perfectly.
Is there any AVP to retrieve the prefix that was matched when querying
the mtree table? I’d like to have a record of this to identify missing
prefixes in my table or wrong configurations for longest-prefix matches.
I have had a look at the documentation but I couldn’t find if this is
stored in an AVP.
Cheers, Francisco.
*From:*Francisco Valentin Vinagrero
*Sent:* Monday, February 12, 2018 16:59
*To:* 'miconda(a)gmail.com' <miconda(a)gmail.com>om>; Kamailio (SER) - Users
Mailing List <sr-users(a)lists.kamailio.org>
*Subject:* RE: [SR-Users] LCR options as of 2018
Thanks Daniel,
Mtree + Dispatcher makes a lot of sense for my use case. I will try to
implement the LCR with that.
Cheers, Francisco.
*From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com]
*Sent:* Monday, February 12, 2018 14:22
*To:* Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>; Francisco Valentin Vinagrero
<francisco.valentin.vinagrero(a)cern.ch
<mailto:francisco.valentin.vinagrero@cern.ch>>
*Subject:* Re: [SR-Users] LCR options as of 2018
Hello,
On 12.02.18 13:52, Francisco Valentin Vinagrero wrote:
Hello,
I am configuring a Kamailio node that will interface with 3
carriers and will implement Least Cost Routing for around 900
destinations.
I have already implemented a quick prototype with the LCR module
and I have been reading the CarrierRoute doc and the CGrates site.
I don’t really need advanced functionality, just:
- Re-routing to a backup carrier when the main one is not
available.
- Ping with OPTIONS to all carriers so I can detect if
any of them is not available (à la Dispatcher)
- Translate prices from a central DB to routing priorities.
- Get some accounting post-call info about the routing
decision (acc module)
So far, while testing the LCR module I have had some issues with
the rule IDs being integers that auto-increment, so the LCR rules
need to be referenced from the rule_target table using this
numeric ID. I can see some issues when scaling this to 900
lcr_rules and 2700 lcr_rule_targets with 3 priorities.
In addition to that, I think the OPTIONS mechanism is just used by
the lcr module when a gateway is marked as defunct, but the
gateways are not actively monitored in the normal status. Is this
correct?
I have been considering CarrierRoute, which has a slightly simpler
table structure, but I can’t find any other advantage for my use
case. Regarding CGrates, it looks great but it looks like it
exceeds my current needs.
For those who have implemented LCR in your kamailios, am I missing
something regarding performance, scalability, etc?
Are there any newer modules that can implement this, or maybe just
a dispatcher-on-steroids setup will do the trick?
Look also at drouting module, the latest version should do OPTIONS
keep alives using keepalive module, otherwise it is a lcr
implementation as well -- I haven't tested myself the keep alive
feature, though.
As for me, typically I go in this case for a combination of mtree +
dispatcher. I have mtree translating from longest prefix to a
dispatcher group id, inside dispatcher group you can use priority
based routing. This works just fine even when you end up in several
dispatcher groups with same destinations but different order based on
priority per group.
You can even map the prefix in mtree to dispatcher group + dispatching
algorithm, latest version supports having many columns loaded in the
value and then you can use script operations to split.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
<http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
<http://www.kamailioworld.com>
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
7:29 p.m.
Yes, that's what I thought.
I implemented a lazy solution, which prepends the prefix to the tvalue so it can be
retrieved with a transformation...
Thanks, Francisco.
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: Monday, February 19, 2018 16:08
To: Francisco Valentin Vinagrero <francisco.valentin.vinagrero(a)cern.ch>ch>; Kamailio
(SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] LCR options as of 2018
Hello,
not aware of such option in mtree to get the matched prefix. Someone has to write some C
code to get it.
Cheers,
Daniel
On 19.02.18 10:17, Francisco Valentin Vinagrero wrote:
Hello,
So far, the mtree + dispatcher option is working perfectly.
Is there any AVP to retrieve the prefix that was matched when querying the mtree table?
I'd like to have a record of this to identify missing prefixes in my table or wrong
configurations for longest-prefix matches.
I have had a look at the documentation but I couldn't find if this is stored in an
AVP.
Cheers, Francisco.
From: Francisco Valentin Vinagrero
Sent: Monday, February 12, 2018 16:59
To: 'miconda@gmail.com<mailto:miconda@gmail.com>'
<miconda@gmail.com><mailto:miconda@gmail.com>; Kamailio (SER) - Users Mailing
List <sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org>
Subject: RE: [SR-Users] LCR options as of 2018
Thanks Daniel,
Mtree + Dispatcher makes a lot of sense for my use case. I will try to implement the LCR
with that.
Cheers, Francisco.
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: Monday, February 12, 2018 14:22
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>; Francisco
Valentin Vinagrero
<francisco.valentin.vinagrero@cern.ch<mailto:francisco.valentin.vinagrero@cern.ch>>
Subject: Re: [SR-Users] LCR options as of 2018
Hello,
On 12.02.18 13:52, Francisco Valentin Vinagrero wrote:
Hello,
I am configuring a Kamailio node that will interface with 3 carriers and will implement
Least Cost Routing for around 900 destinations.
I have already implemented a quick prototype with the LCR module and I have been reading
the CarrierRoute doc and the CGrates site.
I don't really need advanced functionality, just:
- Re-routing to a backup carrier when the main one is not available.
- Ping with OPTIONS to all carriers so I can detect if any of them is not
available (à la Dispatcher)
- Translate prices from a central DB to routing priorities.
- Get some accounting post-call info about the routing decision (acc module)
So far, while testing the LCR module I have had some issues with the rule IDs being
integers that auto-increment, so the LCR rules need to be referenced from the rule_target
table using this numeric ID. I can see some issues when scaling this to 900 lcr_rules and
2700 lcr_rule_targets with 3 priorities.
In addition to that, I think the OPTIONS mechanism is just used by the lcr module when a
gateway is marked as defunct, but the gateways are not actively monitored in the normal
status. Is this correct?
I have been considering CarrierRoute, which has a slightly simpler table structure, but I
can't find any other advantage for my use case. Regarding CGrates, it looks great but
it looks like it exceeds my current needs.
For those who have implemented LCR in your kamailios, am I missing something regarding
performance, scalability, etc?
Are there any newer modules that can implement this, or maybe just a
dispatcher-on-steroids setup will do the trick?
Look also at drouting module, the latest version should do OPTIONS keep alives using
keepalive module, otherwise it is a lcr implementation as well -- I haven't tested
myself the keep alive feature, though.
As for me, typically I go in this case for a combination of mtree + dispatcher. I have
mtree translating from longest prefix to a dispatcher group id, inside dispatcher group
you can use priority based routing. This works just fine even when you end up in several
dispatcher groups with same destinations but different order based on priority per group.
You can even map the prefix in mtree to dispatcher group + dispatching algorithm, latest
version supports having many columns loaded in the value and then you can use script
operations to split.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda<http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - March 5-7, 2018, Berlin -
www.asipto.com<http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 -
www.kamailioworld.com<http://www.kamailioworld.com>
--
Daniel-Constantin Mierla
www.twitter.com/miconda<http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - March 5-7, 2018, Berlin -
www.asipto.com<http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 -
www.kamailioworld.com<http://www.kamailioworld.com>
13 Feb
13 Feb
11:22 a.m.
Francisco Valentin Vinagrero writes:
So far, while testing the LCR module I have had some
issues with the
rule IDs being integers that auto-increment, so the LCR rules need to
be referenced from the rule_target table using this numeric ID. I can
see some issues when scaling this to 900 lcr_rules and 2700
lcr_rule_targets with 3 priorities.
You, for sure. need a GUI to configure your LCR routing.
In addition to that, I think the OPTIONS mechanism is
just used by the
lcr module when a gateway is marked as defunct, but the gateways are
not actively monitored in the normal status. Is this correct?
Yes. A gateway will be monitored only after it fails. That should not
be an issue, however, since you should have a another gw configured with
lower priority.
-- Juha
2468
days inactive
2475
days old
6 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Francisco Valentin Vinagrero -
Juha Heinanen