Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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:

  1. Type wancfg from the command line

  2. On the "Please note:" screen, just hit enter

  3. "Edit" or "Create" as needed

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

  5. Edit:

    1. Enter for "Edit existing Configuration File"

    2. Down/up to choose the wanpipe file to edit & enter

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

pri debug span X

To disable debugging, do

pri no debug span X

 

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:

[trunklocal]
;
; Local seven-digit dialing accessed through trunk interface
;

exten => _9NXXXXXX,1,GotoIf($["${CENTREX}" = "1"]?20);
exten => _9NXXXXXX,2,Set(EXTENSION=${CALLERID(number)});
exten => _9NXXXXXX,3,AGI(fon://localhost:4574);
exten => _9NXXXXXX,4,Dial(Zap/g2/1200${EXTEN:1});

Becomes:

[trunklocal]
;
; Local seven-digit dialing accessed through trunk interface
;

exten => _9NXXXXXX,1,GotoIf($["${CENTREX}" = "1"]?20);
exten => _9NXXXXXX,2,Set(EXTENSION=${CALLERID(number)});
exten => _9NXXXXXX,3,AGI(fon://localhost:4574);
exten => _9NXXXXXX,4,Dial(Zap/G2/1200${EXTEN:1});

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:

 dialparties.agi: Caller ID name is 'unknown' number is '2392678162'

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

 < Protocol Discriminator: Q.931 (8)  len=70
 < Call Ref: len= 2 (reference 3/0x3) (Originator)
 < Message type: SETUP (5)
 < [04 03 90 90 a2]
 < Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: 3.1kHz audio (16)
 <                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
 <                              Ext: 1  User information layer 1: u-Law (34)
 < [18 03 a9 83 83]
 < Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
 <                        ChanSel: Reserved
 <                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
 <                       Ext: 1  Channel: 3 ]
 < [1c 1c 9f 8b 01 00 a1 16 02 01 01 02 01 00 80 0e 42 41 52 54 45 4c 4c 20 54 48 4f 4d 41 53]
 < Facility (len=30, codeset=0) [ 0x9f, 0x8b, 0x01, 0x00, 0xa1, 0x16, 0x02, 0x01, 0x01, 0x02, 0x01, 0x00, 0x80, 0x0e, 'BARTELL', 0x20, 'THOMAS' ]
 < [1e 02 82 83]
 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
 <                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
 < [6c 0c 21 83 32 33 39 34 36 36 32 30 36 31]
 < Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
 <                           Presentation: Presentation allowed of network provided number (3) '2394662061' ]
 < [70 05 a1 37 30 30 30]
 < Called Number (len= 7) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '7000' ]
 -- Making new call for cr 3
 -- Processing Q.931 Call Setup
 -- Processing IE 4 (cs0, Bearer Capability)
 -- Processing IE 24 (cs0, Channel Identification)
 -- Processing IE 28 (cs0, Facility)
 Handle Q.932 ROSE Invoke component
 -- Processing IE 30 (cs0, Progress Indicator)
 -- Processing IE 108 (cs0, Calling Party Number)
 -- Processing IE 112 (cs0, Called Party Number)
 > Protocol Discriminator: Q.931 (8)  len=10
 > Call Ref: len= 2 (reference 3/0x3) (Terminator)
 > Message type: CALL PROCEEDING (2)

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/

 vi /etc/asterisk/extensions.conf

Search for [from-zaptel]

 [from-zaptel]
 exten => _X.,1,Set(DID=${EXTEN})
 exten => _X.,n,Goto(s,1)
 exten => s,1,NoOp(Entering from-zaptel with DID == ${DID})
 ; Some trunks _require_ a RINGING be sent before an Answer.
 exten => s,n,Ringing()

And edit it to look like this:

 [from-zaptel]
 exten => _X.,1,Wait(2)
 exten => _X.,n,Set(DID=${EXTEN})
 exten => _X.,n,Set(CALLERID(name)=${CALLERID(name)})
 exten => _X.,n,Goto(s,1)
 exten => s,1,NoOp(Entering from-zaptel with DID == ${DID})
 ; Some trunks _require_ a RINGING be sent before an Answer.
 exten => s,n,Ringing()

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:

 [from-mypri]
 exten => _.,1,Noop(CALLERID: ${CALLERID(all)})
 exten => _.,n,Wait(1)
 exten => _.,n,Noop(CALLERID: ${CALLERID(all)})
 exten => _.,n,Goto(from-pstn,${EXTEN},1)

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:

span=1,1,0,d4,ami
fxsls=1-24    # can be set to fxsls, e&m, or potentially something else, but not b-chan

  • zapata.conf - an example:

signalling=fxs_ls    # match zaptel as always
context=incoming
busydetect=yes
relaxdtmf=yes
group=2
channel => 1-16

 

  • No labels

Return to Documentation Home I Return to Sangoma Support