according to textops readme:
2.1. Kamailio Modules
The following modules must be loaded before this module: * sl -- Stateless replies.
however, i get these errors if pv module is not loaded before textops module:
Mar 14 10:14:52 wheezy1 sip-proxy[4707]: ERROR: <core> [pvapi.c:790]: pv_parse_spec2(): error searching pvar "avp" Mar 14 10:14:52 wheezy1 sip-proxy[4707]: ERROR: <core> [pvapi.c:994]: pv_parse_spec2(): wrong char [s/115] in [$avp(s:rpid)] at [5 (5)] Mar 14 10:14:52 wheezy1 sip-proxy[4707]: ERROR: siputils [rpid.c:73]: init_rpid_avp(): malformed or non AVP $avp(s:rpid) AVP definition Mar 14 10:14:52 wheezy1 sip-proxy[4707]: ERROR: siputils [siputils.c:235]: mod_init(): failed to init rpid AVP name Mar 14 10:14:52 wheezy1 sip-proxy[4707]: ERROR: <core> [sr_module.c:970]: init_mod(): init_mod(): Error while initializing module siputils (/usr/lib/sip-proxy/modules/siputils.so)
please fix textops module so that it does not depend on pv module if rpid_avp is not set.
-- juha
Is it really about textops module, because the logs are from siputils, or I am missing something obvious?
Cheers, Daniel
On 14/03/14 09:17, Juha Heinanen wrote:
On 14/03/14 21:18, Juha Heinanen wrote:
Actually this is a more generic topic, because most of the functions as well as many parameters can take pseudo-variables. The pseudo-variables are spread across lot of modules, therefore at the end is about how config is written.
Just for example, based on such logic, lcr should depend on all modules that export variables because the parameters of its functions take pseudo-variables.
However, so far dependencies in the readme were listing the modules to which are internal bindings to access their functions/values. In this case is no direct binding from siputils to pv. The pv framework is in the core and it is what siputils uses, but the implementation of the avp as pseudo variable is in pv module.
On the other hand, personally I have nothing against to enhance docs to better reflect this. Feel free to add as you consider more suggestive. Cheers, Daniel
On 14/03/14 23:24, Juha Heinanen wrote:
looking strictly to that, you are not, set the rpid related parameter to "".
Cheers, Daniel
Daniel-Constantin Mierla writes:
it should be the other way around, i.e., the default should be that rpid avp is not set, like is the case with all avp related lcr params. otherwise, when someone adds new functions like these to some module, it suddenly starts to depend something else.
-- juha
On 14/03/14 23:36, Juha Heinanen wrote:
I have nothing against to be changed, rpid is not really used these days. That piece of code is probably from 10 years ago.
Cheers, Daniel