https://sysadminman.net/blog/2013/a2billing-and-opensips-part-3-4814

This is to confirm that SysAdminMan no longer offers FreePBX or A2Billing hosting.There were a few reasons for this decision but one of that main ones was, in my opinion, Sangoma’s aggressive commercialisation of FreePBX and their “FreePBX” trademark. It did not make commercial sense to continue building a business under these circumstances.According to Google Analytics there are still a couple of thousand visitors a week that use the site, so I will leave it here, but will not be adding new guides or tips.

This post has the actual config of OpenSIPS described in part 1 and part 2. Some of this config will not make sense unless you read those parts.

First a warning … many, many people want to use your call credit!! Make sure that your systems are secure. If only the OpenSIPS server needs to talk to your A2Billing/Asterisk servers over SIP then use a fierwall to block other connections.

In the configuration below OpenSIPS does not handle the Audio/RTP traffic, this is passed directly to the Asterisk/A2Billing server.

The code below is the whole opensips.cfg file, just broken up with some description. All indentation has been removed, apologies if this sometimes makes it difficult to read.

First some global settings, including the IP address of the OpenSIPS server –

next we load the modules that are required –

now we set the database URL for the modules that are going to use our MySQL database. This database is on the A2Billing server –

now we set some other module options –

and now to the actual routing. The first block has some general default code that rejects some packets and also immediately relays sip dialogs that have already been established –

next more generic checks. Relay CANCEL messages and reject others with incomplete URIs –

next drop some more invalid packets –

next we are going to create a route header on the packet and switch on some accounting –

now we are going to choose the Asterisk server that the call is passed to. This uses the ds_select_dst command which is part of the dispatcher module. The available Asterisk servers are selected from the ‘dispatcher’ table in the MysQL database. The ‘1’ relates to the ‘setid’ field in the ‘dispatcher’ table, and the ‘destination’ field should be in the format ‘sip:2.2.2.2:5060’ –

Now the good stuff! This is where we do IP authentication, and route the call if it is valid. We use the ‘check_source_address’ command which is part of the permissions module. This is going to look in the MySQL database for a matching IP address. The “1” is a group ID that we hard coded when we set up the VIEW in MySQL. If the IP address matches then the account code is returned to us (because we stored it in the context_info field in MySQL), and we set this to the variable “$avp(accountcode”. We then set this variable in a header on the SIP INVITE packet and send it to A2Billing. In part 2 I showed how to extract this SIP header and set the account code in the Asterisk dialplan, so that A2Billing knows which customer to charge for the call –

next, if IP authentication above failed we want to challenge the caller (the IP address sending the SIP INVITE) for a Username and Secret. “subscriber” is the name of the VIEW in MySQL where we are storing the customer credentials. These are picked up straight from the A2BIlling customers SIP account –

now, if the customer passed the authorisation above, we want to send the call to our Asterisk/A2billing server. First though we want to set the Account Code so that A2Billing knows which customer to charge the call to. This is similar to what we did for IP authentication, but we need to run a separate command to retrieve the account code from the ‘rpid’ field in the ‘subscriber’ table where we stored it. $au is the authorized username –

Finally, we called route(RELAY) several times in the script above, and we define that here, and a couple of other bits, we forward the packets with t_relay –

And that’s the end of the config file!

The code above is definitely not designed to be totally cut and paste. You are going to have to check some documentation and have a fair understanding of what’s going on and how the call is being handled. I would also suggest learning the xlog command and some of the variables available. This you can use at various points in the script to log some output and see why you calls might be failing.

If anyone experienced with OpenSIPS (or Kamailio) can offer any suggestions for how to improve the config I’d be interested to hear them. Also, of anyone with Kamailio experience could let me know how different that config would look in that I’d be interested to hear that too. Thanks!