9 Apr
2014
9 Apr
'14
9:38 p.m.
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/