[asterisk-dev] NFAS Implementation Spanning Multiple Servers

[John Todd]

>On Feb 2, 2006, at 5:04 PM, Steve Totaro wrote:
>>Recently I asked a question on the list about NFAS being able to span
>>across multiple servers.  Kevin F said that this was something in the
>>works and should show up very soon.
>>
>
>I think that maybe something he said that's out of context.  This 
>topic has come up in discussion, and I've thought a lot about how to 
>implement it, but I have no immediate plans to write such a 
>solution.  It would take a significant amount of time (which equal 
>money by the way :-) ), testing, and especially planning for such a 
>thing to come into existence.
>
>>I have a real need for this.  I have a T3 going into an Adtran MX2800
>>and then into seven asterisk boxes with quad T1 cards.  The way things
>>are now, I need seven D channels to go PRI.
>>
>>Problem:  Our carrier charges $100/mo per D channel.
>
>That's understandable.  That's how they pay for their hardware too :-)
>
>>
>>Solutions:
>>1.  Lose PRI alltogether and get straight T3
>>2.  Pay the money (there has to be a better way $8,000 is too much)
>>3.  Buy a high end Adtran that can break the T3 D channel into one D
>>channel per T1 port which would pay itself off in about three years if
>>my estimates are correct.
>>4.  Get Kevin motivated enough (or anybody else for that matter) to get
>>NFAS to be able to span multiple servers.  This could be in exchange for
>>a $$$ bounty, case study, testimonial or whatever.
>>
>
>There are a lot of technical issues that need to be addressed for 
>something of this nature to work.  If we were just talking about 
>terminating incoming calls from the PRI on the boxes, I can see a 
>very clear way to do this.  However, remotely registered phones and 
>having incoming and outgoing calls to successfully make it through 
>this "cloud" is going to be more challenging (adds a lot more to 
>what you have to be able to support in this solution).  There would 
>probably be some sort of control box that would terminate the 
>D-channel, then we'd have groups of bearer channel termination 
>boxes.  There would have to be a protocol for telling the b-channel 
>box what b-channel to expect a call on, or make a call on, and also 
>to accept an RTP stream from an endpoint (whilst keeping the 
>signaling running through the d-channel box).
>
>As you can see, this is going to be a LOT of work :-)  although I do 
>see it as a necessary feature in the future.
>
>>We will be willing to GPL our source in exchange for the NFAS feature as
>>a barter, pay for it, or whatever.  Make some suggestions please people.
>>Maybe I am missing somehting.
>>
>
>It's going to be expensive :-)
>
>---
>Matthew Fredrickson

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?  The system with the "primary" D channel would then be told 
which machines had which "trunk groups", and then messages for each 
of those systems would be split off using a single DS0 TDMoE 
connection to each of the respective platforms.  While I am not able 
to say that this is an "easy" solution, it certainly seems like it 
could re-use quite a few of the existing components, protocols, and 
configuration methodologies that Asterisk currently utilizes. 
Basically: add the ability for the D channel for an NFAS group to 
come in via TDMoE.  Add the ability to split out D channels for 
certain sets of trunks onto a TDMoE channel.  Just like I can take a 
single PRI into an Asterisk server and then transfer/divvy calls out 
to another set of PRIs, so too could (with some patches) the system 
just send the messages to the appropriate trunk slave box as long as 
the master system has a mapping of PRI-trunk-to-chassis relationships.

I think requiring local LAN domain connectivity of a cluster of NFAS 
boxes is reasonable, so TDMoE is a contender.

I don't know where the concept of "remotely registering phones" would 
factor into this, or "RTP" for that matter.  If you are using the 
TDM/IP boxes as SIP registrars and mixing things up, I think that is 
a separate problem that need not be addressed at all by the NFAS 
portion of the code.  That's a problem that can be solved with IAX 
trunking and DUNDi, or "switch" statements, or a centralized SIP/IAX 
system used in conjunction with a set of TDM/IP converters, or any 
number of other mechanisms to have calls find the systems to land on.

(*) I hear unconfirmed, half-baked reports that TDMoE is now 
"broken".  Anyone have details?

JT