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:
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:
- 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