Relay User Machine

Document Charter Relay User Machine WG (rum)
Title Relay User Machine
Last updated 2019-04-12
State Approved
WG State Active
IESG Responsible AD Adam Roach
Charter Edit AD Adam Roach
Send notices to (None)


Many current instances of Video Relay Service (VRS), sometimes called
Video Interpretation Service, use the Session Initiation Protocol (SIP) and
other IETF multimedia protocols. VRS is used by deaf/hard-of-hearing persons
and by persons with speech impairments to communicate with hearing persons. 
The deaf, hard-of-hearing, or speech-impaired person (D-HOH-SI) uses a
SIP-based video phone to connect with an interpreter, and the interpreter
places a phone call to the hearing person. The hearing person can also reach
D-HOH-SI individuals in the same manner as calling any hearing user.  The
D-HOH-SI person uses sign language and possibly real-time text with the
interpreter and the interpreter uses spoken language with the hearing person,
providing on-line, real-time, two-way communication.

Having a standard interface between the end-user device and the VRS provider
allows vendors and open-source developers to build devices that work with
multiple service providers; devices can also be retained when changing
providers.  In this instance, “device” could be a purpose-built videophone or
could be downloadable software on a general purpose computing platform or
mobile phone. To ensure interoperability of the key features of this service,
certain aspects (e.g., codecs, media transport, addressing and SIP features)
must be specified as mandatory-to-implement for SIP-based VRS devices. These
specified features effectively form a profile for SIP and the media it

This working group will produce a single document: a profile of SIP and media
features for use with video relay services (which includes video, real time
text, and audio), and other similar interpretation services that require
multimedia.  It will reference the IETF’s current thinking on multimedia
communication, including references to work beyond SIP (e.g., WebRTC and SLIM).
The profile will require best-practice security mechanisms for SIP-based end
devices. The working group will consider issues related to authentication of
the parties involved in the video relay call. No protocol changes are
anticipated by this work.

Often, the hearing user is on the PSTN, and RUM will include interoperability
specifications for that use, including the use of telephone numbers.  RUM will
not assume hearing users are on the PSTN.

While WebRTC could be used to implement a profile to fulfill RUM's
requirements, the group’s work will focus on the device-to-provider interface. 
The working group will consider ways for WebRTC based services to interwork
with a RUM-compliant provider, but is not required to make such interwork

RUM devices will be expected to be able to place emergency calls conforming to
the current IETF emergency call recommendations.

The scope of the work includes mechanisms to provision the user’s device with
common features such as speed dial lists, provider to contact, videomail
service interface point and similar items.  These features allow users to more
easily switch providers temporarily (a feature known as “dial around”) or
permanently, while retaining their data.

Devices used in VRS can be used to place point-to-point calls where both
communicating parties use sign language.  When used for point-to-point calling
where the participants are not served by the same VRS provider, or when one
provider provides the originating multimedia transport environment, but another
provides the interpreter (“dial-around call”), the call traverses two
providers.  Both of these uses impose additional requirements on a RUM device
and are in scope for this work.

Although the interface between providers also requires standardization to
enable multi-provider point-to-point and dial-around calls, that  interface has
already been defined in a SIP Forum document and is thus out of scope for