2010/5/31 Juha Heinanen <jh(a)tutpro.com>om>:
Iñaki Baz Castillo writes:
So let's imagine a new table
'lcr_stopper_rules' with the following columns:
- id: Primary key as usual.
- rule_id: Integer pointing to an entry under 'lcr_rules' ('lcr') table.
inaki,
the above does not tie stopping to a certain prefix, but rules. what
determines if a given rule applies is:
lcr_id prefix from_uri
stopping should be tied to these three values, which would result in a
table containing
id lcr_id prefix from_uri stop
then there would be a table
id id_from_above_table grp_id priority
Juha, you are 100% right and you gave me the key of the current
problem: lcr rule definitions and lcr rule steps are merged now in
same table 'lcr'. They should be splited in two tables:
table 'lcr_rules':
- id: Id of the rule.
- lcr_id: instance of LCR.
- prefix
- from_uri
- stopper: 1/0
- enabled: 1/0
table 'lcr_rule_steps':
- id: Primary key as usual.
- rule_id: Intenger pointing to 'lcr_rules' entry.
- proirity: Priority of this step within its rule.
- gw_grp_id: Integer pointing to an entry in 'lcr_gw_groups'.
tables 'lcr_gw_groups' and 'lcr_gws' as defined in a previous mail.
perhaps we could handle the rest offline?
Ok, I'm connected to sip-router IRC channel right now. Or let me how
to conntact you whenever it's ok for you.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>