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 [EMAIL PROTECTED] Voice: +1-760-468-3867 PST Newline Fax: +1-760-731-3000 _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users