Implementing Sign Language Interpretation Service Routing for Deaf and Hard-of-Hearing Callers

How-To-Articles
1

Implementing Sign Language Interpretation Service Routing for Deaf and Hard-of-Hearing Callers

What This Guide Covers

This guide details the architectural implementation of a Video Relay Service (VRS) and direct Sign Language Interpretation (SLI) routing workflow within Genesys Cloud CX. You will configure a dedicated video queue, implement logic to detect and route incoming VRS calls from certified interpreters, and establish fallback mechanisms for agent-side video capability verification. The result is a compliant, accessible contact center flow that handles ASL, LS, and other sign language interactions with minimal latency and high availability.

Prerequisites, Roles & Licensing

Licensing Requirements

  • Genesys Cloud CX 2 or CX 3: Required for Video Telephony capabilities. CX 1 does not support video queues or video agent desktops.
  • Video Add-On License: Must be assigned to all agents capable of handling video calls.
  • VRS Provider Agreement: You must have an active contract with a VRS provider (e.g., Soren VRS, ZVRS, AT&T VRS) that supports SIP trunking or direct API integration for call signaling.

Permissions & Roles

  • Admin > Organization > Edit: To configure global video settings.
  • Admin > Telephony > Trunk > Edit: To configure the SIP trunk connected to the VRS provider.
  • Admin > Routing > Queue > Edit: To create and configure the Video SLI queue.
  • Admin > Routing > Architect > Edit: To build the video routing flow.
  • Admin > People > Edit: To assign video capabilities and licenses to agents.

External Dependencies

  • SIP Trunk Configuration: A dedicated SIP trunk or trunk group configured for video media transport (RTP/RTCP for video).
  • VRS Provider DID: A dedicated Direct Inward Dialing number provided by your VRS partner, used specifically for inbound VRS traffic.
  • Agent Video Hardware: Agents must have USB webcams, microphones, and headsets configured and tested in the Genesys Web Client or Desktop Client.

The Implementation Deep-Dive

1. Configuring the Video Telephony Infrastructure

Before routing logic can function, the underlying telephony infrastructure must support video media streams. Unlike voice-only SIP trunks, video trunks require specific codec negotiation and bandwidth allocation.

Step 1.1: Verify SIP Trunk Video Support

Navigate to Admin > Telephony > Trunks. Locate the trunk associated with your VRS provider.

  • Ensure Media Region is set correctly to minimize latency between the VRS provider’s data center and your Genesys Cloud region.
  • Under Codecs, ensure VP8 or H.264 (depending on provider requirement) is enabled and prioritized. VP8 is generally preferred for its open-source nature and hardware acceleration support in modern browsers.
  • Enable DTMF Handling via RFC 2833. VRS providers often use DTMF tones for call control signals during the handoff.

The Trap: Codec Mismatch
If your trunk is configured for G.711 (voice only) and you attempt to route video, the call will either fail to connect or connect as voice-only. The VRS provider sends a SIP INVITE with SDP attributes indicating video payload types. If Genesys Cloud does not have a matching codec enabled on the trunk, it rejects the SDP answer. Always verify the SDP offer from your VRS provider and mirror the codec list in Genesys Cloud.

Step 1.2: Configure Video Queue

Navigate to Admin > Routing > Queues. Create a new queue named SLI_Video_Queue.

  • Set Queue Type to Video. This is critical. Voice queues cannot process video media streams.
  • Under Skills, add a custom skill named ASL_SLI (or specific languages like LS_SLI, BSL_SLI).
  • Under Wrap-up, enable Wrap-up Required. Set the default wrap-up time to 30 seconds. This allows the agent to document the interpretation session and ensure the VRS interpreter has disconnected cleanly.

The Trap: Mixed Media Queues
Do not create a “General SLI” queue that accepts both Voice and Video. Genesys Cloud routing logic treats media types distinctly. An agent logged into a voice queue cannot be offered a video call, even if they have a video license. Segregating media types prevents routing deadlocks and ensures agents are prepared for the interface change.

2. Building the VRS Routing Flow in Architect

The core of the implementation lies in the Architect flow. VRS calls typically arrive via a standard SIP trunk but are identified by specific Caller ID patterns or SIP headers.

Step 2.1: Inbound Trigger Configuration

In Admin > Routing > Architect, create a new flow named VRS_Inbound_Router.

  • Add an Inbound Trigger.
  • Set Trigger Type to Incoming Call.
  • Configure the Trunk to match your VRS provider trunk.
  • Optionally, filter by Caller ID if your VRS provider uses a specific range of numbers for interpreter calls.

Step 2.2: Media Type Verification

Immediately after the trigger, add a Decision block.

  • Condition: {{ call.media_type }} == "video"
  • True Path: Proceed to SLI Queue Offer.
  • False Path: This path should handle errors. If a VRS provider sends a voice-only call to this flow, it indicates a misconfiguration on their end. Add a Play Text block: “This line is for Video Relay Service only. Please contact support.” Then Hangup.

The Trap: Ignoring Media Type
Assuming all calls from the VRS trunk are video calls is dangerous. VRS providers may use the same trunk for administrative voice calls or test calls. If you route a voice call to a Video Queue, the call will fail with a “Media Mismatch” error. Explicitly checking call.media_type prevents these failures.

Step 2.3: Agent Offer Logic with Skill Matching

Add a Queue Offer block.

  • Select SLI_Video_Queue.
  • Set Timeout to 60 seconds. VRS calls have strict compliance requirements for answer speed.
  • Under Attributes, pass the VRS interpreter’s name or ID if available in SIP headers (e.g., {{ call.sip_headers['X-VRS-Interpreter-ID'] }}). This allows downstream reporting.

Step 2.4: Fallback Logic for No Answer

If the Queue Offer times out:

  • Add a Transfer block to a backup video queue (e.g., SLI_Video_Backup).
  • If the backup also fails, implement a Callback or Voicemail option. Note: VRS calls cannot be left on standard voicemail if the caller expects real-time interpretation. The fallback must offer a callback to a human agent who can initiate a video call, or transfer to a text-based relay service if video fails entirely.

The Trap: Infinite Looping
Do not route a failed video offer back to the start of the flow. If you loop the call, you create a SIP loop that exhausts trunk resources. Always terminate the call or offer a distinct alternative (callback/transfer) after the final fallback.

3. Agent Desktop Configuration & Video Capability

Routing is only half the equation. The agent must be technically capable of accepting the video stream.

Step 3.1: Agent Profile Settings

Navigate to Admin > People. Select an agent.

  • Under Licenses, ensure Video is checked.
  • Under Capabilities, ensure Video is enabled.
  • Under Presence, the agent must set their status to Available for Video. In Genesys Cloud, agents can set separate availability for Voice and Video. An agent can be “Available” for voice but “Busy” for video.

The Trap: Partial Availability
Agents often forget to toggle Video availability. If an agent is logged in but has Video set to “Busy” or “Unavailable,” the Queue Offer will skip them, even if they have the correct skills. Train agents to check the video camera icon in the Web Client header to ensure they are accepting video calls.

Step 3.2: Hardware Validation

Ensure agents have completed the Audio and Video Check in the Genesys Web Client (Settings > Audio and Video).

  • Verify the webcam is selected.
  • Verify the microphone and speakers are functioning.
  • Test bandwidth. Video calls require a stable upload speed of at least 1 Mbps for VP8 at standard resolution.

4. Compliance and Recording Considerations

VRS calls are subject to strict privacy laws (e.g., Section 508 of the Rehabilitation Act in the US). Recording these calls requires explicit consent and secure storage.

Step 4.1: Call Recording Configuration

In the SLI_Video_Queue settings:

  • Enable Call Recording.
  • Set Recording Type to Video.
  • Configure Consent Prompt. You must play a pre-recorded message informing all parties (the deaf caller, the VRS interpreter, and the agent) that the call is being recorded.

The Trap: Silent Recording
Recording a VRS call without consent is a severe compliance violation. The VRS interpreter is a third party. You must ensure your consent message is audible to the interpreter and visible/audible to the deaf caller. Use a dual-modal consent prompt if possible (text on screen + audio).

Step 4.2: Secure Storage

Ensure your Genesys Cloud organization’s Data Retention policies cover video recordings. Video files are significantly larger than audio. Monitor storage usage closely. Consider archiving old video recordings to external blob storage (AWS S3/Azure Blob) via Genesys Cloud’s Recordings API to manage costs.

Validation, Edge Cases & Troubleshooting

Edge Case 1: VRS Provider Sends Voice-Only INVITE to Video Trunk

The Failure Condition
The VRS provider initiates a call, but the call fails immediately with a “488 Not Acceptable Here” SIP error.

The Root Cause
The VRS provider’s platform is misconfigured, sending a voice-only SDP offer to a trunk/queue configured for video. This often happens during provider-side updates or when using a legacy VRS gateway.

The Solution

  1. Check the SIP Trunk logs in Genesys Cloud (Admin > Telephony > Trunks > [Trunk Name] > Logs).
  2. Inspect the SDP Offer. Look for m=video lines. If missing, the offer is voice-only.
  3. Contact the VRS provider to correct their signaling.
  4. As a temporary workaround, create a secondary Voice Queue for the same DID and use an Architect flow to check call.media_type and route voice calls to the voice queue and video calls to the video queue.

Edge Case 2: Agent Accepts Call but Video Feed is Black

The Failure Condition
The agent answers the call, audio works, but the video window is black or shows a “No Camera” icon.

The Root Cause
This is usually a client-side browser permission issue or a hardware conflict. The Genesys Web Client requires explicit permission from the browser to access the webcam. If the browser denies this, or if another application (Zoom, Teams) is locking the camera, the video stream fails.

The Solution

  1. Instruct the agent to check the browser address bar for a camera icon (lock or camera symbol). Click it and ensure “Allow” is selected.
  2. Close other applications that might be using the webcam.
  3. Instruct the agent to go to Settings > Audio and Video and re-select the camera from the dropdown.
  4. If using the Desktop Client, restart the client to reset the media stack.

Edge Case 3: High Latency or Choppy Video

The Failure Condition
The video feed is lagging, freezing, or pixelated, making lip-reading or hand-sign interpretation difficult.

The Root Cause
Insufficient bandwidth or high jitter on the agent’s network. Video is more sensitive to packet loss than voice.

The Solution

  1. Check the agent’s network speed using the built-in Network Diagnostics in Genesys Web Client (Settings > Audio and Video > Run Diagnostics).
  2. Ensure the agent is on a wired Ethernet connection, not Wi-Fi.
  3. In the SIP Trunk settings, enable Jitter Buffer and set it to “Adaptive.”
  4. Lower the video resolution in the Agent’s client settings if bandwidth is constrained. Genesys Cloud allows clients to negotiate lower resolutions (e.g., 480p instead of 720p).

Official References