Hi Stefan,
Stefan Sayer wrote:
Hi,
o Elena-Ramona Modroiu [02/11/09 11:48]:
Hi everybody,
a new version, 0.9.1, of SIREMIS - the web management interface for Kamailio (OpenSER) and SIP-Router.org - is released.
this looks very nice.
thanks!
Just recently I started with some monitoring support for SEMS (http://lists.iptel.org/pipermail/semsdev/2009-February/003517.html) The way this works is to push some call related info to the monitoring module, and access it from the outside via DI functions, e.g. via XMLRPC (http://svn.berlios.de/wsvn/sems/trunk/doc/Readme.monitoring). So you can get e.g. a list of callids by executing the XMLRPC function server.listActive(), and get the info for a call with server.get(callid).
At the moment it logs ruri/from/to/application/direction in the core, for conference application additionally the conference room. To illustrate, you would get this from the server:
s.list()
['3c2d4bde0d60-gds81g00uz1n']
s.get(s.list()[0])
[{'from': '"2@stefan-lap.office.iptego.de" sip:2@stefan-lap.office.iptego.de', 'app': 'conference', 'to': 'sip:35@stefan-lap.office.iptego.de;user=phone', 'conf_id': '35', 'ruri': 'sip:35@stefan-lap.office.iptego.de;user=phone', 'dir': 'in'}]
This is of course extensible, e.g. codec used, call start/end time etc.
Maybe, if we would add a way to monitor SEMS servers from within SIREMIS, it would give a good opportunity to monitor e.g. conference bridge, voicemail server, prepaid app, or b2bua (like sbc).
What do you think?
I think it would be very useful. It looks to me more like an extension to communicate via XMLRPC with SEMS - send command and display the result.
What is the XMLRPC you are using in SEMS? The C library used in Kamailio proved quite unstable, therefore SIREMIS uses MI UDP - simpler protocol and easy to troubleshoot. There should be XMLRPC PHP lib, therefore easy to extend SIREMIS.
Is it possible to get statistic information out of SEMS? Like number of active calls? Such data can be used to build charts, which is nice to monitor the service health and evolution.
Regards, Ramona
Hi Ramona,
o Elena-Ramona Modroiu [02/11/09 18:20]:
Maybe, if we would add a way to monitor SEMS servers from within SIREMIS, it would give a good opportunity to monitor e.g. conference bridge, voicemail server, prepaid app, or b2bua (like sbc).
What do you think?
I think it would be very useful. It looks to me more like an extension to communicate via XMLRPC with SEMS - send command and display the result.
What is the XMLRPC you are using in SEMS? The C library used in Kamailio proved quite unstable, therefore SIREMIS uses MI UDP - simpler protocol and easy to troubleshoot. There should be XMLRPC PHP lib, therefore easy
SEMS uses xmlrpc++, with the addition of multi threaded server (and client with failover fallback). We have it deployed for quite some time, and it works pretty reliably. Of course XML is always bloat, but I think that TCP as reliable transport is not bad for this purpose - no need to reimplement on application level. There is also a UDP server, but it is little used, also due to that encoding/decoding of data structures is much more straight forward with xmlrpc. Things on my list to try out are also json-rpc (for easier integration with web apps) to DI, and protocol buffers+libevent, for more performance. But I think for most applications, xmlrpc2di works reasonably well.
To explain this a little further, in SEMS modules can export an internal interface called DI ('dynamic invocation' - runtime function evaluation and variably typed arguments) to export cross module APIs (SIP registrar client, UAC authentication, DIAMETER client, message file storage, accounting, conference room control etc). With xmlrpc2di, these APIs are instantly accessible through XMLRPC from the outside. XMLRPC fits well, because it contains data type description in the function call XML document, and function names are dynamic - just like DI.
Similarly, monitoring data that the SEMS application can add to the call info is variable - applications can add string/int attributes, or arbitrary data structures, referenced by an attribute name. If accessed via XMLRPC, they should be available just as the application added it; int as int, strings as strings, arrays as arrays (struct support for xmlrpc coming soon). If we can come up with a generic way to represent that on the web page, it can be used for many diverse monitoring purposes.
to extend SIREMIS.
Is it possible to get statistic information out of SEMS? Like number of active calls? Such data can be used to build charts, which is nice to monitor the service health and evolution.
the xmlrpc2di module has the calls() method. Also, the listActive() function from 'monitoring' does just that. By calling get() on the call id, further information can be queried - e.g. it can be grouped by application, domain etc.
Stefan
Regards, Ramona
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
Hi Stefan,
Stefan Sayer wrote:
Hi Ramona,
o Elena-Ramona Modroiu [02/11/09 18:20]:
Maybe, if we would add a way to monitor SEMS servers from within SIREMIS, it would give a good opportunity to monitor e.g. conference bridge, voicemail server, prepaid app, or b2bua (like sbc).
What do you think?
I think it would be very useful. It looks to me more like an extension to communicate via XMLRPC with SEMS - send command and display the result.
What is the XMLRPC you are using in SEMS? The C library used in Kamailio proved quite unstable, therefore SIREMIS uses MI UDP - simpler protocol and easy to troubleshoot. There should be XMLRPC PHP lib, therefore easy
SEMS uses xmlrpc++, with the addition of multi threaded server (and client with failover fallback).
are this extensions by you?
We have it deployed for quite some time, and it works pretty reliably. Of course XML is always bloat, but I think that TCP as reliable transport is not bad for this purpose - no need to reimplement on application level.
For management stuff, it is pretty ok, being easier to integrate with other applications. I used in the past the xmlrpc, but c library seemed pretty unstable and then moved to udp.
There is also a UDP server, but it is little used, also due to that encoding/decoding of data structures is much more straight forward with xmlrpc. Things on my list to try out are also json-rpc (for easier integration with web apps) to DI, and protocol buffers+libevent, for more performance.
siremis uses json to create charts, so it may become seamless integration.
But I think for most applications, xmlrpc2di works reasonably well.
To explain this a little further, in SEMS modules can export an internal interface called DI ('dynamic invocation' - runtime function evaluation and variably typed arguments) to export cross module APIs (SIP registrar client, UAC authentication, DIAMETER client, message file storage, accounting, conference room control etc). With xmlrpc2di, these APIs are instantly accessible through XMLRPC from the outside. XMLRPC fits well, because it contains data type description in the function call XML document, and function names are dynamic - just like DI.
ok
Similarly, monitoring data that the SEMS application can add to the call info is variable - applications can add string/int attributes, or arbitrary data structures, referenced by an attribute name. If accessed via XMLRPC, they should be available just as the application added it; int as int, strings as strings, arrays as arrays (struct support for xmlrpc coming soon). If we can come up with a generic way to represent that on the web page, it can be used for many diverse monitoring purposes.
Interesting approach, not sure if I understood correctly, but you are saying that if I know the name of a variable/function, I can get the value/execute it via DI?
Regards, Ramona
to extend SIREMIS.
Is it possible to get statistic information out of SEMS? Like number of active calls? Such data can be used to build charts, which is nice to monitor the service health and evolution.
the xmlrpc2di module has the calls() method. Also, the listActive() function from 'monitoring' does just that. By calling get() on the call id, further information can be queried - e.g. it can be grouped by application, domain etc.
Stefan
Regards, Ramona
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
-
Elena-Ramona Modroiu -
Stefan Sayer