Hi Juha,
On 04/19/2012 07:23 PM, Juha Heinanen wrote:
regex matching has not been part of lcr module on purpose, because it is difficult to determine, how one regex match is "better" than another match. also it is difficult to achieve O(logN) performance while doing regex matching.
Right, I understand the purpose and the reasons, however I think there are there are two quite different use-cases for the module. One is to support a large number of rules and gws with the purpose of doing fast and reliable longest-match-first prefix matching (a typical lcr scenario), and the other one is having only a handful of gws and rules, where flexibility for matching goes first, because due to the low number of rules and gws, it's perfectly feasible to control the order with the gw priority column.
if your ruri user is not a phone number, but ruri is regular "userid" style uri of some domain, then i would think that userpart of the uri does not matter and routing should be done by the hostpart (= domain). it hard to me to imagine that one gateway would serve some users of the domain, but not some others.
It's just a matter of the use-case. We've various deployments where a gw is not just a pstn-gw, but another voip system, which segments its users over multiple IPs, who still share the same domain. Think of the typical outbound-proxy setting you find in lots of SIP clients, where providers provision devices with a common SIP URI domain example.org, but split users using multiple outbound proxy settings like "sip:1.2.3.4:5060" for the first 100k, "sip:1.2.3.5:5060" for the next 100k etc.
That's just one use-case, another one would be forcing various domains over a specific SBC, although the SIP domain part doesn't point to this host. Yes, you find all kinds of crazy setups out there if you interconnect with other peers, and for one reason or another it's not possible to convince them to clean this stuff up.
if you need to do regex matching, then i would recommend using dialplan module either alone or as the first step before using lcr module as is as the second step.
No, usually we do it exactly the other way around. You've an R-URI with which you fetch a gw for the call, and depending on the gw, you apply dialplan sets specific to the gw selected by lcr module. That's because various peering partners require specific number formats, e.g. your national carrier wants national calls in national format for a- and b-numbers, whereas an international carrier needs it in e.164 format with a prefix of "00" or "+" or whatever.
Again, I understand why lcr works the way it does, but an additional regex-based use-case should be supported as well. It's up to the admin to consider which approach he might choose, and that's why I proposed to make it fully backwards compatible, so there won't be any tradeoff for the existing default approach. The regex mode will have its drawbacks in terms of performance or choosing the best match, but will have huge advantages in terms of flexibility. The good thing is that you can choose whatever suits your scenario best.
Andreas