Differences From the P2.6 Release

If you are accustomed to working with the P2.6 release, the transition to P2.8 will mean some big changes. Why? The short answer is that this is the why that the commercial release is evolving and the architecture of the official public release tracks of the commercial release.

Database-Driven Configuration

In P2.8, configuration is no longer from a text file but from an sqlite3 database at /etc/OpenBTS/OpenBTS.db. Any change of a non-static parameter in this database will result in a change in OpenBTS operation within about 2 seconds. In the OpenBTS "tools" directory there is a Python script called translateConfig.py the will convert an old-style configuration file into an SQL file sthat can be fed into sqlite3 to generate a configuration database.

Why?

Database-driven configuration allows external applications to control critical operating parameters of the OpenBTS system. This opens the way for web-based and automated configuration management tools and allows many operating parameters to be changed without disrupting the service.

Real-Time Asterisk

In P2.8, OpenBTS no longer uses Asterisk's internal SIP registry as an HLR replacement. Instead, it uses a new component called the subscriber registry, based on an sqlite3 database at /var/lob/asterisk/sqlite3dir/sqlite3.db. This database includes tables for both SIP user registration and call routing in a configuration called  realtime asterisk. There are three important implications:

1. OpenBTS no longer performs SIP REGISTER exchanges with Asterisk directly. Instead, SIP REGISTER methods are sent to a new server called sipauthserver, the SIP interface of the subscriber registry.
2. OpenBTS handsets can no longer be provisioned into Asterisk through /etc/asterisk/sip.conf. Instead, they must be provisioned into the subscriber registry. Otherwise, Asterisk has no way to know the registered IP address of the handset.
3. The dialplan configuration now uses explicit database lookups through the ODBC interface to route calls. For example:

   [phones]
   ; This is the context for handsets provisioned through the realtime database.
   ; This assumes that OpenBTS units all are running their SIP interfaces on port 5062.
   exten => _N.,1,Set(Name=${ODBC_SQL(select dial from dialdata_table where exten = \"${EXTEN}\")})
   exten => _N.,n,GotoIf($["${Name}" = ""] ?outbound-trunk,${EXTEN},1)
   exten => _N.,n,Set(IPAddr=${ODBC_SQL(select ipaddr from sip_buddies where name = \"${Name}\")})
   exten => _N.,n,GotoIf($["${IPAddr}" = ""] ?outbound-trunk,${EXTEN},1)
   exten => _N.,n,Dial(SIP/${Name}@${IPAddr}:5062)
   

Why?

The real-time Asterisk approach allows multiple programs to access the provisioning databases directly, which opens the way for a wide range of provisioning and account-management tools. It also allows smqueue to run independently of Asterisk and simplifies integration of OpenBTS with other (non-Asterisk) switches and PBXs.

Syslog

OpenBTS P2.8 uses syslog (or rsyslog) for event and message logging. This is a big improvement over the old system of logging to a regular file.

Why?

The advantages should be obvious.

No, I mean "Why not SNMP?"

Because we just haven't gotten around to it yet.

Bug Fixes

There are lots of bug fixes in P2.8, especially in the SIP side. P2.8 has been tested successfully with Asterisk 1.8 and FreeSWITCH and should work with any softswitch. If it does not, that is a bug that should be reported here.

Other Features

There are some other minor features included in P2.8:

• Rest octet support in system information messages.
• Better RRLP support, including an RRLP aiding server.
• Realtime reporting of radio channel activity to an externally visible database.
• The TMSI table has also been moved to an externally visible database, although it will probably be moving into the subscriber registry in future releases.