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
|