[asterisk-ss7] Libss7 Status Update

[Vlasis Hatzistavrou]

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 at lists.digium.com [mailto:asterisk-ss7-bounces at lists.digium.com] On Behalf Of Matthew Fredrickson
Sent: Wednesday, September 27, 2006 11:41 PM
To: asterisk-ss7 at lists.digium.com
Subject: [asterisk-ss7] 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