19 Apr
2012
19 Apr
'12
9:03 p.m.
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
19 Apr
19 Apr
9:23 p.m.
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
20 Apr
20 Apr
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
9:36 a.m.
Andreas Granig writes:
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.
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.
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
4587
days inactive
4588
days old
3 comments
2 participants
participants (2)
-
Andreas Granig -
Juha Heinanen