Received feedback from GFI

Jim Mueller · ‎12-06-2016

I'm looking for some assistance in diagnosing a problem I've inherited.We have a Cisco 2821 running an old version of CME which is passing 4 channels to a Brooktrout TR1034+E4V4FH-T1-1N installed in a Windows server for use with GFI Faxmaker 2015. Faxes sent from outside of the building are delivered correctly to the internal recipients. Faxes sent directly by the GFI lines generate either a 'busy signal' error or a 'remote device did not answer' error depending upon which options I've toggled within GFI.

Here is a partial network diagram. This is all in one closet and the T1 cable between interface Ctrlr1/1 and the Brooktrout T1 port is around 20-30' long.

Below is how I have the TR1034 configured:

GFI is asking about the incrementing Framing Loss Seconds errors showing up on the service-module, but there are not any showing up on the T1 controllers:

---begin---

WP-CME#sh service-module
Interface Serial0/1/0
Module type is T1/fractional
    Hardware revision is 1.2, Software revision is 20110823,
    Image checksum is 0x434803, Protocol revision is 0.1
Transmitter is sending remote alarm.
Receiver has loss of signal, loss of frame,
Framing is ESF, Line Code is B8ZS, Current clock source is line,
Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec.
Last module self-test (done at startup): Passed
Last clearing of alarm counters 00:28:36
    loss of signal        :    1, current duration 00:28:36
    loss of frame         :    1, current duration 00:28:36
    AIS alarm             :    0,
    Remote alarm          :    0,
    Module access errors :    0,
Total Data (last 1 15 minute intervals):
    0 Line Code Violations, 0 Path Code Violations
    0 Slip Secs, 900 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
    0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 900 Unavail Secs
Data in current interval (814 seconds elapsed):
    0 Line Code Violations, 0 Path Code Violations
    0 Slip Secs, 814 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
    0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 814 Unavail Secs

WP-CME#show controller T1
T1 0/0/0 is up.
Applique type is Channelized T1
Cablelength is long gain36 0db
No alarms detected.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Version info Firmware: 20090113, FPGA: 20, spm_count = 0
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (823 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 1 15 minute intervals):
     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
T1 0/0/1 is up.
Applique type is Channelized T1
Cablelength is short 133
No alarms detected.
alarm-trigger is not set
Soaking time: 3, Clearance time: 10
AIS State:Clear LOS State:Clear LOF State:Clear
Version info Firmware: 20090113, FPGA: 20, spm_count = 0
Framing is ESF, Line Code is B8ZS, Clock Source is Internal.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (823 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 1 15 minute intervals):
     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
WP-CME#

---end---

Interfaces:

---begin---

Serial0/0/1:23 is up, line protocol is up (spoofing)
Hardware is DSX1
MTU 1500 bytes, BW 64 Kbit/sec, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Last input 00:00:07, output never, output hang never
Last clearing of "show interface" counters 00:31:39
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations 0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 48 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
     228 packets input, 1104 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     228 packets output, 1472 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
Timeslot(s) Used:24, SCC: 1, Transmitter delay is 0 flags

Service-Engine1/0 is up, line protocol is up
Hardware is I82559FE, address is 0018.1913.8240 (bia 0018.1913.8240)
Interface is unnumbered. Using address of GigabitEthernet0/0 (172.16.3.4)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:19, output 00:00:04, output hang never
Last clearing of "show interface" counters 00:31:39
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 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
     9825 packets input, 2116219 bytes, 0 no buffer
     Received 2 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     12360 packets output, 2647970 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

---end---

Config:

---begin---

!
controller T1 0/0/0
pri-group timeslots 1-24
!
controller T1 0/0/1
clock source internal
cablelength short 133
pri-group timeslots 1-4,24
!

!
interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
isdn map address [2-9]......... plan isdn type national
no cdp enable
!
interface Serial0/0/1:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn protocol-emulate network
isdn incoming-voice voice
no cdp enable
!
interface Serial0/1/0
no ip address
shutdown
!
interface Service-Engine1/0
ip unnumbered GigabitEthernet0/0
service-module ip address 172.16.3.5 255.255.255.0
service-module ip default-gateway 172.16.3.1
!

---end---

Do we have anything misconfigured? Are there any other diagnostics I need to provide (If yes, please provide specific commands)?

Thank you!

Jim

Jim Mueller · ‎12-07-2016

Received feedback from GFI support:

--------------------------------------------------------------

Jim, as I thought they are pointing to the telco provider too:

----------------------------------------------------------------------------------------------------

We are still getting a hang up from telco. Could be something about the setup of the call telco dosent like about the setup of the call. The customer should have telco debug the call as they get it. Also, please make sure to add a 1 if needed.

-----------------------------------------------------------------------------------------------------

I would reach out to them to verify the lines and have them monitor a few calls. We tried with and without "1" country code so that's not it.

--------------------------------------------------------------

Georg Pauwen · ‎12-07-2016

Jim,

"Faxes sent from outside of the building are delivered correctly to the internal recipients. Faxes sent directly by the GFI lines generate either a 'busy signal' error or a 'remote device did not answer' error depending upon which options I've toggled within GFI"

Which interface on the 2821 are the GFI lines using ?

Jim Mueller · ‎12-07-2016

The GFI software integrates with the Dialogic Brooktrout TR1034, and the TR1034 connects to the physical port labeled Ctrlr1/1 on the front panel, which I presume is the same as interface Controller T1 0/0/1 and Serial 0/0/1:23.

Georg Pauwen · ‎12-07-2016

The reason I am asking is that your Serial 0/1/0 is shut, so I am not sure if the errors you are seeing have anything to do with your fax problem...

WP-CME#sh service-module
Interface Serial0/1/0
Module type is T1/fractional
Hardware revision is 1.2, Software revision is 20110823,
Image checksum is 0x434803, Protocol revision is 0.1
Transmitter is sending remote alarm.
Receiver has loss of signal, loss of frame,
Framing is ESF, Line Code is B8ZS, Current clock source is line,
Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec.

Jim Mueller · ‎12-07-2016

"Faxes sent from outside of the building are delivered correctly to the internal recipients."

There is only one cable between the TR1034 and the 2821. If Serial 0/1/0 being shutdown was an issue, wouldn't that prevent receipt of the faxes?

Georg Pauwen · ‎12-07-2016

Hello, I might be missing or misunderstanding something in your physical setup:

interface Serial0/1/0
no ip address
shutdown

Either way, the loss of frame/loss of signal could be caused by either the clock, the line coding,or the framing. You might want to try and use 'clock internal', and ami line coding together with sf framing to see if that clears the remote alarm.

Jim Mueller · ‎12-08-2016

The LEC has come back with this for now, still investigating. Does this mean we need to make a change in the 2821 config? Or are they referring to the LEC's equipment?

---

Hello, it appears the outbound faxes are failing because there is incomplete FROM information in the SIP INVITE message. Your PBX is not providing the DID number in the FROM URI field. This will need to be addressed by your PBX vendor. We have attached a PCAP file to this ticket provide to your vendor so they can further investigate.

---

Georg Pauwen · ‎12-08-2016

Hello Jim,

if this is what the LEC comes back with, don't change anything on the link configuration. Good work form the LEC by the way to provide a PCAP file to help the vendor investigating this...

Jim Mueller · ‎12-09-2016

Here is what 'debug ccisp all' is showing us on the 2821 when I attempt to dial an outbound fax. Faxmaker reports an error and cannot connect to the remote fax machine. Both the LEC and GFI say the change to advertise this out pulse ANI aka caller ID number must occur in the 'PBX', which at this point must be our Cisco 2821 router.

Is there a way to define a 'caller ID' number in the Cisco config so that any outbound calls originating on that fax T1 show a callerID number? We don't want to change the behavior of the ephones defined in CME, though.

---

Dec 9 10:48:45 EST: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId C4F018DCBD5D11E696C4001819138230, SetupTime 10:48:31.541 EST Fri Dec 9 2016, PeerAddress 94076915995, PeerSubAddress , DisconnectCause 12 , DisconnectText no user response (18), ConnectTime 10:48:45.941 EST Fri Dec 9 2016, DisconnectTime 10:48:45.941 EST Fri Dec 9 2016, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 687, TransmitBytes 109203, ReceivePackets 174, ReceiveBytes 28276

Dec 9 10:48:45 EST: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:12/09/2016 10:48:31.517,cgn:,cdn:94076915995,frs:0,fid:46974,fcid:C4F018DCBD5D11E696C4001819138230,legID:80FE,bguid:C4F018DCBD5D11E696C4001819138230

Dec 9 10:48:45 EST: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId C4F018DCBD5D11E696C4001819138230, SetupTime 10:48:31.503 EST Fri Dec 9 2016, PeerAddress , PeerSubAddress , DisconnectCause 12 , DisconnectText no user response (18), ConnectTime 10:48:45.973 EST Fri Dec 9 2016, DisconnectTime 10:48:45.973 EST Fri Dec 9 2016, CallOrigin 2, ChargedUnits 0, InfoType 2, TransmitPackets 174, TransmitBytes 26884, ReceivePackets 687, ReceiveBytes 114699

Dec 9 10:48:45 EST: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:12/09/2016 10:48:31.509,cgn:,cdn:94076915995,frs:0,fid:46973,fcid:C4F018DCBD5D11E696C4001819138230,legID:80FD,bguid:C4F018DCBD5D11E696C4001819138230

---

Jim Mueller · ‎12-08-2016

The LEC is stating that the fax numbers are not going out because it is missing the 'From' number in the packet. The only thing they can do is set a 'master from' number in the Adtran gateway... but that would affect every number which goes through the Adtran and we need the voice numbers to advertise their individual extensions. I'm checking with GFI to see whether they have the ability to do that through software or through the T1 card, but if not then how can we make this happen in the 2821 config?

The LEC also advised that the PRI on the LEC side is set to switch type National ISDN 2. The config references only switch-types of "primary-ni".

Jim Mueller · ‎12-13-2016

I found a Dialogic support document (login required) which allows you to set a default caller ID. So I did that and now I can use the Faxmaker software to send test faxes across the individual 4 lines and most of the time the faxes are received. Once in awhile I receive a failed handshake error.

So I'm still not absolutely confident on the T1 ISDN settings are as compatible as they could be. Any concerns with the following?

[Brooktrout] - [Cisco config]

Switch Type: [AT&T #4 ESS] - [Serial 0/0/1:23 Primary-ni]

Protocol Variant: [AT&T PUB 41449] - [not found]

Emulation: [CPE] - [not found]

Line coding: [B8ZS] - [T1 0/0/1 ESF B8ZS]

Line Build Out: [0-133ft] - [T1 0/0/1 cablelength short 133]

Network Specific Facility: [No message is sent] - [not found]

Should I leave Ctrlr T1 0/0/1 as using the internal clock source?

Georg Pauwen · ‎12-13-2016

Hello,

don't change the line coding, clock source, or switch type. If these were incorrect, your entire T1 would not work, which is not the case...

Jim Mueller · ‎12-19-2016

Receiving a lot of handshaking errors; GFI support has temporarily turned off v34 for further testing. Their comments below; not sure how to 'test' the lines in our environment.

---

In the current situation, It appears there are errors in the logs that indicate line quality issues. The errors FTT (failure to train) and PPR (partial page request) are occuring pretty regularly in the logs that were submitted. These errors basically mean when information was being transmitted it was not all received and they can cause the faxes to fail as as well. This is why the V34 settings are initially disabled since the line issues can decrease when the speed decreases. If we find we can eliminate the handshaking errors we can attempt to increase the speed once more.

I would recommend having the lines checked, as those errors are normally indicative of an issue with the lines.

---

Georg Pauwen · ‎12-19-2016

Jim,

with 'lines' they probably mean the physical cabling to and from the Windows server Is this something under your control ?

T1 Framing Loss troubleshooting