Hello Matthew, All this is great news to hear. Congratulations for all the work that you've done also. I read that an option to transport audio to Asterisk from MGCP gateways would be to use RTP and this is the best solution in my opinion, too. I would just like to add that IMHO there are many more cases where the best way would be to send RTP on a path separate than the signalling path right at the start of the call by disentangling signalling from RTP. That would be a good step towards transforming Asterisk from a PBX to a regular softswitch. So, having only re-invite as the only means to send RTP on a different path than signalling would be rather limiting. Of course, a re-invite would still be a useful option for many applications. Disentangling signalling from media is something that has been discussed in the * mailing lists in the past. I don?t know when this feature is planned for, although I recall that it was planned for * version 1.4. I may be completely wrong, however, because I haven't seen anything towards this direction yet. By the way does anyone have any update on that? Just my 2 cents... :-) Best regards, Vlasis Hatzistavrou. -----Original Message----- From: asterisk-ss7-bounces@xxxxxxxxxxxxxxxx [mailto:asterisk-ss7-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Matthew Fredrickson Sent: Wednesday, September 27, 2006 11:41 PM To: asterisk-ss7@xxxxxxxxxxxxxxxx Subject: Libss7 Status Update Hey all, long time no update. I've had a lot of my time caught up in other projects of late, so I haven't had quite as much time to make major changes, however, here is a short list of things that have changed. First of all, if you haven't been monitoring the threads, with the release of the 1.4 beta branch, I was able to commit all of my asterisk-ss7 branch changes back into trunk. No, this does not mean that it will be in 1.4, but I'll probably be maintaining a 1.4 based branch with the ss7 changes once 1.4 is officially release. For now, if you want to play with libss7 and Asterisk, you will need to check out the trunk version of asterisk (`svn co http://svn.digium.com/svn/asterisk/trunk asterisk-trunk). You still need to have the trunk versions of zaptel (`svn co http://svn.digium.com/svn/zaptel/trunk zaptel-trunk`) or the 1.4 beta release as well as the trunk version of libss7 (`svn co http://svn.digium.com/svn/libss7/trunk libss7`). Feature wise, I just added support for doing remote block requests from the asterisk command line, with the "ss7 block cic <linkset> <cic>" syntax. The first number is the linkset that you want to block the CIC on (from zapata.conf) and the second is the CIC on that linkset you wish to block. There is also a parallel unblock command (ss7 unblock cic <linkset> <cic>). I have been working some more on multilink support, so that's something we'll see in the future. I actually had a conference call with a couple of members of the community about SS7 and future development directions all over an ANSI ss7 link using libss7 and asterisk. It was a quite satisfying experience :-) The primary topics of conversation were regarding making asterisk be able to handle more trunks from one point code. These were the two basic directions for doing that that we thought of: The first was to add support in chan_zap (or a layer below that) for talking to MGCP gateways and being able to control them through that interface. The CICs on them would exist as "virtual" zap channels, and would be controlled as such. The media would just come in as RTP to asterisk, and everything would work very similarly to how things work right now. RTP re-invites could probably be done do take Asterisk out of the media as needed. It would require very little functionality changes within asterisk and the dialplan for that to work. The other direction was to add support for M3UA or a similar protocol to pass ISUP messages on a signalling gateway to other Asterisk boxes that actually terminate the CIC that is relevant to that particular message. This is useful, because then you could use asterisk as a media gateway as well as a signalling gateway, and is very much how asterisk likes to be anyways. On the whole it was fairly productive, as I have thought more about the second path, but the first one I had trouble conceptualizing how it would easily integrate in until we had that call. Now it seems to be a very technically attainable idea. As always, if anyone has any comments or suggestions, peer review is always welcome. Matthew Fredrickson _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-ss7 mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-ss7
|