[asterisk-dev] NFAS Implementation Spanning Multiple Servers

[Paul Cadach]

Hello,

Steven wrote:
[skipped]

> > 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.

This is task of distribution/aggregation application, not for main Asterisk.

Better way IMHO is to make external application which have configuration for distribution of B-channels over boxes, like
(for E1 links with 31 timeslots available per link)
     dchannel = 16
     bchannel = 1-15,17-31:1
     signalling = net:192.168.0.1:1001
     bchannel = 32-62:1
     signalling = net:192.168.0.1:1002
     bchannel = 63-93:1
     signalling = net:192.168.0.1:1003
etc. (where data over "net:" keyword is listening address and port pair for server part while Asterisk have client part;
each Asterisk box connects to the server to specific port, for example, 1st box to port 1001, 2nd box to port 1002 and
so on).

When D-channel (or link) gets down or up, the application "broadcasts" associated event over all neighbours, but when it
get a message for specific channel - it reproduces the message to specific server only and updates (modifies) channel
number (32-62:1 means channels 32-62 in D-channel is mapped to channels 1-31 at associated bearer link).

If transport mechanism is based on libpri (there is possible to replace standard read/write functions with own
implementation by replacing call to pri_new() by call to pri_new_cb()), there is a way to negotiate connection between
libpri's instances (over Q.921 LAPD protocol), so any network problems (disconnects, packet lost, etc.) will be
signalled to libpri immediately as it done for real HDLC channel.

> 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.

Dumb broadcasting is not best way just because you should know about bearer-handling box is ready to receive a message
and it is able to handle one. Also, standard PRI layer 2 protocol (Q.921) is point-to-point so better is to have the
same architecture to simplify implementation of such type of interworking.

> 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.

Taking bearer E1/T1 link down will cause to block making further calls over this link, so it is easy to swap
"bearer-only" box just by disconnecting its link then replace machine with another one.

Taking signalling link down (by physical link failure or by protocol misoperation) should bring backup signalling link
up, so another distribution/aggregation box will act as signalling gateway.


WBR,
Paul.