I assume this run's on Linux only ? Is your project on the web somewhere? Jan > Date: Thu, 15 Jul 2010 15:57:55 +0200 > From: sverker at abrahamsson.com > To: asterisk-ss7 at lists.digium.com > Subject: Re: [asterisk-ss7] SIGTRAN GW based on libss7 > > No, there is no licence conflict as the binaries are not linked together. > The dialogic stack sit on the other side of the SCTP socket and > communicate with the signaling gateway over SIGTAN. It's only the > signaling gateway code itself that has to be released as GPL as it's > linked to libss7. > /Sverker > > > > > Isn't that a license conflict? I assume Dialogic is commercial? > > > > > > Jan > > > > > > > > > > From: sverker at abrahamsson.com > > To: asterisk-ss7 at lists.digium.com > > Date: Thu, 15 Jul 2010 15:28:43 +0200 > > Subject: Re: [asterisk-ss7] SIGTRAN GW based on libss7 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, I?m only using the libss7 up to mtp3 level. The plan is to > > support M2UA as well, and maybe M2PA if the need come up. > > > > > > > > I currently use Dialogic for SCCP/TCAP/MAP layers but the nice > > part about this architecture is that it can be combined with more or less > > any > > stack and any card supported by dahdi. > > > > /Sverker > > > > > > > > > > > > > > > > > > > > From: asterisk-ss7-bounces at lists.digium.com > > [mailto:asterisk-ss7-bounces at lists.digium.com] On Behalf Of Jan Berger > > > > Sent: den 15 juli 2010 2:47 > > > > To: asterisk-ss7 at lists.digium.com > > > > Subject: Re: [asterisk-ss7] SIGTRAN GW based on libss7 > > > > > > > > > > > > > > > > I have never seen the value of ISUP over > > SIGTRAN. CAMEL, INAP, MAP makes more sense, but in that case you should > > only > > use mtp3 and avoid the rest of Asterisk for the IN-apps. > > > > > > > > > > > > That is unless you plan an integrated SRP solution. > > > > > > > > > > > > > > > > For Asterisk I would consider M2UA because that allows an Asterisk to > > benefit > > from the redundancy and failover in M2UA + you could stack a SS7 that > > run's > > over several boxes - thought the value is a bit limited. > > > > > > > > > > > > What do you use for SCCP, TCAP and CAMEL/MAP? > > > > > > > > > > > > Jan > > > > > > > > > > > > > > > > From: sverker at abrahamsson.com > > > > To: asterisk-ss7 at lists.digium.com > > > > Date: Thu, 15 Jul 2010 10:17:16 +0200 > > > > Subject: Re: [asterisk-ss7] SIGTRAN GW based on libss7 > > > > > > > > Hi Jan, > > > > You are right of course, ISUP needs more than just the signaling > > to be relevant. My focus is on SCCP as it?s MAP and INAP that is most > > interesting for me. > > > > > > > > Yes, I use the LGPL M3UA stack. > > > > /Sverker > > > > > > > > > > > > > > > > > > > > From: asterisk-ss7-bounces at lists.digium.com > > [mailto:asterisk-ss7-bounces at lists.digium.com] On Behalf Of Jan Berger > > > > Sent: den 14 juli 2010 3:15 > > > > To: asterisk-ss7 at lists.digium.com > > > > Subject: Re: [asterisk-ss7] SIGTRAN GW based on libss7 > > > > > > > > > > > > > > > > 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. Sign up now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hotmail: > > Powerful Free email with security by Microsoft. Get it now. > > > > > > > > > > _________________________________________________________________ > > Hotmail: Trusted email with powerful SPAM protection. > > https://signup.live.com/signup.aspx?id=60969-- > > _____________________________________________________________________ > > -- 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 > > > -- > _____________________________________________________________________ > -- 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 _________________________________________________________________ Hotmail: Trusted email with Microsoft?s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-ss7/attachments/20100715/a0f7afd5/attachment-0001.htm