Hi,
I'd like to intoduce a way to perform pattern matching on the R-URI in addition to the plain prefix matching of R-URI-User. The use case is for example to only allow numeric destinations on one gw, whereas another one could accept alphanumeric ones as well (e.g. plain SIP peers compared to peers towards PSTN gateways).
In order to keep the current functionality as is, I'd introduce a destination mode column with values 1 (default) for normal prefix matching and 2 for regex matching, and either extend the length of the prefix column or introduce a ruri_pattern column (because the name "prefix" would be misleading, but I'm reluctant to rename it due to backwards compatibility), which is only used if mode==2.
Any comments/opinions on that?
Andreas
Andreas Granig writes:
I'd like to intoduce a way to perform pattern matching on the R-URI in addition to the plain prefix matching of R-URI-User. The use case is for example to only allow numeric destinations on one gw, whereas another one could accept alphanumeric ones as well (e.g. plain SIP peers compared to peers towards PSTN gateways).
Any comments/opinions on that?
andreas,
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.
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.
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.
-- juha
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
Andreas Granig writes:
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.
what i tried to suggest is that you store gw's identity in dialplan/attrs field or store there a prefix that you can use in lcr module to choose a gw.
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.
lcr module is already now quite (too) complex. i'm afraid that adding a new mode to it would increase its complexity beyond repair. i would therefore prefer a modular approach where one module does one simple thing well and then applying the modules sequentially.
but if you don't see this kind of approach feasible, go ahead and add regex support to lcr module (and of course to its README file). i have had in mind before 3.3 freeze to allow lcr_id 0 or null in lcr_gw table meaning that the gw can be used in any lcr instance.
-- juha
-
Andreas Granig -
Juha Heinanen