On Mittwoch, 9. Dezember 2009, Bruce McAlister 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?

Hello Bruce,

i also think this would be an easier way. For some of the important functions (like auth, location) there exists also some ways to use AVPs instead of the table content, so you could build your own queries with the sqlops module. And then you could do also a lot of checks in the script just with the PVs, transformations and logic operators.

You find the scheme definition docs in the wiki at
http://www.kamailio.org:80/dokuwiki/doku.php - point "Database structure".

Regards,

Henning