T1/PRI

1 Zaptel.conf
2 Zapata.conf
3 Wanpipe Drivers
- 3.1 wanpipe1.conf
4 Misc PRI Info
- 4.1 Reading PRI Debug Output
- 4.2 Auto-Response
- 4.3 Dial in reverse order
5 PRI not receiving CID Info
6 D4/AMI Configuration

This general configuration information shows the zaptel.conf, zapata.conf, and wanpipe1.conf files for a A101 Sangoma card. This is attached to a T1/PRI line:

Digium cards run on the zaptel drivers and only require setup of zaptel.conf and zapata.conf.

Zaptel.conf

trixbox Pro: Configure this file ONLY with the web interface (unless it does not support cards.)

loadzone=us
defaultzone=us

span=1,1,0,esf,b8zs
bchan=1-23
hardhdlc=24

Zapata.conf

trixbox Pro: Configure this file ONLY with the web interface (unless it does not support cards.)

[channels]
context=incoming
switchtype=national
signalling=fxs_ks
rxwink=300              ; Atlas seems to use long (250ms) winks
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=1
echocancelwhenbridged=yes
echotraining=0
rxgain=0
txgain=0
group=1
callgroup=1
pickupgroup=1
immediate=no


switchtype=national
pridialplan=unknown
signalling=pri_cpe
context=incoming
group=2
channel => 1-23

NOTE: If the card has HWEC (Hardware Echo Cancellation) echocancel must be enabled in zapata for it to work. In other words, echocancel should be turned on in almost all cases, regardless of whether the card is hardware or software EC. The drivers decide what type of echo cancellation to apply. [reference]

Wanpipe Drivers

wanpipe1.conf

Configure this file ONLY with the wancfg utility or the web interface (comments from file left out.)

Steps on how to do this:

Type wancfg from the command line
On the "Please note:" screen, just hit enter
"Edit" or "Create" as needed
Create:
1. Down for "Create a new Configuration File" & enter
2. Enter to create a new wanpipe1 or down to make a new wanpipeX.conf
3. Enter to "Select from detected cards list"
4. Down/Up to choose the card/interface and press enter
Edit:
1. Enter for "Edit existing Configuration File"
2. Down/up to choose the wanpipe file to edit & enter
... to be completed...

[devices]
wanpipe1 = WAN_AFT_TE1, Comment

[interfaces]
w1g1 = wanpipe1, , TDM_VOICE, Comment

[wanpipe1]
CARD_TYPE       = AFT
S514CPU         = A
CommPort        = PRI
AUTO_PCISLOT    = NO
PCISLOT         = 4
PCIBUS          = 20
FE_MEDIA        = T1
FE_LCODE        = B8ZS
FE_FRAME        = ESF
FE_LINE         = 1
TE_CLOCK        = NORMAL
TE_REF_CLOCK    = 0
TE_HIGHIMPEDANCE        = NO
LBO             = 0DB
FE_TXTRISTATE   = NO
MTU             = 1500
UDPPORT         = 9000
TTL             = 255
IGNORE_FRONT_END = NO
TDMV_SPAN       = 1
TDMV_DCHAN      = 24

[w1g1]
ACTIVE_CH       = ALL
TDMV_ECHO_OFF   = NO
TDMV_HWEC       = YES

Misc PRI Info

Reading PRI Debug Output

You can enable PRI debugging with the asterisk CLI command

To disable debugging, do

When you enable pri debug within the FONcore console, every line of output of debug info will be marked with either a < sign or a > sign. These symbols are very important:

> information transmitted on the PRI FROM FONcore.

< information transmitted on the PRI FROM the Provider.

Making a mental note of which way the arrow faces helps us quickly determine which side of the PRI 'conversation' is talking.

A frequent problem that arises on PRI circuits is that FONcore tries to initiate a connection to the Provider, but FONcore does not receive any reply.

Within the pri debug output, you will see a SABME bit transmitted (Set Asynchronous Balanced Mode Extended).

The SABME bit is the PRI card's way of saying, "Hello, I'm here. Connect to me."

FONcore waits for the ACK bit to the SABME (Acknowledge). If the ACK bit doesn't come - FONcore retransmits the SABME bit. Infinitely...

After the ACK to the initial SABME, FONcore transmits an RR (Receiver Ready) bit to the Provider. The provider (should) reply with an RR bit of it's own. At this point, both sides of the PRI 'conversation' are ready to commence transmission. The PRI "comes up" and you will see Provisioned, Up, Active when you run pri show span 1 from the FONcore console.

Auto-Response

Send the follow to customers who will be using T1/PRI service:

The following information is needed to configure T1/PRI. You must give Fonality Support this information in order to avoid missing your turn up appointment with your provider.

The information provided below are the common settings:

Provider:
PBXtra Server ID:
Framing: ESF
Encoding: B8ZS
Signaling: ISDN PRI
Switch Type: NI2 “National” ISDN
DNIS Digits: 10 (Use 4 if 10 not available)

You can get the information above from your provider. Please forward this information to us as soon as you have it. Fonality Support can configure the PBXtra in advance of your turn up date.

It is not a requirement of Fonality that a Support Engineer participate in the turn up. However, some providers do require a "PBX technician" to be available. If that is the case, you must request a T1/PRI Turn Up Appointment.

Dial in reverse order

If you would like Asterisk to dial OUT on a PRI in reverse order (i.e. 23, 22, 21, etc.), you can make this happen by changing the 'g' in trunk<blah>.conf to 'G'.

So:

Becomes:

Other valid options are:

g: select the lowest-numbered non-busy Zap channel (aka. ascending sequential hunt group).
G: select the highest-numbered non-busy Zap channel (aka. descending sequential hunt group).
r: use a round-robin search, starting at the next highest channel than last time (aka. ascending rotary hunt group).
R: use a round-robin search, starting at the next lowest channel than last time (aka. descending rotary hunt group).

PRI not receiving CID Info

If a customer complains of not receiving CID name when they know CID name is passed, check the logs for a specific CID number that did not pass a name. You may see something like this:

There are times where you can do a PRI debug and see the CID information being passed through

The bold section above shows where CID name information is present.

One thing that works is this instant is editing the extension.conf in /etc/asterisk/

Search for [from-zaptel]

And edit it to look like this:

This adds enough of a delay for the PRI that Asterisk can pick up the CID name information being passed.

Note: Stay on the phone with the customer and ensure that they are not having any problems receiving calls. Test at least 5 calls with them.
An alternative solution:
In /etc/asterisk/zapata.conf

Find line context=from-zaptel
Change to context=from-mypri

In extensions_custom.conf add:

D4/AMI Configuration

Most T1 lines are set to use ESF/B8ZS as the framing & encoding type, but once in a while you will stumble across a server that is set to use D4/AMI. Several things need to be adjusted in order to agree with this:

wancfg settings - while editing wanpipeX.conf
- Enter the "Hardware Setup"
- Choose "Advanced Physical Medium Configuration"
- Change "Line Decoding" to AMI
- Change "Framing" to D4
- Go back twice
- Choose the "Interface Setup"
- Choose the only interface available
- Make sure that "TDM PRI HW-HDLC TIMESLOT" is set to "0 Not Used"
- Back all the way out and save changes
zaptel.conf - an example:

zapata.conf - an example: