VoIP.infoThe independent guide to business communications.
VoIP.info Troubleshooting

T38Fax call connects but T.38 is not negotiated

Trace one fax from the initial SIP dialog and G.711 phase through the T.38 re-INVITE, SDP answer, UDPTL path, ECM state and received-document result.

Reviewed 2026-10-13T38Fax testing, firewall, SIP ALG, packet-capture, ECM and fax-only service pages reviewed October 13, 2026; the exact trunk, endpoint, intermediary, authentication, registration, SIP dialog, re-INVITE owner, SDP, NAT, firewall, ALG, UDPTL packets, fax speed, resolution, ECM result, duration and received document remain deployment specific, and no account, endpoint, PBX, SBC, firewall, packet, call, fax session or document was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one failed fax and every call-path owner

Record timestamp and timezone, direction, caller and called numbers, trunk, endpoint and version, intermediaries, registration or source-IP mode, SIP Call-ID, final response, duration, fax result code, pages, speed, resolution, ECM state and whether the received document exists and is legible.

Draw the actual path from endpoint through PBX, SBC, NAT and firewall to the provider. A successful SIP answer, audible tone and failed document can belong to different stages; do not summarize them as one generic fax failure.

Prove the initial dialog before looking for T.38

Retain the initial INVITE, provisional responses, 200 OK and ACK, including SDP and RTP addresses. Confirm the intended trunk, normalized destination, accepted identity and packets in both directions. If the initial call never establishes, solve routing, authentication, reachability or the G.711 phase first.

Do not treat REGISTER success as call success or a provider portal record as proof that the customer endpoint received the same dialog.

Locate the re-INVITE and its exact outcome

The provider test guide expects the party receiving the initial INVITE to send a later re-INVITE for T.38. Find that transaction, preserve its new Via branch and CSeq, offer, response and ACK, and identify the component that generated or rejected it.

If no re-INVITE exists, inspect endpoint fax detection and intermediary policy. If it is rejected, preserve the response and SDP mismatch. Do not force T.38 globally before identifying which leg lacks an offer or acceptable answer.

Compare negotiated SDP with the observed UDPTL path

After a successful T.38 exchange, compare each negotiated address and port with NAT state, firewall policy and the actual UDPTL packets in both directions. Customer and provider port ranges need not match. SIP and media can also use different addresses.

A completed re-INVITE with no UDPTL points to a later path boundary. Avoid opening media to the Internet; use the documented provider sources and the endpoint vendor ranges, then make the smallest reversible rule change.

Test SIP ALG and port handling as evidence-led changes

Compare messages on both sides of any firewall or SBC for rewritten connection addresses, ports or missing T.38 attributes. T38Fax recommends disabling SIP ALG and often using 5080 because helpers can mishandle re-INVITEs, but the actual device state and behavior must be demonstrated.

Change one control in a maintenance window, clear only the required state, repeat the same authorized fax and retain before-and-after ladders. Do not assume a nonstandard port guarantees that an ALG is bypassed.

Close with ECM and document evidence

Once UDPTL flows, record negotiated fax parameters, ECM use, page count, duration and both endpoint results, then inspect the permitted received document for completeness and legibility. A nominally successful call with corrupt or missing content is not accepted.

Use the provider test service or another expressly authorized destination, keep captures and documents under data-handling policy, and escalate a precise call sample when the earliest failing boundary is provider-side or uncertain. No call, packet or fax was inspected or tested for this article.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Provider research · T38Fax product, support, security and pricing pages reviewed October 13, 2026; the public sources do not prove the selected account, order, number, completed port, credential, source address, registration, DNS answer, firewall, endpoint compatibility, SDP, T.38 re-INVITE, UDPTL path, ECM result, document quality, concurrency, VPN, private circuit, support response, availability or price, and no account, portal, credential, fax endpoint, PBX, SBC, firewall, resolver, packet, call, document, port, failover event, load test or emergency call was inspected or tested

T38Fax SIP trunks: fax-only, T.38, ECM and network boundaries

Research T38Fax as a specialized fax-only SIP service, keeping authentication, registration, T.38 negotiation, UDPTL, ECM, caller identity, concurrency and security attached to the selected trunk and observed document result.

Read guide →
Guide · Analog interface and carrier behavior vary by device, region and firmware

Fax over VoIP: T.38 relay versus G.711 passthrough

Choose a fax path from end-to-end support and observed document delivery, not a codec checkbox.

Read guide →
Guide · Analog interface and carrier behavior vary by device, region and firmware

Fax-over-VoIP troubleshooting by failure stage

Distinguish call setup, fax negotiation, page transfer and completion failures.

Read guide →
Guide

Firewall rules for VoIP

Define management, signaling and media access separately using actual deployment requirements.

Read guide →
Guide · Asterisk 22 FAXOPT, ReceiveFAX and SendFAX documentation plus branch 22 res_fax configuration and implementation reviewed October 13, 2026; the installed Asterisk version, res_fax module, technology resource, configuration, channel, TIFF/F file, signaling, T.38 negotiation, audio path, session result, storage and delivery remain deployment specific, and no host, module, file, channel, packet, fax session or document was inspected or tested

Asterisk res_fax: session options, mode and result evidence

Keep the generic res_fax layer, loaded technology resource, per-session FAXOPT policy, TIFF/F file, audio or T.38 mode and final transmission result independently observable.

Read guide →
Troubleshooting · Asterisk 22 FAXOPT, ReceiveFAX and SendFAX documentation plus branch 22 res_fax configuration and implementation reviewed October 13, 2026; the installed Asterisk version, res_fax module, technology resource, configuration, channel, TIFF/F file, signaling, T.38 negotiation, audio path, session result, storage and delivery remain deployment specific, and no host, module, file, channel, packet, fax session or document was inspected or tested

Asterisk ReceiveFAX or SendFAX fails or uses the wrong mode

Trace one fax from the exact channel and loaded res_fax stack through FAXOPT inputs, file access, audio or T.38 negotiation, application result and downstream artifact handling.

Read guide →