20 Apr
2012
20 Apr
'12
4:27 a.m.
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