[asterisk-users] Asterisk dropping around 2% of ALL calls ever since we moved to EM_W signalling?

[Sherwood McGowan]

Matt Florell wrote:
> Hello,
>
> I have quite a bit of experience with E&M Wink T1s, and I have seen
> the problem you describe twice. In both cases it was either the
> carrier's equipment or the wiring somewhere between the carrier shelf
> and your equipment.
>
> In one case it was water in the line that would seem to cause the
> problem after it rained, and the other case was bad carrier equipment
> at their shelf, once they moved it to another port on another shelf
> the problem disappeared.
>
> Good luck,
>
> MATT---
>
>
> On 5/15/08, Sherwood McGowan <sherwood.mcgowan at gmail.com> wrote:
>   
>> Alright guys and gals,
>>  I'm a little lost, I'm primarily a SIP/IAX based guy, and have ended up
>>  with a Zap installation. Everything was fine with our old provider when
>>  we were using PRI, but the new provider screwed up on provisioning and
>>  we've been temporarily stuck with a pair of EM Wink T's. Ever since
>>  then, we've been dropping 1-2% of all calls (in or out) and even more
>>  strange, when a call gets dropped, a phantom call was being generated on
>>  the incoming side, but only by Asterisk, the T providers (Qwest) say
>>  they have no records of those calls.
>>
>>  So, my question to you is, has anyone else dealt with a EM Wink T before
>>  using Asterisk, if so did you experience problems similar to this, and
>>  finally, if so how did you deal with it?
>>
>>  Here's an outline of our system specs:
>>
>>  Dual 2.3Ghz Athlon
>>  2GB RAM
>>  Asterisk 1.4.16 (Tried 1.4.19 as well)
>>  Zaptel 1.4.10
>>
>>  51 Zap phones connected via SEPARATE TE407 and channel bank
>>  2 EM_W T1's connected via TE407
>>  25 SIP Phones
>>
>>  All calls are being recorded by the Monitor() application, there is no
>>  timeout on the dial command, I can find NOTHING in the system config
>>  that would instruct Asterisk to dump the call.
>>  I have spoken with the Qwest technicians who have pulled their call
>>  records, and they report that we "disconnected the call"....
>>
>>  Any ideas, thoughts? I've reviewed the verbose (full setting, writing to
>>  file) and see that the far end channel disconnects, and then the near
>>  end goes into TIMEOUT. I've watched full debug output as well, from
>>  file, cannot find ANYTHING...
>>
>>  Thanks for any help,
>>  Sherwood McGowan
>>
>>  _______________________________________________
>>  -- 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
>>
>>     
>
> _______________________________________________
> -- 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
>   
I'll check that out, as far as I know I'm not, although our Rhino 
channel bank uses loop timing. Another thing I'm worried about is my 
zttest results have been dipping VERY low, sometimes down to 95% (worst 
hit, not avg)....but this server should be able to handle this 
EASILY....we didn't have the accuracy problems when on PRI, and nothing 
has changed other than that. Quick note, I've checked and we're not 
missing interrupts, and I've gone CRAZY with checking all our Zap 
settings with Digium and with Qwest, to no avail.

I'll check the wiring here in the office tonight to make sure the guy I 
inherited this from didn't make a mistake somewhere, and act on anything 
else you guys might have.

Thanks so far, you're all helping me at least think of new things to 
check out. I've barely worked with Zap, and mostly only on the local 
side with channel banks.

Sherwood McGowan