I noticed that my ul.add command that works OK in 5.0 doesn't anymore work in 5.1. I get back to the xmlrpc query:
<name>faultString</name> <value><string>Not enough parameters or wrong format</string></value>
I then went and compared ul.add in 5.0 and 5.1 and noticed that in 5.1 it has added two optional params:
received (optional) value with the received-from address (source address) (use '0' or '.' if it should not be set). Format: sip:srcip:srcport;transport=abc
socket (optional) value with the local socket address (use '0' or '.' if it should not be set). Format: proto:localip:localport
Note: the position of parameters is relevant, in the case of optional parameters, use '0' or '.' for parameters that should not be set which are positioned before any parameter that has to be set.
What does that mean? Isn't optional really optional, but 0 or . is needed?
-- Juha
Hello,
if you don't need to provide any of those parameters, then it should just work by not having them in the command.
But, for example, if you want to provide socket only, which is after the received as parameter order, then you must provide received parameter as well and use . or 0 to specify that received should not stored.
Cheers, Daniel
On Wed, Oct 18, 2017 at 10:24 AM, Juha Heinanen jh@tutpro.com wrote:
I noticed that my ul.add command that works OK in 5.0 doesn't anymore work in 5.1. I get back to the xmlrpc query:
<name>faultString</name> <value><string>Not enough parameters or wrong format</string></value>
I then went and compared ul.add in 5.0 and 5.1 and noticed that in 5.1 it has added two optional params:
received (optional) value with the received-from address (source address) (use '0' or '.' if it should not be set). Format: sip:srcip:srcport;transport=abc socket (optional) value with the local socket address (use '0' or '.' if it should not be set). Format: proto:localip:localport Note: the position of parameters is relevant, in the case of optional parameters, use '0' or '.' for parameters that should not be set which are positioned before any parameter that has to be set.What does that mean? Isn't optional really optional, but 0 or . is needed?
-- Juha
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Daniel-Constantin Mierla writes:
if you don't need to provide any of those parameters, then it should just work by not having them in the command.
OK, but it doesn't as the error message told. I should not have made any changes to that part of code from 5.0 to 5.1, but can recheck.
-- Juha
Juha Heinanen writes:
if you don't need to provide any of those parameters, then it should just work by not having them in the command.
Perhaps the error is due to this change:
in 5.0: path value of the contact
in 5.1: path value with the Path vector (use '0' or '.' if it should not be set)
In my xmlrpc command path param has empty string value:
..<param>. ...<value>. ....<string></string>. ...</value>. ..</param>.
If that is the reason, would it be possible to make 5.1 backwards compatible with 5.0?
-- Juha
Juha Heinanen writes:
Perhaps the error is due to this change:
in 5.0: path value of the contact
in 5.1: path value with the Path vector (use '0' or '.' if it should not be set)
In my xmlrpc command path param has empty string value:
..<param>. ...<value>. ....<string></string>. ...</value>. ..</param>.
This was not the reason. I change path param to
.<param>. ...<value>. ....<string>.</string>. ...</value>. ..</param>.
and still the error.
Below is the whole xmlrpc request/response.
-- Juha
-----------------------------
T 2017/10/18 12:36:50.360916 127.0.0.1:58310 -> 127.0.0.1:6060 [AP] <?xml version="1.0" ?>. <methodCall>. .<methodName>ul.add</methodName>. .<params>. ..<param>. ...<value>. ....<string>location</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>foo@bar.com</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>sip:foo@vm.bar.com</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<int>0</int>. ...</value>. ..</param>. ..<param>. ...<value>. ....<double>0.2</double>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>.</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<int>0</int>. ...</value>. ..</param>. ..<param>. ...<value>. ....<int>16</int>. ...</value>. ..</param>. ..<param>. ...<value>. ....<int>15</int>. ...</value>. ..</param>. .</params>. </methodCall>.
## T 2017/10/18 12:36:50.361093 127.0.0.1:6060 -> 127.0.0.1:58310 [AP] HTTP/1.0 200 OK. Sia: SIP/2.0/TCP 127.0.0.1:58310. Server: OpenSIPg SIP Proxy (5.1.0-0b4 (x86_64/linux)). Content-Length: 295. . <?xml version="1.0"?> <methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>500</int></value> </member> <member> <name>faultString</name> <value><string>Not enough parameters or wrong format</string></value> </member> </struct> </value> </fault> </methodResponse>
Even in the 5.0 the path was supposed to be 0 if not wanted to be set. It was the inspiration I had for the other optional parameters I added.
I will look at it. If you can the log messages with debug=3 in the config for processing the command, I will try to spot it quicly. Otherwise likely to take 1-2 days until I get back to office and can reproduce myself.
On Wed, Oct 18, 2017 at 11:40 AM, Juha Heinanen jh@tutpro.com wrote:
Juha Heinanen writes:
Perhaps the error is due to this change:
in 5.0: path value of the contact
in 5.1: path value with the Path vector (use '0' or '.' if it should not be
set)
In my xmlrpc command path param has empty string value:
..<param>. ...<value>. ....<string></string>. ...</value>. ..</param>.
This was not the reason. I change path param to
.<param>. ...<value>. ....<string>.</string>. ...</value>. ..</param>.
and still the error.
Below is the whole xmlrpc request/response.
-- Juha
T 2017/10/18 12:36:50.360916 127.0.0.1:58310 -> 127.0.0.1:6060 [AP]
<?xml version="1.0" ?>.
<methodCall>. .<methodName>ul.add</methodName>. .<params>. ..<param>. ...<value>. ....<string>location</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>foo@bar.com</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>sip:foo@vm.bar.com</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<int>0</int>. ...</value>. ..</param>. ..<param>. ...<value>. ....<double>0.2</double>. ...</value>. ..</param>. ..<param>. ...<value>. ....<string>.</string>. ...</value>. ..</param>. ..<param>. ...<value>. ....<int>0</int>. ...</value>. ..</param>. ..<param>. ...<value>. ....<int>16</int>. ...</value>. ..</param>. ..<param>. ...<value>. ....<int>15</int>. ...</value>. ..</param>. .</params>. </methodCall>.
## T 2017/10/18 12:36:50.361093 127.0.0.1:6060 -> 127.0.0.1:58310 [AP] HTTP/1.0 200 OK. Sia: SIP/2.0/TCP 127.0.0.1:58310. Server: OpenSIPg SIP Proxy (5.1.0-0b4 (x86_64/linux)). Content-Length: 295. .
<?xml version="1.0"?>
<methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>500</int></value> </member> <member> <name>faultString</name> <value><string>Not enough parameters or wrong format</string></value> </member> </struct> </value> </fault> </methodResponse>
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Daniel-Constantin Mierla writes:
I will look at it. If you can the log messages with debug=3 in the config for processing the command, I will try to spot it quicly. Otherwise likely to take 1-2 days until I get back to office and can reproduce myself.
I have been busy, but tries by adding to the call two more params with value ".". The error went away. This short of proves that there is some bug in the code regarding optionality of the two new params.
-- Juha
On 18.10.17 14:09, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I will look at it. If you can the log messages with debug=3 in the config for processing the command, I will try to spot it quicly. Otherwise likely to take 1-2 days until I get back to office and can reproduce myself.
I have been busy, but tries by adding to the call two more params with value ".". The error went away. This short of proves that there is some bug in the code regarding optionality of the two new params.
It proved that the issue was in the rpc module implementation related to handling of the optional specifier '*' when there were no more params available. I pushed some patches to both jsonrpcs and xmlrpc, but I could test only with jsonrpcs. Maybe you can give it a try with latest master and if all ok it needs to be backported as well.
Cheers, Daniel
Daniel-Constantin Mierla writes:
It proved that the issue was in the rpc module implementation related to handling of the optional specifier '*' when there were no more params available. I pushed some patches to both jsonrpcs and xmlrpc, but I could test only with jsonrpcs. Maybe you can give it a try with latest master and if all ok it needs to be backported as well.
I tried and with latest master ul.add works with or without the last two opt params.
-- Juha
-
Daniel-Constantin Mierla -
Juha Heinanen