[asterisk-dev] NFAS Implementation Spanning Multiple Servers

[Steven]

On Fri, 2006-02-03 at 13:06 +0600, Paul Cadach wrote:
> Hello,
> 
> John Todd wrote:
> [skipped]
> 
> > Just thinking out loud here, but why couldn't this work with some
> > type of modified TDMoE (*) driver setup that handles just the D
> > channels?
> 
> Signalling is not so timing critical in comparsion to speech channels, so it
> could be done without TDM. For example. specific UDP-based protocol (like
> SIGTRAN) could be able to handle D-channel distribution and aggregation over
> server cluster. 

> For implementation issues, there is should be possible to re-associate
> signalling channel from TDM-link with another transport system (network, etc.).
> It would allow to handle such types of signalling distribution/aggregation
> within Asterisk or standalone application, so there could be possible to declare
> "virtual" channels and specify them at zapata.conf configuration file, for
> example:
>       signalling => net:192.168.0.1:1022 # for UDP transport
> or
>       signalling => unix:/var/lib/asterisk/trunk1.sock # for Unix sockets
> or
>       signalling => zaptel:16 # for existing TDM channels
> 

I like that idea. I also think maybe we might want to augment the
channel definitions while we are at it so that we can define the channel
within the chassis and then where it is within the NFAS group. The
reason I think we should define the relation within NFAS for each
channel is so that you don't have to steer the PRI messages but rather
multicast it out to every box in the group. 

Unfortunately, I don't know enough about the messages in PRI to know if
that would work well. I don't know how many messages are non channel
specific that would still need to be handled by the machine that
receives the message. The benefit I see with multicasting or similar
method of broadcasting all the messages to all the machines is that the
machine with the D channel doesn't have to know anything about changes
taking place around it, it just needs to aggregate responses to send
upstream and broadcast incoming messages. 

I'm thinking there could be further fail over support built where you
use one of those T1 fail over switches to swap input from one machine to
another and the hot swap machine already is receiving the D channel
messages to handle the calls. Maybe the same could be done for the lead
machine with the D channel too. 

I'm sure others already know this, but I will say it in case there are
newer people watching this thread. We need to make sure that what we
decide to do with this, it can scale to take up to a T3 or more. I know
in another section of this thread someone was talking about 8 PRIs, but
if we build it right, we should be able to break up a T3 into a bank of
machines all able to handle this.  
-- 
Steven <critch at basesys.com>