Hi!
When I run sercmd to test dispatcher.list I get a nice output
sercmd> dispatcher.list { SET_NO: 2 SET: { SET_ID: 1 DEST: { URI: sip:pstn1.astritech.org;transport=udp2 FLAGS: AX PRIORITY: 0 ATTRS: } DEST: { URI: sip:pstn2.astritech.org;transport=udp FLAGS: AX PRIORITY: 0 ATTRS: } SET_ID: 2 DEST: { URI: sip:127.0.0.1:5080 FLAGS: AX PRIORITY: 200 ATTRS: } DEST: { URI: sip:127.0.0.1:5084 FLAGS: AX PRIORITY: 50 ATTRS: } DEST: { URI: sip:127.0.0.1:5082 FLAGS: IX PRIORITY: 10 ATTRS: } } }
When trying to use the same over XMLrpc I get this response
HTTP/1.0 200 OK Via: SIP/2.0/TCP 212.3.14.204:48603 Server: Alvondo Core - Bbtele, Sweden Content-Length: 220
<?xml version="1.0"?> <methodResponse> <params> <param> <value><struct><member><name>SET_NO</name><value><int>2</int></value></member><member><name>SET</name><value></struct> </value> </param> </params> </methodResponse>
Seems like the structure of the data in the dispacther list fails to be propagated in the xmlrpc interface. Is this possibly because of the structure of the data?
The XMLRPC docs say
"1.3.4. Limitations
SER xmlrpc modules does not implement all data types allowed in XML-RPC. As well it does not implement arrays and nested structures. "
Maybe we could implement a dispatcher.listflat that just publishes a flat list..
/O
Hello,
the lack of support for nested structures in replies of xmlrpc module should be fixed by commit:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=fb3f37a0...
It is not yet backported, as I could see in the logs, but it should be.
Cheers, Daniel
On 6/8/12 4:28 PM, Olle E. Johansson wrote:
Hi!
When I run sercmd to test dispatcher.list I get a nice output
sercmd> dispatcher.list { SET_NO: 2 SET: { SET_ID: 1 DEST: { URI: sip:pstn1.astritech.org;transport=udp2 FLAGS: AX PRIORITY: 0 ATTRS: } DEST: { URI: sip:pstn2.astritech.org;transport=udp FLAGS: AX PRIORITY: 0 ATTRS: } SET_ID: 2 DEST: { URI: sip:127.0.0.1:5080 FLAGS: AX PRIORITY: 200 ATTRS: } DEST: { URI: sip:127.0.0.1:5084 FLAGS: AX PRIORITY: 50 ATTRS: } DEST: { URI: sip:127.0.0.1:5082 FLAGS: IX PRIORITY: 10 ATTRS: } } }
When trying to use the same over XMLrpc I get this response
HTTP/1.0 200 OK Via: SIP/2.0/TCP 212.3.14.204:48603 Server: Alvondo Core - Bbtele, Sweden Content-Length: 220
<?xml version="1.0"?>
<methodResponse> <params> <param> <value><struct><member><name>SET_NO</name><value><int>2</int></value></member><member><name>SET</name><value></struct> </value> </param> </params> </methodResponse>
Seems like the structure of the data in the dispacther list fails to be propagated in the xmlrpc interface. Is this possibly because of the structure of the data?
The XMLRPC docs say
"1.3.4. Limitations
SER xmlrpc modules does not implement all data types allowed in XML-RPC. As well it does not implement arrays and nested structures. "
Maybe we could implement a dispatcher.listflat that just publishes a flat list..
/O _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Olle,
try with the XMLRPC from head and see if that works for you. I added the nested structure support to xmlrpc to dump our IMS usrloc structures and it works (lots of nests). If you have any hassles drop me a log file and I'll take a look
Cheers Jason
On Fri, Jun 8, 2012 at 10:03 PM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
the lack of support for nested structures in replies of xmlrpc module should be fixed by commit:
http://git.sip-router.org/cgi-**bin/gitweb.cgi/sip-router/?a=**commit;h=** fb3f37a0ba46bcb39a79a05465f512**197a30da6bhttp://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=fb3f37a0ba46bcb39a79a05465f512197a30da6b
It is not yet backported, as I could see in the logs, but it should be.
Cheers, Daniel
On 6/8/12 4:28 PM, Olle E. Johansson wrote:
Hi!
When I run sercmd to test dispatcher.list I get a nice output
sercmd> dispatcher.list { SET_NO: 2 SET: { SET_ID: 1 DEST: { URI: sip:pstn1.astritech.org;**transport=udp2 FLAGS: AX PRIORITY: 0 ATTRS: } DEST: { URI: sip:pstn2.astritech.org;**transport=udp FLAGS: AX PRIORITY: 0 ATTRS: } SET_ID: 2 DEST: { URI: sip:127.0.0.1:5080 FLAGS: AX PRIORITY: 200 ATTRS: } DEST: { URI: sip:127.0.0.1:5084 FLAGS: AX PRIORITY: 50 ATTRS: } DEST: { URI: sip:127.0.0.1:5082 FLAGS: IX PRIORITY: 10 ATTRS: } } }
When trying to use the same over XMLrpc I get this response
HTTP/1.0 200 OK Via: SIP/2.0/TCP 212.3.14.204:48603 Server: Alvondo Core - Bbtele, Sweden Content-Length: 220
<?xml version="1.0"?>
<methodResponse> <params> <param> <value><struct><member><name>**SET_NO</name><value><int>2</** int></value></member><member><**name>SET</name><value></**struct> </value> </param> </params> </methodResponse>
Seems like the structure of the data in the dispacther list fails to be propagated in the xmlrpc interface. Is this possibly because of the structure of the data?
The XMLRPC docs say
"1.3.4. Limitations
SER xmlrpc modules does not implement all data types allowed in XML-RPC. As well it does not implement arrays and nested structures. "
Maybe we could implement a dispatcher.listflat that just publishes a flat list..
/O ______________________________**_________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**devhttp://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/**micondahttp://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
______________________________**_________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**devhttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
This email is subject to the disclaimer of Smile Communications (PTY) Ltd. at http://www.smilecoms.com/disclaimer
9 jun 2012 kl. 08:05 skrev Jason Penton:
Hi Olle,
try with the XMLRPC from head and see if that works for you. I added the nested structure support to xmlrpc to dump our IMS usrloc structures and it works (lots of nests). If you have any hassles drop me a log file and I'll take a look
Great! You just saved me a few hours worth of trying to understand and fix the code. I'll go ahead and try that one. If time permits during this training week, I'll upgrade my server to 3.3 and test your XMLRPC - did you fix it before the 3.3 code fork? Otherwise, I'll just take xmlrpc from head.
/O