8 Dec
2009
8 Dec
'09
2:36 p.m.
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.
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
8 Dec
8 Dec
7:13 p.m.
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
9 Dec
9 Dec
9:32 a.m.
Hi Henning,
Henning Westerholt wrote:
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/ ?
Thanks for the link to the pdf, I will have a look through this
information to see if it will suite to implement in our environment.
I've not yet looked at the samples in the perlvdb directory, I will take
a look over the course of the day.
Thanks again for the info.
Bruce
12:24 a.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9:37 a.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
10:39 a.m.
Bruce McAlister wrote:
Hi Klaus,
Klaus Darilion wrote:
They are included in the source tarball. In Kamailio, they are in
scripts/mysql or scripts/pgsql inside the root directory.
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
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?
11:19 a.m.
On Mittwoch, 9. Dezember 2009, Bruce McAlister wrote:
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
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?
5259
days inactive
5260
days old
6 comments
4 participants
participants (4)
-
Alex Balashov -
Bruce McAlister -
Henning Westerholt -
Klaus Darilion