diff options
Diffstat (limited to 'doc/rfc/rfc9248.txt')
| -rw-r--r-- | doc/rfc/rfc9248.txt | 1901 |
1 files changed, 1901 insertions, 0 deletions
diff --git a/doc/rfc/rfc9248.txt b/doc/rfc/rfc9248.txt new file mode 100644 index 0000000..8da89e2 --- /dev/null +++ b/doc/rfc/rfc9248.txt @@ -0,0 +1,1901 @@ + + + + +Internet Engineering Task Force (IETF) B. Rosen +Request for Comments: 9248 June 2022 +Category: Standards Track +ISSN: 2070-1721 + + + Interoperability Profile for Relay User Equipment + +Abstract + + Video Relay Service (VRS) is a term used to describe a method by + which a hearing person can communicate with a sign language speaker + who is deaf, deafblind, or hard of hearing (HoH) or has a speech + disability using an interpreter (i.e., a Communications Assistant + (CA)) connected via a videophone to the sign language speaker 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 employed 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 sign language speakers. It is + desirable that the videophones used by the sign language speaker + conform to a standard so that any device may be used with any + provider and that direct video calls between sign language speakers + work. This document describes the interface between a videophone and + a provider. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9248. + +Copyright Notice + + Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Requirements Language + 4. General Requirements + 5. SIP Signaling + 5.1. Registration + 5.2. Session Establishment + 5.2.1. Normal Call Origination + 5.2.2. Dial-Around Origination + 5.2.3. RUE Contact Information + 5.2.4. Incoming Calls + 5.2.5. Emergency Calls + 5.3. Mid-Call Signaling + 5.4. URI Representation of Phone Numbers + 5.5. Transport + 6. Media + 6.1. SRTP and SRTCP + 6.2. Text-Based Communication + 6.3. Video + 6.4. Audio + 6.5. DTMF Digits + 6.6. Session Description Protocol + 6.7. Privacy + 6.8. Negative Acknowledgement, Picture Loss Indicator, and Full + Intraframe Request Features + 7. Contacts + 7.1. CardDAV Login and Synchronization + 7.2. Contacts Import/Export Service + 8. Video Mail + 9. Provisioning and Provider Selection + 9.1. RUE Provider Selection + 9.2. RUE Configuration Service + 9.2.1. Provider Configuration + 9.2.2. RUE Configuration + 9.2.3. Versions + 9.2.4. Examples + 9.2.5. Using the Provider Selection and RUE Configuration + Services Together + 9.3. OpenAPI Interface Descriptions + 9.3.1. Provider List + 9.3.2. Configuration + 10. IANA Considerations + 10.1. RUE Provider List Registry + 10.2. Registration of Rue-Owner Value of the Purpose Parameter + 11. Security Considerations + 12. Normative References + 13. Informative References + Acknowledgements + Author's Address + +1. Introduction + + Video Relay Service (VRS) is a form of Telecommunications Relay + Service (TRS) that enables people 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, 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 and 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 subscriber-to-provider (interpreted) and direct subscriber-to- + subscriber 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, not any other interface the provider may + have. + + The following illustrates a typical relay call. The RUE device and + the communications assistant (sign language interpreter) have + videophones. The hearing user has a telephone (mobile or fixed). + + ||== RUE Interface (this document) + || + \/ + +------+ +------+ - +--------+ - +-------+ + |User | |RUE | ( ) |Provider| ( ) |User | + |who is| |Device|<-(Internet)->| | |who is | + |Deaf |<->| | | |<-( PSTN )->|Hearing| + +------+ +------+ -------- +--------+ ------ +-------+ + ^ + | + +--------------+ + |Communications| + |Assistant | + +--------------+ + +2. Terminology + + Communications 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 lipreading, 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 the 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 people with hearing or speech disabilities to + use a RUE to talk to users of conventional voice services with the + aid of a CA to relay the communication. + + Relay service (RS): + A service that allows 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, 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 smartphone; 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 a RUE. This is the conventional telecom term for + an end-user customer, which in this 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. + +3. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. Lower- or mixed-case uses of these key + words are not to be interpreted as carrying special significance. + +4. General Requirements + + All HTTP/HTTPS [RFC9110] [RFC9112] 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 Interactive + Connectivity Establishment (ICE) [RFC8445] is used; in which case, + candidates may explicitly offer IPv4, IPv6, or both for any media + stream. + +5. SIP Signaling + + 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) + + * [RFC3311] (UPDATE Method) + + * [RFC5393] (Loop-Fix) + + * [RFC5658] (Record-Route Fix) + + * [RFC5954] (ABNF Fix) + + * [RFC3960] (Early Media) + + * [RFC6442] (Geolocation Header Field) + + In the above documents, the RUE device conforms to the requirements + of a SIP user agent, and the provider conforms to the requirements of + the registrar and proxy server where the document specifies different + behavior for different roles. For providers offering a video mail + service, [RFC6665] (SIP Events) MUST be implemented to support the + Message-Waiting Indicator (MWI) (see Section 8). + + In addition, implementations MUST conform to: + + * [RFC3327] (Path Header Field) + + * [RFC8445] and [RFC8839] (ICE) + + * [RFC3326] (Reason Header Field) + + * [RFC3515] (REFER Method) + + * [RFC3891] (Replaces Header Field) + + * [RFC3892] (Referred-By Header Field) + + Implementations MUST implement full ICE, although they MAY interwork + with user agents that implement ICE-lite. + + 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 the background state. + + The SIP signaling for registration and placing/receiving calls + depends on the configuration of various values into the RUE device. + Section 9.2 describes the configuration mechanism that provides + values that are used in the signaling. When the device starts, the + configuration mechanism is run, which retrieves the configuration + data; then, SIP registration occurs using the values from the + configuration. After registration, calls may be sent or received by + the RUE device. + +5.1. Registration + + 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" + in "RueConfigurationData", 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 and formatted as follows: + + * if "user-name" is provided: "username@provider-domain" + + * if "user-name" is not provided: as specified in Section 5.4, use + "phone-number" and "provider-domain" from the configuration + + The RUE determines the URI to resolve by initially determining if one + or more "outbound-proxies" are configured. If they are configured, + the URI will be that of one of the "outbound-proxies". If no + "outbound-proxies" are 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.net" 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 reattempt registration without using + the outbound mechanism. + + The registrar MAY authenticate the RUE using SIP digest + authentication. The credentials to be used MUST come from the + configuration in Section 9.2: "user-name" if provided or "phone- + number" if user-name is not provided, and "sip-password". This + "user-name"/"sip-password" combination SHOULD NOT be the same as that + used for other purposes, except as expressly described below, 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 MUST 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 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. + +5.2. Session Establishment + +5.2.1. Normal Call Origination + + 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 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:+15551234567@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 requirements specified in Section 6 + of this document. + + To allow time for an unanswered call to time out 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. + +5.2.2. Dial-Around Origination + + 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 dual-tone multi-frequency + (DTMF) to provide the called party's telephone number. In two-stage + dial-around, the To URI is the "front-door" URI (see Section 9.2) in + "ProviderConfigurationData" of the dial-around provider. The RUE + Provider Selection service (Section 9.1) can be used by the RUE to + obtain a list of providers; then, the provider configuration + (Section 9.2.1) 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's 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 as described in 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:+15552220001@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:+15552220001@red.example.net;user=phone + P-Asserted-Identity: sip:+15552220001@red.example.net + + Figure 1: One-Stage Dial-Around + +5.2.3. RUE Contact Information + + To identify the owner of a RUE, the initial INVITE for a call from a + RUE, or the 200 OK the RUE uses to accept a call, identifies the + owner by sending a Call-Info header field with a purpose parameter of + "rue-owner". The URI MAY be an HTTPS URI or Content-ID 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 an xCard [RFC6351]. Please refer to [RFC6442] for an + example of using content indirection URLs in SIP messages. Note that + use of the content indirection URL usually implies multiple message + bodies ("mime/multipart"). The RUE owner is the entity that has + local control over the device that is not necessarily the legal owner + of the equipment. It often is the user, but that is not necessarily + true. While no minimum fields in the xCard are specified, the name, + address, phone number, and email address of the RUE owner are + expected to be supplied. + +5.2.4. Incoming Calls + + 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 using a CANCEL request. + +5.2.5. Emergency Calls + + 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 + field and without a Route header field (since it would be unable to + query the Location-to-Service Translation (LoST) server for a route, + per [RFC6881]). If an emergency call arrives at the provider without + a Geolocation header field, the provider MUST supply location by + adding the Geolocation header field 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, the location MAY be extracted from the [RFC6881] conformant + INVITE and used to propagate it to the appropriate country-specific + entities. If the configuration specifies it, an implementation of a + RUE device MAY send a Geolocation header field containing its + location in the REGISTER request. If implemented, users MUST be + offered an opt-out. Country-specific procedures might require the + location to be preloaded in some entity prior to placing an emergency + call; however, the RUE may have a more accurate and timely device + location than the manual, preloaded entry. 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 information, device information, + and owner/subscriber information blocks. + +5.3. Mid-Call Signaling + + Implementations MUST support re-INVITE to renegotiate media session + parameters (among other uses). Per Section 6.8, implementations MUST + be able to support an INFO message for full frame refresh for devices + that do not support SRTCP (please refer to Section 6.1). + Implementations MUST support an in-dialog REFER (as described in + [RFC3515] and updated by [RFC7647], and including support for + norefersub per [RFC4488]) with the Replaces header field [RFC3891] to + enable call transfer. + +5.4. URI Representation of Phone Numbers + + 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", as defined in + [RFC3966]. The user part MUST NOT contain any "visual-separator" + characters, as defined in [RFC3966]. + + 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. + +5.5. Transport + + Implementations MUST conform to [RFC8835], except for its guidance on + the WebRTC data channel, which this specification does not use. See + 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). + +6. Media + + 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. Various RTPs, RTCPs, SDPs, and specific + media requirements specified for WebRTC are adopted for this + document. Explicit requirements from the WebRTC suite of documents + are described below . + + To use WebRTC with this document, a gateway that presents a WebRTC + server interface towards a browser and a RUE client interface towards + a provider is assumed. The gateway would interwork signaling and, as + noted below, interwork at least any real-time text media in order to + allow a standard browser-based WebRTC client to be a VRS client. The + combination of the browser client and the gateway would be a RUE + user. This document does not specify the gateway. + + 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, an implementation + presenting a call across the RUE interface (where the call originates + in the PSTN 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. Conformance to this document + allows end-to-end RTCP and media congestion control for audio and + video. + +6.1. SRTP and SRTCP + + Implementations MUST support [RFC8834], except that MediaStreamTracks + are not used. Implementations MUST conform to Section 6.4 of + [RFC8827]. + +6.2. Text-Based Communication + + Implementations MUST support real-time text [RFC4102] [RFC4103] via + T.140 media. One original and two redundant generations MUST be + transmitted and supported with a 300 ms transmission interval. + Implementations MUST support [RFC9071], especially for emergency + calls. Note that [RFC4103] 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. + + Transport of T.140 real-time text in WebRTC is specified in + [RFC8865], using the WebRTC data channel. [RFC8865] also has some + advice on how gateways between [RFC4103] and [RFC8865] should + operate. It is RECOMMENDED that [RFC8865], including multiparty + support, be used for communication with browser-based WebRTC + implementations. Implementations MUST support [RFC9071]. + +6.3. Video + + Implementations MUST conform to [RFC7742] with the following + exceptions: only H.264, as specified in [RFC7742], is Mandatory to + Implement, and VP8 support is OPTIONAL at both the device and + providers. This is because backwards compatibility is desirable, and + older devices do not support VP8. + +6.4. Audio + + Implementations MUST conform to [RFC7874]. + +6.5. DTMF Digits + + 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. + +6.6. Session Description Protocol + + The SDP offers and answers MUST conform to the SDP rules in [RFC8829] + except that the RUE interface uses SIP transport for SDP. The SDP + for real-time text MUST specify the T.140 payload type [RFC4103]. + +6.7. Privacy + + The RUE MUST provide for user privacy by implementing a local one-way + mute, without signaling, for both audio and video. However, RUE MUST + maintain any states in the network (e.g., NAT bindings) by + periodically sending media packets on all active media sessions + containing silence, comfort noise, blank screen, etc., per [RFC6263]. + +6.8. Negative Acknowledgement, Picture Loss Indicator, and Full + Intraframe Request Features + + The NACK, FIR, and Picture Loss Indicator (PLI) features, as + described in [RFC4585] and [RFC5104], MUST be implemented. + Availability of these features MUST be announced with the "ccm" + feedback value. NACK should be used when negotiated and conditions + warrant its use and the other end supports it. Signaling picture + losses as a PLI should be preferred. FIR should be used only in + situations where not sending a decoder refresh point would render the + video unusable for the users, as per Section 4.3.1.2 of [RFC5104]. + + 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]. + +7. Contacts + +7.1. CardDAV Login and Synchronization + + Support of vCard Extensions to WebDAV (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] [RFC6764]. + + The configuration (see Section 9.2) RueConfigurationData MAY supply a + "carddav-username" and "carddav-domain" identifying a CardDAV server + and address book for this account, plus an optional "carddav- + password". + + To access the CardDAV server and address book, the RUE MUST follow + Section 6 of [RFC6764], using the configured carddav-username and + carddav-domain in place of an email address. If the request triggers + a challenge for digest authentication credentials, the RUE MUST + continue using matching carddav-username and carddav-password from + the configuration. If no carddav-username and carddav-password are + configured, the RUE MUST use the SIP user-name and sip-password 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. + + The RUE MAY support other CardDAV services. + +7.2. Contacts Import/Export Service + + Implementations MUST be able to export/import the list of contacts in + xCard [RFC6351] XML 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 the "contacts-username" and "contacts-password" from + the configuration. If no contacts-username is configured, the SIP + user-name from the configuration is used; if the SIP user-name is not + configured, the phone-number is used. If user-name or phone-number + is used, the sip-password is used to authenticate to the contact list + server. + +8. Video Mail + + Support for video mail includes a retrieval mechanism and a Message- + Waiting Indicator (MWI). Message storage is not specified by this + document. RUE devices MUST support message retrieval using a SIP + call to a specified SIP URI using DTMF to manage the mailbox, as well + as a browser-based interface reached at a specified HTTPS URI. If a + provider supports video mail, at least one of these mechanisms MUST + be supported. RUE devices MUST support both. See Section 9.2 for + how the URI to reach the retrieval interface is obtained. + + Implementations MUST support subscriptions to "message-summary" + events [RFC3842] to the URI specified in the configuration. + Providers MUST support MWI if they support video mail. RUE devices + MUST support MWI. + + The "videomail" and "mwi" properties in the configuration (see + RueConfigurationData in Section 9.2.2) give the URIs for message + retrieval and "message-summary" subscription. + + In notification bodies, if detailed message summaries are available, + messages with video MUST be reported using "message-context-class + multimedia-message", as defined in [RFC3458] . + +9. Provisioning and Provider Selection + + 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 can allow easy provider selection + either for registering or for dial-around. The other provides + configuration data for the device for each provider. + +9.1. RUE Provider Selection + + 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 list entry point string (see + Section 10.1). The entry point, when used with the following OpenAPI + interface, returns a list of provider names for a country code + suitable for display, with a corresponding entry point to obtain + information about that provider. No mechanism to determine the + country where the RUE is located is specified in this document. + Typically, the country is the home country of the user but may be a + local country while traveling. Some countries allow support from + their home country when traveling abroad. Regardless, the RUE device + will need to allow the user to choose the country. + + Each country that supports VRS using this specification MAY support + the provider list. This document does not specify who maintains the + list. Some possibilities are a regulator or an entity designated by + a regulator, an agreement among providers to provide the list, or a + user group. + + The interface to obtain the list of providers is described by an + OpenAPI [OpenAPI] interface description. In that interface + description, the "servers" component includes an occurrence of + "localhost". The value from the registry of the "list entry point" + string for the desired country is substituted for "localhost" in the + "servers" component to obtain the server URI prefix of the interface + to be used to obtain the list of providers for that country. The + "Providers" path then specifies the rest of the URI used to obtain + the list. For example, if the list entryPoint is "example.com/api", + the provider list would be obtained from + https://example.com/api/rum/v1/Providers. + + The V1.0 "ProviderList" is a JSON object consisting of an array where + each entry describes one provider. Each entry consists of the + following items: + + * name: This parameter contains the text label identifying the + provider and is meant to be displayed to the human VRS user. + + * providerEntryPoint: A string used for configuration purposes by + the RUE (as discussed in Section 9.2). The string MUST start with + a domain but MAY include other URI path elements after the domain. + + 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", + "entryPoint": "red.example.net" + }, + { + "name": "Green", + "entryPoint": "green.example.net" + }, + { + "name": "Blue", + "entryPoint": "blue.example.net" + } + ] + } + + Figure 2: Example of a ProviderList JSON Object + +9.2. RUE Configuration Service + + A RUE device may retrieve a provider configuration using a simple + HTTPs web service. There are two entry points. One is used without + user credentials, and the response includes configuration data for + new user signup and dial-around. The other uses a locally stored + username and password that results from a new user signup to + authenticate to the interface and returns configuration data for the + RUE. + + The interface to obtain configuration data is described by an OpenAPI + [OpenAPI] interface description. In that interface description, the + "servers" component string includes an occurrence of "localhost". + The entry point string obtained from the provider list (Section 9.1) + is substituted for "localhost" to obtain the server prefix of the + interface. The path then specifies the rest of the URI used to + obtain the list. For example, if the entryPoint from the provider + list is "red.example.net", the provider configuration would be + obtained from https://red.example.net/rum/V1/ProviderConfig and the + RUE configuration would be obtained from + https://red.example.net/rum/V1/RueConfig. + + In both the queries, an optional parameter may be provided to the + interface, which is an API Key (apiKey). The implementation MAY have + an apiKey obtained from the provider and specific to the + implementation. The method used to obtain the apiKey is not + specified in this document. The provider MAY refuse to provide + service to an implementation presenting an apiKey it does not + recognize. + + Also in both queries, the RUE device provides a client-provided, + required parameter, which contains an instance identifier + (instanceId). 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. This should be + globally unique. A Universally Unique Identifier (UUID) is + suggested. + + For example, a query for the RUE configuration could be + https://red.example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisK + t8999"&instanceId="5595b5a3-0687-4b8e-9913-a7f2a04fb7bd" + + The data returned is a JSON object consisting of key/value + configuration parameters to be used by the RUE. + + 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. + +9.2.1. Provider Configuration + + * signup: (OPTIONAL) an array of JSON objects consisting of: + + - language: entry from the IANA "Language Subtag Registry" + (https://www.iana.org/assignments/language-subtag-registry). + Normally, this would be a written language tag. + + - uri: a URI to the website for creating a new account in the + supported language. The new user signup URI may only initiate + creation of a new account. Various vetting, approval, and + other processes may be needed, which could take time, before + the account is established. The result of creating a new + account would be account credentials (e.g., username and + password), which would be manually entered into the RUE device + that forms the authentication parameters for the RUE + configuration service described below in Section 9.2.2. + + * dial-around: an array of JSON objects consisting of: + + - language: entry from the IANA "Language Subtag Registry". + Normally, this would be a sign language tag. + + - front-door: a URI to a queue of interpreters supporting the + specified language for a two-stage dial-around. + + - oneStage: a URI that can be used with a one-stage dial-around + (Section 5.2.2) using an interpreter supporting the specified + language. + + * helpDesk: (OPTIONAL) an array of JSON objects consisting of: + + - language: entry from the IANA "Language Subtag Registry". + Normally, this would be a sign language tag; although, it could + be a written language tag if the help desk only supports a chat + interface. + + - uri: a URI that reaches a help desk for callers supporting the + specified language. The URI MAY be a SIP URI for help provided + with a SIP call or MAY be an HTTPS URI for help provided with a + browser interface. + + A list is specified so that the provider can offer multiple + choices to users for language and interface styles. + +9.2.2. RUE Configuration + + * lifetime: (OPTIONAL) specifies how long (in seconds) the RUE MAY + cache the configuration values. Values may not be valid when + lifetime expires. If the RUE caches configuration values, it MUST + cryptographically protect them against unauthorized disclosure + (e.g., by other applications on the platform the RUE is built on). + The RUE SHOULD retrieve a fresh copy of the configuration before + the lifetime expires or as soon as possible after it expires. The + lifetime is not guaranteed, i.e., the configuration may change + before the lifetime value expires. In that case, the provider MAY + indicate this by generating authorization challenges to requests + and/or prematurely terminating a registration. Emergency calls + MUST continue to work. If not specified, the RUE MUST fetch new + configuration data every time it starts. + + * sip-password: (OPTIONAL) a password used for SIP, STUN, and TURN + authentication. The RUE device retains this data, which it MUST + cryptographically protect against unauthorized disclosure (e.g., + by other applications on the platform the RUE is built on). If it + is not supplied but was supplied on a prior invocation of this + interface, the most recently supplied password MUST be used. If + it was never supplied, the password used to authenticate to the + configuration service is used for SIP, as well as STUN and TURN + servers mentioned in this configuration. + + * phone-number: (REQUIRED) the telephone number (in E.164 format) + assigned to this subscriber. This becomes the user portion of the + SIP URI identifying the subscriber. + + * user-name: (OPTIONAL) a username used for authenticating to the + provider. If not provided, phone-number is used. + + * display-name: (OPTIONAL) a human-readable display name for the + subscriber. + + * provider-domain: (REQUIRED) the domain for the provider. This + becomes the server portion of the SIP URI identifying the + subscriber. + + * outbound-proxies: (OPTIONAL) an array of URIs of SIP proxies to be + used when sending requests to the provider. + + * mwi: (OPTIONAL) a URI identifying a SIP event server that + generates "message-summary" events for this subscriber. + + * videomail: (OPTIONAL) a SIP or HTTPS URI that can be used to + retrieve video mail messages. + + * contacts: (OPTIONAL) an HTTPS URI ("contacts-uri"), (OPTIONAL) + "contacts-username", and "contacts-password" that may be used to + export (retrieve) the subscriber's complete contact list managed + by the provider. At least the URI MUST be provided if the + subscriber has contacts. If contact-username and contacts- + password are not supplied, the sip credentials are used. If the + contacts-username is provided, contacts-password MUST be provided. + If contacts-password is provided, contacts-username MUST be + provided. + + * carddav: (OPTIONAL) an address ("carddav-domain"), (OPTIONAL) + "carddav-username", and "carddav-password" identifying a "CardDAV" + server and account that can be used to synchronize the RUE's + contact list with the contact list managed by the provider. If + carddav-username and carddav-password are not supplied, the sip + credentials are used. If the carddav-username is provided, + carddav-password MUST be provided. If carddav-password is + provided, carddav-username MUST be provided. + + * sendLocationWithRegistration: (OPTIONAL) true if the RUE should + send a Geolocation header field with REGISTER; false if it should + not. Defaults to false if not present. + + * ice-servers: (OPTIONAL) an array of server types and URLs + identifying STUN and TURN servers available for use by the RUE for + establishing media streams in calls via the provider. If the same + URL provides both STUN and TURN services, it MUST be listed twice, + each with different server types. + +9.2.3. Versions + + Both web services also have a simple version mechanism that returns a + list of versions of the web service it supports. This document + describes version 1.0. Versions are displayed as a major version, + followed by a period ".", followed by a minor version, where the + 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. Backwards compatibility applies to both the server and the + client. Either may have any higher or lower minor revision and + interoperate with its counterpart with the same major version. To + achieve backwards compatibility, implementations MUST ignore any + object members they do not implement. Minor version definitions + SHALL only add objects, optional members of existing objects, and + non-mandatory-to-use functions and SHALL NOT delete or change 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 version mechanism returns an array of supported versions, one for + each major version supported, with the minor version listed being the + highest-supported minor version. + + Unless the per-country provider list service is operated by a + provider at the same base URI as that provider's configuration + service, the version of the configuration service MAY be different + from the version of the provider list service. + + { + "versions": [ + { + "major": 1, + "minor": 6 + }, + { + "major": 2, + "minor": 13 + }, + { + "major": 3, + "minor": 2 + } + ] + } + + Figure 3: Example of a Version JSON Object + +9.2.4. Examples + + { + "signUp": [ + { "language" : "en", "uri" : "https:hello-en.example.net"}, + { "language" : "es", "uri" : "https:hello-es.example.net"} ] , + "dial-around": [ + { "language" : "en", "front-door" : "sip:fd-en.example.net", + "oneStage" : "sip:1stg-eng.example.com" } , + { "language" : "es", "front-door" : "sip:fd-es.example.net", + "oneStage" : "sip:1stg-spn.example.com" } ] , + "helpDesk": [ + { "language" : "en", "uri" : "sip:help-en.example.net"} , + { "language" : "es", "uri" : "sip:help-es.example.net"} ] + } + + Figure 4: Example JSON Provider Configuration Payload + + { + "lifetime": 86400, + "display-name" : "Bob Smith", + "phone-number": "+15551234567", + "provider-domain": "red.example.net", + "outbound-proxies": [ + "sip:p1.red.example.net", + "sip:p2.red.example.net" ], + "mwi": "sip:+15551234567@red.example.net;user=phone", + "videomail": "sip:+15551234567@vm.red.example.net;user=phone", + "contacts": { + "contacts-uri": + "https://red.example.net:443/c/3617b719-2c3a-46f4-9c13", + "contacts-username": "bob", + "contacts-password": "XhOT4ch@ZEi&3u2xEYQNMO^5UGb" + }, + "carddav": { + "carddav-domain": "carddav.example.com", + "carddav-username": "bob", + "carddav-password": "sj887%dd*jJty%87hyys5hHT" + }, + "sendLocationWithRegistration": false, + "ice-servers": [ + {"stun":"stun.red.example.com:19302" }, + {"turn":"turn.red.example.com:3478"} + ] + } + + Figure 5: Example JSON RUE Configuration Payload + +9.2.5. Using the Provider Selection and RUE Configuration Services + Together + + One way to use these two services is: + + 1. At startup, the RUE retrieves the provider list for the country + it is located in. + + 2. For each provider in the list: + + * If the RUE does not have credentials for that provider, if + requested by the user, use the ProviderConfig path without + credentials to obtain signup, dial-around, and help desk + information. + + * If the RUE has credentials for that provider, use the + RueConfig path with the locally stored credentials to + configure the RUE for that provider. + +9.3. OpenAPI Interface Descriptions + + The interfaces in Sections 9.1 and 9.2 are formally specified with + OpenAPI 3.0 [OpenAPI] descriptions in YAML form. + + The OpenAPI description below is normative. If there is any conflict + between the text or examples and this section, the OpenAPI + description takes precedence. + +9.3.1. Provider List + + openapi: 3.0.1 + info: + title: RUM Provider List API + version: "1.0" + servers: + - url: https://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' + /Versions: + servers: + - url: https://localhost/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 + - providerEntryPoint + properties: + name: + type: string + description: Human-readable provider name + providerEntryPoint: + type: string + description: Provider entry point 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 + + Figure 6: Provider List OpenAPI Description (RueProviderList.yaml) + +9.3.2. Configuration + + openapi: 3.0.1 + info: + title: RUM Configuration API + version: "1.0" + servers: + - url: https://localhost/rum/v1 + paths: + /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://localhost/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: + ProviderConfigurationData: + type: object + required: + - dial-around + properties: + signup: + type: array + items: + 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 + this language + dial-around: + type: array + items: + type: object + required: + - language + - front-door + - oneStage + properties: + language: + type: string + description: Entry from IANA "Language Subtag + Registry" + front-door: + type: string + format: uri + description: SIP URI for two-stage dial-around + oneStage: + type: string + format: uri + description: SIP URI for one-stage dial-around + helpDesk: + type: array + items: + 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 help desk supporting language + RueConfigurationData: + type: object + required: + - phone-number + - provider-domain + 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 in + E.164 format + user-name: + type: string + description: A username assigned to this subscriber + display-name: + type: string + description: Display name for the subscriber + provider-domain: + type: string + description: Domain of the provider for this subscriber + outbound-proxies: + type: array + items: + type: string + format: uri + description: SIP URI of a 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: An HTTPS or SIP URI that can be used to + retrieve video mail messages + contacts: + type: object + description: Server and credentials for contact + import/export + required: + - contacts-uri + properties: + contacts-uri: + 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 + contacts-username: + type: string + description: Username for authentication with the + CardDAV server. Use SIP user-name if not provided + contacts-password: + type: string + description: Password for authentication. Use provider + sip-password if not provided + 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 + required: + - carddav-domain + properties: + carddav-domain: + type: string + description: CardDAV server address + carddav-username: + type: string + description: Username for authentication with the + CardDAV server. Use SIP user-name if not provided + carddav-password: + type: string + description: Password for authentication to the CardDAV + server. Use provider sip-password if not provided + sendLocationWithRegistration: + type: boolean + description: True if the RUE should send a Geolocation + header field with REGISTER; false if it should not. + Defaults to false if not present + ice-servers: + type: array + items: + type: object + required: + - server-type + - uri + properties: + server-type: + type: string + description: Server type ("stun" or "turn") + uri: + 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 + 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 + + Figure 7: Configuration OpenAPI Description (RueConfiguration.yaml) + +10. IANA Considerations + +10.1. RUE Provider List Registry + + IANA has created the "RUE Provider List" registry. The registration + policy is "Expert Review" [RFC8126]. A regulator operated or + designated list interface operator is preferred. 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 determines that + the proposed URI provides a more accurate list than the existing + entry. Each entry has two fields; values for both MUST be provided + when registering or updating an entry: + + * country code: a two-letter ISO93166 country code + + * list entry point: a string is used to compose the URI to the + provider list interface for that country + +10.2. Registration of Rue-Owner Value of the Purpose Parameter + + This document defines the new predefined value "rue-owner" for the + "purpose" header field parameter of the Call-Info header field. The + use for rue-owner is defined in Section 5.2.3. IANA has added a + reference to this document in the "Header Field Parameters and + Parameter Values" subregistry of the "Session Initiation Protocol + (SIP) Parameters" for the header field "Call-Info" and parameter name + "purpose". + + Header Field: Call-Info + + Parameter Name: purpose + + Predefined Values: Yes + +11. Security Considerations + + 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. + + This document requires implementation and use of a number of other + specifications in order to fulfill the RUE profile; the security + considerations described in those documents apply accordingly to the + RUE interactions. + + When a CA participates in a conversation, they have access to the + content of the conversation even though it is nominally a + conversation between the two endpoints. There is an expectation that + the CA will keep the communication contents in confidence. This is + usually defined by contractual or legal requirements. + + Since different providers (within a given country) may have different + policies, RUE implementations MUST include a user interaction step to + select from available providers before proceeding to actually + register with any given provider. + +12. Normative References + + [OpenAPI] Miller, D., Whitlock, J., Gardiner, M., Ralphson, M., + Ratovsky, R., and U. Sarid, "OpenAPI Specification + v3.0.1", December 2017, + <https://spec.openapis.org/oas/v3.0.1>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource + Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, + <https://www.rfc-editor.org/info/rfc2392>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation + Protocol (SIP): Locating SIP Servers", RFC 3263, + DOI 10.17487/RFC3263, June 2002, + <https://www.rfc-editor.org/info/rfc3263>. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + <https://www.rfc-editor.org/info/rfc3264>. + + [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) + UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October + 2002, <https://www.rfc-editor.org/info/rfc3311>. + + [RFC3323] Peterson, J., "A Privacy Mechanism for the Session + Initiation Protocol (SIP)", RFC 3323, + DOI 10.17487/RFC3323, November 2002, + <https://www.rfc-editor.org/info/rfc3323>. + + [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason + Header Field for the Session Initiation Protocol (SIP)", + RFC 3326, DOI 10.17487/RFC3326, December 2002, + <https://www.rfc-editor.org/info/rfc3326>. + + [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol + (SIP) Extension Header Field for Registering Non-Adjacent + Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, + <https://www.rfc-editor.org/info/rfc3327>. + + [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message + Context for Internet Mail", RFC 3458, + DOI 10.17487/RFC3458, January 2003, + <https://www.rfc-editor.org/info/rfc3458>. + + [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer + Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, + <https://www.rfc-editor.org/info/rfc3515>. + + [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute + in Session Description Protocol (SDP)", RFC 3605, + DOI 10.17487/RFC3605, October 2003, + <https://www.rfc-editor.org/info/rfc3605>. + + [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, + "Indicating User Agent Capabilities in the Session + Initiation Protocol (SIP)", RFC 3840, + DOI 10.17487/RFC3840, August 2004, + <https://www.rfc-editor.org/info/rfc3840>. + + [RFC3842] Mahy, R., "A Message Summary and Message Waiting + Indication Event Package for the Session Initiation + Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August + 2004, <https://www.rfc-editor.org/info/rfc3842>. + + [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation + Protocol (SIP) "Replaces" Header", RFC 3891, + DOI 10.17487/RFC3891, September 2004, + <https://www.rfc-editor.org/info/rfc3891>. + + [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) + Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, + September 2004, <https://www.rfc-editor.org/info/rfc3892>. + + [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing + Tone Generation in the Session Initiation Protocol (SIP)", + RFC 3960, DOI 10.17487/RFC3960, December 2004, + <https://www.rfc-editor.org/info/rfc3960>. + + [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", + RFC 3966, DOI 10.17487/RFC3966, December 2004, + <https://www.rfc-editor.org/info/rfc3966>. + + [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", + RFC 4102, DOI 10.17487/RFC4102, June 2005, + <https://www.rfc-editor.org/info/rfc4102>. + + [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text + Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, + <https://www.rfc-editor.org/info/rfc4103>. + + [RFC4488] Levin, O., "Suppression of Session Initiation Protocol + (SIP) REFER Method Implicit Subscription", RFC 4488, + DOI 10.17487/RFC4488, May 2006, + <https://www.rfc-editor.org/info/rfc4488>. + + [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control + Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, + DOI 10.17487/RFC4585, July 2006, + <https://www.rfc-editor.org/info/rfc4585>. + + [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF + Digits, Telephony Tones, and Telephony Signals", RFC 4733, + DOI 10.17487/RFC4733, December 2006, + <https://www.rfc-editor.org/info/rfc4733>. + + [RFC4967] Rosen, B., "Dial String Parameter for the Session + Initiation Protocol Uniform Resource Identifier", + RFC 4967, DOI 10.17487/RFC4967, July 2007, + <https://www.rfc-editor.org/info/rfc4967>. + + [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, + "Codec Control Messages in the RTP Audio-Visual Profile + with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, + February 2008, <https://www.rfc-editor.org/info/rfc5104>. + + [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for + Media Control", RFC 5168, DOI 10.17487/RFC5168, March + 2008, <https://www.rfc-editor.org/info/rfc5168>. + + [RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. + Campen, "Addressing an Amplification Vulnerability in + Session Initiation Protocol (SIP) Forking Proxies", + RFC 5393, DOI 10.17487/RFC5393, December 2008, + <https://www.rfc-editor.org/info/rfc5393>. + + [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., + "Managing Client-Initiated Connections in the Session + Initiation Protocol (SIP)", RFC 5626, + DOI 10.17487/RFC5626, October 2009, + <https://www.rfc-editor.org/info/rfc5626>. + + [RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing + Record-Route Issues in the Session Initiation Protocol + (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, + <https://www.rfc-editor.org/info/rfc5658>. + + [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., + "Essential Correction for IPv6 ABNF and URI Comparison in + RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, + <https://www.rfc-editor.org/info/rfc5954>. + + [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for + Keeping Alive the NAT Mappings Associated with RTP / RTP + Control Protocol (RTCP) Flows", RFC 6263, + DOI 10.17487/RFC6263, June 2011, + <https://www.rfc-editor.org/info/rfc6263>. + + [RFC6351] Perreault, S., "xCard: vCard XML Representation", + RFC 6351, DOI 10.17487/RFC6351, August 2011, + <https://www.rfc-editor.org/info/rfc6351>. + + [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed + Authoring and Versioning (WebDAV)", RFC 6352, + DOI 10.17487/RFC6352, August 2011, + <https://www.rfc-editor.org/info/rfc6352>. + + [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance + for the Session Initiation Protocol", RFC 6442, + DOI 10.17487/RFC6442, December 2011, + <https://www.rfc-editor.org/info/rfc6442>. + + [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, + DOI 10.17487/RFC6665, July 2012, + <https://www.rfc-editor.org/info/rfc6665>. + + [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions + to WebDAV (CalDAV) and vCard Extensions to WebDAV + (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, + <https://www.rfc-editor.org/info/rfc6764>. + + [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for + Communications Services in Support of Emergency Calling", + BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, + <https://www.rfc-editor.org/info/rfc6881>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <https://www.rfc-editor.org/info/rfc7525>. + + [RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of + REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, + September 2015, <https://www.rfc-editor.org/info/rfc7647>. + + [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec + Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, + <https://www.rfc-editor.org/info/rfc7742>. + + [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and + J. Winterbottom, "Additional Data Related to an Emergency + Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, + <https://www.rfc-editor.org/info/rfc7852>. + + [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing + Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, + <https://www.rfc-editor.org/info/rfc7874>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive + Connectivity Establishment (ICE): A Protocol for Network + Address Translator (NAT) Traversal", RFC 8445, + DOI 10.17487/RFC8445, July 2018, + <https://www.rfc-editor.org/info/rfc8445>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8599] Holmberg, C. and M. Arnold, "Push Notification with the + Session Initiation Protocol (SIP)", RFC 8599, + DOI 10.17487/RFC8599, May 2019, + <https://www.rfc-editor.org/info/rfc8599>. + + [RFC8760] Shekh-Yusef, R., "The Session Initiation Protocol (SIP) + Digest Access Authentication Scheme", RFC 8760, + DOI 10.17487/RFC8760, March 2020, + <https://www.rfc-editor.org/info/rfc8760>. + + [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for + Browser-Based Applications", RFC 8825, + DOI 10.17487/RFC8825, January 2021, + <https://www.rfc-editor.org/info/rfc8825>. + + [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, + DOI 10.17487/RFC8827, January 2021, + <https://www.rfc-editor.org/info/rfc8827>. + + [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., + "JavaScript Session Establishment Protocol (JSEP)", + RFC 8829, DOI 10.17487/RFC8829, January 2021, + <https://www.rfc-editor.org/info/rfc8829>. + + [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport + and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, + January 2021, <https://www.rfc-editor.org/info/rfc8834>. + + [RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, + DOI 10.17487/RFC8835, January 2021, + <https://www.rfc-editor.org/info/rfc8835>. + + [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, + A., and R. Shpount, "Session Description Protocol (SDP) + Offer/Answer Procedures for Interactive Connectivity + Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, + January 2021, <https://www.rfc-editor.org/info/rfc8839>. + + [RFC8865] Holmberg, C. and G. Hellström, "T.140 Real-Time Text + Conversation over WebRTC Data Channels", RFC 8865, + DOI 10.17487/RFC8865, January 2021, + <https://www.rfc-editor.org/info/rfc8865>. + + [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: + Session Description Protocol", RFC 8866, + DOI 10.17487/RFC8866, January 2021, + <https://www.rfc-editor.org/info/rfc8866>. + + [RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real- + Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, + <https://www.rfc-editor.org/info/rfc9071>. + + [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + <https://www.rfc-editor.org/info/rfc9110>. + + [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, + June 2022, <https://www.rfc-editor.org/info/rfc9112>. + +13. Informative References + + [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and + K. Summers, "Session Initiation Protocol (SIP) Basic Call + Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, + December 2003, <https://www.rfc-editor.org/info/rfc3665>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + +Acknowledgements + + Brett Henderson and Jim Malloy provided many helpful edits to prior + draft versions of this document. Paul Kyzivat provided extensive + reviews and comments. + +Author's Address + + Brian Rosen + 470 Conrad Dr + Mars, PA 16046 + United States of America + Email: br@brianrosen.net |