VoIP.infoThe independent guide to business communications.
VoIP.info Provider research

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.

Reviewed 2026-10-13T38Fax 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 testedAdvancedDocumentation based · not lab tested

Treat this as a fax-only service

Record the legal account, plan, trunk, assigned or porting numbers, authentication mode, fax endpoints, intermediary PBXs or SBCs, sites, owners and rollback path. T38Fax expressly prohibits voice calls; do not treat it as a general-purpose voice trunk or emergency path.

A compatible device entry, successful registration or answered call is only one boundary. Acceptance requires the intended number route, negotiated fax mode and a permitted received-document result.

Documented service facts

Reviewed 2026-10-13. Compare SIP trunk services →

SIP authentication

Documented

T38Fax documents both username/password and public source-IP authentication, with credential authentication as the default recommendation. The billing telephone number is the SIP username; the SIP password is distinct from the customer-portal login. Select one trunk mode deliberately, protect the credential and preserve the actual source address or challenge-response evidence without publishing secrets.

SIP registration

Documented

The registration-authenticated workflow relies on an active SIP registration for bidirectional signaling through typical NAT, while IP-authenticated trunks require explicit inbound reachability. Record registrar or proxy, transport, local and remote port, contact, expiry, observed address and response; a portal object or reachable socket is not a successful registration.

Inbound fax delivery and identity

Documented

The service supports assigned or ported fax numbers and inbound caller identity. Preserve the exact DID, Request-URI, source, receiving trunk, fax endpoint and provider call record for one inbound attempt. A port order, forwarded temporary number and completed native port are different routing states.

Resilience and failover

Not verified

The reviewed public material recommends the sip.t38fax.com service name rather than fixed addresses and publishes multiple signaling and media ranges, but it does not establish customer-controlled destination priority, retry policy, active-session survival or a recovery objective for one trunk. Preserve DNS, the selected edge, transaction results and a provider-approved failure test before claiming failover.

Number and destination coverage

Documented

The reviewed support page says outbound service covers the United States, Canada, Puerto Rico, the US Virgin Islands and Guam, while number supply or porting is limited to the 48 contiguous US states. It separately says standard DIDs can receive international calls and toll-free reachability needs case-by-case testing. Confirm current inventory, port eligibility and destination policy for the selected order.

Voice media and UDPTL boundary

Documented

T38Fax describes initial G.711 RTP followed by a T.38 re-INVITE and a switch to UDPTL fax data. Voice calling is prohibited. Preserve both SDP bodies, re-INVITE ownership, response, negotiated addresses and packet types; an answered SIP dialog, audible fax tones or a T.38-capable endpoint does not prove that UDPTL was negotiated or reached both directions.

T.38 fax and ECM

Documented

The product is purpose-built for T.38 fax and describes ECM as available on calls. ECM detects corrupt blocks and requests retransmission, but a reported success still needs a legible received-document check. Preserve protocol mode, pages, speed, resolution, ECM result, duration and both endpoint results for each accepted test case.

Transport and network controls

Documented

The default public-Internet path uses SIP and UDPTL, and T38Fax offers optional IPSec VPN plus private or direct connectivity. The firewall guide publishes source ranges and recommends least-privilege rules. SOC 2, HIPAA statements, a BAA, source authentication and VPN encryption address different controls; confirm the ordered topology and retained metadata with the organization responsible for compliance.

Concurrent fax sessions

Documented

The current support material describes a two-session free-trial limit and a 20-session soft cap for activated accounts, adjustable on request; the testing guide also instructs operators to set and exercise the portal limit. Treat those as published defaults, not the selected account or a measured result. Record the portal setting, endpoint capacity and permitted concurrency test separately.

Emergency calling

Not verified

The reviewed material expressly prohibits voice calls and presents the service as fax-only, so it is not an emergency-calling path. Maintain a separately qualified and accessible emergency service; do not attempt an emergency call through this trunk.

Pricing and contract

Documented

T38Fax publishes service plans, a trial and usage terms, but the applicable rate, included sessions, number charges, porting, international use, private connectivity, taxes and support terms remain order- and date-specific. Preserve a dated quote or checkout summary rather than copying a headline price into a deployment plan.

Portal, records and support

Documented

The provider publishes a customer portal, call records, compatibility guides, packet-capture procedures and support escalation. Preserve portal ownership, configuration export, exact call sample, timestamps and timezone, caller and called numbers, duration, SIP Call-ID where available, endpoint logs and a bounded capture with sensitive fax content handled under policy.

SMS and MMS

Not verified

The reviewed fax-service documentation does not establish SMS or MMS eligibility, sender registration, routing, throughput, retention or pricing for its numbers. Treat messaging as a separate product and compliance path rather than inferring it from DID ownership.

Keep credential and source-IP authentication separate

For the documented default credential mode, protect the billing-number SIP username and separate SIP password from portal credentials. Preserve REGISTER contact, observed source, expiry and response. For source-IP authentication, record every authorized public address and the inbound forwarding and firewall owner.

Do not mix both models accidentally, publish a secret, or infer that a portal login authenticates SIP. If the service appears reachable, prove which identity control accepted the exact request.

Build least-privilege signaling and media paths

Use the provider service name where documented and preserve the resolved destinations. The public firewall page distinguishes provider signaling sources from media ranges and notes that customer endpoint ports can differ from provider ports. Model both directions, NAT, registration state and local listener before changing rules.

The provider recommends port 5080 and disabling SIP ALG because incomplete helpers can alter signaling and mishandle the T.38 re-INVITE. Treat those as provider guidance, not proof of the local fault; capture the unmodified and observed messages before a controlled change.

Prove the transition from RTP to UDPTL

The published test workflow expects an initial SIP call with G.711 RTP, followed by a T.38 re-INVITE, successful response and a switch to UDPTL. Retain the offer and answer, connection addresses, ports, T.38 attributes, transaction ownership and packets in both directions.

Audible fax tones show an audio phase, not successful T.38. A 200 OK to the original INVITE does not prove the re-INVITE completed, and a re-INVITE alone does not prove that UDPTL traversed NAT or the firewall.

Validate ECM and the received document

Record direction, calling and called number, page count, speed, resolution, ECM state, duration, endpoint result and the legibility and completeness of the received document. ECM can request retransmission of corrupt blocks; disabling it may make a call appear to finish while degrading the received page.

Use only authorized test destinations and non-sensitive documents. Keep signaling success, T.38 negotiation, transport, fax-protocol completion and content acceptance as distinct evidence states.

Close commercial, security and operating gaps

Confirm current number inventory and port eligibility, destination coverage, caller identity policy, concurrency, pricing, retention, support, maintenance and incident escalation for the selected order. If IPSec, a private circuit, direct cloud connectivity, a BAA or audit evidence is required, retain the executed and implemented result rather than relying on a public description.

Run a bounded acceptance plan for inbound and outbound fax, representative page counts, long duration, permitted concurrency, endpoint restart and recovery. No trunk, packet, fax or document 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

Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
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 · T38Fax 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 tested

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.

Read guide →