Friends,
I've been trying to play with the XMLRPC module in Kamailio. It turns out that the answers in some modules are not XML-rpc compliant, so my PHP based XMLrpc library only shows one part of the response.
XMLrpc standards says that there has to be ONE and only ONE structure in a response. When running "htable.dump" I get one param struct per object. There should be a common structure encapsultating all the responses.
It seems like the output of sercmd allows this, but XMLrpc does not.
One quick fix would be to change the xmlrpc module and add an encapsulating structure. This would of course break a lot of clients. We could make it an option so that we're backwards compatible, like a "xmlrpccompliant" modparam. Another fix would be to change all the modules, but that would also change the SER RPC output, which would be a far bigger change.
Anyone that has seen the same issues? Agree with a fix?
/O
2012/11/18 Olle E. Johansson oej@edvina.net:
Friends,
I've been trying to play with the XMLRPC module in Kamailio. It turns out that the answers in some modules are not XML-rpc compliant, so my PHP based XMLrpc library only shows one part of the response.
XMLrpc standards says that there has to be ONE and only ONE structure in a response. When running "htable.dump" I get one param struct per object. There should be a common structure encapsultating all the responses.
It seems like the output of sercmd allows this, but XMLrpc does not.
One quick fix would be to change the xmlrpc module and add an encapsulating structure. This would of course break a lot of clients. We could make it an option so that we're backwards compatible, like a "xmlrpccompliant" modparam. Another fix would be to change all the modules, but that would also change the SER RPC output, which would be a far bigger change.
Anyone that has seen the same issues? Agree with a fix?
IMHO the XMLRPC response's structure should be really much better. If I'm not wrong (I must recognize I've haven't used yet XMLRPC in 3.X) the response is an XML object containing a "string" (like the MI FIFO output) which must parsed. Why then using XML? Each field of the response should be a XML-parseable element, right?
Olle E. Johansson writes:
XMLrpc standards says that there has to be ONE and only ONE structure in a response. When running "htable.dump" I get one param struct per object. There should be a common structure encapsultating all the responses.
Anyone that has seen the same issues? Agree with a fix?
i don't have any problems with htable_dump at least when using python:
# python sr-xmlrpc.py <ServerProxy for 127.0.0.1:6060/RPC2> Nov 19 00:46:55 sip /usr/sbin/sip-proxy[3565]: INFO: Handling XMLRPC POST from <192.98.102.10> with body <<?xml version='1.0'?><methodCall><methodName>mi</methodName><params><param><value><string>sht_dump</string></value></param><param><value><string>htable</string></value></param></params></methodCall>> ['Entry:: 0', 'gw::3::calling_host:: foo.bar', 'Entry:: 1', 'rpi::30001::acl[0]:: 3', 'Entry:: 8', 'rpi::30001::charging_uri:: sip:+358407058050@test.fi', 'Entry:: 11', 'rpi::30001::flags:: 209', 'Entry:: 14', 'gw::4::dpid:: 1001', 'Entry:: 15', 'lpi::20001::prefix[0]:: +3581623456', ...
i haven't noticed any problems with php either, but i'm not using the xmlrpc lib that comes with php.
-- juha
18 nov 2012 kl. 23:49 skrev Juha Heinanen jh@tutpro.com:
Olle E. Johansson writes:
XMLrpc standards says that there has to be ONE and only ONE structure in a response. When running "htable.dump" I get one param struct per object. There should be a common structure encapsultating all the responses.
Anyone that has seen the same issues? Agree with a fix?
i don't have any problems with htable_dump at least when using python:
# python sr-xmlrpc.py <ServerProxy for 127.0.0.1:6060/RPC2> Nov 19 00:46:55 sip /usr/sbin/sip-proxy[3565]: INFO: Handling XMLRPC POST from <192.98.102.10> with body <<?xml version='1.0'?><methodCall><methodName>mi</methodName><params><param><value><string>sht_dump</string></value></param><param><value><string>htable</string></value></param></params></methodCall>> ['Entry:: 0', 'gw::3::calling_host:: foo.bar', 'Entry:: 1', 'rpi::30001::acl[0]:: 3', 'Entry:: 8', 'rpi::30001::charging_uri:: sip:+358407058050@test.fi', 'Entry:: 11', 'rpi::30001::flags:: 209', 'Entry:: 14', 'gw::4::dpid:: 1001', 'Entry:: 15', 'lpi::20001::prefix[0]:: +3581623456', ...
i haven't noticed any problems with php either, but i'm not using the xmlrpc lib that comes with php.
Well, it clearly breaks the XMLrpc standard, but since you have it working this way, I think we will need an optional compliant setting. I use the Code Igniter xmlrpc library and it only delivers one entry and skips the rest of the payload.
/O
Hello,
is it about native rpc commands or the execution of mi commands via rpc interface?
The second is just an workaround, where the output of a mi command in encapsulated in a rpc response.
Juha's example is execution of a mi command. Hopefully, at some point all mi commands will have a native rpc variant.
Cheers, Daniel
On 11/19/12 7:46 AM, Olle E. Johansson wrote:
18 nov 2012 kl. 23:49 skrev Juha Heinanen jh@tutpro.com:
Olle E. Johansson writes:
XMLrpc standards says that there has to be ONE and only ONE structure in a response. When running "htable.dump" I get one param struct per object. There should be a common structure encapsultating all the responses. Anyone that has seen the same issues? Agree with a fix?
i don't have any problems with htable_dump at least when using python:
# python sr-xmlrpc.py <ServerProxy for 127.0.0.1:6060/RPC2> Nov 19 00:46:55 sip /usr/sbin/sip-proxy[3565]: INFO: Handling XMLRPC POST from <192.98.102.10> with body <<?xml version='1.0'?><methodCall><methodName>mi</methodName><params><param><value><string>sht_dump</string></value></param><param><value><string>htable</string></value></param></params></methodCall>> ['Entry:: 0', 'gw::3::calling_host:: foo.bar', 'Entry:: 1', 'rpi::30001::acl[0]:: 3', 'Entry:: 8', 'rpi::30001::charging_uri:: sip:+358407058050@test.fi', 'Entry:: 11', 'rpi::30001::flags:: 209', 'Entry:: 14', 'gw::4::dpid:: 1001', 'Entry:: 15', 'lpi::20001::prefix[0]:: +3581623456', ...
i haven't noticed any problems with php either, but i'm not using the xmlrpc lib that comes with php.
Well, it clearly breaks the XMLrpc standard, but since you have it working this way, I think we will need an optional compliant setting. I use the Code Igniter xmlrpc library and it only delivers one entry and skips the rest of the payload.
/O _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
I am using the XMLRPC module, so I guess it's the RPC interface and not the MI.
/O
19 nov 2012 kl. 09:44 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
is it about native rpc commands or the execution of mi commands via rpc interface?
The second is just an workaround, where the output of a mi command in encapsulated in a rpc response.
Juha's example is execution of a mi command. Hopefully, at some point all mi commands will have a native rpc variant.
Cheers, Daniel
On 11/19/12 7:46 AM, Olle E. Johansson wrote:
18 nov 2012 kl. 23:49 skrev Juha Heinanen jh@tutpro.com:
Olle E. Johansson writes:
XMLrpc standards says that there has to be ONE and only ONE structure in a response. When running "htable.dump" I get one param struct per object. There should be a common structure encapsultating all the responses. Anyone that has seen the same issues? Agree with a fix?
i don't have any problems with htable_dump at least when using python:
# python sr-xmlrpc.py <ServerProxy for 127.0.0.1:6060/RPC2> Nov 19 00:46:55 sip /usr/sbin/sip-proxy[3565]: INFO: Handling XMLRPC POST from <192.98.102.10> with body <<?xml version='1.0'?><methodCall><methodName>mi</methodName><params><param><value><string>sht_dump</string></value></param><param><value><string>htable</string></value></param></params></methodCall>> ['Entry:: 0', 'gw::3::calling_host:: foo.bar', 'Entry:: 1', 'rpi::30001::acl[0]:: 3', 'Entry:: 8', 'rpi::30001::charging_uri:: sip:+358407058050@test.fi', 'Entry:: 11', 'rpi::30001::flags:: 209', 'Entry:: 14', 'gw::4::dpid:: 1001', 'Entry:: 15', 'lpi::20001::prefix[0]:: +3581623456', ...
i haven't noticed any problems with php either, but i'm not using the xmlrpc lib that comes with php.
Well, it clearly breaks the XMLrpc standard, but since you have it working this way, I think we will need an optional compliant setting. I use the Code Igniter xmlrpc library and it only delivers one entry and skips the rest of the payload.
/O _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 11/19/12 10:38 AM, Olle E. Johansson wrote:
I am using the XMLRPC module, so I guess it's the RPC interface and not the MI.
there is a RPC command to execute any of the MI commands, named 'mi' (actually there are few other variants of it). Juha's example shows the execution of this command - method name is 'mi' (the rpc command) and the parameter is 'sht_dump' (which is the mi command).
What command did you execute?
Cheers, Daniel
/O
19 nov 2012 kl. 09:44 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
is it about native rpc commands or the execution of mi commands via rpc interface?
The second is just an workaround, where the output of a mi command in encapsulated in a rpc response.
Juha's example is execution of a mi command. Hopefully, at some point all mi commands will have a native rpc variant.
Cheers, Daniel
On 11/19/12 7:46 AM, Olle E. Johansson wrote:
18 nov 2012 kl. 23:49 skrev Juha Heinanen jh@tutpro.com:
Olle E. Johansson writes:
XMLrpc standards says that there has to be ONE and only ONE structure in a response. When running "htable.dump" I get one param struct per object. There should be a common structure encapsultating all the responses. Anyone that has seen the same issues? Agree with a fix?
i don't have any problems with htable_dump at least when using python:
# python sr-xmlrpc.py <ServerProxy for 127.0.0.1:6060/RPC2> Nov 19 00:46:55 sip /usr/sbin/sip-proxy[3565]: INFO: Handling XMLRPC POST from <192.98.102.10> with body <<?xml version='1.0'?><methodCall><methodName>mi</methodName><params><param><value><string>sht_dump</string></value></param><param><value><string>htable</string></value></param></params></methodCall>> ['Entry:: 0', 'gw::3::calling_host:: foo.bar', 'Entry:: 1', 'rpi::30001::acl[0]:: 3', 'Entry:: 8', 'rpi::30001::charging_uri:: sip:+358407058050@test.fi', 'Entry:: 11', 'rpi::30001::flags:: 209', 'Entry:: 14', 'gw::4::dpid:: 1001', 'Entry:: 15', 'lpi::20001::prefix[0]:: +3581623456', ...
i haven't noticed any problems with php either, but i'm not using the xmlrpc lib that comes with php.
Well, it clearly breaks the XMLrpc standard, but since you have it working this way, I think we will need an optional compliant setting. I use the Code Igniter xmlrpc library and it only delivers one entry and skips the rest of the payload.
/O _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
19 nov 2012 kl. 10:43 skrev Daniel-Constantin Mierla miconda@gmail.com:
On 11/19/12 10:38 AM, Olle E. Johansson wrote:
I am using the XMLRPC module, so I guess it's the RPC interface and not the MI.
there is a RPC command to execute any of the MI commands, named 'mi' (actually there are few other variants of it). Juha's example shows the execution of this command - method name is 'mi' (the rpc command) and the parameter is 'sht_dump' (which is the mi command).
What command did you execute?
htable.dump
/O
Cheers, Daniel
/O
19 nov 2012 kl. 09:44 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
is it about native rpc commands or the execution of mi commands via rpc interface?
The second is just an workaround, where the output of a mi command in encapsulated in a rpc response.
Juha's example is execution of a mi command. Hopefully, at some point all mi commands will have a native rpc variant.
Cheers, Daniel
On 11/19/12 7:46 AM, Olle E. Johansson wrote:
18 nov 2012 kl. 23:49 skrev Juha Heinanen jh@tutpro.com:
Olle E. Johansson writes:
XMLrpc standards says that there has to be ONE and only ONE structure in a response. When running "htable.dump" I get one param struct per object. There should be a common structure encapsultating all the responses. Anyone that has seen the same issues? Agree with a fix?
i don't have any problems with htable_dump at least when using python:
# python sr-xmlrpc.py <ServerProxy for 127.0.0.1:6060/RPC2> Nov 19 00:46:55 sip /usr/sbin/sip-proxy[3565]: INFO: Handling XMLRPC POST from <192.98.102.10> with body <<?xml version='1.0'?><methodCall><methodName>mi</methodName><params><param><value><string>sht_dump</string></value></param><param><value><string>htable</string></value></param></params></methodCall>> ['Entry:: 0', 'gw::3::calling_host:: foo.bar', 'Entry:: 1', 'rpi::30001::acl[0]:: 3', 'Entry:: 8', 'rpi::30001::charging_uri:: sip:+358407058050@test.fi', 'Entry:: 11', 'rpi::30001::flags:: 209', 'Entry:: 14', 'gw::4::dpid:: 1001', 'Entry:: 15', 'lpi::20001::prefix[0]:: +3581623456', ...
i haven't noticed any problems with php either, but i'm not using the xmlrpc lib that comes with php.
Well, it clearly breaks the XMLrpc standard, but since you have it working this way, I think we will need an optional compliant setting. I use the Code Igniter xmlrpc library and it only delivers one entry and skips the rest of the payload.
/O _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Olle E. Johansson writes:
What command did you execute?
htable.dump
also htable.dump work ok with me:
$ python sr-xmlrpc.py
<ServerProxy for 127.0.0.1:6060/RPC2> Nov 19 12:43:38 sip /usr/sbin/sip-proxy[3556]: INFO: Handling XMLRPC POST from <192.98.102.10> with body <<?xml version='1.0'?><methodCall><methodName>htable.dump</methodName><params><param><value><string>htable</string></value></param></params></methodCall>> ({'slot': {'item': {'name': 'gw::3::calling_host', 'value': 'foo.bar'}}, 'entry': 0, 'size': 1}, {'slot': {'item': {'name': 'rpi::30001::acl[0]', 'value': 3}}, 'entry': 1, 'size': 1}, {'slot': {'item': {'name': 'rpi::30001::charging_uri', 'value': 'sip:+358407058050@test.fi'}}, 'entry': 8, 'size': 1}, ...
-- juha
19 nov 2012 kl. 11:44 skrev Juha Heinanen jh@tutpro.com:
Olle E. Johansson writes:
What command did you execute?
htable.dump
also htable.dump work ok with me:
$ python sr-xmlrpc.py
<ServerProxy for 127.0.0.1:6060/RPC2> Nov 19 12:43:38 sip /usr/sbin/sip-proxy[3556]: INFO: Handling XMLRPC POST from <192.98.102.10> with body <<?xml version='1.0'?><methodCall><methodName>htable.dump</methodName><params><param><value><string>htable</string></value></param></params></methodCall>> ({'slot': {'item': {'name': 'gw::3::calling_host', 'value': 'foo.bar'}}, 'entry': 0, 'size': 1}, {'slot': {'item': {'name': 'rpi::30001::acl[0]', 'value': 3}}, 'entry': 1, 'size': 1}, {'slot': {'item': {'name': 'rpi::30001::charging_uri', 'value': 'sip:+358407058050@test.fi'}}, 'entry': 8, 'size': 1}, ...
Check the full XML in the response and see if you have multiple values in the <param> part.
/O
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen -
Olle E. Johansson