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 negotiates. 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 possible. 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 RUM.