User Stories

• As a Communication Service Provider (CSP), I want to offer Real-Time Text (RTT) functionality across my communication services to ensure accessibility for customers, including those with hearing or speech impairments, in compliance with regulatory requirements.
• As an end user with hearing or speech impairments, I want to communicate on calls via text, so that I can communicate more effectively and flexibly during calls, ensuring I have access to the services I need regardless of my communication abilities.
• As an end user, I want to communicate on calls with other end users with hearing or speech impairments via text, so that I understand my counterpart regardless of their communication abilities.

Example of use

An end user with a hearing impairment initiates a call to Emergency service using RTT. The agent communicates with the user via text, providing real-time assistance. The agent asks the user to enable voice stream in addition to text in order to better understand the user's surroundings. The agent can hear the background noises and communicate with the deaf user's via text at the same time. 

Business model

Cloud PBX / Call Center

Technology

RTT (Real-Time Text) is a technology that allows text to be transmitted instantly as it is typed during a phone call. Unlike SMS or instant messaging, RTT provides a real-time communication experience, where both parties see the text as it is being typed, character by character. This technology is particularly useful for people with hearing or speech impairments, enabling them to communicate effectively over the phone.

Current Solution

Currently, PortaSwitch does not support RTT or Text-over-IP capabilities

Stakeholders and their benefits

Use Cases

Use Case #1: Using calls with RTT

Preconditions:

• Emergency vendor is configured in PortaSwitch with a connection for processing off-net calls to vendor.
• Emergency vendor supports RTT codecs:
  • T.140: Standard for real-time text transmission over RTP.
  • RED: Adds redundancy to T.140 transmissions by sending multiple copies of real-time text data in RTP packets.

• The end user's Phone app supports RTT

Role:

• CSP
• Emergency agent
• End Users: 
  
  • John with hearing impairment
  • David with speech impairment
  • Mark

Use scenario #1.1: Initiating a call with RTT

1. John calls Emergency service using RTT-enabled Phone app by dialing 112.
2. Emergency agent receives an RTT invitation and accepts the call.
3. John starts typing his issue, e.g. "Somebody broke into my house. My home alarm reported an intruder."
4. As John types, Emergency agent sees the text appear in real time and responds immediately: "Are you safe? Please provide your address."
5. John types back: "I’m hiding in the closet. 123 Main Street, Apt 4B."

Use scenario #1.2: Switching from RTT to voice/video

1. Continues after #1.1

2. Emergency agent writes: "Can you switch to voice or video? It may be faster to communicate." 

3. Although John is hearing-impaired, he switches from RTT to video using the corresponding button on his Phone app to allow the agent to better assess the situation visually.
4. RTT stream is terminated, and Emergency agent communicates with John only via video using gestures.

Use scenario #1.3:  Enabling voice/video in addition to RTT (alternative to #1.2)

1. Continues after #1.1
2. Emergency agent notices that John’s responses are delayed and writes: "Can you enable voice or video? I need to hear what’s happening." 

3. John enables voice/video on his Phone app.

4. Emergency agent can now hear the background noise and continues communicating with John via text at the same time.

Use scenario #1.4: Switching from voice/video to RTT

1. David is on a voice/video call with Emergency agent, answering agent's questions in whisper and stuttering because he is afraid to talk loud as an intruder is in the house.
2. Emergency agent has difficulty to understand what John is saying and asks him to write his contact information.
3. John switches from voice/video to RTT using the corresponding button on his Phone app.
4. Voice/video stream is terminated, and Emergency agent communicates with John only via text.

Use scenario #1.5: Enabling RTT in addition to voice/video (alternative to #1.4)

1. David is on a voice/video call with Emergency agent, answering agent's questions whisper and stuttering because he is afraid to talk loud as an intruder is in the house.
2. Emergency agent has difficulty to understand what John is saying and asks him to write his contact information.
3. John enables RTT using the corresponding button on his Phone app.
4. Emergency agent can hear the background noise and sees that John is typing his contact information in text. 

Use scenario #1.6: Handling RTT call with poor connection

1. John is on RTT call with Emergency agent.

2. As John types, he notices a slight delay in the text appearing on his screen (the symbols do not appear instantly as he types).

3. John sees a network status warning indicating weak connectivity.
4. John's Phone app detects packet loss and, as it supports RTT redundancy (RED), retrieves missing text from the redundant data in subsequent packets.
5. RTP packets containing both the original text and redundant copies from John's device are sent to the emergency agent without any modifications on PortaSwitch side.
6. The emergency agent's device processes the received packets, using redundancy to recover any lost text.
7. John continues typing, reassured that his messages are still reaching the agent despite the weak connection.

Use scenario #1.7: Managing RTT codecs order

1. CSP wants to prioritize sending the RTT codec with redundancy (RED) first, followed by T.140, to ensure high-quality RTT sessions with their emergency vendor.
2. CSP configures the service policy with the enforced codec order and assigns to the emergency vendor connection in PortaSwitch, instructing the system to use RED first, followed by T.140.

Use scenario #1.8: RTT call to a device not supporting RTT

1. John initiates an on-net/off-net call to his friend Mark, using an RTT-enabled Phone app.

2. John’s device sends RTT codecs in the SDP.

3. PortaSwitch does not interfere with the SDP negotiation and transparently passes SDP to Mark's device.

4. Mark’s device does not support RTT and therefore does not accept RTT in the SDP answer.

5. RTT is not established, and the call proceeds as a regular voice call, John and Mark communicate using only voice.

6. Later during the call, John tries to write a text to Mark using RTT.

7. PortaSwitch again passes the SDP transparently to Mark's device.

8. Mark’s device still does not support RTT and does not accept the RTT codecs.

9. John's RTT text is not delivered, and the call continues as a voice-only conversation.

Non-functional Requirements

1. Backport of the feature to MR110 is required. 

Peculiarities

N/A

Performance / Clustering, Geo Redundancy/ Dual-Version, Porter / Call Control API

N/A

ESPF / Monitoring

N/A