NFAS
Created by: jht2,Last modification on Fri 13 of Jan, 2006 [17:24 UTC] by abrezinsky
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.
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>
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,1
spanmap => 2,1,2
spanmap => 3,2,3
spanmap => 4,2,4
The spans are registered in asterisk by the zapspan that the primary d channel resides.
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>
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>
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,1
spanmap => 2,1,2
spanmap => 3,2,3
spanmap => 4,2,4
The spans are registered in asterisk by the zapspan that the primary d channel resides.
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
Comments
333one way or no audio wth NFAS
We were told (by Qwest) that the primary D channel was the 24th channel on the first T1 and the secondary D channel was on the 24th channel on the second T1. This turned out to be false. We even had the tech drop carrier on each T1 (one at a time) so we could identify which T1 was plugged into which port on the card.
The "winning" strategy was to configure all 4 T1's as if they had a D channel and let Asterisk tell me which T1's actually had a "provisioned and up" D channel using the "pri show span x" command. The one that showed as "active" I made primary and "standby" as backup.
Once I knew which physical channels were actually D's, setting up the trunkgroup was easy.
When I placed a call, I got audio. I nearly fell off my chair. Then the next call was dead air. The first call landed on the last channel of a T1 and the next call was the first channel of the next T1.
I tried to "logically" figure out which zapspan was which logicalspan, but in the end I cracked open a beer, made a table of the 26 permutations and stepped through them one by one. On my 13th try, I got an "order" that gave audio on all 96 channels.
The morals of the story:
) Don't believe the tech if it conflicts with reality.
) Don't accept an NFAS trunk group until you have tested each and every channel.
) Brute force and beer can solve anything :)
333
/etc/zaptel.conf
span=1,1,0,esf,b8zs
span=2,2,0,esf,b8zs
bchan=1-23,25-48
dchan=24
loadzone = us
defaultzone = us
/etc/asterisk/zapata.conf
trunkgroups
trunkgroup=>1,24
spanmap => 1,1,0
spanmap => 2,1,2
channels
language=en
context=from-pstn
group=1
signalling=pri_cpe
switchtype=5ess
callerid=asreceived under
rxwink=300
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=400
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
channel => 1-23,25-48
333NFAS PRI ISDN Configuration
Our setup is TE405P installed on a Debian(2.4Kernel), with the Latest Asterisk, Zaptel, libpri CVS.
Goal, configure ISDN group with one D-Channel and 95 B-Channels.
/etc/zaptel.conf
span=1,0,0,esf,b8zs
span=2,0,0,esf,b8zs
span=3,0,0,esf,b8zs
span=4,0,0,esf,b8zs
bchan=1-23,25-96
dchan=24
loadzone = us
defaultzone=us
/etc/asterisk/zapata.conf
trunkgroups
trunkgroup => 1,24
spanmap => 1,1,1
spanmap => 2,1,2
spanmap => 3,1,3
spanmap => 4,1,3
channels
context=default
switchtype=national
; needed for our ATT side, your results may very
nsf=none
signalling=pri_cpe
group=1
channel => 1-23,25-48
This successfully worked without a hitch with good support on our end. Most of the issues I encountered were on the FE.
Also, for testing I suggest writing a script to load/unload the modules, as rebooting is not a requirement.
Basically a script to 'modprobe ' and to stop 'rmmod .
Script I wrote.
- !/bin/bash
Option="$1"case $Option in
start ) lsmod | grep wct4xxp > /dev/null; status=$?
if
then printf "\nalready running...\n"
else printf "\nStarting..."
modprobe wct4xxp
sleep 2
printf "\t\t\t
fi
;;
stop ) lsmod | grep wct4xxp > /dev/null; status=$?
if
then printf "\nStopping..."
rmmod wct4xxp
sleep 2
printf "\t\t\t
else printf "\nNot running... \n\n"
exit 1
fi
;;
status ) lsmod | grep wct4xxp > /dev/null; status=$?
if
then printf "Module Loaded...\n"
lsmod | grep wct4xxp
else printf "\nModule NOT Loaded...\n\n"
fi
;;
- ) printf "\nUsage wildcard start\n" ;;
esacFinal Notes:
/var/log/messages (/var/log/kern.log debian) Look at them!
ztcfg -vv nice
zttool IS YOUR FRIEND!
peaCe
rob owens
333NFAS
The oposite is called CAS (Channel Associated SIgnalling)