Intercom Accessibility — RTT / TTY

Latch Intercom Accessibility Mode

At Latch, we strive to engineer products that utilize modern technology to create functional experiences for all people, regardless of physical ability. And so, we are proud to discuss specifically our hard of hearing/speech impaired Accessibility flow for Latch Intercom which incorporates RTT / TTY calling through Users’ smartphones. First, we will describe what already existed in this space and then we will overview what Latch Intercom provides. Finally, we will provide technical details on how to implement such a flow. We hope that where relevant, companies will continue to adopt smartphone RTT / TTY capabilities to provide productive, modern experiences for all.

The Existing

The TeleTYpewriter (TTY) was introduced in the 1960s as a way for those that are hard of hearing or speech impaired to communicate via live text messages. Users at either end plug a TTY machine into the line and their text is converted to and from morse code style tones. This technology went on for far too long without innovation until 2017 when iOS and Android both introduced this functionality to their smartphone operating systems. The smartphone version of this technology is often referred to as Real-Time Texting (RTT). However, nowadays the terms RTT and TTY are regularly used interchangeably as the underlying technology of morse code style tones has remained the same.

Physical TTY Machine

The current standard for intercoms is that they provide a headphone jack which allows Guests & Residents to use the machines founded in the 60s to converse. Unfortunately, these machines are not only old but large and expensive. With the incorporation of RTT to smartphones, it is completely unnecessary to expect an entire set of people to constantly lug these machines around.

The New

iOS RTT Interface

With the Latch Intercom, we recognized that there is an opportunity to go beyond simple compliance in order to create a truly useful experience for those that are hard of hearing or speech impaired. It is important to note that there are two major actors in an intercom exchange: the Guest using the intercom and the Resident being contacted by the Guest. The Guest is trying to call a specific Resident in order to verify his/her/their identity and the Resident decides whether or not to permit entry.

Here is what we did with the Latch Intercom:

• Guests that desire to use our Accessibility mode can press and hold the left button for 5 seconds. This is signaled to the Guest both via text and a braille plate.
• Once Accessibility mode is triggered, we display a number to which the Guest at the Intercom can choose to call. It is important to note that the displayed number is NOT the Resident’s phone number but rather a Latch owned phone number that will host a group call.

• If the Guest is hard of sight but otherwise able, then they may proceed without calling the number and our Text-to-Speech interface will carry on reading instructions aloud. If the Guest is hard of hearing or speech impaired then they may call this number and be placed into a call with the Latch Intercom.
• From here the Guest will receive a text message in their RTT interface instructing them to select a Resident (pictured to the left).
• Once selected, the Resident will be called, and upon answering be placed into a group call with the Guest. We play a short, spoken message to the Resident informing them that the caller is expecting them to use their phone’s RTT interface.
• When the Resident is connected, we stream an RTT/TTY message to the group call stating that all parties are connected.
• Now the Guest and Resident can successfully converse via RTT. Neither party requires a TTY machine. If the Resident trusts the Guest then they can press 9 to trigger the unlock.

The Technical

For the purposes of this article, we will stay at a high-level so that this framework can help those using any calling partner/implementation. For the web-hooks, response bodies won’t be specified as that would be implementation-specific, but the flow charts will provide definitive logical steps.

Dynamic Number Allocation

The number shown by the Latch Intercom has to be known by our Backend in order to route the Guest and Resident into the correct conversation. Naturally, a one number per intercom model AKA static allocation comes to mind first. However, given the less frequent nature of Accessibility calls, this would be cost-ineffective. Thus we’ve developed a dynamic number allocation system. Intercoms request a number from the Backend when they need it and free the number when it is no longer in use. With dynamic allocation, we are able to scale up or down the number pool in order to meet the demand seen in the field. Here is the logic around the endpoint which allocates this number:

GET /accessibility

Flow Chart:

Latch Accessibility Number Allocation

Expiring stale allocations could be designed to happen outside of this endpoint, but we prefer to do that here in order to maximize the chances of having a free number available. At the current scale, this is possible without being overly time-consuming. Another potential improvement is instead of returning a 4XX error when there aren’t any numbers available, we could actually buy a number here. Otherwise, the logic is straightforward.

We also expose an endpoint where intercoms can explicitly free numbers themselves. The intercom hits this endpoint if Accessibility mode expires or is canceled without a call. The logic here is just the freeing of any number that is allocated to the intercom thus no flow chart is necessary. On top of this, for any call termination events, we check if the Intercom has an Accessibility number allocated. If it does, we end that allocation thus freeing the number. That sums up how our dynamic number allocation works, but we still need to discuss how all the actors are placed into a group call.

Web-Hooks

At Latch, we use a web-hook model with our calling partner in order to dictate the flow of all calls. This model seems standard across many communication APIs. We leverage this framework to place the Guest, Latch Intercom, and Resident all in the same call. We have two web-hooks with our calling partner: the answer-hook and the events-hook. The answer-hook provides our partner with all the control information necessary at the time the Latch Intercom places a call or a Latch-owned virtual number is called. The events-hook is where our partner sends informative events about the status of the call. This second hook is necessary to determine when we stream RTT messages into the conversation in order to guide our Guest and Resident. Let’s get into the general logic for each:

Answer Hook — POST /answer

Request Body:

• Source: Who is calling?
• Target: Who is being called?

Flow Chart:

Latch Answer Hook

In yellow is the path which directs the Guest into the call. In red is the path which directs the Intercom into the call and invites the Resident. In blue is the non-accessibility path.

Events Hook — POST /event

Request Body:

• Source: Who is the caller for the leg of the call to which this event relates?
• Target: Who is the callee for the leg of the call to which this event relates?
• Status: What is the status of the call leg?

Flow Chart for events with Connected Status:

Latch Events Hook

With the general logic outlined above, any company should be able to set up group RTT / TTY calling from an IP-based intercom. Any calling service or implementation should provide the methods needed to execute the call control needed. Some in-house work will be needed around owning/allocating Accessibility numbers and tracking Accessibility calls, but hopefully, this article makes that process clearer. This feature is currently live at every Latch Intercom but we hope to see versions of it at every intercom in the world. This is a great opportunity to serve our hard of hearing and speech impaired communities! As always, we are open to feedback and potential improvements. Please do not be afraid to comment or reach out.