Mailing list: email@example.com [Subscribe] [Archive]
SIP Forum Technical Working Group Director: Spencer Dawkins – firstname.lastname@example.org (Huawei)
Task Group Co-Chairs: Gunnar Hellstrom – email@example.com (Omnitor); Brian Rosen – Brian.Rosen@neustar.biz (NeuStar)
Task Group Chief Document Editor: Paul Kyzivat – firstname.lastname@example.org
Meetings: Meetings take place on a schedule established by the task group. You can stay informed about upcoming meetings by subscribing to the vrs email list (see link above).
Background and Overview
Relay Services enable persons with communication related disabilities to communicate with other persons using other communication modalities. This document presents the SIP Forum Video Relay Service Task Group’s plan of action for developing, as its primary purpose, standards recommendations to achieve interoperability among sign relay service endpoints and relay services.
Sign Relay Service
Sign Relay Service is a form of Relay Service that enables deaf and hearing impaired persons who use Sign Language to communicate with hearing voice telephone users. Sign Relay Services are also often called Video Relay Services (VRS). A video communications session connects the relay service user with a sign language interpreter, enabling the relay service user and the interpreter to communicate in sign language. The interpreter relays the relay service user’s signed conversation as a voice conversation with a voice telephony user. The video communications between the relay service user and the interpreter may be supplemented by the user’s voice (e.g., for relay service users who can speak but cannot hear) and by real-time text (e.g., for deafblind users or to facilitate communicating otherwise cumbersome detail).
Relay Services in General
Other forms of relay services are deafblind relay services, text relay services (including traditional PSTN Text telephone service (e.g. TTY in North America) and IP relay service), captioned telephony relay services and speech-to-speech relay services. The legal basis for the relay services lies in various national laws .
In some cases, the call leg described above as going to a hearing person with a voice phone may also have multimedia capabilities.
Relay Service Users
The relay service user may be a communication user of a mainstream multimedia communication service provider, registered with a communication service provider specialized in accessible communication, or directly registered with a relay service provider. Relay Service users and hearing telephony users use the standard fully expressed E.164 phone number to reach each other through the Relay Service.
The system also enables deaf, hard-of-hearing, deafblind or speech disabled users to reach each other directly at their phone numbers or other address identifier in order to have a conversation in sign and text and voice as suitable for each call. This communication is referred to here as peer-to-peer calling (and is commonly known as point-to-point calling in the United States). Number translation to an address identifier for the relay service user terminal is handled through queries to a number database, in some cases based on RFC 6116 [ENUM].
The VRS providers in the United States have developed their current solutions based on H.323 and have encountered multiple interoperability issues  . Given that SIP is becoming the dominant standard for video and audio communications, it is desirable to create a new infrastructure for the VRS industry based on this protocol, and where interoperability between providers can be planned in advance. Europe is mainly using SIP and has similar needs for establishing interoperability.
There is also a desire that mainstream off-the-shelf terminals or software registered with mainstream communication service providers would be possible to use for relay service access as well as for peer-to-peer calls.
Emergency Service Access
For emergency service access, there is an additional set of requirements that need to be fulfilled.
The Resulting Need of an Interoperability Profile
A comprehensive interoperability profile for relay services based on SIP is therefore now required.
The task group will produce one or more SIP Forum recommendations that define a common set of interoperability standards for relay services using SIP communication components. These recommendations will specify which standards must be supported, provide guidance in the areas where the standards leave multiple options and supplement functional gaps in existing protocols.
The task group will not attempt to modify or define SIP technical standards as they might relate to the relay services but will document requirements that may require further standardization. Should modifications or clarifications to the existing SIP standards be warranted in order to achieve the interoperability goal the task group will fully document these new requirements and forward them to the IETF DISPATCH Working Group for further action.
Primary Objectives of the Task Group Related to Interoperability
- Develop a comprehensive requirements document that sets forth the common network elements for the relay service.
- Specify the protocols and protocols extensions that must be supported by each element in the relay service system. Specify the exact RFC or other existing standards to be used.
- Specify mandatory to implement video, audio and text codecs [MUST per RFC 2119], recommended optional codecs and which entities must support them.
- Integration with systems for calling by number from national and international number plans. E.g. ENUM [RFC 6116], including standards for URI registration.
- Interoperability with systems using other call control protocols.
- Emergency service calling for registered and unregistered User Agents (endpoints), including registration of device address with service provider.
- Recommend minimum broadband connectivity requirements.
Other Features For Investigation
- Develop credentials for both Client User Agents and Proxies in the relay service system.
- Mixing and presentation aspects for video, audio and text media.
- Incoming call alerting system.
- Visual messaging waiting feature.
- Communication of service provider name and interpreter identification.
- Indication of communication modality requirements and preferences and its use for selecting appropriate service.
- Session security.
- Relay service invocation based on user action.
- Relay service invocation based on user profile evaluation.
- Use in IMS versus native SIP.
- Specify mandatory to implement video, audio and text codecs [MUST per RFC 2119] , recommended optional codecs to support for Video/Audio/Text mail and specify which entities must support them.
- The ability of a relay service user to freely connect to any of several Relay Service providers.
- Client User Agent portability or the ability to move a Client User Agent with its assigned phone number that has been managed by one operator or relay service provider to a new operator or relay service provider.
- Import and export of user phonebooks and speed dial lists Session quality reporting and measurement.
- Initial Client User Agent configuration. The task group is encouraged to coordinate with SIP Forum Client User Agent Configuration Task Group.
- Special attention will be given to integration and support of emerging standards for IP based emergency services, e.g. specified by the ECRIT group in IETF.
- It is understood that the scope of the relay service interoperability problem may require the work to be segmented in to one or more profiles.
Goals and Timeline
The goals and timelines for published documents are as follows:
- A comprehensive SIP interoperability requirements document – February 2014, enabling:
- Relay communication between relay service users and telephony users, allowing both deaf/hearing impaired and hearing parties to place the call using their preferred relay provider.
- Point-to-point communication between deaf/hearing impaired individuals.
- Emergency service access.
- A valid collection of use cases to be enabled – February 2014.
- Combined profiles for interaction between relay service Client User Agents, operator and relay service provider network components – May 2014.
- A Client User Agent portability specification – June 2014.
- Specifications for other features identified in the charter and requirement specification but not included in the first profiles – September 2014.
Participation in the Task Group
The SIP Forum has appointed Gunnar Hellstrom, Omnitor, and Brian Rosen, NeuStar, as co-chairs for this task group to coordinate the creation of the various activities of the group. The various activities are intended to be open to all members—full, academic and participant—as determined by the Task Groups and the Working Group Chairs.
The VRS Task Group will establish various activities as required to support its activities. The specific meeting and operational schedule for each activity will be established by the chairs.
VRS Task Group Document Repository
For More Information
- REACH112 Platform specification. D3.2 from
- ETSI ES 202 975 Harmonized Relay Services, from
National and Regional Specifics
In the United States the VRS is authorized and governed by several laws including the 1996 Communications Act, as amended, The Americans for Disabilities Act [ADA] and the Twenty-First Century Communications and Video Accessibility Act [CVAA ]. Users’ ten-digit numbers are managed through the iTRS Numbering Directory, which is administered by a neutral third-party (Neustar). Emergency service access is defined by NENA in NG9-1-1 standards.
In Europe, relay services and equivalent functionality are required by the EU Directives for Electronic Communication, implemented in each member state by national law.
Group Status as of 10-29-1013
The group is since mid-June 2013 actively working with composing a requirements document. A working group draft exists and an editor, Paul Kyzivat, is working on collecting material from the mail list and ordering it in the document. The chairs both contribute with material and comments and manage the group and the progress.
While the requirements are collected, the group often enters detailed technical discussions on how to specify the technology satisfying the functional requirements. The editor is collecting these ideas that are expected to become the initial draft of a profile document in parallel with the creation of the functional requirements document.
The group’s discussions take place primarily on the email list and are often lively, representing tradeoffs among user functionality, development cost and time pressures.
Participants are from Europe and North America and include existing providers, users, technical experts and vendors. USA has some urgency in reaching the goals soon in order to match requirements from FCC Order FCC-13-82A1. The U.S. regulator has taken note of this work, has an active participant in the discussion, and is encouraging the evolution of the profile to meet the Order.