Configure T.38 Fax Routing via SIP Trunk for Genesys Cloud BYOC

How-To-Articles
1

Configure T.38 Fax Routing via SIP Trunk for Genesys Cloud BYOC

What This Guide Covers

This guide details the configuration of a Bring Your Own Carrier (BYOC) trunk to support T.38 fax transmission within Genesys Cloud CX. The end result is a telephony infrastructure where incoming fax calls are automatically routed through a dedicated SIP trunk to an external gateway, preserving document integrity without conversion to voice.

Prerequisites, Roles & Licensing

  • Licensing Tier: Genesys Cloud CX 3 or higher. Advanced routing features and BYOC capabilities require the Enterprise tier. WEM Add-on is required for detailed call recording of fax sessions if compliance auditing is necessary.
  • Granular Permissions:
    • Telephony > Trunk > Edit (To modify SIP trunk properties).
    • Routing > Flow > Edit (To construct routing logic).
    • Settings > External Integrations > Edit (If using API-based fax services).
  • OAuth Scopes: None required for UI configuration. If provisioning via API, the tokens.read and trunks.write scopes are necessary.
  • External Dependencies:
    • A SIP Trunk Provider capable of T.38 pass-through or termination (e.g., Bandwidth, Twilio, Amazon Chime Connect).
    • An external Fax Gateway or Store-and-Forward service (e.g., eFax, RingCentral Fax) registered as a SIP endpoint.
    • Network access for the BYOC trunk IP addresses to allow bidirectional UDP/TCP traffic on ports 5060 and RTP ranges.

The Implementation Deep-Dive

1. Carrier Prerequisites & Codec Negotiation

Before configuring Genesys Cloud, the external carrier must be verified as T.38 capable. Most modern carriers default to G.711 for voice and T.30 (G.711) for fax unless explicitly configured otherwise. You must ensure the carrier supports application/t38 in the Session Description Protocol (SDP) exchange.

Configuration Steps:

  1. Navigate to Admin > Telephony > Trunks.
  2. Select the BYOC trunk intended for fax traffic or create a new one specifically for fax routing.
  3. In the Trunk Properties, set Transport to UDP. While TCP is often preferred for signaling, T.38 reliability over IP networks frequently depends on UDP with specific jitter buffer settings in the gateway.
  4. Locate the Codecs section. Ensure PCMU (G.711u) and PCMA (G.711a) are enabled. Although T.38 is a distinct protocol, fallback mechanisms often rely on G.711 negotiation during the initial handshake before switching to image data transfer.
  5. Enable SIP URI Routing. Set the format to + or E164 to match carrier expectations.

The Trap:
A common misconfiguration involves disabling G.711 codecs entirely in favor of T.38. If the remote gateway does not support T.38 initially, the call will fail immediately with a 488 Not Acceptable Here error. Genesys Cloud requires the capability to negotiate G.711 as a fallback during the SDP offer/answer exchange even for fax calls if the carrier demands it. Ensure both voice and image codecs are present in the allow list.

Architectural Reasoning:
You configure both because T.38 negotiation happens within the SDP body of the INVITE request. The presence of G.711 capabilities signals that the endpoint can handle audio streams if the fax protocol fails, allowing for a voice fallback rather than a hard drop. This preserves availability during network instability.

2. SIP Trunk Configuration & Transport Security

The trunk configuration must enforce specific security and transport parameters to ensure T.38 packets are not dropped by intermediate firewalls or NAT devices. T.38 relies heavily on the stability of the RTP stream, which can be disrupted by standard voice optimizations like jitter buffers that expect constant bit-rate audio streams.

Configuration Steps:

  1. In the Trunk Configuration, locate TLS Settings. Set Enable TLS to True if your carrier requires encrypted signaling (recommended for HIPAA or PCI compliance).
  2. Configure SIP Trunk Routing Rules. Create a specific rule that matches fax-specific DIDs or ANI patterns. For example, match any DID ending in FAX or specific prefixes like 555-0199.
  3. Set the Outbound Proxy to point directly to your gateway provider’s SIP URI. Do not use the default Genesys Cloud proxy for T.38 traffic as it may introduce latency incompatible with fax timing requirements (typically < 200ms round trip).
  4. Under Advanced Settings, ensure Allow Early Media is checked. Some fax gateways send early media to confirm line readiness before the user answers, which is critical for automated fax transmission.

The Trap:
Enabling SIP Re-invite or Session Timer Refresh incorrectly can cause fax sessions to drop mid-transmission. T.38 sessions often require longer session durations than standard voice calls. If the carrier forces a 90-second refresh timer (common in SIP standards), a long document transmission may be terminated before completion.

  • Mitigation: Set the Session Timer Refresh Interval to a higher value (e.g., 3600 seconds) or ensure the carrier supports T.38-specific keep-alive mechanisms that do not rely on standard session timers.

Architectural Reasoning:
Standard SIP sessions are designed for voice conversations lasting minutes, whereas fax sessions can last from 15 seconds to several minutes of continuous data transfer. The Session Timer mechanism in SIP is designed to tear down idle connections. If a long document is being transmitted and the timer expires without activity (because T.38 packets might be spaced out), the session drops. Adjusting this prevents premature termination.

3. Routing Flow Logic

Routing logic must distinguish between voice calls and fax calls at the moment of ingress. This ensures that T.38 traffic is directed to the correct gateway endpoint without attempting to route it to an agent queue or voicemail system.

Configuration Steps:

  1. Navigate to Admin > Routing > Flows. Create a new flow named Fax_Intake_Flow.
  2. Add a Route To External API step. This step will trigger the connection to your external fax service if you are using an integration. Alternatively, use a Route To Trunk step if routing directly via SIP.
  3. If using Route To Trunk, select the BYOC trunk configured in Step 2.
  4. In the Condition logic of the flow, define the match criteria. Use ANI (Automatic Number Identification) or DNIS (Dialed Number Identification Service).
    • Example Logic: If DNIS contains "FAX" OR ANI matches known Fax Provider IDs.
  5. Set the Default branch to route to the main IVR or voice queue, ensuring fax traffic does not bleed into agent queues where agents cannot handle T.38 sessions.

The Trap:
Routing all incoming calls to a single trunk that supports T.38 creates a performance bottleneck and security risk. If a standard voice call hits a T.38 endpoint, the gateway may interpret the audio tones as fax data, resulting in garbled transmission or connection failure. Conversely, routing T.38 traffic through a generic SIP proxy can result in codec mismatches where the proxy attempts to transcode the fax data into audio.

  • Mitigation: Use dedicated DID patterns for fax lines and enforce strict routing rules that prevent non-fax traffic from entering the T.38 path.

Architectural Reasoning:
This separation ensures that media processing resources are allocated correctly. Genesys Cloud does not process T.38 packets itself; it acts as a signaling router. By isolating fax traffic, you ensure that the signaling path remains clear for voice calls and that the specific SDP requirements for image data transfer do not interfere with standard audio routing logic.

4. Gateway Signaling & NAT Traversal

The final critical step is ensuring the network path between Genesys Cloud and the external gateway supports T.38 packet transmission without interference from NAT (Network Address Translation) devices or firewalls. T.38 relies on specific RTP payload types that are often filtered by default security policies designed for voice traffic.

Configuration Steps:

  1. Verify NAT Traversal settings on the BYOC trunk. Enable ICE (Interactive Connectivity Establishment) if your gateway supports it, as this helps establish direct media paths between endpoints behind NATs.
  2. Ensure STUN/TURN servers are configured in the network infrastructure. If the Genesys Cloud Edge or Proxy is behind a firewall, ICE ensures that T.38 packets can find a viable path through symmetric NAT devices.
  3. Check Firewall Rules. Open outbound UDP ports for RTP ranges (typically 10,000 to 20,000) and ensure no deep packet inspection (DPI) is altering the SDP payload type fields. DPI can strip the application/t38 header, causing the gateway to reject the fax session.
  4. Configure SDP Filtering on the Genesys Cloud side if available in your specific BYOC provider’s portal. Ensure that m=image lines are not stripped during routing.

The Trap:
Firewall rules often block UDP ports used for T.38 media streams because they appear as non-standard traffic compared to G.711 audio. Additionally, some carriers perform “SDP rewriting” where they alter the IP address in the SDP body. If Genesys Cloud sends a private IP in the SDP and the carrier rewrites it incorrectly, the fax gateway will send packets to an unreachable address.

  • Mitigation: Validate the SDP payload using a SIP trace tool (such as Wireshark or the Genesys Cloud SIP Trunk Monitoring tools) to confirm that the a=rtpmap line includes t38. Ensure the IP addresses in the SDP match public routable addresses.

Architectural Reasoning:
T.38 is sensitive to packet loss and latency. NAT traversal mechanisms like ICE are essential because they allow endpoints to discover their public IP addresses dynamically. Without this, the media path may be established via a relay server (TURN), which adds latency. Excessive latency (> 200ms) can cause T.38 handshake timeouts. Direct peer-to-peer connectivity is preferred for fax reliability.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Fallback to G.711 (T.30)

The Failure Condition: A fax transmission begins successfully but then fails after a few pages, or the receiving gateway rejects the document entirely. The logs show a transition from application/t38 to audio/PCMU.
The Root Cause: The remote gateway does not support T.38 or has disabled it due to network jitter. It requests a fallback to G.711 (T.30 fax over voice), but the Genesys Cloud flow is locked into routing only to a T.38-capable endpoint that does not support the fallback negotiation.
The Solution: Update the Routing Flow to include a Retry Logic step. If the initial connection fails, route the call to a different trunk or gateway that explicitly supports T.30 (G.711) faxing as a secondary option. Monitor the Reason header in the SIP response; look for 488 Not Acceptable Here indicating codec mismatch.

Edge Case 2: Jitter and Latency Causing T.38 Negotiation Failure

The Failure Condition: Calls connect successfully, but the fax transmission fails with a “NO ANSWER” or “BUSY” signal from the remote end after the handshake phase.
The Root Cause: T.38 requires low latency for its timing-dependent error correction mechanisms. Network jitter buffers on intermediate SIP proxies often add delay incompatible with T.38 requirements (which typically require < 100ms one-way latency).
The Solution: Adjust the Jitter Buffer settings on the BYOC trunk to “Fixed” or “Low”. Avoid “Adaptive” buffers for fax traffic as they introduce variable latency. Additionally, request a QoS (Quality of Service) tag from your network administrator to prioritize T.38 RTP packets over standard voice traffic.

Edge Case 3: Fax Modem Tone Detection vs. Real T.38 Packets

The Failure Condition: The system attempts to route a call as a fax because it detects V.21/V.27 tones, but the call fails because it was actually a human voice call with background noise resembling fax tones.
The Root Cause: Relying solely on tone detection for routing decisions can lead to misrouting of voice calls into fax paths. Conversely, some legacy fax machines do not announce themselves via T.38 signaling immediately.
The Solution: Do not rely on CDR (Call Detail Record) metadata alone for routing. Use explicit DID/ANI patterns where possible. If you must use tone detection, ensure the Flow Logic includes a confirmation step where the gateway sends a test packet back to confirm T.38 capability before completing the full routing action.

Official References