[sr-dev] rfc: evapi architecture and message format

Daniel-Constantin Mierla miconda at gmail.com
Wed Apr 9 11:02:11 CEST 2014


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

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda




More information about the sr-dev mailing list