9 Dec
2009
9 Dec
'09
7:37 p.m.
Hi Klaus,
Klaus Darilion wrote:
Maybe you can solve it by a mixture of kamailio tables and your tables
format. For example, "location" table is purely for Kamailio to store
location of registered client - thus integration with other systems is
often not needed. On the other hand, the "subscriber" table (user
provisioning) is often already present in different format.
I previously used Kamailio's location table for registration handling,
but instead of Kamailio's subscriber/user-avps/domain/db_aliases/...
table I used views which map the existing provisioning DB-structure to
Kamailio's structure (e.g. subscriber/domain/db_aliases are usually only
read-only - so it easy to make views).
This seems like it could be an easier route to get Kamailio/SIPRouter
into our environment. I will take a look at what is involved in
following the approach you suggest. Do you know where I can find the
table definitions for each module? Would it be listed in the module
documentation?
With regards the location information, we have custom built systems that
would need the information that is stored in the location table as well,
I am beginning to think that we may be able to work around that with
views or even triggers at some stage. I will need to investigate this
further though.
Thanks for the suggestion, I will certainly look in to it more.
Bruce