[Devel] Introduction and new module [rather long ;)]
bastian.friedrich at collax.com
Tue Nov 14 11:23:11 CET 2006
Dear OpenSER developer community,
Before starting with my questions, I'd first like to shortly introduce myself.
I've been studying computer sciences in Freiburg, Germany, for (quite) a while
now and now am writing my diploma thesis for the chair of communication
systems. The work itself is done here at Collax GmbH, an up-and-coming young
Linux company with future interest in VoIP technology.
The outcome of my work is to be published as Open Source. I'm looking forward
to see my code in the main OpenSER tree some time :)
The initial topic of my thesis was to provide LDAP access for OpenSER, esp.
for the alias and user database. Unfortunately, the current model is
restricted to a relational database model; introducing a configurable LDAP
backend would probably only be possible by rewriting the modules in concern,
as the definition of data paths is not a matter of "configuration" in the
common sense, but rather a matter of "programming".
The solution to this problem is the implementation of a perl module within
OpenSER. This module will make it possible for OpenSER adminitrators to
implement arbitrary request functions by the means of perl scripts. By adding
an easily usable LDAP interface, alias database requests will (hopefully) be
as easy as a one or two-line request.
A perl module within OpenSER will give a huge amount of new possibilities.
Instead of the hassles included when implementing custom modules, a simply
usable perl interface will provide the means to arbitrarily modify the
routing behavior within OpenSER. Quite possibly, current OpenSER
configuration files /may/ almost completely be rebuilt within perl.
Current state and perspective
The basic infrastructure for my module is running. Perl is integrated through
it's embedding mechanisms (see "perldoc perlembed"). The reverse direction,
modification of OpenSER structures from within perl, is done via XSUB
defintions. On the perl side, reading (msg->firstline.u.request.uri) and
updating the URI (alias_db's "rewrite_ruri") is already possible; arbitrary
header bodies can be retrieved. There's still lots of work to do, such as a
means to call arbitrary exported functions from other modules. Error handling
behavior is really bad, currently... ;)
I'm planning on implementing these functions:
* Get header names
* Get header list for one name
* Get full header
* Get full body
* Get full message
* Call functions from other modules (through "find_export")
* Rewrite URI
* Modify/Add a header line
Request for comments
A couple of questions are arising during my design, and I'd like to hear your
opinions about them.
* It needs a name! :)) Current suggestions include "perl4ser" and "PerSer"
("Perser" is german for "Persian")
* Structure from the perl view: I'm planing on creating an OpenSER package
plus a number of access packages for the message structures, such as
OpenSER::Message and OpenSER::URI.
* Naming conventions: Would you prefer "perl style" naming conventions, such
as "RewriteRURI(newuri)", or would you rather want OpenSER naming
* Do you have suggestions for additional functions?
* My current "GetHeader" works on arbitrary headers. Header parsing
(parse_headers()) thus is done for all header types; I'm using "~0" (all
ones) as the "flags" parameter. Will this create too much overhead? Should I
restrict the call to certain header types?
Any suggestions for the project are welcome. Let me know how far you're
interested in the "perl idea"; if you just don't mind, you probably don't
want to take any influence... ;)
And now... For the questions.
Unfortunately, I was not yet able to find any "use these functions in your
module" type of documentation. In some cases, it is difficult to gather the
authors' intentions by reading the code :(
* There seems to be a relation between what can be done by the "do_action"
and "append_new_lump" functions. My understanding is that "do_action" is
sort of "typed" (as you add types of actions with parameters), while the
*_lump functions let you arbitrarily modify the message. Is this correct? In
this case, I'd rather create an interface for the "do_action" function...?
* Is it correct that there are not too many negative effects when
calling "parse_headers" multiple times? The function will know that it
already parsed the header types concerned and (more or less) instantly
return - correct?
* After calling parse_headers and parse_sip_msg_uri, most "global" parsing
should be done, i.e. the header fields plus RURI are available. Other
parsing functions (e.g. parse_content_disposition,
parse_content_length, ...) are rarely necessary. Right or wrong? How
expensive are parse_headers and parse_sip_msg_uri? Would you say it is
alright to always call these functions?
I'll probably return with more questions during the next couple of months...
Thx a lot for your time and interest,
Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany
p: +49 (0) 761-45684-24
f: +49 (0) 761-45684-10 www.collax.com
\ To be, or not to be, those are the parameters.
More information about the Devel