On Dienstag, 8. Dezember 2009, Bruce McAlister wrote:

We are looking to integrate SIPRouter/Kamailio into our existing infrastructure. Currently we have a sip proxy and registrar that handles registration and routing.

Hello Bruce,

The main issue we have with integrating SIPRouter/Kamailio into our environment is that the table structure for kamailio's tables are vastly different to our existing database tables.

We have several application built around our current database structure so I think it is fair to assume that we will be forced to use the existing structures.

I understand.

I had a look at perlvdb which seems to do what I had in plan, where the table structure is transparent to kamailio. so for example, when a registration request comes in and we then authenticate the user and want to save the location, could we use the perlvdb module to intercept the save and manipulate it so that it inserts/updates/reads data from a table structure that is different to what it is expecting?

I think you could use the perlvdb module as a kind of virtual DB module. To quote from the docs:

"The Perl Virtual Database (VDB) provides a virtualization framework for Kamailio's database access. It does not handle a particular database engine itself but lets the user relay database requests to arbitrary Perl functions."

I've been trying to find an example of how to use perlvdb but have been unsucessfull in my google searches and mailing list searches.

I never used it so far, so i can't give you examples or similar. But you can find probably additional informations about the design and the usage of the module in the (diploma) thesis from the author of this code, especially in the chapters 8-10:

http://www.bastian-friedrich.de/study/diploma/Diploma-BastianFriedrich.pdf

And do you already checked the samples in the module directory at perlvdb/doc/samples/ ?

Regards,

Henning

Bruce McAlister wrote:

Hi All,

We are looking to integrate SIPRouter/Kamailio into our existing infrastructure. Currently we have a sip proxy and registrar that handles registration and routing.

The main issue we have with integrating SIPRouter/Kamailio into our environment is that the table structure for kamailio's tables are vastly different to our existing database tables.

We have several application built around our current database structure so I think it is fair to assume that we will be forced to use the existing structures.

Hi Bruce!

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).

regards klaus

I had a look at perlvdb which seems to do what I had in plan, where the table structure is transparent to kamailio. so for example, when a registration request comes in and we then authenticate the user and want to save the location, could we use the perlvdb module to intercept the save and manipulate it so that it inserts/updates/reads data from a table structure that is different to what it is expecting?

I've been trying to find an example of how to use perlvdb but have been unsucessfull in my google searches and mailing list searches.

Does anyone have an example of how to use the perlvdb module?

Thanks Bruce

---

sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users