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:mico...@gmail.com]
Sent: Monday, February 19, 2018 16:08
To: Francisco Valentin Vinagrero <francisco.valentin.vinagr...@cern.ch>; 
Kamailio (SER) - Users Mailing List <sr-users@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: 'mico...@gmail.com<mailto:mico...@gmail.com>' 
<mico...@gmail.com><mailto:mico...@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:mico...@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.vinagr...@cern.ch<mailto:francisco.valentin.vinagr...@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>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to