Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Submitted By: Philippe Favier (quark38)
Assigned to: Dan (dan_pascu)
Summary: call_control: TCP connection for external prepaid app
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
Comment By: Adrian Georgescu (adigeo)
Date: 2009-06-10 09:27
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.
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.
Comment By: Philippe Favier (quark38)
Date: 2009-06-10 09:14
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
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
The code to add a TCP connection in the call_control module is VERY
o add a few config parameters (socket type, server name & port)
o add an init sequence for socket type TCP
and that's it !
Comment By: Dan (dan_pascu)
Date: 2009-06-05 09:30
Are you aware of the callcontrol application, available from
That is a bridge between the opensips call_control module and the actual
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
- 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
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.