Video relay — standards, interoperability, and the all-IP vision — library

The relay-services entry covers what relay is and how it is funded. This one covers how Video Relay Service actually works over IP — and why “interoperable” has been a twenty-year project rather than a solved problem.

The interoperability problem

VRS is provided by several competing companies. A deaf user signs to a video interpreter at their provider, who voices to the hearing party. The catch is that the video, the signaling, the contact lists, and the point-to-point features were historically proprietary to each provider — so a user on one service could not smoothly reach or use another, and switching providers meant losing your setup. Solving that is what the standards below are for.

Numbering: the shared directory

The one piece that is shared is addressing. VRS users get ten-digit NANP numbers, and the routing for those numbers lives in a central iTRS Numbering Directory (47 CFR § 64.613), operated by the TRS Numbering Administrator. Each user has a “default provider” (§ 64.611) — the provider that registered them and holds their number — and calls route to that provider via the directory, except for case-by-case “dial-around” calls to other providers. So cross-provider addressing is solved in principle: there is one directory mapping numbers to routing records. What was not solved was the media and feature interoperability on top of it.

The FCC interoperability rule and its standards

47 CFR § 64.621 is the interoperability mandate: every VRS user must be able to call through any provider, no provider may degrade a competitor’s users, and — the part that has evolved most — providers’ platforms must interoperate with a VRS Access Technology Reference Platform and a Neutral Video Communication Service Platform, on pain of their minutes being non-compensable. The rule incorporates two technical standards by reference:

The US VRS Provider Interoperability Profile, authored by the SIP Forum’s VRS Task Group (the “TWG-6” profile) — the provider-to-provider and provider-to-directory interface. The FCC codified the September 2015 build; the SIP Forum has since ratified later versions (v1.0 in 2015, v2.0 in 2020), so the regulatory baseline trails the standards body’s own work.
RFC 6351 (xCard) for contact-list export.

For user equipment, the relevant standard is RFC 9248, the “Interoperability Profile for Relay User Equipment” (RUE), published by the IETF’s rum working group in 2022. RUE profiles SIP and its media protocols to specify the minimal call flows and behaviors a relay user’s device must support to register and place calls interoperably — the client-side counterpart to the SIP Forum’s provider-side profile. Notably, the RUE draft that was once referenced in the FCC rules now shows as “[Reserved]” in the current CFR, so RFC 9248 itself is not yet incorporated — another instance of the codified baseline lagging the standards.

The NANC Interoperable Video Calling work

The most ambitious attempt to generalize this beyond relay was the NANC Interoperable Video Calling (IVC) working group, chartered under the North American Numbering Council to explore voluntary, telephone-number-based interoperable video calling between ten-digit NANP numbers — the idea being that video calling (including but not limited to relay) could become a native, number-addressed capability rather than a set of walled gardens. It produced two deliverables: a Final Report in September 2019, and a second Final Report to NANC in July 2020. The effort mapped how existing SIP profiles, the numbering directory, and provider interconnection could support interoperable, number-based video — the conceptual groundwork for treating video (and relay) as a first-class service on the shared numbering plane rather than a provider silo.

Current state and the all-IP vision

Reachability across providers and point-to-point video are mandated (§ 64.621) and technically enabled by the shared directory, the SIP Forum provider profile, and RFC 9248 for user equipment. The FCC has pushed past “each silo must bridge to the others” toward a genuinely neutral, provider-agnostic platform — the VRS Access Technology Reference Platform (an open reference implementation any provider can test against) and the codified Neutral Video Communication Service Platform. That is the regulatory vehicle for a shared video fabric rather than bilateral silo-bridging, and it is still being deployed.

A fully all-IP, converged relay ecosystem would go further than interoperability between relay providers — it would fold relay into the same IMS/SIP telephone network everyone else uses. The remaining gaps are concrete: the codified standards baseline lags the current SIP Forum and IETF work; relay uses a separate iTRS numbering directory and default-provider model rather than participating natively in the carrier NANP routing and identity (STIR/SHAKEN) fabric; direct video calling and point-to-point remain hampered by legacy proprietary platforms; and video codecs, presence, and registration are not unified with mainstream IMS. Closing those is what it would take for a video-relay call — or any video call — to be just another call on the network, addressed by a telephone number, carried end to end, and reachable from anywhere. That convergence is the accessibility face of the same all-IP transition this section tracks.

The identity gap is now specific rather than general. Answering paragraphs 123 and 124 of the KYUP FNPRM on August 10, 2026, InnoCaption told the Commission that TRS providers “cannot obtain Service Provider Code (‘SPC’) tokens, as they do not meet the STIR/SHAKEN Governance Authority’s requirements to obtain a token,” and Sorenson and CaptionCall argued that VRS and IP CTS providers “perform the functions of an initiating provider” and asked that originating providers be required to recognize a certificate carrying the TRS provider’s attestation of end-user verification. Sorenson’s alternative is to expand SPC token eligibility to internet-based TRS providers. ZP Better Together tied the consequence to the statute, quoting the Notice that downstream filtering of unsigned VRS calls “disproportionately harm[s] individuals with disabilities.” The relay services entry covers the full set of filings; reply comments are due September 8, 2026.