I have uploaded xlog and (stripped) pv Kamailio/Openser modules to
sip-router.org site at:
If you are willing to test them, then just get the branch "master" from
git and merge with "daniel/pv". Details about GIT repository:
The pv module does not include yet the pseudo-variables and
transformations dependent of K/O extensions (e.g., branch, script flags,
...). Probably one important to decide upon is the AVP (to start a new
discussion about it separately). The ones missing now will be gradually
activated as dependent code is sorted out. Testing and feedback is welcome.
Andrei is doing heavy work to improve the config script interpreter for
string and arithmetic operations, you can track the commits at:
Once work is finished and the developers' branches are merged, we can
mark an important milestone - K/O pseudo-variables working in sip-router
config file, opening full functionality for large set of K/O modules and
clean compatibility of config files for many typical deployments.
SIP-Router is able to load now both types of modules: ser and k/o. DB
APIs from both projects were tested as library, from K/O point of view
mi and statistics API are the extensions yet to be made libraries for
while adapting the PV API, I got into the AVP script flags? Is anyone
still using them? If yes, for what purpose, maybe we can figure out a
nicer way and drop these flags.
We have to find the solution to make AVPs from kamailio/openser and ser
compatible in the new sip-router.org project.
Just for those not being sure what I am talking about, avp names can
have flags after the name type specifier, like:
$avp(i3:23) - meaning that flags 1 and 2 (bitmask ...0011) are set for
As I haven't seen any related discussions for quite some time, the
functionality might not be updated all over the code.
It would be better to have different operators for strings and for
integers. Right now we have '+', '==' and '!=' that can be used both for
strings and integers. The problem with this approach is that it makes
some optimizations impossible, especially when combined with dynamic
typed variables (avps or pvars). '+' is especially bad because one
can tell what type ($v + x) has only at runtime.
I think having perl like operators would help a lot:
- '.' for string concatenation (instead of reusing '+'), e.g.:
$v= "foo" . "bar"
- 'eq' instead of == for strings, e.g.: $v eq "bar"
- 'ne' instead of != for strings, e.g.: $v ne "bar"
We could support them right now in parallel with the old ones and
obsolete +, == and != for strings in the future (but that means we
still cannot optimize '+' in all the cases) or switch right now
(maybe with some old compat switch which will support old scripts
The question is how much are they used right now. While I think '==' and
'!=' are used quite often, I'm not sure about '+' for strings (and '+'
is the most important anyway).
Note: we can still support '==' and '!=' for condition tests not
involving variables (e.g. method=="INVITE", uri=="sip:foo" a.s.o.).
Another advantage that this change would bring is better type checking
at startup (more errors flagged without having to run the script) and
possible implicit conversions (e.g. int to string or string to int) if
we decide to support them.
In the future it would also be much better to have typed script vars
(e.g. int $var1). This would help a lot in checking the script for
correctness. With the dynamic typed vars, one has to run the script to
find errors. It would also help in optimizing, but not so much if we
separate the operators, like above.
As you probably have noticed the git repository for sip-router is now
It was started from ser core and tm.
(read only, slower, git://... recomended)
(read write but account on git.sip-router.org needed)
Web interface: http://git.sip-router.org/cgi-bin/gitweb.cgi
Branches acl: the repository is setup so that you can write/commit
only to the following branches:
We'll add access to more branches as needed (I've added this rules to
avoid creating lots of "root" branches by mistake, e.g. git pull
from a local branch without a refspec).
Please create the commit messages following the git convention
(start with one short line, preferably less then 50 chars summarizing
the changes, then one empty line and then a more detailed description).
Quick git introduction:
# clone the repo into the sip-router directory
git clone git://git.sip-router.org/sip-router
git branch -a # show all branches
# create a local branch based on origin/andrei/mod_f_params
git checkout --track -b my_branch origin/andrei/mod_f_params
git log # see commit log
git log --pretty=oneline # only the first line from each commit
git add Makefile.defs
git commit # or git commmit -a to skip the add step and commit all
# changed files
# push changes back (note you need ssh access for this)
# note: the next command will fail, unless your username is andrei :-)
# publish changes on the local "my_branc" to the remote
git push origin my_branch:andrei/mod_f_params
# or push them into the master branch if you are sure about them
git push origin my_branch:master
For more info about git try:
and if you want to know how it works:
CVS_SERVER="git cvsserver" cvs \
-d :ext:email@example.com/sip-router co master
(instead of master you can use any other branch name that doesn't
include a '/')
The initial checkout takes a while, but after that cvs update seems fast
SVN access: unfortunately we do not have it. It looks like the
git svnserver is in the project stage (there is some python code but not
runnable yet). There is a way around it, but it would be quite complex
to setup: a git to svn gateway and then svn to git imports.
Other repositories on git.sip-router.org:
ser - entire ser updated from cvs
ser_core - only ser_core, automatically updated from cvs, read-only
test - test repository, contains an early sip-router version, it has the
same access rules as sip-router (if you have something you want
to test, please use it rather then trying directly on
Special thanks go to Jan, who not only did setup git.sip-router.org
(including automatic cvs sync for some of the repos), but he's also
hosting it on one of his private machines.