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