Fax over IP Intermittently Not Working Since Conversion to SIP

[Michael Mertens]

I recently found out that since the conversion of a site from T-1 CAS PSTN connections to SIP over a year ago, that faxing has been intermittently not working. At the trouble site, all fax machines are off of a PBX, which is T-1 CAS integrated to SBC/CUBEs, which then have SIP connectivity to the PSTN. I'm using my own fax at a test site- fax is ATA connected to UC cluster which is SIP connected to PSTN. 

I have T38 enabled on all VoIP dial-peers at both sites, and my POTS dial-peer for the PBX integration is pretty bare. Please see below with the attached diagram. In my test scenario, I initiated a fax from "Test"site to "Trouble site". My dial-peers at trouble site are VoIP DP199 and POTS DP 20001.

Call flow is:
Test Site------------------------------------|                     Carriers/PSTN              |--------Trouble Site ------------|
Fax -> ATA -> CUCM SIP TRUNK -> Cisco CUBE-> Lumen SIP Trunk -> AT&T SIP Trunk-> Cisco CUBE-> T-1 CAS -> PBX->Fax

dial-peer voice 199 voip
description Inbound PSTN Calls to PBX - Incoming Call Leg
translation-profile incoming into-PBX
no modem passthrough
session protocol sipv2
incoming called-number 802[27][86][89]....
voice-class codec 1
voice-class sip asymmetric payload full
voice-class sip asserted-id pai
voice-class sip privacy-policy passthru
voice-class sip profiles 1
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte
fax-relay ecm disable
fax-relay sg3-to-g3
fax rate 14400
fax nsf 000000
ip qos dscp cs3 signaling
no vad

dial-peer voice 20001 pots
description VoIP call to PBX (Outbound leg)
preference 1
destination-pattern [26]....
port 0/1/1:1
forward-digits all
!

Global Config:

voice service voip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

Questions:

1) Do my dial-peers look correct? Do I not need anything on my POTS dial-peer facing the PBX since it's simply TDM and somehow, the CUBE is converting T38 to PCM?
2) Assuming that AT&T and Lumen are all VoIP and their interfaces between each other are VoIP, are my CUBEs at either end of the carriers' network doing the actual T38 and subsequent DIS/DCS and switch over to RTP? (Does the carrier do anything in that scenario on the T38 level?

Thank you for help in me understanding fax over IP!

[MxHadi]

maybe this help >>

go to CUCM, on SIP-Trunk, once do checked & once do unchecked of MTP option.. (Media Termination Point)
 & see what happens..

[SteveK066]

We're still primarily using an old TDM system, with ongoing migration to CUCM. In 2023 we replaced our legacy TDM T1s which were directly from the central office on copper lines, to fiber based SIP trunks that are converted to the standard PRI (23B + 1D) 4 wire connection to the legacy system. Since then, we have also experienced many reports of unsuccessful faxing. Some buildings do yet have Cisco CER for 911 location information - those outgoing calls still route through the legacy system. We do have direct SIP trunks to the Cubes. With a fax line on an ATA and using the Cube SIP trunk Calling Search Space for outgoing calls instead of the one to the legacy system, the success rate is pretty good, but not perfect. Because of that, we're offering an efax service which has been quite successful. Departments that use faxing often, such as medical departments are moving to efax services that are HIPPA compliant. 

[Michael Mertens]

Steve, 

I believe efax will be the ultimate solution-I appreciate the input and hearing that others' using legacy fax are experiencing problems, also. If I understand FoIP correctly, all it takes is one end-point or one carrier to mis-configure and there's nothing one can do to fix it on their end. 

Thanks again.

Mike