Architecting TTY and TDD Relay Service Integration for Deaf Caller Support Workflows

How-To-Articles
1

Architecting TTY and TDD Relay Service Integration for Deaf Caller Support Workflows

What This Guide Covers

This guide details the configuration of SIP trunk signaling, flow logic, and routing patterns required to detect TTY/TDD calls and seamlessly integrate with a Relay Service Provider (RSP) for compliant deaf caller support. By the end of this guide, your contact center will automatically identify text-based telephony traffic, route it to an RSP without agent intervention, and handle return-path calls from the RSP while preventing infinite transfer loops and compliance violations.

Prerequisites, Roles & Licensing

Licensing & Tiers

  • Genesys Cloud CX: CX 1 or higher. TTY detection and routing are included in standard telephony licensing. No WEM or specialized add-on is required.
  • NICE CXone: Standard Telephony license. Studio flows for routing are included.
  • External Dependencies: A contracted Relay Service Provider (RSP) with a dedicated SIP endpoint or DID. An SBC or Carrier capable of passing SIP INFO messages or DTMF tones.

Permissions & Scopes

  • Genesys Cloud:
    • UI: Telephony > Trunk > Edit, Architect > Flow > Edit, Routing > Queue > Edit.
    • API: routing:flow:edit, telephony:trunk:edit, telephony:trunk:view.
  • NICE CXone:
    • UI: Studio > Edit, Telephony > Trunk > Edit, Routing > Queue > Edit.
    • API: studio:flows:edit, telephony:trunks:edit.

Technical Prerequisites

  • Access to the SIP Trunk configuration to enable SIP INFO passing.
  • A designated RSP phone number or SIP URI.
  • Understanding of RFC 3964 (SIP INFO for T.38/Text) and FCC 47 CFR Part 64 accessibility requirements.

The Implementation Deep-Dive

1. Trunk Configuration for TTY/TDD Detection

The foundation of TTY integration is accurate detection at the network edge. TTY and TDD devices transmit text over voice channels using Baudot code or V.21 modem signals. Modern CCaaS platforms detect these calls via SIP signaling rather than audio analysis. The standard mechanism is the SIP INFO message containing application/telcom-soft-telephony or text/plain bodies, often triggered by the carrier or the calling device.

We must configure the SIP trunk to preserve and parse these INFO messages. If the trunk strips SIP INFO, the platform cannot distinguish a TTY call from a voice call, resulting in routing to a voice agent. This causes the agent to speak into silence, creating a compliance violation and a poor customer experience.

Genesys Cloud Trunk Configuration

Navigate to Telephony > Trunks and edit the inbound trunk. In the SIP Settings section, locate the SIP INFO configuration.

  • Set SIP INFO to Enabled.
  • Ensure Pass SIP INFO is checked. This prevents the Genesys media server from discarding the INFO packet before Architect processes it.
  • Configure DTMF Handling to RFC 2833 or In-band depending on your carrier. TTY devices often use DTMF to signal call initiation or relay requests (e.g., dialing 711).

API Payload Example:
Use the following payload to configure the trunk via API. This ensures programmatic consistency across environments.

PUT /api/v2/trunks/{id}
Authorization: Bearer <access_token>
Content-Type: application/json

{
  "name": "Primary_SIP_Trunk",
  "sipInfoEnabled": true,
  "dualToneMultiFrequency": {
    "enabled": true,
    "rfc2833": true
  },
  "media": {
    "sipInfo": {
      "enabled": true,
      "passToFlow": true
    }
  }
}

The Trap: SBC Stripping SIP INFO
The most common failure mode occurs when the customer’s Session Border Controller (SBC) strips SIP INFO messages for security or normalization reasons. If the SBC removes the INFO packet, Genesys Cloud receives a standard audio call with no TTY indicator. You will observe calls routing correctly in the flow but failing to trigger TTY-specific logic.

  • Diagnosis: Check the SBC logs for SIP INFO messages on the inbound leg. Verify that the Content-Type header is preserved.
  • Mitigation: Work with the network team to whitelist SIP INFO methods on the SBC. If the SBC cannot be modified, you must implement a fallback detection method using DTMF analysis or a “711” prefix dialing pattern, though this is less reliable than SIP INFO.

NICE CXone Trunk Configuration

In NICE CXone, navigate to Telephony > Trunk and edit the inbound trunk.

  • Enable SIP INFO Support.
  • Ensure Pass Through SIP INFO is active.
  • Verify that the Media Settings allow text telephony passthrough.

2. Architect Flow Logic for TTY Routing

Once detection is enabled at the trunk level, the flow must evaluate the call type and route accordingly. The architectural goal is to minimize latency. TTY users expect immediate connection to the relay service. We do not play announcements or gather input from TTY calls unless the relay service explicitly requires it.

Genesys Cloud Architect Implementation

Create a new Flow or edit the existing inbound flow. At the start of the flow, immediately check the call type.

  1. Set Variable Block: Capture the TTY status.

    • Variable Name: isTTYCall
    • Value: call.tty.enabled
    • This boolean variable evaluates to true if SIP INFO indicates a TTY call.

  2. Decision Block: Branch based on isTTYCall.

    • Condition: isTTYCall == true
    • True Path: Route to Relay Service Provider.
    • False Path: Continue to standard IVR logic.

  3. Transfer Block (Relay Path):

    • Destination: RSP Phone Number or SIP URI.
    • Type: phoneNumber
    • Critical Configuration: Set Transfer Type to Blind Transfer. Do not use Consult Transfer. A consult transfer requires the agent to answer, which is impossible for a TTY-to-Voice relay without proper agent equipment. The platform must transfer the call directly to the RSP.

Architect JSON Snippet:
The following JSON represents the critical decision and transfer structure.

{
  "blocks": {
    "start": {
      "name": "Start",
      "type": "start",
      "settings": {
        "timeoutSeconds": 30
      },
      "outcomes": {
        "success": "checkTTYStatus"
      }
    },
    "checkTTYStatus": {
      "name": "Set TTY Variable",
      "type": "setVariable",
      "settings": {
        "variables": [
          {
            "name": "isTTYCall",
            "value": {
              "type": "function",
              "functionName": "equal",
              "arguments": [
                {
                  "type": "variable",
                  "variableName": "call.tty.enabled"
                },
                {
                  "type": "boolean",
                  "value": true
                }
              ]
            }
          }
        ]
      },
      "outcomes": {
        "success": "routeDecision"
      }
    },
    "routeDecision": {
      "name": "Route TTY or Voice",
      "type": "decision",
      "settings": {
        "condition": {
          "type": "variable",
          "variableName": "isTTYCall"
        }
      },
      "outcomes": {
        "true": "transferToRelay",
        "false": "standardIVR"
      }
    },
    "transferToRelay": {
      "name": "Transfer to RSP",
      "type": "transfer",
      "settings": {
        "destination": {
          "type": "variable",
          "variableName": "relayProviderNumber"
        },
        "type": "phoneNumber",
        "transferType": "blind"
      },
      "outcomes": {
        "success": "end",
        "failure": "errorHandling"
      }
    }
  }
}

The Trap: Relay Return Path Loops
When the RSP receives the call, a Communications Assistant (CA) answers. The CA then dials your contact center to reach the agent. The return call arrives at your trunk. If your flow blindly checks for TTY and transfers to the RSP, and the RSP sends SIP INFO on the return call, the flow will transfer the call back to the RSP. This creates an infinite transfer loop, exhausting trunk capacity and preventing the agent from ever answering.

  • Solution: Implement a loop-breaker. The return call from the RSP should bypass the relay transfer logic. You can achieve this by:
    • Using a dedicated DID for relay returns that routes to a separate flow.
    • Checking the from address. If the call originates from the RSP’s SIP domain, skip the relay transfer.
    • Using a flow variable passed via SIP headers (e.g., X-Relay-Return: true) if the RSP supports custom headers.

3. Return Path Handling and Agent Routing

The return call from the RSP represents the relay agent calling your contact center. This call must be routed to the appropriate queue or agent with minimal friction. The CA will be speaking on behalf of the deaf caller. The agent should be aware that this is a relay call to adjust their communication style (e.g., pausing longer, avoiding slang).

Queue Configuration

Create a dedicated queue for relay returns, or configure existing queues to accept relay traffic.

  • Queue Name: Relay_Return_Queue
  • Routing Strategy: Longest Available Agent or Priority. Relay calls often have higher urgency due to the stop-and-wait nature of text telephony.
  • Wrap-up Codes: Define a wrap-up code for Relay Call to track compliance metrics.

Agent Workforce Management Implications

Relay calls require agents capable of clear, concise communication. While any agent can handle a relay call, training is essential. Agents must understand that the CA is reading the caller’s text and speaking to the agent. The agent speaks, and the CA types the response to the caller. Latency is inherent in this process. Agents must not interrupt the CA.

The Trap: VAD Thresholds on Relay Media
Voice Activity Detection (VAD) algorithms may misinterpret the speech patterns of a Communications Assistant. CAs often speak in short, distinct phrases or pause frequently while reading text. Aggressive VAD settings may cut off the CA prematurely, causing media glitches or premature call termination.

  • Diagnosis: Agents report audio cutting out or the CA repeating phrases.
  • Mitigation: Adjust VAD sensitivity for the trunk or queue handling relay traffic. In Genesys Cloud, verify that the media settings for the relay queue do not apply aggressive silence suppression. Consider disabling silence suppression for relay queues to ensure the CA’s pauses are preserved for the TTY device to process.

4. DTMF Fallback and 711 Dialing

Not all carriers or legacy TTY devices support SIP INFO. In these cases, detection must rely on DTMF sequences. The standard sequence for relay access in North America is dialing 711. Some carriers send a DTMF tone when the TTY device is detected.

Flow Implementation for DTMF Detection

If SIP INFO detection is unavailable, implement a DTMF collection block at the start of the flow.

  1. Collect Input Block:
    • Timeout: 3 seconds.
    • Max Digits: 3.
    • Prompt: None (Silent collection).
  2. Decision Block:
    • Check if input equals 711.
    • If true, route to RSP.
    • If false, continue to IVR.

The Trap: DTMF Interference with IVR Prompts
Collecting DTMF silently at the start of the flow can interfere with IVR prompts if the user is a voice caller. If the voice caller presses a digit immediately, the flow may capture it and route incorrectly.

  • Mitigation: Use a hybrid approach. Check SIP INFO first. If SIP INFO is absent, wait for a brief period (e.g., 1 second) or rely on carrier-provided DTMF signals rather than user input. For inbound calls, the TTY device may send a “break” signal or specific DTMF upon call setup. Coordinate with the carrier to determine the exact signaling method for TTY detection.

Validation, Edge Cases & Troubleshooting

Edge Case 1: SIP INFO Stripping by Carrier

  • Failure Condition: Calls are not routing to the RSP. Logs show call.tty.enabled is false.
  • Root Cause: The carrier is not sending SIP INFO, or the SBC is stripping it.
  • Solution:
    • Verify SIP INFO presence using a packet capture on the trunk interface.
    • If the carrier does not send SIP INFO, request that they enable TTY signaling.
    • If the SBC strips INFO, update SBC policies to pass SIP INFO with Content-Type: application/telcom-soft-telephony.
    • Implement DTMF fallback as a temporary measure.

Edge Case 2: Infinite Relay Loop

  • Failure Condition: Calls are bouncing between the contact center and the RSP. Agents never receive the call.
  • Root Cause: The return call from the RSP triggers the relay transfer logic again.
  • Solution:
    • Inspect the flow for the return path.
    • Add a condition to check the from address. If from matches the RSP domain, bypass the relay transfer.
    • Example Genesys Architect condition: not equal(from.address, "relay-provider.com").

Edge Case 3: High Latency and “Talker” Detection Failure

  • Failure Condition: The CA reports that the agent’s audio is cutting off or the call drops.
  • Root Cause: VAD is too aggressive for relay speech patterns. The CA pauses to type, and VAD interprets the pause as end of call.
  • Solution:
    • Disable silence suppression for the relay queue.
    • Adjust VAD thresholds to allow longer silence periods (e.g., 2 seconds instead of 0.5 seconds).
    • Verify that the media codec supports text telephony passthrough if using T.38.

Edge Case 4: International Relay Variations

  • Failure Condition: International TTY calls are not detected.
  • Root Cause: Different countries use different signaling standards for relay services. Some regions use Video Relay Service (VRS) with SIP SDP attributes rather than TTY INFO.
  • Solution:
    • Verify the signaling requirements for international trunks.
    • If VRS is used, check for SDP attributes indicating video relay.
    • Update the flow to handle multiple detection methods based on the trunk or region.

Official References