[ opensips-Patches-2799993 ] call_control: TCP connection for external prepaid app

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[ opensips-Patches-2799993 ] call_control: TCP connection for external prepaid app

Patches item #2799993, was opened at 2009-06-02 15:46
Message generated for change (Comment added) made by quark38
You can respond by visiting:

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.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Philippe Favier (quark38)
Assigned to: Dan (dan_pascu)
Summary: call_control: TCP connection for external prepaid app

Initial Comment:
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: Philippe Favier (quark38)
Date: 2009-06-10 09:14

                  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
  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 !!! :-)


Comment By: Dan (dan_pascu)
Date: 2009-06-05 09:30

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.


You can respond by visiting:

Devel mailing list
[hidden email]