[asterisk-users] No audio on Zap (T1/PRI) channels

[Steve Edwards]

On Thu, 4 Oct 2007, Matthew Fredrickson wrote:

> Steve Totaro wrote:
>> Steve Edwards wrote:
>>> I have 12 T1's going into 3 servers, 4 in each into "Digium, Inc. Wildcard
>>> TE410P Quad-Span togglable E1/T1/J1 card 3.3v (rev 02)" cards.
>>>
>>> Each "group" of T1's have the primary D on 24 and the secondary D on 96.
>>>
>>> The first server (ts20) and the last server (ts22) can playback
>>> "demo-congrats" fine. The "middle" server (ts21) cannot -- just dead air.
>>>
>>> If I call via ZAP, dead air. If I call via IAX, I hear the file.
>>>
>>> I copied /etc/zaptel.conf, /etc/asterisk/*,
>>> /var/lib/asterisk/sounds/demo-congrats.gsm from ts20 to ts21 -- no joy.
>>>
>>> I have seen this in my system log file:
>>>
>>> Oct 2 18:41:49 WARNING[7477]: chan_zap.c:8087 zt_pri_error: [Span 0
>>> D-Channel 0] PRI: !! Got reject for frame 95, but we have nothing --
>>> resetting!
>>>
>>> I'm running asterisk-1.2.24, asterisk-addons-1.2.7, libpri-1.2.5,
>>> zaptel-1.2.20.1.
>>>
>>> "show channel zap/?," "zap show channel ?" appear identical between
>>> working and non-working systems both "on-hook" and "off-hook."
>>>
>>> Any clues or clues where to start looking?
>>
>> Double check both zaptel.conf and zapata.conf and also call the telco to
>> make sure they have they have the same NFAS scheme on all T1s setup
>> correctly.  Sometimes (let's face it, alot of times, the provider messes
>> something up).
>>
>> Also check that all of your T1 cables are plugged into the correct T1
>> port.  I have made that mistake myself when doing 28 T1s off a T3.  I
>> got dead air just as you described.
>
> Yes, if you are running NFAS, getting dead air on a call is a symptom of
> not having the logical span identifier correctly corresponding to the
> physical span you have plugged in (spanmap option in zapata.conf, IIRC).

Success (finally). The spanmap that worked (of no value to anyone else) 
is:

         trunkgroup                      = 1,96,24
         spanmap                         = 1,1,1
         spanmap                         = 2,1,3
         spanmap                         = 3,1,2
         spanmap                         = 4,1,0

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.

Thanks in advance,
------------------------------------------------------------------------
Steve Edwards      sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline                                             Fax: +1-760-731-3000