NFAS (Non-Facilities Associated Signaling) is an ISDN feature for sharing one ISDN D channel accross multiple ISDN PRI lines.
Example, if you used NFAS to share one D channel accross 10 PRI lines, you would gain 9 extra B channels over a configuration that used one D channel per PRI line.
NFAS also supports a backup D channel if should the first one fail.
NFAS is configured in zapata.conf
Trunk groups are used for NFAS or GR-303 connections.
The spans are registered in asterisk by the zapspan that the primary d channel resides.
Archived example (confusion due to incorrect logicalspan numbering):
spanmap => 1,1,1
spanmap => 2,1,2
spanmap => 3,2,3
spanmap => 4,2,4
In the above sample, trungroup 1 would register as span 1 and trunkgroup 2 would register as span 3.
The bolded statement above is important to understand. Let's assume we're bringing in 4 T1 channels into a 4 port Digium card. You can place the D channel on any of the T1's, but the spanmap will be different based on the one you pick.
For a D-Channel on T1 1, channel 24, you can use the example spanmap. However in our configuration we have the D-channel on T1 4, channel 24 (aka Zap-96). This requires us to change the spanmap to the following (we're starting at logical span 0 since that's what GBLX has listed):
spanmap => 1,1,3
spanmap => 2,1,1
spanmap => 3,2,2
spanmap => 4,2,0
When we had it configured 0,1,2,3 any calls that came into spans 1 or 2 worked fine. But spans 0 and 3 did not pass any audio. Switching the logical span numbers fixed it. This is because zapspan #1 is suppose to be the one that the D-Channel is on. In our case that was actually logical span 3. Be sure to watch out for this, we were confused and took up a few hours of a GBLX tech's time to get it fixed.
ISDN
PRI
Asterisk PRI
Example, if you used NFAS to share one D channel accross 10 PRI lines, you would gain 9 extra B channels over a configuration that used one D channel per PRI line.
NFAS also supports a backup D channel if should the first one fail.
NFAS is configured in zapata.conf
Trunk groups are used for NFAS or GR-303 connections.
Group: Defines a trunk group.
trunkgroup => <trunkgroup>,<dchannel>[,<backup1>...]
trunkgroup is the numerical trunk group to create
dchannel is the zap channel which will have the
d-channel for the trunk.
backup1 is an optional list of backup d-channels.
trunkgroup => 1,24,48
trunkgroup => 2,72,96
Spanmap: Associates a span with a trunk group
spanmap => <zapspan>,<trunkgroup>[,<logicalspan>]
- Note the logicalspan numbering must start at 0 (according to Digium)
zapspan is the zap span number to associate
trunkgroup is the trunkgroup (specified above) for the mapping
logicalspan is the logical span number within the trunk group to use.
if unspecified, no logical span number is used.
spanmap => 1,1,0
spanmap => 2,1,1
spanmap => 3,2,2
spanmap => 4,2,3
The spans are registered in asterisk by the zapspan that the primary d channel resides.
Archived example (confusion due to incorrect logicalspan numbering):
spanmap => 1,1,1
spanmap => 2,1,2
spanmap => 3,2,3
spanmap => 4,2,4
In the above sample, trungroup 1 would register as span 1 and trunkgroup 2 would register as span 3.
The bolded statement above is important to understand. Let's assume we're bringing in 4 T1 channels into a 4 port Digium card. You can place the D channel on any of the T1's, but the spanmap will be different based on the one you pick.
For a D-Channel on T1 1, channel 24, you can use the example spanmap. However in our configuration we have the D-channel on T1 4, channel 24 (aka Zap-96). This requires us to change the spanmap to the following (we're starting at logical span 0 since that's what GBLX has listed):
spanmap => 1,1,3
spanmap => 2,1,1
spanmap => 3,2,2
spanmap => 4,2,0
When we had it configured 0,1,2,3 any calls that came into spans 1 or 2 worked fine. But spans 0 and 3 did not pass any audio. Switching the logical span numbers fixed it. This is because zapspan #1 is suppose to be the one that the D-Channel is on. In our case that was actually logical span 3. Be sure to watch out for this, we were confused and took up a few hours of a GBLX tech's time to get it fixed.
See Also
ISDN
PRI
Asterisk PRI