Module: sip-router Branch: master Commit: 0acecd065ef0852fedeb723bd7c727f12d26316f URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0acecd06...
Author: Daniel-Constantin Mierla miconda@gmail.com Committer: Daniel-Constantin Mierla miconda@gmail.com Date: Wed Mar 12 21:50:02 2014 +0100
evapi: new module to push event details via tcp to external applications
- uses libev for handling connections
---
modules/evapi/Makefile | 36 ++++ modules/evapi/README | 133 +++++++++++++++ modules/evapi/doc/Makefile | 4 + modules/evapi/doc/evapi.xml | 37 ++++ modules/evapi/doc/evapi_admin.xml | 135 +++++++++++++++ modules/evapi/evapi_dispatch.c | 334 +++++++++++++++++++++++++++++++++++++ modules/evapi/evapi_dispatch.h | 38 +++++ modules/evapi/evapi_mod.c | 214 ++++++++++++++++++++++++ 8 files changed, 931 insertions(+), 0 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=0ace...
Daniel-Constantin Mierla writes:
evapi: new module to push event details via tcp to external applications
from readme:
1. Overview
This module pushes event details to remote applications, via TCP.
3.1. workers (int)
Number of worker processes to be started to handle incoming messages from remote applications.
i confused regarding what messages remote apps sent to sip proxy, because the purpose of the module seems to be opposite.
-- juha
On 13/03/14 01:48, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
evapi: new module to push event details via tcp to external applications
from readme:
Overview
This module pushes event details to remote applications, via TCP.
3.1. workers (int)
Number of worker processes to be started to handle incoming messages from remote applications.i confused regarding what messages remote apps sent to sip proxy, because the purpose of the module seems to be opposite.
The part with workers is for getting commands from the tcp client apps. It is done up to reading what is sent to kamailio via tcp, but not interpreted (simply prints to syslog at this moment). The target would be to have two ways interaction, e.g., interact with an external authorization/billing system that can say to allow/deny the call, or even set destination address. Because those types of actions were not defined, there is no doc for it. More will follow soon.
Cheers, Daniel
On 12 Mar 2014, at 21:51, Daniel-Constantin Mierla miconda@gmail.com wrote:
evapi: new module to push event details via tcp to external applications
I think this is a great start - but also (based on my exprience with Asterisk manager) complex.
Would it be beneficial to have a larger discussion about requirements and formats before too much code is produced?
If I understand correctly, we only have one type of message - "event". Is there a need for other types of messages?
Using a Json payload for the payload seems clever and extensible to me.
When a connection is opened, should we send an event to identify a particular server, version of the server and version of the evapi so that client can handle changes and upgrades in the future?
Should potential commands from client to server be done over the standard RPC commands - do we really need a new way for clients to control Kamailio? The event part was clearly missing, but we have a few ways to connect to Kamailio already.
Can we protect this listen port with TLS? Do we need authentication?
Just a few thoughts. This will be a very important new feature, so it's important we get it right.
Thank you for starting this, Daniel! /O
On 13/03/14 10:51, Olle E. Johansson wrote:
On 12 Mar 2014, at 21:51, Daniel-Constantin Mierla miconda@gmail.com wrote:
evapi: new module to push event details via tcp to external applications
I think this is a great start - but also (based on my exprience with Asterisk manager) complex.
Would it be beneficial to have a larger discussion about requirements and formats before too much code is produced?
Yes, I will start it very soon, just didn't have time yet -- I had the code already working as prototype, so I pushed to have something to rely on.
If I understand correctly, we only have one type of message - "event". Is there a need for other types of messages?
We will discuss and decide.
Using a Json payload for the payload seems clever and extensible to me.
When a connection is opened, should we send an event to identify a particular server, version of the server and version of the evapi so that client can handle changes and upgrades in the future?
Should potential commands from client to server be done over the standard RPC commands - do we really need a new way for clients to control Kamailio? The event part was clearly missing, but we have a few ways to connect to Kamailio already.
Can we protect this listen port with TLS? Do we need authentication?
Authentication is planned, tls can be added in the future. Main goal is for local communication between kamailio and some application. But then it can be extended as needed.
I was using libev, not the core code for transport, thinking of playing with this framework for concurrency, not expecting anyhow lot of connections there. It might be a good reason to try gnutls particulary for this case when we want to add tls to see if is easier/better in any way than openssl.
Cheers, Daniel
Just a few thoughts. This will be a very important new feature, so it's important we get it right.
Thank you for starting this, Daniel! /O _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson