[Devel] Introduction and new module [rather long ;)]

[Bastian Friedrich]

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):
> 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.

Right.

The behaviour of the module is a little different, though: You load the module 
along with a parameter that points to the script:

loadmodule "/usr/local/lib/openser/modules/perl4ser.so"
modparam("perl4ser", "filename", "/path/to/test.pl")

You can then call arbitrary _functions_ defined in the test.pl, later:

route{
        perl4ser_run("myfunction");
[...]

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", 
right?

> , 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
> alright.

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.

Thx,
   Bastian

-- 
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.