in sr_3.0 this works:
t_set_fr("$avp(i:722)", 5000);
but in kamailio_3.0 i get error:
0(27178) : <core> [cfg.y:3326]: parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 1983, column 31-34: Function parameter with integer value not allowed
why is that? i thought that k and sr are using the same tm module.
-- juha
Hello,
On 1/14/10 10:06 AM, Juha Heinanen wrote:
in sr_3.0 this works:
t_set_fr("$avp(i:722)", 5000);
but in kamailio_3.0 i get error:
0(27178) :<core> [cfg.y:3326]: parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 1983, column 31-34: Function parameter with integer value not allowed
why is that? i thought that k and sr are using the same tm module.
they use, but this one is thrown by core since in K function parameters must be enclosed in double quotes, e.g., "x").
Daniel
Daniel-Constantin Mierla writes:
they use, but this one is thrown by core since in K function parameters must be enclosed in double quotes, e.g., "x").
does sr accept either way, i.e., would
t_set_fr("$avp(i:722)", "5000");
work in sr or is there total incompatibility?
i feel strongly that core and tm should be the same in k and sr as the original idea was. it is not scalable to keep on sherry picking stuff from each other. after a short time, sherry picks start to fail and patches need to get done manually. after a bit longer time even that does not work anymore and the projects become separated again.
-- juha
On 1/14/10 8:42 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
they use, but this one is thrown by core since in K function parameters must be enclosed in double quotes, e.g., "x").
does sr accept either way, i.e., would
t_set_fr("$avp(i:722)", "5000");work in sr or is there total incompatibility?
it works as I understood from Andrei. Initially I thought is wrong and I forced in kamailio to use the classic way. Andrei cleared later that if an integer is given as parameter then is converted by core to string before passing to module.
Next k version will have this one enabled as well and probably will be no difference than packaging other sets of modules (and maybe compile flags enabled/disabled) between k and sr. With this release the main target was to have as much as possible backward compatibility with k1.5. There are some things that need to be discussed to get to one implementation and time was not sufficient for 3.0 (example: statistics).
Cheers, Daniel
i feel strongly that core and tm should be the same in k and sr as the original idea was. it is not scalable to keep on sherry picking stuff from each other. after a short time, sherry picks start to fail and patches need to get done manually. after a bit longer time even that does not work anymore and the projects become separated again.
-- juha
-
Daniel-Constantin Mierla -
jh＠tutpro.com