[Kamailio-Users] [Kamailio-Devel] SIREMIS v0.9.1 Released

[Elena-Ramona Modroiu]

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 at lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>     
>
>