[asterisk-ss7] SIGTRAN GW based on libss7

[Jan Berger]

hi Sverker,

 

Most interesting article.

 

SCCP over M3UA is straight forward, but how would you do ISUP?

 

What I mean is that ISUP contains reference to CIC's and basically is an instruction to connect a voice channel - but what will you use to actually connect to the voice channel ? Asterisk acting as an AS can be on a different box than the SG, meaning that if you run a proper SG you will need to connect the voice out from that box as well.

 

Are you using the LGPL M3UA stack?

 

Jan

 
> From: sverker at abrahamsson.com
> To: asterisk-ss7 at lists.digium.com
> Date: Tue, 13 Jul 2010 20:31:22 +0200
> Subject: [asterisk-ss7] SIGTRAN GW based on libss7
> 
> 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
> 
> 
> -- 
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-ss7
 		 	   		  
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-ss7/attachments/20100714/4847d844/attachment.htm