Firstly, what is SAM support? One end of an SS7 link initialises a new call by sending an Initial Address Message (IAM). All SS7 software stacks support this and usually it’s enough. One case where it’s not enough is when one wants to address a phone number with more than the E.164 standard max length of 16  (usually to pass additional information tacked on the start, end of or even replacing an A or B number). In this scenario, SS7 uses a Subsequent Address Message (SAM) to send the additional digits. Most / all mainstream Asterisk SS7 software stacks do not support this.

The platform and software used is as follows:

• Ubuntu 10.04 LTS standard CLI install;
• dahdi-linux-complete-2.4.0 from the archives (direct link);
• a patched version of libss7 supporting SAM via SVN (see below);
• a patched version of chan-dahdi via SVN (see below);
• Asterisk 1.6.0.28 from the archives (direct link);
• Asterisk Addons 1.6.0.6 from the archives (direct link);
• Sangoma Wanpipe 3.5.24 (direct link).

Yes, I know some of the above are obsolete. Unfortunately it’s what’s required for everything to play nicely together. And, guess what, it works!

Before You Start

Ensure you have all the necessary packages for building the packages:

apt-get install build-essential libnewt-dev subversion    \
   libsqlite3-dev libsnmp-dev bison libtool flex          \
   autoconf2.13 libmysqlclient-dev

You can assume the working directory is /usr/local/src in the following.

Installing dahdi-linux-complete

Download and extract dahdi-linux-complete into /usr/local/src. Then, in the same directory, create some symbolic links:

ln -s dahdi-linux-complete-2.4.0+2.4.0/linux dahdi-linux
ln -s dahdi-linux-complete-2.4.0+2.4.0/tools dahdi-tools

Now build dahdi-linux:

cd dahdi-linux
make
make install

Now move onto dahdi-tools:

cd dahdi-tools
./configure
make menuconfig # (and select tools or accept defaults)
make
make install
make config

Installing libss7

There is a patched version of Digium’s libss7 referred to as Attila’s libss7 available via SVN. Download and install it:

svn co https://observer.router.hu/repos_pub/libss7/trunk alibss7
cd alibss7
make
make install

Installing Asterisk

Download and extract the Asterisk 1.6.0.28 package reference above.

cd asterisk-1.6.0.28

Now this next bit is very important and easy to miss - you also need a patched version of chan_dahdi.c that is compatible with the patched version of libss7. This is also available from SVN:

svn co https://observer.router.hu/repos_pub/chan_dahdi/trunk achan_dahdi

Then copy it to your Asterisk source:

cp achan_dahdi/chan_dahdi.c asterisk-1.6.0.28/channels/chan_dahdi.c

Now continue with the Asterisk installation:

./configure
make menuconfig
make
make install
make samples
make config

Install Asterisk Addons (optional)

Download and unpack the above referenced add ons package and build and install:

cd asterisk-addons-1.6.0.6
./configure
make menuconfig
make
make install
make samples

Sangoma Wanpipe

I’m using one of Sangoma’s E1 / T1 interface cards and so I need Wanpipe also. I’m using version 3.5.24 and preceed as follows after unpacking:

cd wanpipe-3.5.24./Setup install

During the install, follow these prompts:

• select option 2 => Asterisk/Dahdi Support;
• enter path /usr/local/src/dahdi-linux (for Zaptel path prompt);
• select defaults for everything else;
• you DO want to install start-up scripts;
• you DO to configure wanpipe devices for DAHDI;
• you DO want to generate /etc/asterisk/chan_dahdi.conf and:
  • select E1 / T1 as appropriate;
  • select line framing and encoding;
  • choose clock source;
  • select Zaptel/Dahdi – PRI CPE as signalling;
  • select National ISDN 2 as switch type;
  • do not enable hardware DTMF detection;
  • use all channels;
  • select dial plan context as appropriate;
• and continue for other ports as necessary;
• finally, choose Save cfg: Stop Asterisk & Wanpipe now
• you would like wanrouter to start on system boot;
• and you would like to execute ‘dahdi_cfg’ each time wanrouter starts.

Configuration Steps

We now need to set various options in Wanpipe, Dahdi and Asterisk for SS7 as it’s PRI/ISDN by default.

Edit all /etc/wanpipe/wanpipeX.conf files as necessary and change:

 TDMV_DCHAN              = 16

to

TDMV_DCHAN              = 0

Now edit /etc/dahdi/system.conf and change (for example):

span=1,1,0,ccs,hdb3,crc4
bchan=1-15,17-31
echocanceller=mg2,1-15,17-31
hardhdlc=16

to

span=1,1,0,ccs,hdb3,crc4
bchan=2-31
echocanceller=mg2,2-31
mtp2=1

which of course assumes signalling is on channel 1. If you have voice only links, you might need something like:

span=1,0,0,ccs,hdb3,crc4bchan=1-31
echocanceller=mg2,2-31

Lastly, we need to configure Asterisk. Replace lines such as:

;Sangoma A102 port 1 [slot:4 bus:5 span:1]
switchtype=national
context=from-pstn
group=0
echocancel=yes
signalling=pri_cpe
channel =>1-15,17-31

with an appropriate configuration. Mine follows below with some edits and some important notes at the end:

;Sangoma A102 port 1 [slot:4 bus:5 span:1]
switchtype=national
context=from-pstn
group=0
echocancel=yes

signaling=ss7
ss7type=itu
ss7_called_nai=dynamic
ss7_calling_nai=dynamic
ss7_internationalprefix=00
ss7_nationalprefix=0
ss7_subscriberprefix=
ss7_unknownprefix=
linkset=1
pointcode=1
adjpointcode=2
defaultdpc=3
networkindicator=national_spare
cicbeginswith=2
channel=2-31
sigchan=1

• Set pointcode, adjpointcode and defaultdpc as appropriate;
• set networkindicator as appropriate and ensure it matches the other end (you can see what you’re being sent and what you’re sending via ss7 debug;
• cicsbeginwith is normally 1 but the telco on my end are starting at 2 – this was groping in the dark diagnostics and issues such as no audio, CICs not in service when both sides claim they are, etc may point to misaligned CICs;
• make sure you have configured from-pstn or the appropriate context in yourextensions.conf.

Confirming Your Link Is Up

Now start wanrouter (/etc/init.d/wanrouter start); dahdi (/etc/init.d/dahdi start); and Asterisk (/etc/init.d/asterisk start). You should see your link come up via logs available with the dmesg command. Launch the Asterisk console and check the status of your links:

ast-deg1-1*CLI> ss7 show cics 1
  CIC   DPC  DAHDI        STATE   BLOCKING
    2    3      2         Idle
    3    3      3         Idle
    4    3      4         Idle
    5    3      5         Idle
    6    3      6         Idle
    7    3      7         Idle
    8    3      8         Idle
    9    3      9         Idle
   10    3     10         Idle
   11    3     11         Idle
   12    3     12         Idle
   13    3     13         Idle
   14    3     14         Idle
   15    3     15         Idle
   16    3     16         Idle
   17    3     17         Idle
   18    3     18         Idle
   19    3     19         Idle
   20    3     20         Idle
   21    3     21         Idle
   22    3     22         Idle
   23    3     23         Idle
   24    3     24         Idle
   25    3     25         Idle
   26    3     26         Idle
   27    3     27         Idle
   28    3     28         Idle
   29    3     29         Idle
   30    3     30         Idle
   31    3     31         Idle

You should now be okay to make test calls.

Do You Need Professional Support / Consultancy?

While I will try to respond to comments and questions on this blog, I don’t have the time to provide one on one assistance pro-bono. Professional consultancy on Asterisk and SS7 is available worldwide through my company, Open Solutions with contact details here.

References

For posterity, I have added Domjan Attila patched libss7 and chan_dahdi to GitHub:

• https://github.com/barryo/attila-libss7
• https://github.com/barryo/attila-libss7-chan_dahdi

To that end, I have created a repository on GitHub for the task with a detailed readme file:

• https://github.com/barryo/nagios-plugins

As a starting point, there are four plugins available now:

The straw finally came when Nick forced my hand for a project we wanted to release through our work in INEX. I was pushing for Google Code but he had his heart set on GitHub. Now, in fairness, GitHub has some SVN bindings but after some research, I decided to dive right in.

Now, there’s both a steep learning curve but also a complete change of mindset required from centralised source code management (SCM) with SVN to the distributed model of Git. In the end, most projects will decide on a canonical Git repository anyway which pushes you slightly back towards centralised but there’s still a world of a difference.

So, what’s so good about Git? Well, lots. But first and foremost is it’s exceptionally powerful yet simple branching and merging that just works. And works fast – remember, with Git everything is local.

One work flow that used to kill me in SVN was that you’d be implementing feature X but someone needed bug Y fixed immediately involving some of the same code. Getting just the fix for Y in was tough and complicated. And branching in SVN isn’t quick or simple. In Git, I branch from the main development branch for every new feature, bug fix, etc and then merge what I need between them and back into develop when they’re ready to be pushed back to the agreed canonical repository.

I’ve been so impressed with Git that I’ve moved an open source project we created in Open Solutions over to Github: ViMbAdmin. I’ve also forced the rest of my team in Open Solutions over to Git and migrated a number of customer projects already. And we’re reaping productivity rewards!

How we work Git for projects was taken from this excellent post which I would fully recommend: A successful Git branching model.

Useful Git Links:

• Git for SVN Users: http://git.or.cz/course/svn.html
• Git SVN Comparison: https://git.wiki.kernel.org/index.php/GitSvnComparison
• Git’s own website: http://git-scm.com/
• Git Cheat Sheets: http://help.github.com/git-cheat-sheets/
• The excellent book Version Control with Git (from Amazon)

ViMbAdmin (pronounced vim-be-admin) is essentially a modern replacement for PostfixAdmin – a web based interface which will allow you to manage virtual mailboxes, virtual domains and aliases.

We have a live demo which you can access here. You can also browse screenshots by clicking the image on this page.

ViMbAdmin was written in PHP using our own web application framework which includes the Zend Framework, the Doctrine ORM and the Smarty templating system with JQuery on the frontend.

The decision to use Smarty, Doctrine and Zend unfortunately adds a bit of overhead for someone installing the product as they will also need to locate these third party libraries. Fortunately:

• many distributions include all three as packages now;
• if you take the svn install option then they will be also installed from external svn sources.

ViMbAdmin can work as a slot in replacement for Postfix Admin with a few MySQL ALTER statements.

Features

• Super admin(s) user level with full access;
• Admin(s) user level with access only to assigned domains and their mailboxes and aliases;
• Super admins can create and modify super admins and admins;
• JQuery Datatable throughout for quick in browser searching and pagination;
• Create, modify and purge domains including limited the number of mailboxes and aliases a non-super admin can create per-domain;
• Activate / deactivate admins, domains, mailboxes and aliases at the click of a button;
• Full logging;
• Facility for users (mailbox owners) to change their password;
• Forgotten Password / Password Reset function for admins;
• Very configurable including:
  • set default values for quotas, number of mailboxes and aliases for domain creation;
  • templated welcome and settings email for users;
  • either plain or MD5 mailbox password support.

We hope it’s of use to you!

In this first of a serious of articles where we delve into some of the hidden treasures in our ViMbAdmin application, we look at how to integrate Doctrine ORM with Zend – and specifically Zend_Application and Zend_Controller.

As all the code is available with the GPL license online, I didn’t over explain the set-up but I’d love some feedback on whether I’ve been too obscure for the article to be useful at all.

Head over to my article on the company blog for the tips.

Cannot find autoconf. Please check your autoconf installation and the
$PHP_AUTOCONF environment variable. Then, rerun this script.

and when fixed, it’s followed up by:

Cannot find autoheader. Please check your autoconf installation and the
$PHP_AUTOHEADER environment variable. Then, rerun this script.

The fix is to set those environment variables (as appropriate for the autoconf and autoheader version numbers – the below is my example on FreeBSD 8.1):

export PHP_AUTOCONF=/usr/local/bin/autoconf-2.68
export PHP_AUTOHEADER=/usr/local/bin/autoheader-2.68

in bash of the following in tcsh:

setenv PHP_AUTOCONF autoconf-2.68
setenv PHP_AUTOHEADER autoheader-2.68

These retrofits include installing virus and SPAM filters to protect both ourselves and the ISP customers but also to stop customers who have infected computers from spewing these emails out.

When everything’s up and appears to be working, I like to test both filtering systems to ensure they’re working. Quoting from eicar:

Using real viruses for testing in the real world is rather like setting fire to the dustbin in your office to see whether the smoke detector is working. Such a test will give meaningful results, but with unappealing, unacceptable risks.

Fortunately, test files exist for virus checkers and SpamAssassin:

• The EICAR standard anti-virus test file can be found here.
• SpamAssassin created the GTUBE (Generic Test for Unsolicited Bulk Email) for the same purpose and this can be found here.

Most people’s first impression of 8.10 will be based on the upgrade process and post install issues. To date, I’ve always had to fix a lot of problems with the system after an upgrade to make it work. Not this time – it was absolutely seamless.

I was also apprehensive about KDE 4.1 and, to be honest, I was really worried that in a crunch I’d have to fall back to Gnome before degrading back to 8.04. I just don’t have the time these days to follow KDE development as much as I used to and I briefly installed KDE 4 a few months ago and thought it was far from finished.

I’m delighted to report KDE 4.1 is very slick and very polished. I’ve only had it for just over 24 but I have no complaints yet.

However, my main motivation for the upgrade was mobile broadband. Like most people, I use my laptop when on the move and my desktop when in the office. My laptop has an Ethernet port and a wi-fi card which both worked great with KNetworkManager but not mobile broadband. I got O2′s broadband dongle (the small USB stick) about four months ago and rely on it heavily.

I’ve been using Vodafone’s Mobile Connect Client to great effect but there were some issues:

• setting up the connection was a manual process (change X window access control; su to root; export the DISPLAY setting; and start the application);
• if I suspended the laptop then I needed to reboot the system to use the dongle again.

While both of the above could be solved, it’s just not plug and play. 8.10 is. With the dongle plugged into the USB port, KNetworkManager discovered the tty port. Configuring it was as easy as right clicking on the KNetworkManager icon and selecting New Connection… icon for the tty port.

The next step requires knowledge of the O2 / provider settings but this is readily available online. For O2:

KNetworkManager - Settings for O2 Ireland

After the above, I just accepted the defaults for the rest of the options. And – to my delight – it just worked. And it worked after suspended the laptop. And after popping the USB dongle in and out for the heck of it. By clicking the Auto Connect option as part of the process, it also just works when I pop the dongle in.

Anders Baekgaard of Dicea ApS (current chan_ss7 maintainers) recommends the following alternative patch. Please note that mtp3d.c will also need to be patched in the same way:

--- chan_ss7.c~ 2008-04-03 09:23:56.000000000 +0200
+++ chan_ss7.c  2008-04-29 08:29:20.000000000 +0200
@@ -249,11 +249,12 @@

 static void dump_pcap(FILE *f, struct mtp_event *event)
 {
+  unsigned int sec  = event->dump.stamp.tv_sec;
   unsigned int usec  = event->dump.stamp.tv_usec -
     (event->dump.stamp.tv_usec % 1000) +
     event->dump.slinkno*2 + /* encode link number in usecs */
     event->dump.out /* encode direction in/out */;

-  fwrite(&event->dump.stamp.tv_sec, sizeof(event->dump.stamp.tv_sec), 1, f);
+  fwrite(&sec, sizeof(sec), 1, f);
   fwrite(&usec, sizeof(usec), 1, f);
   fwrite(&event->len, sizeof(event->len), 1, f); /* number of bytes of packet in file */
   fwrite(&event->len, sizeof(event->len), 1, f); /* actual length of packet */

END UPDATE: April 29th 2008

A quickie for the Google trolls:

While trying to debug some SS7 Nature of Address (NAI) indication issues, I needed to use chan_ss7′s ‘dump’ feature from the Asterisk CLI. It worked fine but the resultant pcap files always failed with messages like:

# tshark -r /tmp/now
tshark: "/tmp/now" appears to be damaged or corrupt.
(pcap: File has 409000-byte packet, bigger than maximum of 65535)

After much digging about and head-against-wall banging, I discovered the issue
is with the packet header in the pcap file. It’s defined by its spec to be:

typedef struct pcaprec_hdr_s {
        guint32 ts_sec;         /* timestamp seconds */
        guint32 ts_usec;        /* timestamp microseconds */
        guint32 incl_len;       /* number of octets of packet saved in file */
        guint32 orig_len;       /* actual length of packet */
} pcaprec_hdr_t;

chan_ss7 uses the timeval struct defined by system headers to represent ts_sec and ts_usec. But, on 64bit machines (certainly mine), these values are defined as unsigned long rather than unsigned int (presumably as a step to get over the ‘year 2038 bug’). Hence the packet header is all wrong.

An easy solution is the following patch in mtp.h:

77a78,90
> /*
>  * The packet header in the pcap file (used for the CLI command 'dump') is
defined so has to
>  * have the two time components as unsigned ints. However, on 64bit
machines, the system
>  * timeval struct may use unsigned long. As such, we use a custom version
here:
>  */
> struct _32bit_timeval
> {
>   unsigned int tv_sec;            /* Seconds.  */
>   unsigned int tv_usec;      /* Microseconds.  */
> };
>
>
>
125c138
<       struct timeval stamp;        /* Timestamp */
---
>       struct _32bit_timeval stamp;        /* Timestamp */

There may be a better way – but this works.

This relates to chan_ss7-1.0.0 from http://www.dicea.dk/company/downloads and I have let them know also. It’s also a known issue for the Wireshark developers (although I did not investigate in detail to see what their resolution was for the future). See the following thread from 1999:

• http://www.ethereal.com/lists/ethereal-dev/199908/msg00065.html