Hello,
I have uploaded xlog and (stripped) pv Kamailio/Openser modules to
sip-router.org site at:
http://sip-router.org/pub/tmp/miconda/
If you are willing to test them, then just get the branch "master" from
git and merge with "daniel/pv". Details about GIT repository:
http://sip-router.org/2008/11/18/git-repository-online/
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:
http://lists.sip-router.org/pipermail/sr-dev/
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
sip-router.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
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
that avp.
As I haven't seen any related discussions for quite some time, the
functionality might not be updated all over the code.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
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
style).
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.
Any comments?
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.
Andrei