[Devel] Introduction and new module [rather long ;)]
bastian.friedrich at collax.com
Tue Nov 14 16:06:41 CET 2006
Hi Daniel et al,
Am Dienstag, 14. November 2006 12:12 schrieb Daniel-Constantin Mierla:
> 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 ...
ACK. Sounds sensible :)
> > * 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.
This is exactly how how I see it.
> So I would like to have (just
> as example):
> and inside "/sbin/script.pl" to be able to use RewriteRURI(newuri). In
> this way programming applications will look native in both sides.
The behaviour of the module is a little different, though: You load the module
along with a parameter that points to the script:
modparam("perl4ser", "filename", "/path/to/test.pl")
You can then call arbitrary _functions_ defined in the test.pl, later:
By handling the file name as a module parameter, the perl interpreter only has
to be initialized once. Parsing and compilation are done at initialization
time. Calling the function will be very inexpensive, then.
I should add a "re-init function" accessible via the fifo routines to allow
re-loading of perl scripts without reloading OpenSER. Routing could then be
modified without restarting OpenSER.
> > * 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,
I.e. the functions from flags.h? Should be easy.
> dst uri
I'm quite new to the topic, so bear with me... dst uri is the same as "RURI",
> , branches,
Right. I need to look into that one.
> AVPs, sockets...
> We can help if you have questions here
I'll come back to that ;)
> > * 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.
The downside of this behaviour is that the perl script needs to _know_ what
headers to parse. I expect the average author of such perl scripts to be an
arbitrary OpenSER _user_ instead of a developer; taking over the work for him
would imho be an advantage.
Maybe I'll find a solution.
> > 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
Current implementation: Uppon calling any perl function, parse_sip_msg_uri is
called before passing execution flow to the perl function. First step in the
new Perl function "GetHeader" is the execution of parse_headers. From what I
gather from your mail, this should be OK :)
Daniel, I'll write a seperate mail to you off-list.
Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany
p: +49 (0) 761-45684-24
f: +49 (0) 761-45684-10 www.collax.com
\ Despite the high cost of living, it remains popular.
More information about the Devel