Hi Bastian,
a perl module is brilliant idea. I would call it 'perl' to be clear that
adds Perl extensions to OpenSER, same as we did with mysql/postgres ...
Such a module will bring lot of flexibility and powerful functionality
to configuration.
See my other comments inline.
On 11/14/06 12:23, Bastian Friedrich wrote:
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 :)
Initial intent
==============
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".
Solution
========
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.
New possibilities
=================
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
conventions ("rewrite_ruri(newuri)")?
openser style would integrate better in the scription, maybe prefixed by
'perl_' to be distinctive and suggestive, if you want to export
functions to openser configuration script. If it is about the Perl
library I think Perl-like style is better. So I would like to have (just
as example):
perl_exec("/sbin/script.pl");
and inside "/sbin/script.pl" to be able to use RewriteRURI(newuri). In
this way programming applications will look native in both sides.
* Do you have suggestions for additional functions?
Functions to access some internals of SIP message structure and global
environment would be great, like playing with flags, dst uri, branches,
AVPs, sockets... We can help if you have questions here
* 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?
Most of processings end up parsing all headers, for example the messages
going through nat processing. But if you can make it work with headers
type is better -- maybe as an improvement in next versions.
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... ;)
I would like to play with as soon as possible, even in early stages.
And now... For the questions.
=============================
Unfortunately, I was not yet able to find any "use these functions in your
module" type of documentation.
Maybe it can built along with this case. dokuwiki is a good place to
start a new doc project.
In some cases, it is difficult to gather the
authors' intentions by reading the code :(
All will be glad to help as much as possible and time allows.
* 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),
do_action() is used to execute the functions exported in configuration
script, it is like a generic function where you give the type of
function and parameters.
while the
*_lump functions let you arbitrarily modify the message. Is this correct?
yes, lump functions are used to change content of sip messages.
Add/remove header functions are using them.
In
this case, I'd rather create an interface for the "do_action" function...?
This should have higher priority, since there is no export of *_lump
functions for directly usage in configuration script.
* 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?
Should be no negative effect, parse functions should detect and return
immediately if the header was parsed already.
* 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?
yes
How
expensive are parse_headers
this is not very expensive, it parse the header in (name, body)
structure mainly. Just few of them do parsing of header content, and
those are parsed by default most of the time.
and parse_sip_msg_uri? Would you say it is
alright to always call these functions?
I do not know what you mean by 'always' -- if is needed, sure it is alright.
Looking forward to first version.
Cheers,
Daniel
I'll probably return with more questions during the next couple of months...
Thx a lot for your time and interest,
Bastian
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
