Copyright © 2007 Collax GmbH
| Revision History | |
|---|---|
| Revision $Revision: 5901 $ | $Date: 2013-01-29 13:35:11 +0100 (Tue, 29 Jan 2013) $ |
Table of Contents
List of Examples
The time needed when writing a new OpenSIPS module unfortunately is quite high, while the options provided by the configuration file are limited to the features implemented in the modules.
With this Perl module, you can easily implement your own OpenSIPS extensions in Perl. This allows for simple access to the full world of CPAN modules. SIP URI rewriting could be implemented based on regular expressions; accessing arbitrary data backends, e.g. LDAP or Berkeley DB files, is now extremely simple.
This Perl module is loaded in opensips.cfg (just like all the other modules) with loadmodule("/path/to/perl.so");.
For the Perl module to compile, you need a reasonably recent version of perl (tested with 5.8.8) linked dynamically. It is strongly advised to use a threaded version. The default binary packages from your favorite Linux distribution should work fine.
Cross compilation is supported by the Makefile. You need to set the environment variables PERLLDOPTS, PERLCCOPTS and TYPEMAP to values similar to the output of
PERLLDOPTS: perl -MExtUtils::Embed -e ldopts
PERLCCOPTS: perl -MExtUtils::Embed -e ccopts
TYPEMAP: echo "`perl -MConfig -e 'print $Config{installprivlib}'`/ExtUtils/typemap"
The exact position of your (precompiled!) perl libraries depends on the setup of your environment.
The Perl module has two interfaces: The perl side, and the OpenSIPS side. Once a Perl function is defined and loaded via the module parameters (see below), it may be called in OpenSIPS's configuration at an arbitary point. E.g., you could write a function "ldap_alias" in Perl, and then execute
...
if (perl_exec("ldap_alias")) {
...
}
...
just as you would have done with the current alias_db module.
The functions you can use are listed in the "Exported Functions" section below.
On the Perl side, there are a number of functions that let you read and modify the current SIP message, such as the RURI or the message flags. An introduction to the Perl interface and the full reference documentation can be found below.
The following modules must be loaded before this module:
The "sl" module is needed for sending replies uppon fatal errors. All other modules can be accessed from the Perl module, though.
The following libraries or applications must be installed before running OpenSIPS with this module loaded:
Perl 5.8.x or later
Additionally, a number of perl modules should be installed. The OpenSIPS::LDAPUtils package relies on Net::LDAP to be installed. One of the sample scripts needs IPC::Shareable
This module has been developed and tested with Perl 5.8.8, but should work with any 5.8.x release. Compilation is possible with 5.6.x, but its behavior is unsupported. Earlier versions do not work.
On current Debian systems, at least the following packages should be installed:
perl
perl-base
perl-modules
libperl5.8
libperl-dev
libnet-ldap-perl
libipc-shareable-perl
It was reported that other Debian-style distributions (such as Ubuntu) need the same packages.
On SuSE systems, at least the following packages should be installed:
perl
perl-ldap
IPC::Shareable perl module from CPAN
Although SuSE delivers a lot of perl modules, others may have to be fetched from CPAN. Consider using the program “cpan2rpm” - which, in turn, is available on CPAN. It creates RPM files from CPAN.
This is the file name of your script. This may be set once only, but it may include an arbitary number of functions and “use” as many Perl module as necessary.
May not be empty!
Example 1.1. Set filename parameter
...
modparam("perl", "filename", "/home/john/opensips/myperl.pl")
...
The path to the Perl modules included (OpenSIPS.pm et.al). It is not absolutely crucial to set this path, as you may install the Modules in Perl's standard path, or update the “%INC” variable from within your script. Using this module parameter is the standard behavior, though.
Example 1.2. Set modpath parameter
...
modparam("perl", "modpath", "/usr/local/lib/opensips/perl/")
...
Calls a perl function without passing it the current SIP message. May be used for very simple simple requests that do not have to fiddle with the message themselves, but rather return information values about the environment.
The first parameter is the function to be called. An arbitrary string may optionally be passed as a parameter.
This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, ONREPLY_ROUTE and BRANCH_ROUTE.
Example 1.3. perl_exec_simple() usage
...
if (method=="INVITE") {
perl_exec_simple("dosomething", "on invite messages");
};
...
Calls a perl function with passing it the current SIP message. The SIP message is reflected by a Perl module that gives you access to the information in the current SIP message (OpenSIPS::Message).
The first parameter is the function to be called. An arbitrary string may be passed as a parameter.
This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, ONREPLY_ROUTE and BRANCH_ROUTE.
This module provides access to a limited number of OpenSIPS core functions. As the most interesting functions deal with SIP messages, they are located in the OpenSIPS::Message class below.
Logs the message with OpenSIPS's logging facility. The logging level is one of the following:
* L_ALERT * L_CRIT * L_ERR * L_WARN * L_NOTICE * L_INFO * L_DBG
Please note that this method is NOT automatically exported, as it collides
with the perl function log (which calculates the logarithm). Either
explicitly import the function (via use OpenSIPS qw ( log );), or call
it with its full name:
OpenSIPS::log(L_INFO, "foobar");
This package provides access functions for an OpenSIPS sip_msg structure and its
sub-components. Through its means it is possible to fully configure
alternative routing decisions.
Returns one of the constants SIP_REQUEST, SIP_REPLY, SIP_INVALID stating the type of the current message.
Returns the status code of the current Reply message. This function is invalid in Request context!
Returns the reason of the current Reply message. This function is invalid in Request context!
This function returns the recipient URI of the present SIP message:
my $ruri =
$m->getRURI();
getRURI returns a string. See “getParsedRURI()” below how to receive a parsed structure.
This function is valid in request messages only.
Returns the current method, such as INVITE, REGISTER, ACK and so on.
my $method =
$m->getMethod();
This function is valid in request messages only.
Returns the full message header as present in the current message. You might use this header to further work with it with your favorite MIME package.
my $hdr =
$m->getFullHeader();
Returns the body of the first message header with this name.
print
$m->getHeader("To");
"John"
<sip:john@doe.example>
Search for an arbitrary function in module exports and call it with the parameters self, string1, string2.
string1 and/or string2 may be omitted.
As this function provides access to the functions that are exported to the OpenSIPS configuration file, it is autoloaded for unknown functions. Instead of writing
$m->moduleFunction("sl_send_reply", "500", "Internal Error");
$m->moduleFunction("xlog", "L_INFO", "foo");you may as well write
$m->sl_send_reply("500", "Internal Error");
$m->xlog("L_INFO", "foo");WARNING
In OpenSIPS 1.2, only a limited subset of module functions is available. This restriction will be removed in a later version.
Here is a list of functions that are expected to be working (not claiming completeness):
* alias_db_lookup * consume_credentials * is_rpid_user_e164 * append_rpid_hf * bind_auth * avp_print * cpl_process_register * cpl_process_register_norpl * load_dlg * ds_next_dst * ds_next_domain * ds_mark_dst * ds_mark_dst * is_from_local * is_uri_host_local * dp_can_connect * dp_apply_policy * enum_query (without parameters) * enum_fquery (without parameters) * is_from_user_enum (without parameters) * i_enum_query (without parameters) * imc_manager * jab_* (all functions from the jabber module) * sdp_mangle_ip * sdp_mangle_port * encode_contact * decode_contact * decode_contact_header * fix_contact * use_media_proxy * end_media_session * m_store * m_dump * fix_nated_contact * unforce_rtp_proxy * force_rtp_proxy * fix_nated_register * add_rcv_param * options_reply * checkospheader * validateospheader * requestosprouting * checkosproute * prepareosproute * prepareallosproutes * checkcallingtranslation * reportospusage * mangle_pidf * mangle_message_cpim * add_path (without parameters) * add_path_received (without parameters) * prefix2domain * allow_routing (without parameters) * allow_trusted * pike_check_req * handle_publish * handle_subscribe * stored_pres_info * bind_pua * send_publish * send_subscribe * pua_set_publish * loose_route * record_route * load_rr * sip_trace * sl_reply_error * sms_send_msg * sd_lookup * sstCheckMin * append_time * has_body (without parameters) * is_peer_verified * t_newtran * t_release * t_relay (without parameters) * t_flush_flags * t_check_trans * t_was_cancelled * uac_restore_from * uac_auth * has_totag * tel2sip * check_to * check_from * radius_does_uri_exist * ul_* (All functions exported by the usrloc module for user access) * xmpp_send_message
Logs the message with OpenSIPS's logging facility. The logging level is one of the following:
* L_ALERT * L_CRIT * L_ERR * L_WARN * L_NOTICE * L_INFO * L_DBG
The logging function should be accessed via the OpenSIPS module variant. This one, located in OpenSIPS::Message, is deprecated.
Sets a new destination (recipient) URI. Useful for rerouting the current message/call.
if ($m->getRURI() =~ m/\@somedomain.net/) {
$m->rewrite_ruri("sip:dispatcher\@organization.net");
}Sets a message flag. The constants as known from the C API may be used, when Constants.pm is included.
Returns a new string where all pseudo variables are substituted by their values. Can be used to receive the values of single variables, too.
Please remember that you need to escape the '$' sign in perl strings!
This package provides functions for access to sip_uri structures.
This package provides access functions for OpenSIPS's AVPs. These variables can be created, evaluated, modified and removed through this package.
Please note that these functions do NOT support the notation used in the configuration file, but directly work on strings or numbers. See documentation of add method below.
Add an AVP.
Add an OpenSIPS AVP to its environment. name and val may both be integers or strings; this function will try to guess what is correct. Please note that
OpenSIPS::AVP::add("10", "10")is something different than
OpenSIPS::AVP::add(10, 10)
due to this evaluation: The first will create _string_ AVPs with the name 10, while the latter will create a numerical AVP.
You can modify/overwrite AVPs with this function.
get an OpenSIPS AVP:
my $numavp = OpenSIPS::AVP::get(5);
my $stravp = OpenSIPS::AVP::get("foo");OpenSIPS::Utils::PhoneNumbers - Functions for canonical forms of phone numbers.
use OpenSIPS::Utils::PhoneNumbers;
my $phonenumbers = new OpenSIPS::Utils::PhoneNumbers(
publicAccessPrefix => "0",
internationalPrefix => "+",
longDistancePrefix => "0",
areaCode => "761",
pbxCode => "456842",
countryCode => "49"
);
$canonical = $phonenumbers->canonicalForm("07612034567");
$number = $phonenumbers->dialNumber("+497612034567");A telphone number starting with a plus sign and containing all dial prefixes is in canonical form. This is usally not the number to dial at any location, so the dialing number depends on the context of the user/system.
The idea to canonicalize numbers were taken from hylafax.
Example: +497614514829 is the canonical form of my phone number, 829 is the number to dial at Pyramid, 4514829 is the dialing number from Freiburg are and so on.
To canonicalize any number, we strip off any dial prefix we find and then add the prefixes for the location. So, when the user enters the number 04514829 in context pyramid, we remove the publicAccessPrefix (at Pyramid this is 0) and the pbxPrefix (4514 here). The result is 829. Then we add all the general dial prefixes - 49 (country) 761 (area) 4514 (pbx) and 829, the number itself => +497614514829
To get the dialing number from a canonical phone number, we substract all general prefixes until we have something
As said before, the interpretation of a phone number depends on the
context of the location. For the functions in this package, the
context is created through the new operator.
The following fields should be set:
'longDistancePrefix' 'areaCode' 'pbxCode' 'internationalPrefix' 'publicAccessPrefix' 'countryCode'
This module exports the following functions when useed:
The new operator returns an object of this type and sets its locational context according to the passed parameters. See OpenSIPS::Utils::PhoneNumbers above.
Convert a phone number (given as first argument) into its canonical form. When no context is passed in as the second argument, the default context from the systems configuration file is used.
OpenSIPS::LDAPUtils::LDAPConf - Read openldap config from standard config files.
use OpenSIPS::LDAPUtils::LDAPConf; my $conf = new OpenSIPS::LDAPUtils::LDAPConf();
This module may be used to retrieve the global LDAP configuration as
used by other LDAP software, such as nsswitch.ldap and pam-ldap. The configuration is
usualy stored in /etc/openldap/ldap.conf
When used from an account with sufficient privilegs (e.g. root), the ldap manager passwort is also retrieved.
Returns an uri to contact the ldap server. When there is no
ldap_uri in the configuration file, an ldap: uri is constucted from host
and port.
Returns the ldap "root" password.
Note that the rootbindpw
is only available when the current account has sufficient privilegs
to access /etc/openldap/ldap.secret.
Returns the DN to use for authentication to the ldap server. When
no bind dn has been specified in the configuration file, returns
the rootbinddn.
OpenSIPS::LDAPUtils::LDAPConnection - Perl module to perform simple LDAP queries.
OO-Style interface:
use OpenSIPS::LDAPUtils::LDAPConnection;
my $ldap = new OpenSIPS::LDAPUtils::LDAPConnection;
my @rows = $ldap-search("uid=andi","ou=people,ou=coreworks,ou=de");Procedural interface:
use OpenSIPS::LDAPUtils::LDAPConnection;
my @rows = $ldap->search(
new OpenSIPS::LDAPUtils::LDAPConfig(), "uid=andi","ou=people,ou=coreworks,ou=de");
This perl module offers a somewhat simplified interface to the
Net::LDAP functionality.
It is intended for cases where just a few attributes should be
retrieved without the overhead of the full featured Net::LDAP.
Set up a new LDAP connection.
The first argument, when given, should be a hash reference pointing
to to the connection parameters, possibly an OpenSIPS::LDAPUtils::LDAPConfig
object. This argument may be undef in which case a new
(default) OpenSIPS::LDAPUtils::LDAPConfig
object is used.
When the optional second argument is a true value, the connection will be authenticated. Otherwise an anonymous bind is done.
On success, a new LDAPConnection object is
returned, otherwise the result is undef.
perform an ldap search, return the dn of the first matching directory entry, unless a specific attribute has been requested, in wich case the values(s) fot this attribute are returned.
When the first argument (conf) is a OpenSIPS::LDAPUtils::LDAPConnection,
it will be used to perform the queries. You can pass the first
argument implicitly by using the "method" syntax.
Otherwise the conf
argument should be a reference to a hash containing the connection
setup parameters as contained in a OpenSIPS::LDAPUtils::LDAPConf
object. In this mode, the OpenSIPS::LDAPUtils::LDAPConnection
from previous queries will be reused.
configuration object, used to find host,port,suffix and use_ldap_checks
ldap search filter, eg '(mail=some@domain)'
search base for this query. If undef use default suffix, concat base with default suffix if the last char is a ','
retrieve the given attributes instead of the dn from the ldap directory.
This package is an (abstract) base class for all virtual databases. Derived packages can be configured to be used by OpenSIPS as a database.
The base class itself should NOT be used in this context, as it does not provide any functionality.
This package provides a number of constants taken from enums and defines of OpenSIPS header files. Unfortunately, there is no mechanism for updating the constants automatically, so check the values if you are in doubt.
This package is intended for usage with the alias_db module. The query VTab has to take two arguments and return an array of two arguments (user name/domain).
This package is an Adapter for the acc and siptrace modules, featuring only an insert operation.
This package is intended for debug usage. It will print information about requested functions and operations of a client module.
Use this module to request schema information when creating new adapters.
This adapter is intended for usage with the auth_db module. The VTab should take a username as an argument and return a (plain text!) password.
This package represents a request condition for database access, consisting of a column name, an operator (=, <, >, ...), a data type and a value.
This package inherits from OpenSIPS::VDB::Pair and thus includes its methods.
This package represents database key/value pairs, consisting of a key, a value type, and the value.
This package inherits from OpenSIPS::VDB::Value and thus has the same methods.
This package handles virtual tables and is used by the OpenSIPS::VDB class to store information about valid tables. The package is not inteded for end user access.
This package represents a database value. Additional to the data itself, information about its type is stored.
When accessing a OpenSIPS::VDB::Value object as a string, it simply returns its data regardless of its type. =cut
use strict;
package OpenSIPS::VDB::Value;
use overload '""' => \&stringify;
sub stringify { shift->{data} }
use OpenSIPS; use OpenSIPS::Constants;
our @ISA = qw ( OpenSIPS::Utils::Debug );
Constructs a new Value object. Its data type and the data are passed as parameters.
Returns or sets the current data type. Please consider using the constants from OpenSIPS::Constants
This package represents database column definition, consisting of a column name and its data type.
When accessing a OpenSIPS::VDB::Column object as a string, it simply returns its column name regardless of its type. =cut
package OpenSIPS::VDB::Column;
use overload '""' => \&stringify;
sub stringify { shift->{name} }
use OpenSIPS; use OpenSIPS::Constants;
our @ISA = qw ( OpenSIPS::Utils::Debug );
Constructs a new Column object. Its type and the name are passed as parameters.
Returns or sets the current type. Please consider using the constants from OpenSIPS::Constants
This class represents a VDB result set. It contains a column definition, plus an array of rows. Rows themselves are simply references to arrays of scalars.
The constructor creates a new Result object. Its first parameter is a reference to an array of OpenSIPS::VDB::Column objects. Additional parameters may be passed to provide initial rows, which are references to arrays of scalars.
There are a number of example scripts in the “samples/”. They are documented well. Read them, it will explain a lot to you :)
If you want to use any of these scripts directly in your implementation, you can use Perl's “require” mechanism to import them (just remember that you need to use quotes when require'ing .pl files).
The included sample scripts are described below:
The minimal function in branches.pl demonstrates that you can access the "append_branch" function from within perl, just as you would have done from your normal configuration file. You'll find documentation on the concepts of branching in the OpenSIPS documentation.
Message's first_line structure may be evaluated. Message can be either of SIP_REQUEST or SIP_REPLY. Depending on that, different information can be received. This script demonstrates these functions.
The perl module provides access to OpenSIPS's flagging mechanism. The flag names available for OpenSIPS modules are made available through the OpenSIPS::Constants package, so you can flag messages as "green", "magenta" etc.
The first function, setflag, demonstrates how the "green" flag is set. In the second function, readflag, the "green" and "magenta" flags are evaluated.
This sample script demonstrates different things related to calling functions from within perl, and the different types of functions you can offer for OpenSIPS access.
“exportedfuncs” simply demonstrates that you can use the moduleFunction method to call functions offered by other modules. The results are equivalent to calling these functions from your config file. In the demonstrated case, telephone calls with a destination number beginning with 555... are rejected with an internal server error. Other destination addresses are passed to the alias_db module.
Please note that the moduleFunction method is not fully available in OpenSIPS 1.2. See the method's documentation for details.
“paramfunc” shows that you can pass arbitrary strings to perl functions. Do with them whatever you want :)
“autotest” demonstrates that unknown functions in OpenSIPS::Message objects are automatically transformed into calls to module functions.
The “diefunc”s show that dying perl scripts - by "manual" dying, or because of script errors - are handled by the OpenSIPS package. The error message is logged through OpenSIPS's logging mechanism. Please note that this only works correctly if you do NOT overwrite the default die handler. Oh, yes, that works for warnings, too.
Header extraction is among the most crucial functionalities while processing SIP messages. This sample script demonstrates access to header names and values within two sample functions.
“headernames” extracts all header names and logs their names.
“someheaders” logs the contents of the two headers, “To” and “WWW-Contact”. As you can see, headers that occur more than once are retrieved as an array, which may be accessed by Perl's array accessing methods.
For debugging purposes, you probably want to write messages to the syslog. The “logdemo” shows three ways to access the OpenSIPS log function: it is available through the OpenSIPS class as well as through the OpenSIPS::Message class.
Remember that you can use exported functions from other modules. You may thus as well use the “xlog” module and it's xlog function.
The L_INFO, L_DBG, L_ERR, L_CRIT... constants are available through the OpenSIPS::Constants package.
This script demonstrates how to access the whole message header of the current message. Please note that modifications on the message made by earlier function calls in your configuration script may NOT be reflected in this dump.
When processing SIP messages, you may want to use persistent data across multiple calls to your Perl functions. Your first option is to use global variables in your script. Unfortunately, these globals are not visible from the mulitple instances of OpenSIPS. You may want to use a mechanism such as the IPC::Shareable shared memory access package to correct this.
The OpenSIPS::Utils::PhoneNumbers package provides two methods for the transformation of local to canonical telephone numbers, and vice versa. This script demonstrates it's use.
This script demonstrates the Perl module's “pseudoVar” method. It may be used to retrieve the values of current pseudo variables.
You might notice that there is no particular function for setting pseudo variables; you may use the exported functions from the avpops module, though.
4.1. | Are there known bugs in the Perl module? |
The Perl module does have a few shortcomings that may be regarded as bugs.
| |
4.2. | Where can I find more about OpenSIPS? |
Take a look at http://www.opensips.org/. | |
4.3. | Where can I post a question about this module? |
First at all check if your question was already answered on one of our mailing lists:
E-mails regarding any stable OpenSIPS release should be sent to
If you want to keep the mail private, send it to
| |
4.4. | How can I report a bug? |
Please follow the guidelines provided at: https://github.com/OpenSIPS/opensips/issues. |