#94 call_control: TCP connection for external prepaid app

[Philippe Favier]

Added socket type TCP in addition to UNIX socket.

New config parameters:
o modparam("call_control", "socket_type", "tcp") # default = "unix"
o modparam("call_control", "server_name", "myserver.mydomain.com")
o modparam("call_control", "server_port", 5000)

Motivations for this patch:
o external prepaid application in Java (no Unix socket in Java)
o several openSIPS B2BUA's can be client to the same prepaid app
o prepaid app can run on a different server

[Philippe Favier]

call control patch for TCP connection

[Dan Pascu]

Hi Philippe,

Are you aware of the callcontrol application, available from http://callcontrol.ag-projects.com/ ?
That is a bridge between the opensips call_control module and the actual prepaid engine.

With this application combined with the call_control opensips module, one can already do all you list there. We currently have this running with:

- external prepaid application in PHP (the rating engine from CDRTool)
- multiple opensips proxies are clients to the same rating engine (via the callcontrol application)
- rating engine runs on a different server

The external callcontrol application acts as a bridge between the opensips call_control module and the prepaid engine.
On input it listens on the unix socket and it connects over tcp to the rating engine.

From this point of view, it's much easier to modify this callcontrol application to connect to your rating engine than to modify the opensips module to talk tcp. One of the reasons why a direct TCP connection to the rating engine was not considered in the first place is that tcp connections can potentially freeze your proxy if the other site becomes unavailable. Plus the callcontrol application is also able to keep track of time and close the sessions that exceed their credit limit.

[Philippe Favier]

Dear Dan,

Yes I am aware of ag-projects's callcontrol application.

Before developping a new prepaid / postpaid convergent system, I looked for existing open source applications, but I did not find anything with enough functionality & flexibility.

In particular, I did not consider using the callcontrol application for the following reasons:

o the RE has not enough functionality (e.g. multiple measurement units, multiple charging units, balance change without call interruption, arbitrary call parameters for cost calculation, volume charging, event charging, fee calculation, arbitrary calculation function etc)

o the code looks risky to modify (no OO design)

o the code is written in an interpreted language, which means that there is no static verification ; one of the prerequisites on my side was to use a compiled language with static checking to improve reliability

Therefore, I decided to implement a new prepaid / postpaid app in Java which I will probably publish on SF when it will be extensively tested.

I do not see your point about the TCP connection I propose, since with the current implementation:

o the call_control interface is synchronous, which means that it blocks if the prepaid application blocks

o in particular, if the RE is on another server and the TCP connection hangs, then openSIPS blocks

My primary intend is to have an interface with a Java application. I plan to deploy that app on the same server as openSIPS. However, I made disconnect / reconnect tests (with deployment on separate servers) which perform OK.

The code to add a TCP connection in the call_control module is VERY simple:
o add a few config parameters (socket type, server name & port)
o add an init sequence for socket type TCP
and that's it !

PLEASE, consider my patch !!! :-)

[Adrian Georgescu]

Hi Philippe,

You have not read carefully enough or understood what Dan wrote. CallControl module and server does not have anything to do with pricing calculation. You are referring to the PHP code in CDRTool that does that and is probably the code you want to replace with your solution.

Dan talks about the Python written Call Control server that sites between the opensips callcontrol module and CDRTool rating engine. What you describe your software does is already achieved by the Call Control server, which is well written in Python that is very object oriented code that you could also attempt to modify with little risk if you need to, this server must connect to your application where you can design any pricing feature your want that way you see fitted.

This picture shows you more clear what is this about:
http://callcontrol.ag-projects.com/raw-attachment/wiki/WikiStart/CallControl.png

So while you are rightfully trying to replace the CDRTool rating engine functionality with your own program, you are trying to do this in the wrong place without understanding the whole design of the underlying software.

The idea is that your program should sit after the Call Control server in place of the CDRTool rating engine.