2010/5/31 Juha Heinanen <[email protected]>: > 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 <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
