Hi! I have some remark - should add many members to asterisk channel structure to carry the SS7 attributes, eliminate the tons of SS7_* channel variables - implement the new channel structure memebers to pass on other channel types (SIP, IAX2) - adding type flag on SIP/IAX2 channels to describe the peer is "custemer" -> hide callerid if presentation not allowed, don't pass many additianal channel attributes, "trunk" -> pass many attributes to peer as the channel driver can - I had many dirty hacking around dtmf in chan_dahdi for for alarm systems. I had turn off dtmf detection on dahdi -> SIP/MGCP g711 calls. The alarm systems communicates 10digits/sec... So would be nice if a new bridging option, turning off any dtmf detection on uncompressed media bridging. I have not posted all off the patches to bugs.digium.com you can find it in my svn. This version is stable, I'm using in my production system, have 10k+ customers, with modified asterisk 1.6.0.9 + modifed chan_mgcp (NCS, realtime, PacketCable COPS). A On Thu, 2010-03-25 at 23:40 -0500, Matthew Fredrickson wrote: > Hey all, > > It's been a long time. I apologize for my quietness for the last while > here, it has been a very busy year this last year with some of the other > projects I've been working on. > > I just wanted to let everyone know that I'm still alive, and haven't > given up or forgotten about libss7, and Asterisk with SS7. > > I appreciate very much Attila's great work on getting libss7 polished > up. He's done a very good job taking it to the next level, and has done > a great job helping everyone out. Thanks very much Attila. > > As far as getting his code merged back in, I was in the midst of this a > while ago, but had to stop due to personal time issues as well as some > other potentially architectural issues that subsequently came up. > Hopefully we can get that moving again in the next little bit though. > > I actually have been quite busy, and hopefully have some things to show > for it, two things actually. > > I'll not go into too much detail tonight (as it's getting quite late) > but I'm looking for some hungry testers, that wouldn't mind beating up > on some probably alpha level code. > > They are: > > 1.) libss7 point code clustering support. > > Basically, you can have Asterisk boxes share signalling links now using > this code. Although the signalling links are physically terminated on > other machines, you can plug bearer T1s/E1s into other Asterisk boxes > and virtually utilize the signalling links of the other boxes. > > 2.) A new channel driver, called chan_ccs, that allows, among other > things, you to control MGCP media gateways for bearer trunks, instead of > having to locally terminate them on the asterisk box that's controlling > the signalling links. There is also code in the same branch that has > chan_ccs that modified chan_mgcp so that Asterisk can act as a media > gateway (since I don't have any good real media gateways to test on). > This basically means you can have Asterisk TDM channel scalability up to > (in the ideal state) the same level as you can do with SIP with no > media, per box. > > In essence, this is turning Asterisk into a "true" softswitch, allowing > native bridging between media gateways and any other RTP endpoint > (including other media gateways). This also means that you don't have > to terminate bearer T1s/E1s on the main signalling box. > > -- So, what does this mean for you, you may be asking? > > These are really the next steps in making big SS7 work with Asterisk. > They both allow for scaling a point code across multiple asterisk > machines, and distribution of bearers on different boxes than the ones > that contain signalling links. > > Like I said though, most of the work is in a functional but early phase, > and so I need some people that are interested enough in the added > functionality that they're willing to work with potential hickups along > the way. > > Some of the changes I've had to make to libss7 have made it further more > difficult to merge Attila's changes back in, which is the other reason > why it has been so long and it still has not been merged. > > If you're interested, either reply to me or this thread and let me know. > > Thanks again, > > Matthew Fredrickson > Digium, Inc. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part Url : http://lists.digium.com/pipermail/asterisk-ss7/attachments/20100326/2da54fcc/attachment.pgp