[SR-Users] LCR with gateway capabilities

Grant Bagdasarian gb at cm.nl
Wed Apr 29 13:21:01 CEST 2015


The Tag column size is 64. If I make this larger in the database, will it be truncated once it is loaded into memory?
Through which list do I need to iterate? You mentioned the data is stored in a hash table, what is the name of this hash table?

Basically for each call I need to call the load_gws() function, which is O(N) * O(M).
What if I take a different approach and call a stored procedure (for each call) which does the selection of a gateway based on the supplied criteria.
Of course the tables would be optimized with indices for the best possible performance.

When comparing load_gws() (O(N) * O(M)) with the stored procedure approach, would there be a huge performance loss when taking the stored procedure approach?
I know this approach brings a whole new set of problem with availability and the loss of features, but for now I'm only interested in the performance aspect of both methods.

From: sr-users [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Vitaliy Aleksandrov
Sent: Wednesday, April 29, 2015 12:27 PM
To: sr-users at lists.sip-router.org
Subject: Re: [SR-Users] LCR with gateway capabilities


On 29/04/15 12:34, Grant Bagdasarian wrote:
That sounds possible! Thanks.

That does this description mean: "Execution time of load_gws() function is O(N) * O(M), where N is number of different prefix lengths and M is number of collisions for matching prefix(es) in lcr rules hash table of the LCR instance."?

Does this mean it loads the data from its internal memory or does it load the data from the database again?
load_gws() prepares an ordered list of gateways for current destination. It loads data only from internal in-memory gateways db (hash table).

How fast does it select a gateway after load_gws using next_gw()? Is it O(N) again?
O(1) since load_gws already prepared ordered (by price) list and next_gw() only takes next gw in a list.


What about multiple combinations of capabilities? For example caller id spoofing and g729 codec, or caller id spoofing and g711ulaw codec? Etc.
Wouldn't this cause the data to grow exponentially?
It would.

Another idea:
You can also have only one lcr instance and keep gateways capabilities in the tag field (serialized somehow). Then you can just iterate through a list generated by load_gws() skipping gateways which don't match your criteria and in the end a call will be routed to the cheapest gateway with proper capabilities.


From: sr-users [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Vitaliy Aleksandrov
Sent: Wednesday, April 29, 2015 10:36 AM
To: sr-users at lists.sip-router.org<mailto:sr-users at lists.sip-router.org>
Subject: Re: [SR-Users] LCR with gateway capabilities

What about configuring two LCR instances with different "lcr_id".
The first one can use only gateways with requested capabilities and the second one all gateways.
Then you can make a decision about which instance to use during call routing process providing this lcr_id to load_gws() function.



Hello,

>From what I understand about the LCR module is that the rules have to be prioritized by the admin, be it manually or automatically by an application.

Let's say the LCR database has 10 gateways, each with their own rules etc.
4 of these gateways support caller id spoofing and the others don't.
But the other 6 are cheaper and Kamailio has to route a call using a gateway which support caller id spoofing and is the cheapest of the 4.

Would it be possible to tell the LCR module to select a gateway based on certain capabilities and is the cheapest of the ones which support a certain capability?







_______________________________________________

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list

sr-users at lists.sip-router.org<mailto:sr-users at lists.sip-router.org>

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users





_______________________________________________

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list

sr-users at lists.sip-router.org<mailto:sr-users at lists.sip-router.org>

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150429/5aef83bb/attachment.html>


More information about the sr-users mailing list