Faxes missing lines (ATA 186 / CUCM 7.1)

[PhilBieber]

Hi all!

I have an environment of two CUCM7.1 (sub+pub) at my main office and 8 remote locations, all with their own voice gateways. All voice traffic goes through the PSTN. One remote location complained last year about corrupted faxes. After moving the fax machine from a VG224 to an ATA186 the problem seemed to get better, but now every third fax is missing lines.

The local setup:

The voice gateway is a Cisco 3825 connected to the CUCM via MGCP. The ATA 186 has the following software installed: v3.1.0 atasccp (Build 040305B)

I have all in all about 50 ATAs spread over all my remote offices and only this one is making trouble. At this remote office, I have two ATA. We have tried to eliminate all cabling in between. The ATA is connected to a Cisco 2960 switch. According to my Cacti installation, the switchport has encountered no notable errors. The ATA is connected directly to the fax machine (max. 5 meters / 16ft) , no wall cabling involved. I have linked to two paste bin logs below: The Voice Gateway's output for 'debug isdn q931' (call ref 0xDA0A, starting line 2603, calling number 272263880 for 805475). Also, I have linked to a pserv output for the ATA for the same call. It *should* be the last incoming call (starting line 761), but I'm not confident at all, that I'm reading those logs correctly.

I would greatly appreciate any suggestions to resolve this matter.

Log from ATA 186 / pserv: http://pastebin.com/HTMB0pcu

Log from local Voice Gateway: http://pastebin.com/7qHhsnRY

Thank you very much for taking your time to look at all this info. If any more info is needed, I will do my best to provide it.

Cheers

Philipp Bieber

[acampbell]

Hi,

I can not see your links.

Can you pook at your 3825 gateway.

Can you post the show run.

This type of issue is usually related to TDM clocking from your ISDN/PRI lines.

Regards

Alex

[PhilBieber]

Thanks for the quick answer,

I have attached the files directly to this post.

I probably should have mentiones this earlier:

I have additional fax machines at this site using the VG224 with no problems, and this used to work for about a year / year and a half... I had not changed anything on the VG224 or the CUCM or the voice gateway when these problems started to appear. There was a power outage around the first occurene, though.

How can I check for the TDM clock settings?

[acampbell]

Hi,

On your 3825

show controller e1

Look for rising errors at the bottom of the display

  Total Data (last 24 hours)

     0 Line Code Violations, 0 Path Code Violations,

    0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Your TDM config looks OK

network-clock-participate wic 0

network-clock-select 1 E1 0/0/0

So you are taking the ISDN/PSTN clock as using this as the primary clock.

Verify this with :-

3825#sh network-clocks
  Network Clock Configuration
  ---------------------------
  Priority      Clock Source    Clock State     Clock Type

     1          E1 1/0/0        GOOD            E1
    11          Backplane       GOOD            PLL

  Current Primary Clock Source
  ---------------------------
  Priority      Clock Source    Clock State     Clock Type

     1          E1 1/0/0        GOOD            E1

Regards

Alex

[PhilBieber]

Hi Alex,

I did both commands and there are no errors reported:

VGW#show controller e1
E1 0/0/0 is up.
  Applique type is Channelized E1 - balanced
  No alarms detected.
  alarm-trigger is not set
  Version info Firmware: 20090408, FPGA: 13, spm_count = 0
  Framing is CRC4, Line Code is HDB3, Clock Source is Line.
  Data in current interval (20 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
  Total Data (last 24 hours)
     0 Line Code Violations, 0 Path Code Violations,
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
VGW#sh network-clocks
  Network Clock Configuration
  ---------------------------
  Priority      Clock Source    Clock State     Clock Type
     1          E1 0/0/0        GOOD            E1
    11          Backplane       GOOD            PLL
  Current Primary Clock Source
  ---------------------------
  Priority      Clock Source    Clock State     Clock Type
     1          E1 0/0/0        GOOD            E1

I also issued these commands yesterday at around noon (my time / GMT+1) and there was no difference in the output...

Cheers

Philipp

[PhilBieber]

Can somebody please shred some light on this matter?

[Aaron Harrison]

Hi Philipp

ATA 186s only support pass through fax as you are probably aware, and only at low speeds.

Missing lines generally indicates packet loss - have you checked the call stats for any rx loss at either end? YOu can do this through CAR easily if you have it set up.

Aaron

[PhilBieber]

Hi Aaron,

I tried enabling the CAR and also enabled the cluster wide parameter "Call Diagnostics Enabled" yesterday. Also, I added a "Owner User ID" to the offending devices. Today I created a report (System Reports -> QoS -> Detail) for the user, but all calls are listed with "Orig. QoS" and "Dest. QoS" of N\A... All the other information should be fine, here is a screebnshot from the report...

Do I have to do any other configuration to enable the QoS information?

Currently, we do no priorization of traffic in our LAN (our contractor said it was not necessary..)

Also, I looked at the switchport, and there are no errors reported, just some collisions, but that is expected, as the ATA 186 is just half-duplex:

FastEthernet0/24 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 6416.8d95.3698 (bia 6416.8d95.3698)
  Description: ATA Fax Zentrale 9475 / 9477
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Half-duplex, 10Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:29, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 42000 bits/sec, 22 packets/sec
  5 minute output rate 44000 bits/sec, 27 packets/sec
     54113377 packets input, 11498444779 bytes, 0 no buffer
     Received 154425 broadcasts (122277 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 122277 multicast, 0 pause input
     0 input packets with dribble condition detected
     80448677 packets output, 13986706513 bytes, 0 underruns
     0 output errors, 36303 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

I also have a Cacti server running that is reporting errors accumulated on the switch. It doesn't report any errors for the past ~3,5 weeks...

The fax machine is configured for 9600kbit/s and ECM is disabled.

Maybe this is related to a problem we had, before I installed the ATA:

In September last year, the fax machines were connected to VG224, but after a power outage (at least that was the point when the users started to complain), some (not all) customers were unable to send any faxes at all. Those customers that had problems were unable to send any faxes, other customers had no problems at all. Back then we had our PSTN checked by our provider (I had them check again, yesterday), the fax machine was exchanged, we chenged the cabeling, I restarted the VG224,... Then we switched to the ATA186 and the problem was solved. A week later, the users started to report missing lines in most faxes...

I don't know what else to do... I would apreciate any help. If you need any more info, just tell me and I will try to get back to you ASAP.

Cheers

Phil

[PhilBieber]

So, it seems I just had a bad case of not waiting long enough. I just created another QoS Detail Report from CAR and now the "Orig. QoS" field is filled. On every line, since yesterday 8.50 a.m. it says "Good"...

So this should confirm my Cacti findings, shouldn't it?

Cheers

Phil

[PhilBieber]

Shameless bump...

Still, any help would be greatly appreciated...

Thanks!

[kusatija]

Hey,

Can you try upgrading the firmware on the ATA to 3.2.4?

Regards

Kunal

[PhilBieber]

Hi Kunal,

thanks for your suggestion, but unfortunately the upgrade didn't help...

Cheers

Phil

Edit:

Clicking around in the 'new' web interface, I found this:

Should the dropped packet count concern me, or is this within boundaries of normal behavior?

Cheers again

Phil

Nachricht geändert durch Philipp Bieber

[PhilBieber]

Yet another shameless bump.

Thank you for any input on this matter!