[asterisk-dev] NFAS Implementation Spanning Multiple Servers

[Matthew Fredrickson]

On Feb 3, 2006, at 12:25 PM, Paul Cadach wrote:
>>> 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).
>

This is more along what I have been thinking as well.  Messages 
destined for specific bearer channels would be redirected to the box at 
which they are defined.  A similar client side (CPE) could be done on 
the receive side, telling the box which messages map to which local zap 
devices.

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

Ditto.

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

Yeah, if one of the B-channel boxen are down, it would be important 
that the signaling box knew that so that it can "re-negotiate" the 
bearer channel for the call, as opposed to blind multicasting.

Matthew Fredrickson