02-27-2012 03:23 AM - edited 03-16-2019 09:47 AM
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
02-27-2012 04:10 AM
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
02-27-2012 04:44 AM
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?
02-27-2012 05:18 AM
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
02-27-2012 10:11 PM
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
03-14-2012 05:31 AM
Can somebody please shred some light on this matter?
03-14-2012 05:46 AM
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
03-15-2012 02:33 AM
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
03-16-2012 12:06 AM
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
03-26-2012 12:32 AM
Shameless bump...
Still, any help would be greatly appreciated...
Thanks!
03-26-2012 07:02 AM
Hey,
Can you try upgrading the firmware on the ATA to 3.2.4?
Regards
Kunal
03-29-2012 12:02 AM
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
04-04-2012 02:52 AM
Yet another shameless bump.
Thank you for any input on this matter!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide