| Internet-Draft | Relay User Equipment Profile | August 2021 |
| Rosen | Expires 27 February 2022 | [Page] |
Video Relay Service (VRS) is a term used to describe a method by which a hearing persons can communicate with deaf/Hard of Hearing user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be supplied by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other deaf/HoH users. It is desirable that the videophones used by the deaf/HoH/H-I user conform to a standard so that any device may be used with any provider and that video calls direct between deaf/HoH users work. This document describes the interface between a videophone and a provider.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 February 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Video Relay Service (VRS) is a form of Telecommunications Relay Service (TRS) that enables persons with hearing disabilities who use sign language, such as American Sign Language (ASL), to communicate with voice telephone users through video equipment. These services also enable communication between such individuals directly in suitable modalities, including any combination of sign language via video, real-time text (RTT), and speech.¶
This Interoperability Profile for Relay User Equipment (RUE) is a profile of the Session Initiation Protocol (SIP) and related media protocols that enables end-user equipment registration and calling for VRS calls. It specifies the minimal set of call flows, Internet Engineering Task Force (IETF) and ITU-T standards that must be supported, provides guidance where the standards leave multiple implementation options, and specifies minimal and extended capabilities for RUE calls.¶
Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/HoH calls are supported on this interface. While there are some accommodations in this document to maximize backwards compatibility with other devices and services that are used to provide VRS service, backwards compatibility is not a requirement, and some interwork may be required to allow direct video calls to older devices. This document only describes the interface between the device and the provider, and not any other interface the provider may have.¶
Communication Assistant (CA): A sign-language interpreter working for a VRS Provider, providing functionally equivalent phone service.¶
Communication modality (modality): A specific form of communication that may be employed by two users, e.g., English voice, Spanish voice, American Sign Language, English lip-reading, or French real-time-text. Here, one communication modality is assumed to encompass both the language and the way that language is exchanged. For example, English voice and French voice are two different communication modalities.¶
Default video relay service: The video relay service operated by a subscriber's default VRS provider.¶
Default video relay service Provider (Default Provider): The VRS provider that registers, and assigns a telephone number to a specific subscriber, and by default provides the VRS for incoming voice calls to the user. The default Provider also by default provides VRS for outgoing relay calls. The user can have more than one telephone number and each has a default provider.¶
Outbound Dial-around call: A relay call where the subscriber specifies the use of a VRS provider other than the default VRS provider. This can be accomplished by the user dialing a "front-door" number for a VRS provider and signing or texting a phone number to call ("two-stage"). Alternatively, this can be accomplished by the user's RUE software instructing the server of its default VRS provider to automatically route the call through the alternate Provider to the desired public switched telephone network (PSTN) directory number ("one-stage"). Dial-around is per-call -- for any call, a user can use the default VRS provider or any dial-around VRS provider.¶
Full Intra Request (FIR): A request to a video media sender, requiring that media sender to send a Decoder Refresh Point at the earliest opportunity. FIR is sometimes known as "instantaneous decoder refresh request", "video fast update request", or "fast update request". Point-to-Point Call (P2P Call): A call between two RUEs, without including a CA.¶
Relay call: A call that allows persons with hearing or speech disabilities to use a RUE to talk to users of traditional voice services with the aid of a communication assistant (CA) to relay the communication. Please refer to FCC-VRS-GUIDE.¶
Relay service (RS): A service that allow a registered subscriber to use a RUE to make and receive relay calls, point-to-point calls, and relay-to-relay calls. The functions provided by the relay service include the provision of media links supporting the communication modalities used by the caller and callee, and user registration and validation, authentication, authorization, automatic call distributor (ACD) platform functions, routing (including emergency call routing), call setup, mapping, call features (such as call forwarding and video mail), and assignment of CAs to relay calls.¶
Relay service Provider (Provider): An organization that operates a relay service. A subscriber selects a relay service Provider to assign and register a telephone number for their use, to register with for receipt of incoming calls, and to provide the default service for outgoing calls.¶
Relay user: Please refer to "subscriber".¶
Relay user E.164 Number (user E.164): The telephone number (in ITU-T E.164 format) assigned to the user.¶
Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra features to support a subscriber in requesting, receiving and using relay calls. A RUE may take many forms, including a stand-alone device; an application running on a general-purpose computing device such as a laptop, tablet or smart phone; or proprietary equipment connected to a server that provides the RUE interface.¶
RUE Interface: the interfaces described in this document between a RUE and a VRS provider who supports it¶
Sign language: A language that uses hand gestures and body language to convey meaning including, but not limited to, American Sign Language (ASL).¶
Subscriber: An individual who has registered with a Provider and who obtains service by using relay user equipment. This is the traditional telecom term for an end-user customer, which in our case is a relay user. A user may be a subscriber to more than one VRS provider.¶
Video relay service (VRS): A relay service for people with hearing or speech disabilities who use sign language to communicate using video equipment (video RUE) with other people in real time. The video link allows the CA to view and interpret the subscriber's signed conversation and relay the conversation back and forth with the other party.¶
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]¶
All HTTP/HTTPS connections specified throughout this document MUST use HTTPS. Both HTTPS and all SIP connections MUST use TLS conforming to at least [RFC7525] and must support [RFC8446]¶
All text data payloads not otherwise constrained by a specification in another standards document MUST be encoded as Unicode UTF/8.¶
Implementations MUST support IPv4 and IPv6. Dual stack support is NOT required and provider implementations MAY support separate interfaces for IPv4 and IPv6 by having more than one server in the appropriate SRV record where there is either an A or AAAA record in each server DNS record but not both. The same version of IP MUST be used for both signaling and media of a call unless ICE ([RFC5245]) is used, in which case candidates may explicitly offer IPv4, IPv6 or both for any media stream.¶
Implementations of the RUE Interface MUST conform to the following core SIP standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent Capabilities), [RFC5626] (Outbound), [RFC8866] (Session Description Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP), [RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop-Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960] (Early Media), and [RFC6442] (Geolocation Header).¶
In the above documents the RUE device conforms to the requirements of a SIP user Agent, and the provider conforms to the requirements of Registrar and Proxy Server where the document specifies different behavior for different roles. The only requirement on providers for RFC6655 (Events) is support for the Message Waiting Indicator (See Section Section 8), which is optional and providers not supporting voicemail need not support RFC6665.¶
In addition, implementation MUST conform to [RFC3327] (Path), [RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER Method), [RFC3891] (Replaces Header), [RFC3892] (Referred-By).¶
Implementations MUST include a "User-Agent" header field uniquely identifying the RUE application, platform, and version in all SIP requests, and MUST include a "Server" header field with the same content in SIP responses.¶
Implementations intended to support mobile platforms MUST support [RFC8599] and MUST use it as at least one way to support waking up the client from background state.¶
The RUE MUST register with a SIP registrar, following [RFC3261] and [RFC5626] at a provider it has an account with. If the configuration (see Section 9.2) contains multiple "outbound-proxies", then the RUE MUST use them as specified in [RFC5626] to establish multiple flows.¶
The request-URI for the REGISTER request MUST contain the "provider-domain" from the configuration. The To-URI and From-URI MUST be identical URIs, formatted as specified in Section 13, using the "phone-number" and "provider-domain" from the configuration.¶
The RUE determines the URI to resolve by initially determining if an outbound proxy is configured. If it is, the URI will be that of the outbound proxy. If no outbound proxy is configured, the URI will be the Request-URI from the REGISTER request. The RUE extracts the domain from that URI and consults the DNS record for that domain. The DNS entry MUST contain NAPTR records conforming to RFC3263. One of those NAPTR records MUST specify TLS as the preferred transport for SIP. For example, a DNS NAPTR query for "sip: p1.red.example.netv" could return:¶
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net
¶
If the RUE receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it MUST re-attempt registration without using the outbound mechanism.¶
The registrar MAY authenticate using SIP digest authentication. The credentials to be used (username and password) MUST be supplied within the credentials section of the configuration and identified by the realm the registrar uses in a digest challenge. This username/password combination SHOULD NOT be the same as that used for other purposes, such as retrieving the RUE configuration or logging into the Provider's customer service portal. [RFC8760] MUST be supported by all implementations and SHA-512 digest algorithms MUST be supported.¶
If the registration request fails with an indication that credentials from the configuration are invalid, then the RUE SHOULD retrieve a fresh version of the configuration. If credentials from a freshly retrieved configuration are found to be invalid, then the RUE MUST cease attempts to register and SHOULD inform the RUE User of the problem.¶
Support for multiple simultaneous registrations with multiple providers by the RUE is OPTIONAL for the RUE (and providers do not need any support for this option).¶
Multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI SHOULD be permitted by the Provider. The Provider MAY limit the total number of simultaneous registrations. When a new registration request is received that results in exceeding the limit on simultaneous registrations, the Provider MAY then prematurely terminate another registration; however, it SHOULD NOT do this if it would disconnect an active call.¶
If a Provider prematurely terminates a registration to reduce the total number of concurrent registrations with the same URI, it SHOULD take some action to prevent the affected RUE from automatically re-registering and re-triggering the condition.¶
After initial SIP registration, the RUE adheres to SIP [RFC3261] basic call flows, as documented in [RFC3665].¶
A RUE device MUST route all outbound calls through an outbound proxy if configured.¶
The SIP URIs in the To field and the Request-URI MUST be formatted as specified in subsection Section 5.4 using the destination phone number, or as SIP URIs, as provided in the configuration (Section 9.2. The domain field of the URIs SHOULD be the "provider-domain" from the configuration (e.g., sip:+13115552368@red.example.com;user=phone) except that an anonymous call would not use the provider domain.¶
Anonymous calls MUST be supported by all implementations. An anonymous call is signaled per [RFC3323].¶
The From-URI MUST be formatted as specified in Section 5.4, using the phone-number and "provider-domain" from the configuration. It SHOULD also contain the display-name from the configuration when present. (Please refer to Section 9.2.)¶
Negotiated media MUST follow the guidelines specified in Section 6 of this document.¶
To allow time to timeout an unanswered call and direct it to a videomail server, the User Agent Client MUST NOT impose a time limit less than the default SIP Invite transaction timeout of 3 minutes.¶
Providers and RUE devices MUST support both One-Stage and Two-Stage dial-around¶
Outbound dial-around calls allow a RUE user to select any Provider to provide interpreting services for any call. "Two-stage" dial-around calls involve the RUE calling a telephone number that reaches the dial-around Provider and using signing or DTMF to provide the called party telephone number. In two-stage dial-around, the To URI is the front door URI (see Section Section 9.2 of the dial-around Provider and the domain of the URI is the Provider domain from the configuration. The provider list service (Section 9.1) can be used to by the RUE to obtain a list of providers and then the configuration service (xref target="providerConfig"/>) without credentials can be used to find the front door URI for each of these providers.¶
One-stage dial-around is a method where the called party telephone number is provided in the To URI and the Request-URI, using the domain of the dial-around Provider.¶
For one-stage dial-around, the RUE MUST follow the procedures in Section 5.2.1 with the following exception: the domain part of the SIP URIs in the To field and the Request-URI MUST be the domain of the dial-around Provider, discovered according to Section 9.1.¶
The following is a partial example of a one-stage dial-around call from VRS user +1-555-222-0001 hosted by red.example.com to a hearing user +1-555-123-4567 using dial-around to green.example.com for the relay service. Only important details of the messages are shown and many header fields have been omitted:¶
,-+-. ,----+----. ,-----+-----.
|RUE| |Default | |Dial-Around|
| | |Provider | | Provider |
`-+-' `----+----' `-----+-----'
| | |
| [1] INVITE | |
|-------------->| [2] INVITE |
| |-------------->|
Message Details:
[1] INVITE Rue -> Default Provider
INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" <sip:+18135551212@red.example.net;user=phone>
[2] INVITE Default Provider -> Dial-Around Provider
INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" sip:+18135551212@red.example.net;user=phone
P-Asserted-Identity: sip:+18135551212@red.example.net
To identify the owner of a RUE, the initial INVITE for a call from a RUE, or the 200 OK accepting a call by a RUE, identifies the owner by sending a Call-Info header with a purpose parameter of "rue-owner". The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is defined by [RFC2392] to locate message body parts. This URI type is present in a SIP message to convey the RUE ownership information as a MIME body. The form of the RUE ownership information is a xCard [RFC6351]. for an example of using Content-Indirect URLs in SIP messages. Note that use of the Content-Indirect URL usually implies multiple message bodies ("mime/multipart").¶
The RUE MUST only accept inbound calls sent to it by a proxy mentioned in the configuration.¶
If Multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI exist, the Provider MUST parallel fork the call to all registered RUEs so that they ring at the same time. The first RUE to reply with a 200 OK answers the call and the Provider MUST CANCEL other call branches.¶
Implementations MUST conform to [RFC6881] for handling of emergency calls, except that if the device is unable to determine its own location, it MAY send the emergency call without a Geolocation header and without a Route header (since it would be unable to query the LoST server for a route per RFC6881). If an emergency call arrives at the provider without a Geolocation header, the provider MUST supply location by adding the Geolocation header, and MUST supply the route by querying the LoST server with that location.¶
If the emergency call is to be handled using existing country specific procedures, the Provider is responsible for modifying the INVITE to conform to the country-specific requirements. In this case, location MAY be extracted from the RFC6881 conformant INVITE and used to propagate it to the appropriate country-specific entities. Because the RUE may have a more accurate and timely location of the device than the a manual entry location for nomadic RUE devices, but country-specific procedures require the location to be pre-loaded in some entity prior to placing an emergency call, implementations of a RUE device MAY send a Geolocation header containing its location in the REGISTER request if the configuration specifies it. That information MAY be used to populate the location to appropriate country-specific entities. Re-registration SHOULD be used to update the location, so long as the rate of re-registration is limited if the device is moving.¶
Implementations MUST implement Additional Data, [RFC7852]. RUE devices MUST implement Data Provider, Device Implementation and Owner/Subscriber Information blocks.¶
Implementations MUST support re-INVITE to renegotiate media session parameters (among other uses). Per Section 6.1, implementations MUST, be able to support an INFO request for full frame refresh for devices that do not support RTCP mechanisms (please refer to Section 6.8). Implementations MUST support an in-dialog REFER ([RFC3515] updated by [RFC7647] and including support for norefersub per [RFC4488]) with the Replaces header [RFC3891] to enable call transfer.¶
SIP URIs constructed from non-URI sources (dial strings) and sent to SIP proxies by the RUE MUST be represented as follows, depending on whether they can be represented as an E.164 number. In this section "expressed as an E.164 number" includes numbers such as toll free numbers that are not actually E.164 numbers, but have the same format.¶
A dial string that can be expressed as an E.164 phone number MUST be represented as a SIP URI with a URI ";user=phone" tag. The user part of the URI MUST be in conformance with 'global-number' defined in [RFC3966]. The user part MUST NOT contain any 'visual-separator' characters.¶
Dial strings that cannot be expressed as E.164 numbers MUST be represented as dialstring URIs, as specified by [RFC4967], e.g., sip:411@red.example.net;user=dialstring.¶
The domain part of Relay Service URIs and User Address of Records (AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or IPv6 addresses.¶
Implementations MUST conform to [RFC8835] except that that this specification does not use the WebRTC data channel. See Section Section 6.2 for how RUE supports real time text without the data channel.¶
Implementations MUST support SIP outbound [RFC5626] (please also refer to Section 5.1).¶
This specification adopts the media specifications for WebRTC ([RFC8825]). Where WebRTC defines how interactive media communications may be established using a browser as a client, this specification assumes a normal SIP call. The RTP, RTCP, SDP and specific media requirements specified for WebRTC are adopted for this document. The RUE is a WebRTC non-browser" endpoint, except as noted expressly below.¶
The following sections specify the WebRTC documents to which conformance is required. "Mandatory to Implement" means a conforming implementation must implement the specified capability. It does not mean that the capability must be used in every session. For example, OPUS is a mandatory to implement audio codec, and all conforming implementations must support OPUS. However, implementation presenting a call across the RUE Interface where the call originates in the Public Switched Telephone Network, or an older, non-RUE-compatible device, which only offers G.711 audio, does not need to include the OPUS codec in the offer, since it cannot be used with that call.¶
Implementations MUST support [RFC8834] except that MediaStreamTracks are not used. Implementations MUST conform to Section 6.4 of [RFC8827].¶
Implementations MUST support real-time text ([RFC4102] and [RFC4103]) via T.140 media. One original and two redundant generations MUST be transmitted and supported, with a 300 ms transmission interval. Note that this is not how real time text is transmitted in WebRTC and some form of transcoder would be required to interwork real time text in the data channel of WebRTC to RFC4103 real time text.¶
Implementations MUST conform to [RFC7742] with the exception that, since backwards compatibility is desirable and older devices do not support VP8, that only H.264, as specified in [RFC7742] is Mandatory to Implement and VP8 support is OPTIONAL at both the device and providers.¶
Implementations MUST support the "audio/telephone-event" [RFC4733] media type. They MUST support conveying event codes 0 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. Handling of other tones is OPTIONAL.¶
The SDP offers and answers MUST conform to the SDP rules in [RFC8829] except that the RUE Interface uses SIP transport for SDP and the SDP for real time text MUST specify [RFC4103].¶
The RUE MUST be able to control privacy of the user by implementing a one-way mute of audio and or video, without signaling, locally, but MUST maintain any NAT bindings by periodically sending media packets on all active media sessions containing silence/comfort noise/black screen/etc. per [RFC6263].¶
NACK SHOULD be used when negotiated and conditions warrant its use. Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be preferred, as described in [RFC5104].¶
FIR SHOULD be used only in situations where not sending a decoder refresh point would render the video unusable for the users, as per RFC5104 subsection 4.3.1.2.¶
For backwards compatibility with calling devices that do not support the foregoing methods, implementations MUST implement SIP INFO messages to send and receive XML encoded Picture Fast Update messages according to [RFC5168].¶
Support of CardDAV by Providers is OPTIONAL.¶
The RUE MUST and Providers MAY be able to synchronize the user's contact directory between the RUE endpoint and one maintained by the user's VRS provider using CardDAV ([RFC6352] and [RFC6764]).¶
The configuration MAY supply a username and domain identifying a CardDAV server and address book for this account.¶
To access the CardDAV server and address book, the RUE MUST follow Section 6 of RFC6764, using the chosen username and domain in place of an email address. If the request triggers a challenge for digest authentication credentials, the RUE MUST attempt to continue using matching "credentials" from the configuration. If no matching credentials are configured, the RUE MUST use the SIP credentials from the configuration. If the SIP credentials fail, the RUE MUST query the user.¶
Synchronization using CardDAV MUST be a two-way synchronization service, with proper handling of asynchronous adds, changes, and deletes at either end of the transport channel.¶
Implementations MUST be able to export/import the list of contacts in jCard [RFC6351] json format.¶
The RUE accesses this service via the "contacts" URI in the configuration. The URL MUST resolve to identify a web server resource that imports/exports contact lists for authorized users.¶
The RUE stores/retrieves the contact list (address book) by issuing an HTTPS POST or GET request. If the request triggers a challenge for digest authentication credentials, the RUE MUST attempt to continue using matching "credentials" from the configuration. If no credentials are configured, the RUE MUST query the user.¶
Providers MUST support MWI if they support video mail. RUE devices MUST support MWI.¶
Implementations MUST support subscriptions to "message-summary" events [RFC3842] to the URI specified in the configuration.¶
In notification bodies, videomail messages SHOULD be reported using "message-context-class multimedia-message" defined in [RFC3458].¶
To simplify how users interact with RUE devices, the RUE interface separates provisioning into two parts. One provides a directory of providers so that a user interface that allows easy provider selection either for registering or for dial-around. The other provides configuration data for the device for each provider.¶
To allow the user to select a relay service, the RUE MAY at any time obtain (typically on startup) a list of Providers that provide service in a country. IANA has established a registry that contains a two letter country code and a URI. The URI, when used with the following interface, returns a list of provider names for a country code suitable for display, with a corresponding a URI to obtain information about that provider. The provider URI is the entry point of a simple web service that returns contact information for that provider.¶
Each country that supports video relay service using this specification MAY support the provider list. This document does not specify who maintains the list. Some possibilities are a regulator or entity designated by a regulator, an agreement among providers to provide the list, or a user group.¶
The web service also has a simple version mechanism that returns a list of versions of the web service it supports. This document describes version 1.0. Versions are described as a major version, the period "." and a minor version, where major and minor versions are integers. A backwards compatible change within a major version MAY increment only the minor version number. A non-backwards compatible change MUST increment the major version number. To achieve backwards compatibility, implementations MUST ignore any object members they do not implement and minor version definitions SHALL only add objects, non-required members of existing objects, and non-mandatory-to use functions and SHALL NOT delete any objects, members of objects or functions. This means an implementation of a specific major version and minor version is backwards compatible with all minor versions of the major version. The versions mechanism returns an array of supported versions, one for each major version supported, with the minor version listed being the highest supported minor version.¶
The V1 provider list is a json object consisting of an array where each entry describes one Provider. Each entry consists of the following items:¶
The VRS user interacts with the RUE to select from the Provider list one or more Providers with whom the user has already established an account, wishes to establish an account, or wishes to use the provider for a one stage dial around.¶
{
"providers": [
{
"name": "Red",
"domain": "red.example.net",
},
{
"name": "Green",
"domain": "green.example.net",
},
{
"name": "Blue",
"domain": "blue.example.net"
}
]
}
{
"versions": [
{
"major": 1,
"minor": 6,
},
{
"major": 2,
"minor": 13,
},
{
"major": 3,
"minor": 2
}
]
}
A RUE device may retrieve a provider configuration the using a simple HTTPs web service. There are two entry points. One is used without user credentials, the response includes configuration data for new user sign up and dial around. The other uses the userid/password to authenticate to the interface and returns configuration data for the RUE.¶
An optional parameter may be provided to the interface which is an API Key. The implementation MAY have an API Key obtained from the provider and specific to the implementation. The method the API Key is obtained is not specified in this document. The provider MAY refuse to provide service to an implementation presenting an API Key it does not recognize.¶
A required parameter which contains an instance identifier. This parameter MUST be the same value each time this instance (same implementation on same device) queries the interface. This may be used by the provider, for example, to associate a location with the instance for emergency calls.¶
The data returned is a json object consisting of an array of key/value configuration parameters to be used by the RUE.¶
The configuration API also provides the same version mechanism as specified above in Section 9.1. The version of the configuration service MAY be different than the version of the provider list service.¶
The configuration data payload includes the following data items. Items not noted as (OPTIONAL) are REQUIRED. If other unexpected items are found, they MUST be ignored.¶
signup: (OPTIONAL) an array of json objects consisting of:¶
dialAround: an array of json objects consisting of:¶
helpDesk: (OPTIONAL) an array of json objets consisting of:¶
{
"signUp": [
{ "language" : "en", "uri" : "welcome-en.example.net"} ,
{ "language" : "es", "uri" : "welcome-es.example.net"} ] ,
"dialAround": [
{ "language" : "en", "frontDoor" : "fd-en.example.net",
"oneStage" : "1stg-eng.example.com" } ,
{ "language" : "es", "frontDoor" : "fd-es.example.net",
"oneStage" : "1stg-spn.example.com" } ] ,
"helpDesk": [
{ "language" : "en", "uri" : "help-en.example.net"} ,
{ "language" : "es", "uri" : "help-es.example.net"} ] ,
{
"lifetime": 86400,
"display-name" : "Bob Smith",
"phone-number": "+18135551212",
"provider-domain": "red.example.net",
"outbound-proxies": [
"sip:p1.red.example.net",
"sip:p2.red.example.net"
],
"mwi": "sip:+18135551212@red.example.net",
"videomail": "sip:+18135551212@vm.red.example.net",
"contacts": "https://red.example.net:443/contacts/1dess45awd",
"carddav": "bob@red.example.com" ,
"sendLocationWithRegistration": false,
"ice-servers": [
{"stun":"stun.l.google.com:19302" },
{"turn":"turn.red.example.net:3478"}
],
}
One way to use these two services is:¶
The interfaces in Sections Section 9.1 and Section 9.2 are formally specified with OpenAPI 3.0 descriptions in yaml form.¶
openapi: 3.0.1
info:
title: RUM API
version: "1.0"
servers:
- url: http://localhost/rum/v1
paths:
/Providers:
get:
summary: Get a list of providers and domains to get
config data from
operationId: GetProviderList
responses:
'200':
description: List of providers for a country
content:
application/json:
schema:
$ref: '#/components/schemas/ProviderList'
/ProviderConfig:
get:
summary: Configuration data for one provider
operationId: GetProviderConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: configuration object
content:
application/json:
schema:
$ref: '#/components/schemas/ProviderConfigurationData'
/RueConfig:
get:
summary: Configuration data for one RUE
operationId: GetRueConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: configuration object
content:
application/json:
schema:
$ref: '#/components/schemas/RueConfigurationData'
/Versions:
servers:
- url: https://api.example.com/rum
description: Override base path for Versions query
get:
summary: Retrieves all supported versions
operationId: RetrieveVersions
responses:
'200':
description: Versions supported
content:
application/json:
schema:
$ref: '#/components/schemas/VersionsArray'
components:
schemas:
ProviderList:
type: object
required:
- providers
properties:
providers:
type: array
items:
type: object
required:
- name
- domain
properties:
name:
type: string
description: Human readable provider name
domain:
type: string
description: provider domain for interface
VersionsArray:
type: object
required:
- versions
properties:
versions:
type: array
items:
type: object
required:
- major
- minor
properties:
major:
type: integer
format: int32
description: Version major number
minor:
type: integer
format: int32
description: Version minor number
ProviderConfigurationData:
type: object
properties:
signup:
type: object
required:
- language
- uri
properties:
language:
type: string
description: entry from IANA language-subtag-registry
uri:
type: string
format: uri
description: uri to signup website supporting language
dialAround:
type: object
required:
- language
- frontDoor
properties:
language:
type: string
description: entry from IANA language-subtag-registry
frontDoor:
type: string
format: uri
description: SIP uri for 2 stage dial around
oneStage:
type: string
format: uri
description: SIP uri for 1 stage dial around
helpDesk:
type: object
required:
- language
- uri
properties:
language:
type: string
description: entry from IANA language-subtag-registry
uri:
type: string
format: uri
description: SIP uri of helpdesk supporting language
RueConfigurationData:
type: object
properties:
lifetime:
type: integer
description: how long (in seconds) the RUE MAY cache the
configuration values
sip-password:
type: string
phone-number:
type: string
description: telephone number assigned this subscriber
outbound-proxy:
type: string
format: uri
description: SIP uri of proxy to be used when sending
requests to the Provider
mwi:
type: string
format: uri
description: A URI identifying a SIP event server that
generates "message-summary" events for this subscriber.
videomail:
type: string
format: uri
description: A SIP URI that can be called to retrieve
videomail messages.
contacts:
type: string
format: uri
description: An HTTPS URI that may be used to export
(retrieve) the subscriber's complete contact list
managed by the Provider.
carddav:
type: object
description: CardDAV server and user information that can be
used to synchronize the RUE's contact list with the
contact list managed by the Provider.
properties:
domain:
type: string
description: CardDAV server address
username:
type: string
description: username for authentication with CardDAV
server. Use provider username if not provided
password:
type: string
description: password for authentication to the CardDAV
server. Use provider password if not provided
sendLocationWithRegistration:
type: boolean
description: True if the RUE should send a Geolocation Header
with REGISTER, false if it should not.
Defaults to false if not present.
ice-servers:
type: array
items:
type: string
format: uri
description: URIs identifying STUN and TURN servers
available for use by the RUE for establishing
media streams in calls via the Provider.
Brett Henderson and Jim Malloy provided many helpful edits to prior versions of this document.¶
IANA has created the "RUE Provider List" registry. The management policy for this registry is "Expert Review" [RFC8126]. The expert should prefer a regulator operated or designated list interface operator. Otherwise, evidence that the proposed list interface operator will provide a complete list of providers is required to add the entry to the registry. Updates to the registry are permitted if the expert judges the new proposed uri to be better than the existing entry. Each entry has two fields, values for both of which MUST be provided when registering or updating an entry:¶
This document defines the new predefined value "rue-owner" for the "purpose" header field parameter of the Call-Info header field. This modifies the "Header Field Parameters and Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry by adding this RFC as a reference to the line for the header field "Call-Info" and parameter name "purpose"¶
The RUE is required to communicate with servers on public IP addresses and specific ports to perform its required functions. If it is necessary for the RUE to function on a corporate or other network that operates a default-deny firewall between the RUE and these services, the user must arrange with their network manager for passage of traffic through such a firewall in accordance with the protocols and associated SRV records as exposed by the Provider. Because VRS providers may use different ports for different services, these port numbers may differ from Provider to Provider.¶