18 Nov
2012
18 Nov
'12
9:09 p.m.
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
18 Nov
18 Nov
11:22 p.m.
2012/11/18 Olle E. Johansson <oej(a)edvina.net>et>:
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?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:49 p.m.
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
19 Nov
19 Nov
7:46 a.m.
18 nov 2012 kl. 23:49 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Olle E. Johansson writes:
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
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. 
9:44 a.m.
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(a)tutpro.com>om>:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Olle E. Johansson writes:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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.
10:38 a.m.
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(a)gmail.com>om>:
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(a)tutpro.com>om>:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Olle E. Johansson writes:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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.
10:43 a.m.
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(a)gmail.com>om>:
> 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(a)tutpro.com>om>:
>>
>>> 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(a)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
11 a.m.
19 nov 2012 kl. 10:43 skrev Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
On 11/19/12 10:38 AM, Olle E. Johansson wrote:
htable.dump
/O
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(a)gmail.com>om>:
> 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(a)tutpro.com>om>:
>>
>>> 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(a)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
11:44 a.m.
Olle E. Johansson writes:
also htable.dump work ok with me:
What command
did you execute?
htable.dump $ 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
1:18 p.m.
19 nov 2012 kl. 11:44 skrev Juha Heinanen <jh(a)tutpro.com>om>:
Olle E. Johansson writes:
also htable.dump work ok with me:
Check the full XML in the response and see if you have multiple values in the
<param> part.
/O
What
command did you execute?
htable.dump $ 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}, ...
4199
days inactive
4200
days old
9 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen -
Olle E. Johansson