Layout:
db = [sipxconfig|sipxuseragent]
${domain}:
${userid}:
permissions
call-forwarding
dial-by-name
ex
subscriptions
registrations
aliases
Examples:
sipxconfig (replication Plan A*)
example.com:
uid : 200
prm : { AA, VM, CustomPermission }
fwd : {100, [email protected]}
*dbn : { 2312, 5528 }
alias : {joe, 21312423}
sipxuseragent (replication Plan B*)
example.com
master01
uid : 200
sub {[email protected]}
reg : {[email protected]?lorem=ipsum&expires=2}
slave01:
uid : 200
reg : {[email protected]?lorem=ipsum&expires=1,
[email protected]?blah=blah}
* dbn - dial-by-name, a unique id that is balanced by sipxconfig using
dtmf to letters alg.. May not need this, looks like sipXivr does this
on the fly, but not entirely sure. it would obviously be much more
efficient to do this in sipxconfig so sipxivr doesn't have to load
10000 users each time someone tries to dial-by-name and attempt
decache the results when there is a change to the data.
* Replication Plan A - sipXconfig owns master, all other nodes slave
* Replication Plan B - Each SIP server is a master, but some rules to honor
- never update a record, only delete and add to allow for
master-master replication
* the sipxuseragent is still a ways out, we have time to think about
this. trick part is allowing 2 or more servers to write to the same
database without violating restrictions of master-master configuration
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
