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