[SR-Users] rfc: evapi architecture and message format

Alex Balashov abalashov at evaristesys.com
Wed Apr 9 19:38:41 CEST 2014

My personal opinion is that evapi should be simple to use and that the 
module should be as simple as possible, allowing the user maximal 
control to create their own desired outcomes, in the message format of 
their choice.

That said, it would probably be beneficial to have some way for 
particular clients to subscribe to particular events. This should 
probably be as simple as providing a "name" parameter for the event 
emitted, and allowing a listener to subscribe to that same name token. 
It would be convenient to have a subscription message that would allow 
the comma-separated enumeration of multiple events to subscribe to as well.

Other than that, I see no need to make this module complicated. I think 
that, as with everything else in Kamailio, maximal control and less 
"management" is a strength, even if that isn't so mass-market friendly...

On 04/09/2014 05:02 AM, Daniel-Constantin Mierla wrote:

> Hello,
> (cross-posting because the results are impacting users)
> recently I added a new module named evapi:
>    - http://www.kamailio.org/docs/modules/devel/modules/evapi.html
> The purpose is to able to send custom messages to applications that
> connect to kamailio via tcp on a special port (different than sip port)
> as well as receive messages and react on them.
> One of the first use case we look at is integration with cgrates for
> real time billing. For example:
>    - send notification when a new call comes in and cgrates will return
> allow/reject
>    - send notification when the call starts so cgrates can start billing
>    - send notification when the call ends so cgrates will close bllling
> The module is now in quite good shape, sending and receiving messages.
> Sending is done from config file, in the future some modules might do it
> from inside. Received message is passed to config file via an
> event_route and variables.
> Now, the point of this discussion is to debate following points:
>    1) should there be a specific format used for this messages? The
> examples in the README use json. The module can encapsulate them in
> netstring format when sending over tcp to be easy to parse and read the
> message at once. This is optional, the message can be sent as it is
>    2) now messages are sent to all connected applications, should be
> there some subscription mechanism per event? If yes, then there has to
> be a way to specify the event, so point 1) might need a specific format
>    3) handle response - should be there a defined api that will say
> allow, reject, drop? I was thinking that the return could be some script
> for an embedded interpreter (e.g., Lua) that can be executed from config
> file. Or, alternative, manually scripted in the event route, so each
> user defines its own api
>    3) other suggestions for what should be discussed?
> Looking forward to opinions regarding these matters.
> Cheers,
> Daniel

Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

More information about the sr-users mailing list