[asterisk-ss7] SIGTRAN GW based on libss7

[Sverker Abrahamsson]

Hello everybody,
Since a while back I've been working on a SIGTRAN signaling gateway which
use libss7 for MTP2 and MTP3 layers and currently support M3UA on the IP
side, it needs some more work as still many things are hardcoded for the
specific application but it is being used in production currently. I'm using
E1 card from Sangoma with wanpipe 3.5.11.4 and dahdi 2.3.0.

To do that I've modified libss7 1.0.2 to allow SCCP packages to be passed
from libss7 to the gateway app, as I'm currently using only that protocol.
I'm now looking into cleaning up the code and making it general purpose, and
I'm also facing an issue. Some questions and remarks:

* libss7 contains implementations for MTP2, MTP3 and ISUP. I'd be interested
to support ISUP over the SIGTRAN as well. One way to solve that is that the
lib has a call where the application can register which protocols it's
interested of, i.e. ISUP in that case will be passed on to gw application
instead of handled by internal implementation

* in file NEWS-05-30-2008 it is mentioned that part of MTP2 processing has
been moved to kernel space with a new channel driver in zaptel. Does that
work with dahdi as well and is there any configuration needed to enable it?
I saw an issue on sending mtp2 packets, they were queued in user space but
the poll in ss7linktest (that I based my app on) never got enabled for
write. I did a quick fix in mtp3_transmit that after calling mtp2_msu then
ss7_write is called.

* as I understand the trunk is not the most up to date but there are
development in other branches. Should I port my changes to trunk or to some
other branch?

* In trunk there has been some api changes so that ss7linktest doesn't
compile. I did changes to make it compile but I might have misunderstood
something as it didn't work to run it, the link didn't come up. Is there any
API docs or working example code to use with trunk (or recommended branch)?
How about merging the branches and make a 2.0 release?

* I'm currently facing an issue with memory corruption, I get the following
from valgrind:

==3591== 4999998 errors in context 2 of 8:
==3591== Thread 3:
==3591== Invalid free() / delete / delete[]
==3591==    at 0x400551D: free (vg_replace_malloc.c:325)
==3591==    by 0xC53E2F: mtp2_receive (mtp2.c:403)
==3591==    by 0xC5460B: ss7_read (ss7.c:365)
==3591==    by 0x80493B6: ss7_run (sgw.c:114)
==3591==    by 0xC83831: start_thread (in /lib/libpthread-2.5.so)
==3591==    by 0xBC3E0D: clone (in /lib/libc-2.5.so)
==3591==  Address 0x40c9958 is 0 bytes inside a block of size 520 free'd
==3591==    at 0x400551D: free (vg_replace_malloc.c:325)
==3591==    by 0xC53E2F: mtp2_receive (mtp2.c:403)
==3591==    by 0xC5460B: ss7_read (ss7.c:365)
==3591==    by 0x80493B6: ss7_run (sgw.c:114)
==3591==    by 0xC83831: start_thread (in /lib/libpthread-2.5.so)
==3591==    by 0xBC3E0D: clone (in /lib/libc-2.5.so)
==3591==
==3591==
==3591== 4999998 errors in context 3 of 8:
==3591== Invalid read of size 4
==3591==    at 0xC53E22: mtp2_receive (mtp2.c:402)
==3591==    by 0xC5460B: ss7_read (ss7.c:365)
==3591==    by 0x80493B6: ss7_run (sgw.c:114)
==3591==    by 0xC83831: start_thread (in /lib/libpthread-2.5.so)
==3591==    by 0xBC3E0D: clone (in /lib/libc-2.5.so)
==3591==  Address 0x40c9b5c is 516 bytes inside a block of size 520 free'd
==3591==    at 0x400551D: free (vg_replace_malloc.c:325)
==3591==    by 0xC53E2F: mtp2_receive (mtp2.c:403)
==3591==    by 0xC5460B: ss7_read (ss7.c:365)
==3591==    by 0x80493B6: ss7_run (sgw.c:114)
==3591==    by 0xC83831: start_thread (in /lib/libpthread-2.5.so)
==3591==    by 0xBC3E0D: clone (in /lib/libc-2.5.so)

Is this something that has already been addressed in trunk/dev branch? It
had worked fine for a couple of weeks and then suddenly started to happen
quite frequently under load.

* The plan for the signaling gateway is to support M3UA, M2UA and M2PA as
well as the Dialogic gct api. Naturally it will have to be released under
GPL since libss7 is.

Best regards
Sverker