[OpenSER-Devel] [ openser-Patches-1736696 ] lcr: regex prefix mode

[SourceForge.net]

Patches item #1736696, was opened at 2007-06-13 15:18
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1736696&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Nobody/Anonymous (nobody)
Summary: lcr: regex prefix mode

Initial Comment:
Here's a patch for lcr that will allow regex prefix matching.

A new module parameter has been added: "prefix_mode".
The default value of the param is '0' (the regex functionality is disabled).  Any other value different then '0' will enable the regex functionality.

# enable regex prefix mode
modparam("lcr", "prefix_mode", 1)

----------------------------------------------------------------------

>Comment By: Ovidiu Sas (osas)
Date: 2007-12-14 13:20

Message:
Logged In: YES 
user_id=1395524
Originator: YES

Hello Juha,


Do you think that is worth integrating this patch into the lcr module?

The matching algorithm will be:
For non-regex mode:
 (1) according to longest user part match
 (2) according to gateway's priority
 (3) randomly.
For regex mode:
 (1) according to gateway's priority
 (2) randomly.

In regex mode, the longest user part match doesn't make sense.  It will be
the admin's responsibility to properly design the routes.  The regex and
non-regex mode will be using different approaches for routing (there's no
hierarchical relation between them).


If we want to keep a similar matching algorithm for both modes, one
alternative would be to add a new field inside the lcr table that will be
used for "longest user match" part of the algorithm
(regex_matching_prefix_len).  The new field will be ignored in non-regex
mode.

In this case, the matching algorithm will be:
 (1) - (non-regex mode) according to longest user part match
     - (regex mode) according to "regex_matching_prefix_len" (big value
takes priority over small value)
 (2) according to gateway's priority
 (3) randomly.


If you don't think that is worth integrating it, please close the patch as
'Rejected'.



Regards,
Ovidiu Sas

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1736696&group_id=139143