Hello,

On 13.07.2009 15:44 Uhr, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

several days ago, a new module named mi_rpc was introduced to source tree. The goal is to be able to execute MI commands using RPC interface from sip router core.

Back to mi_rpc, one issue that needs to be sorted out is the output format. Right now doing a pretty-format printing which is not suitable for xmlrpc.

Feedback is very much appreciated, thanks,

i tried to get core stats out using xmlrcp. using serctl, i can do it like this:

srctl mi get_statistics core:200 OK

• :: core:rcv_requests = 10
• :: core:rcv_replies = 0
• :: core:fwd_requests = 0
• :: core:fwd_replies = 0
• :: core:drop_requests = 0
• :: core:drop_replies = 0
• :: core:err_requests = 0
• :: core:err_replies = 0
• :: core:bad_URIs_rcvd = 0
• :: core:unsupported_methods = 10
• :: core:bad_msg_hdr = 0

using xmlrpc interface, i tried by giving command called "mi" with argument list "get_statistics" and "core":, but it didn't work:

c.mi(['get_statistics', 'core:']) ... xmlrpclib.Fault: <Fault 500: 'command parameter missing'>

how is the actual command and and its arguments supplied?

I haven't played that much with xmlrpc, but the command must be "mi", the first parameter must be the name of the mi command, then follows the parameters of the mi command.

Cheers, Daniel

On 13.07.2009 17:33 Uhr, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

I haven't played that much with xmlrpc, but the command must be "mi", the first parameter must be the name of the mi command, then follows the parameters of the mi command.

k mi_xmlrpc module takes parameters of command as an array. i have tried many combinations without luck.

probably does not work to send same format of xmlrpc message to xmlrpc module as to mi_xmlrpc module.

here is what mi_rpc modules does: - it receives a rpc handler form the rpc interface in core - reads first parameter and then lookups MI command, if not found then returns error, if found: - reads all parameters as string and build internal MI tree

Cheers, Daniel

where should i put some debug statements in order to figure out why

c.mi(get_statistics', 'core:')

or

c.mi('get_statistics', ['core:'])

give

400 Too few or too many arguments?

-- juha

Hi guys!

It would be great if you could write a small page on the wiki shortly describing the interfaces into sip-router/kamailio and the difference between the "ser way" and "kamailio way" (mi_*, xmlrpc, fifo? (still alive?), statistics ...)

thanks klaus

Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

here is what mi_rpc modules does:

• it receives a rpc handler form the rpc interface in core
• reads first parameter and then lookups MI command, if not found then

returns error, if found:

• reads all parameters as string and build internal MI tree

ok, after andrei fixed some bug, i got stats working via mi_rpc and xmlrpc module interface.

all stats except "tm:", which is now implemented using tm.stats command.

res = c.tm.stats()

provides this kind of result:

{'2xx': 0, 'created': 0, '5xx': 0, 'delayed_free': 0, 'current': 0, 'total_local': 0, 'waiting': 0, '6xx': 0, '4xx': 0, '3xx': 0, 'total': 0, 'replied_locally': 0, 'freed': 0}

whereas mi based stat results look like this:

['200 OK\n', '+ :: core:rcv_requests = 3', '+ :: core:rcv_replies = 0', '+ :: core:fwd_requests = 0', '+ :: core:fwd_replies = 0', '+ :: core:drop_requests = 0', '+ :: core:drop_replies = 0', '+ :: core:err_requests = 0', '+ :: core:err_replies = 0', '+ :: core:bad_URIs_rcvd = 0', '+ :: core:unsupported_methods = 3', '+ :: core:bad_msg_hdr = 0']

would it be possible to get the result in same (preferable the former) format in both cases?

-- juha

---

Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

Daniel-Constantin Mierla writes:

MI tm stats are exported natively via tmx module.

since i need to use xmlrpc module anyway, i prefer to use mi_rpc only when necessary. if idea behind mi_rpc is backwards compatibility, then also its output should look like before, which is not now the case, e.g. for stats.

-- juha