[libss7-commits] mattf: trunk r176 - /trunk/

[SVN commits to the libss7 project]

Author: mattf
Date: Fri May 30 14:32:50 2008
New Revision: 176

URL: http://svn.digium.com/view/libss7?view=rev&rev=176
Log:
Add a few of the public service announcments I have made on the Asterisk-ss7 mailing list as well as update the README

Added:
    trunk/NEWS-08-23-2006
    trunk/NEWS-09-11-2006
    trunk/NEWS-09-27-2006
Modified:
    trunk/README

Added: trunk/NEWS-08-23-2006
URL: http://svn.digium.com/view/libss7/trunk/NEWS-08-23-2006?view=auto&rev=176
==============================================================================
--- trunk/NEWS-08-23-2006 (added)
+++ trunk/NEWS-08-23-2006 Fri May 30 14:32:50 2008
@@ -1,0 +1,5 @@
+Hey all, just wanted to let anybody know that attempted to test libss7/asterisk-ss7 this last weekend, that if you had any build problems, they should be resolved now.  In the course of some major merges that went into asterisk-trunk this last weekend, automerge failed on most of the developer branches (including my asterisk-ss7 branch).  I just got it fixed this morning, so everything should work now and build properly.
+
+For the record, in case nobody noticed, thanks to Luciano Ramos on the asterisk-ss7 list, libss7 was tested and successfully was able to receive a call on a Siemens EWSD switch running the ITU variant of SS7.  I added a section to the README file which gives the tested switch types that I have tested libss7 on.  As soon as we got that done, I started working on circuit blocking/unblocking support.  That should be in the asterisk-ss7 branch now to be tested.  I still haven't gotten an ANSI link to work on, so that is still in the works, however I seem to be getting a lot of good feedback and interest from everybody for testing.  Also, if nobody noticed the message I wrote this last week, I added another option to zapata.conf called defaultdpc which is for layer4 message routing, in case your desired destination point code is not the same as your adjacent node's point code (i.e. you have an STP or something between you and the remote end of your bearer channels, or simple A li
 nk support).  That's pretty much all I can remember for now, but I'll try to keep the feature list documented in the README file for libss7.  For all of you that offered links and resources, thanks again!  You have been a tremendous help. Stay tuned for more soon :-)
+
+Matthew Fredrickson 

Added: trunk/NEWS-09-11-2006
URL: http://svn.digium.com/view/libss7/trunk/NEWS-09-11-2006?view=auto&rev=176
==============================================================================
--- trunk/NEWS-09-11-2006 (added)
+++ trunk/NEWS-09-11-2006 Fri May 30 14:32:50 2008
@@ -1,0 +1,16 @@
+Hey all, long time no see, but I just wanted to give a status update on what is going on with libss7.  Last week I was able to commit my alarm detection code (in case you get an alarm on your spans that have signalling channels). It should restart the link when it comes out of alarm fine.  I think I need to get some more testing in though, since I mostly just wrote the code and did very rudimentary testing on it.  I also just added today support in zapata.conf for national_spare and international_spare networkindicator options in case your link uses the spare network  indicator values (someone on the list today had a problem with that).
+
+On an entirely different note, I got an ANSI style link working this week!!!!  I didn't ask permission to see if they minded being mentioned, so I won't mention any names for now, however it was a night to remember.  It was over a 56kbps link channel, using an older switch.  It went surprisingly easier than I thought it would.  MTP2 was already working well, MTP3 only had slight modifications, and ISUP had the most changes.   Other than the fact that I'd never seen a 56kbps link before.  Basically, the difference was that they don't use the top bit in a DS0 timeslot for HDLC code.  So if you want to try out libss7 on your ANSI link, this is how you do it:
+
+Disclaimer: You have to be using either a TE2xxp or TE4xxp for this to work, since I used the hardware hdlc features of the framer of that card to do the 56kbps link.
+
+Get current zaptel-trunk, libss7, and asterisk-ss7 from svn (You may also have to get libpri, I haven't checked if chan_zap compiles cleanly without libpri installed)
+Build them, and install them.
+
+If you are using 56kbps links, when you load the wct4xxp.ko module, you have to pass it the parameter hardhdlcmode=0x7f and instead of using "dchan" in zaptel.conf for your signalling channel, you need to use "hardhdlc" on that channel.
+
+In zapata.conf, setup your link following the pattern in the sample zapata.conf that comes with asterisk-ss7 and set your ss7type=ansi.  That should pretty much be it.  All the rest of the configuration is the same.
+
+As always, if you have any more questions, comments, requests, or anything else that matter, let me know.  I'd love to get feedback.
+
+Matthew Fredrickson 

Added: trunk/NEWS-09-27-2006
URL: http://svn.digium.com/view/libss7/trunk/NEWS-09-27-2006?view=auto&rev=176
==============================================================================
--- trunk/NEWS-09-27-2006 (added)
+++ trunk/NEWS-09-27-2006 Fri May 30 14:32:50 2008
@@ -1,0 +1,12 @@
+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
+

Modified: trunk/README
URL: http://svn.digium.com/view/libss7/trunk/README?view=diff&rev=176&r1=175&r2=176
==============================================================================
--- trunk/README (original)
+++ trunk/README Fri May 30 14:32:50 2008
@@ -27,7 +27,7 @@
 COLT
 
 Thanks to:
-=======
+==========
 Mark Spencer, for writing Asterisk and libpri and being such a great friend and boss.
 
 Luciano Ramos, for donating a link in getting the first "real" ITU switch working.
@@ -74,14 +74,26 @@
 instead.
 
 CONFIGURATION:
-In zaptel.conf, your signalling channel(s) should be a "dchan" and your bearers should
-be set as "bchan".
+In zaptel.conf, your signalling channel(s) should be a "mtp2" and your bearers should
+be set as "bchan".  If you have an older version of Zaptel (pre 1.4.11) that does not
+support the mtp2 channel type, it is strongly recommended that you update to a version that
+supports it.  If you cannot, or your card does not support the "mtp2" channel type, you
+can use "dchan" instead for your signalling link.  See NEWS-05-30-2008 for more details
+about the mtp2 channel type.
+
+zaptel.conf:
+============
+# For signalling link on Zap/24 and bearers on Zap/1-23
+mtp2=24
+bchan=1-23
 
 In the asterisk-ss7 branch, there is a sample zapata.conf that is installed which
 contains sample configuration for setting up an E1 link.
 
 In brief, here is a simple ss7 linkset setup:
 
+zapata.conf
+===========
 signalling = ss7
 ss7type = itu 		; or ansi if you are using an ANSI link
 
@@ -148,6 +160,9 @@
 Hop counter parameter
 Carrier identification parameter - (very simple, not configurable)
 SS7 debug looks *MUCH* nicer
+Kernel level MTP2 support (woohoo!) - See NEWS-05-30-2008 for more info
+* Many more messages are supported than are listed.  isup.c is the best place to look.
+
 
 TODO:
 =====
@@ -157,7 +172,7 @@
 Timer for last SU received so we know if layer2 goes out under us
 
 long term:
-SCCP support
+SCTP support (seems more people are interested in that than SCCP)
 
 For more information, please use the Asterisk-ss7 or Asterisk-dev mailing
 lists (I monitor them regularly) or email me directly.