[Spce-user] peering rules, does seem to be using as set

[Daniel Grotti]

Hi Matthew,
if you have different between gui and mysql, it sounds weird.
Of course you have to check you lcr_rule in mysql.
Also you can check if you have some errors or wrong characters in mysql (maybe you wrote a wrong "^" symbol, or maybe you wrote a wrong REGEXP), that makes your rules unusable.
If you want, you can share your rules and let us know which call is failing, as well as which RURI you are trying to match.


Regards,
Daniel


 



On Saturday, February 8, 2014 18:57 CET, Matthew Ogden <matthew at tenacit.net> wrote: 
 
> Hi Daniel,
> 
> 
> 
> (I had to receive your reply online, I often don't seem to get mails
> from sipwise forum... I use google apps, and I've checked my junk/spam,
> but your reply is not there).
> 
> 
> 
> 
> 
> Anyway, yes, that's exactly how I expected them to work based on the
> user manual. So I have an entry that is the longer part, and it does
> not work. If I modify that entry, and take its original contents, and
> put them into a new entry, it works, but the pre-existing one that was
> created in 2.5, if I put my mobile in that line, its not working.
> 
> 
> 
> I looked in mysql in lcr_rule to see if I could see any noticeable
> difference between the old "upgraded" entry, and the new one, but I'm
> guessing the problem lay in lcr_rule_target.
> 
> 
> 
> Deleting the non working rule and making a new one fixes the problem,
> but how can I run a query again lcr_rule and lcr_rule_target to see
> there are no other broken entries like this one was? (Also the broken
> rule is still in the table, but not in the GUI... didn't make much sense
> to me?)
> 
> 
> 
> Kind Regards
> 
> 
> 
> Matthew
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hi Matthew,
> 
> the rules matching works like that:
> 
> 
> 
> (1) match according to longest Request-URI user part match
> 
> (2) match according to tuple's priority
> 
> (3) match according to tuple's randomized weight
> 
> 
> 
> So first of all it matches the longest prefix (no matter about priority)
> 
> Then the priority is take in place.
> 
> 
> 
> Daniel
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 02/06/2014 12:58 PM, Matthew Ogden wrote:
> 
> >* I have 3 peering groups, 2 on priority 2, and another on priority 4.*
> 
> >
> 
> >
> 
> >
> 
> >* Inside each of those is only one peering server.*
> 
> >
> 
> >
> 
> >
> 
> >* The group on priority 4 has a peering rule, the full length of my mobile*
> 
> >* number in "Callee Prefix", the others have some peering rules, but they*
> 
> >* are much shorter, only 4 digits, or no digits (default).*
> 
> >
> 
> >
> 
> >
> 
> >* But lowest priority server is never used to phone my mobile . Templates*
> 
> >* are on 2.8.18*
> 
> >
> 
> >
> 
> >
> 
> >* I just get this: Feb  6 13:46:52 spce /usr/sbin/kamailio[2359]: INFO:*
> 
> >* <script>: Load gws matching calling part*
> 
> >
> 
> >* And the first peer it uses, is not the one I had expected it to.*
> 
> >
> 
> >
> 
> >
> 
> >* I have also tried reducing the digits that match my mobile number,  but*
> 
> >* that didn't make an impact.*
> 
> >
> 
> >
> 
> >
> 
> >* On at least version 2.5 or 2.6 this did work as expected.*
> 
> >
> 
> >
> 
> >
> 
> >* I wondered... perhaps this is broken during an upgrade, and the data is*
> 
> >* missing a column during upgrade process or something like that... I then*
> 
> >* added an entry again for my mobile number and it works!*
> 
> >
> 
> >
> 
> >
> 
> >* Instead of re-adding every entry, can I check in the DB what the*
> 
> >* difference might be?*
> 
> >
> 
> >
> 
> >
> 
> >* _______________________________________________*
> 
> >* Spce-user mailing list*
> 
> >* Spce-user at lists.sipwise.com <http://lists.sipwise.com/listinfo/spce-user>*
> 
> >* http://lists.sipwise.com/listinfo/spce-user <http://lists.sipwise.com/listinfo/spce-user>*
> 
> >