[asterisk-ss7] Libss7 Status Update

[Matthew Fredrickson]

Hey all, long time no update.  I've had a lot of my time caught up in 
other projects of late, so I haven't had quite as much time to make 
major changes, however, here is a short list of things that have 
changed.  First of all, if you haven't been monitoring the threads, 
with the release of the 1.4 beta branch, I was able to commit all of my 
asterisk-ss7 branch changes back into trunk.  No, this does not mean 
that it will be in 1.4, but I'll probably be maintaining a 1.4 based 
branch with the ss7 changes once 1.4 is officially release.  For now, 
if you want to play with libss7 and Asterisk, you will need to check 
out the trunk version of asterisk (`svn co 
http://svn.digium.com/svn/asterisk/trunk asterisk-trunk).  You still 
need to have the trunk versions of zaptel (`svn co 
http://svn.digium.com/svn/zaptel/trunk zaptel-trunk`) or the 1.4 beta 
release as well as the trunk version of libss7 (`svn co 
http://svn.digium.com/svn/libss7/trunk libss7`).

Feature wise, I just added support for doing remote block requests from 
the asterisk command line, with the "ss7 block cic <linkset> <cic>" 
syntax.  The first number is the linkset that you want to block the CIC 
on (from zapata.conf) and the second is the CIC on that linkset you 
wish to block.  There is also a parallel unblock command (ss7 unblock 
cic <linkset> <cic>).  I have been working some more on multilink 
support, so that's something we'll see in the future.  I actually had a 
conference call with a couple of members of the community about SS7 and 
future development directions all over an ANSI ss7 link using libss7 
and asterisk.  It was a quite satisfying experience :-)  The primary 
topics of conversation were regarding making asterisk be able to handle 
more trunks from one point code.  These were the two basic directions 
for doing that that we thought of:

The first was to add support in chan_zap (or a layer below that) for 
talking to MGCP gateways and being able to control them through that 
interface.  The CICs on them would exist as "virtual" zap channels, and 
would be controlled as such.  The media would just come in as RTP to 
asterisk, and everything would work very similarly to how things work 
right now.  RTP re-invites could probably be done do take Asterisk out 
of the media as needed.  It would require very little functionality 
changes within asterisk and the dialplan for that to work.

The other direction was to add support for M3UA or a similar protocol 
to pass ISUP messages on a signalling gateway to other Asterisk boxes 
that actually terminate the CIC that is relevant to that particular 
message.  This is useful, because then you could use asterisk as a 
media gateway as well as a signalling gateway, and is very much how 
asterisk likes to be anyways.

On the whole it was fairly productive, as I have thought more about the 
second path, but the first one I had trouble conceptualizing how it 
would easily integrate in until we had that call.  Now it seems to be a 
very technically attainable idea.  As always, if anyone has any 
comments or suggestions, peer review is always welcome.

Matthew Fredrickson