I’ve been meaning for a while to write more about our Signalling/SS7 products and the API that comes with those. The architecture of the Signalling products is known as SigDiA, and this means that there is a common API, whether you’re using SIGTRAN, server-based products (like the SIU) or SS7 boards like the new SS7AM100Q
ATCA mezzanine board.

APIs come in all different shapes and sizes, and I guess in general each API falls somewhere on a line that looks like this:

Abstract, Simple Specific, Complex

In other words, an API can set out to offer maximum richness and flexibility, but this comes at the cost of simplicity. Likewise, you can set out to be abstract and simple (for example like the Diva Server Component API), and this has the advantage that programmers do not need to understand all of the mechanisms “under the hood”. The cost, however, is that total flexibility is not there, and perhaps some requirements still need enhancements to the API.

The SigDiA architecture allows every SS7/Sigtran protocol layer to be addressed, for example if you want access the MTP3 (routing) layer of SS7, or the MAP layer (for texting, location based services etc), then the same basic mechanism is used. In SS7 and SIGTRAN there are many different layers you access, depending on what protocols you need to communicate with the far-end device, for example Message Switching Centre (MSC), or Home Location Register (HLR).

The SigDia architecture presents an API that has a simple mechanism for submitting and waiting for messages. This is the simple part of the API, and is common to every protocol layer implemented in the system. Each protocol layer (including the end user app itself) has its own message queue for receiving requests from other layers, and the length of this queue can be tuned as part of the configuration to ensure that each layer can run at its optimal message processing rate without necessarily wasting memory.

The messages themselves are the complex part of the API, and in this way it is a bit reminiscent of the CAPI API (for those of you familiar with that). The messages allow you create a protocol message where every bit and byte of the message can be adjusted by the developer. Of course this means that in order to program a protocol layer, you need to understand the workings of the protocol really well. In many cases (like for SMS and the MAP protocol, or for call control and the ISUP protocol) we have sample code that can be used as the basis of a development.

One really great thing about the SigDiA architecture is that you can connect two machines back-to-back and use this as a development system using the Sigtran protocol layers. The driver software itself will run for 10 hours without licensing, and then needs to be restarted, but this is ideal for ad-hoc testing of an application in the lab. Once an app has been tested in the Sigtran configuration, it can be used in exactly the same way with SS7 hardware or with a server-based product, since at the application level, you only need to know the point code numbers, and the detail of the message transport is abstracted by the software configuration.

We will shortly be opening a forum specific to developer questions with the Signalling software, so this will be a good place to ask questions about how to build signalling solutions with our products.