470 Conrad Dr Mars PA 16046 United States of America br@brianrosen.net

art rum rue relay user equipment 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 .

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 () 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

• .  Introduction
• .  Terminology
• .  Requirements Language
• .  General Requirements
• .  SIP Signaling
  • .  Registration
  • .  Session Establishment
    • .  Normal Call Origination
    • .  Dial-Around Origination
    • .  RUE Contact Information
    • .  Incoming Calls
    • .  Emergency Calls
  • .  Mid-Call Signaling
  • .  URI Representation of Phone Numbers
  • .  Transport
• .  Media
  • .  SRTP and SRTCP
  • .  Text-Based Communication
  • .  Video
  • .  Audio
  • .  DTMF Digits
  • .  Session Description Protocol
  • .  Privacy
  • .  Negative Acknowledgement, Picture Loss Indicator, and Full Intraframe Request Features
• .  Contacts
  • .  CardDAV Login and Synchronization
  • .  Contacts Import/Export Service
• .  Video Mail
• .  Provisioning and Provider Selection
  • .  RUE Provider Selection
  • .  RUE Configuration Service
    • .  Provider Configuration
    • .  RUE Configuration
    • .  Versions
    • .  Examples
    • .  Using the Provider Selection and RUE Configuration Services Together
  • .  OpenAPI Interface Descriptions
    • .  Provider List
    • .  Configuration
• . IANA Considerations
  • .  RUE Provider List Registry
  • .   Registration of Rue-Owner Value of the Purpose Parameter
• . Security Considerations
• . Normative References
• . Informative References
• Acknowledgements
• Author's Address

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 | +--------------+

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.

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 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.

General Requirements All HTTP/HTTPS connections specified throughout this document MUST use HTTPS. Both HTTPS and all SIP connections MUST use TLS conforming to at least and MUST support . 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) is used; in which case, candidates may explicitly offer IPv4, IPv6, or both for any media stream.

SIP Signaling Implementations of the RUE interface MUST conform to the following core SIP standards:

• (Base SIP)
• (Locating SIP Servers)
• (Offer/Answer)
• (User Agent Capabilities)
• (Outbound)
• (Session Description Protocol)
• (Privacy)
• (RTCP Attribute in SDP)
• (UPDATE Method)
• (Loop-Fix)
• (Record-Route Fix)
• (ABNF Fix)
• (Early Media)
• (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, (SIP Events) MUST be implemented to support the Message-Waiting Indicator (MWI) (see ). In addition, implementations MUST conform to:

• (Path Header Field)
• and (ICE)
• (Reason Header Field)
• (REFER Method)
• (Replaces Header Field)
• (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 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. 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.

Registration The RUE MUST register with a SIP registrar, following and , at a provider it has an account with. If the configuration (see ) contains multiple "outbound-proxies" in "RueConfigurationData", then the RUE MUST use them as specified in 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 , 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 . 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 : "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. 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.

Session Establishment

Normal Call Origination After initial SIP registration, the RUE adheres to SIP basic call flows, as documented in . 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 using the destination phone number or as SIP URIs as provided in the configuration (). 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 . The From URI MUST be formatted as specified in , 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 .) Negotiated media MUST follow the requirements specified in 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.

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 ) in "ProviderConfigurationData" of the dial-around provider. The RUE Provider Selection service () can be used by the RUE to obtain a list of providers; then, the provider configuration () 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 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 . 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:

One-Stage Dial-Around ,-+-. ,----+----. ,-----+-----. |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

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 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 . Please refer to 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.

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.

Emergency Calls Implementations MUST conform to 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 ). 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 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 . RUE devices MUST implement data provider information, device information, and owner/subscriber information blocks.

Mid-Call Signaling Implementations MUST support re-INVITE to renegotiate media session parameters (among other uses). Per , implementations MUST be able to support an INFO message for full frame refresh for devices that do not support SRTCP (please refer to ). Implementations MUST support an in-dialog REFER (as described in and updated by , and including support for norefersub per ) with the Replaces header field to enable call transfer.

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 . The user part MUST NOT contain any "visual-separator" characters, as defined in . Dial strings that cannot be expressed as E.164 numbers MUST be represented as dialstring URIs, as specified by , 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 ) to globally routable IPv4 and/or IPv6 addresses.

Transport Implementations MUST conform to , except for its guidance on the WebRTC data channel, which this specification does not use. See for how RUE supports real-time text without the data channel. Implementations MUST support SIP outbound (please also refer to ).

Media This specification adopts the media specifications for WebRTC . 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.

SRTP and SRTCP Implementations MUST support , except that MediaStreamTracks are not used. Implementations MUST conform to .

Text-Based Communication Implementations MUST support real-time text via T.140 media. One original and two redundant generations MUST be transmitted and supported with a 300 ms transmission interval. Implementations MUST support , especially for emergency calls. Note that 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 real-time text. Transport of T.140 real-time text in WebRTC is specified in , using the WebRTC data channel. also has some advice on how gateways between and should operate. It is RECOMMENDED that , including multiparty support, be used for communication with browser-based WebRTC implementations. Implementations MUST support .

Video Implementations MUST conform to with the following exceptions: only H.264, as specified in , 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.

Audio Implementations MUST conform to .

DTMF Digits Implementations MUST support the "audio/telephone-event" media type. They MUST support conveying event codes 0 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of . Handling of other tones is OPTIONAL.

Session Description Protocol The SDP offers and answers MUST conform to the SDP rules in except that the RUE interface uses SIP transport for SDP. The SDP for real-time text MUST specify the T.140 payload type .

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 .

Negative Acknowledgement, Picture Loss Indicator, and Full Intraframe Request Features The NACK, FIR, and Picture Loss Indicator (PLI) features, as described in and , 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 . 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 .

Contacts

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 . The configuration (see ) 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 , 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.

Contacts Import/Export Service Implementations MUST be able to export/import the list of contacts in xCard 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.

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 for how the URI to reach the retrieval interface is obtained. Implementations MUST support subscriptions to "message-summary" events 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 ) 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 .

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.

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 ). 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 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 ). 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.

Example of a ProviderList JSON Object { "providers": [ { "name": "Red", "entryPoint": "red.example.net" }, { "name": "Green", "entryPoint": "green.example.net" }, { "name": "Blue", "entryPoint": "blue.example.net" } ] }

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 interface description. In that interface description, the "servers" component string includes an occurrence of "localhost". The entry point string obtained from the provider list () 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="t65667Ajjss90uuuDisKt8999"&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.

Provider Configuration

• signup: (OPTIONAL) an array of JSON objects consisting of:
  • language: entry from the IANA "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 .
• 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 () 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.

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.

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.

Example of a Version JSON Object { "versions": [ { "major": 1, "minor": 6 }, { "major": 2, "minor": 13 }, { "major": 3, "minor": 2 } ] }

Examples

Example JSON Provider Configuration Payload { "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"} ] }

Example JSON RUE 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"} ] }

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.

OpenAPI Interface Descriptions The interfaces in Sections and are formally specified with OpenAPI 3.0 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.

Provider List

Provider List OpenAPI Description (RueProviderList.yaml) 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

Configuration

Configuration OpenAPI Description (RueConfiguration.yaml) 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

IANA Considerations

RUE Provider List Registry IANA has created the "RUE Provider List" registry. The registration policy is "Expert Review" . 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

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 . 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

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.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK] This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS-TRACK] This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK] The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS-TRACK] This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK] This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK] The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS-TRACK] This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. [STANDARDS-TRACK] This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative. [STANDARDS-TRACK] The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. [STANDARDS-TRACK] This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community. This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK] This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK] This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text. This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK] The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. [STANDARDS-TRACK] Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK] This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833. This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use. This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS-TRACK] RFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI. [STANDARDS-TRACK] This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK] This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. This memo provides information for the Internet community. This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS-TRACK] The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK] A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) or SIPS (secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only a Record-Route rewriting solution. [STANDARDS-TRACK] This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. [STANDARDS-TRACK] This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK] This document defines the XML schema of the vCard data format. [STANDARDS-TRACK] This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK] This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK] This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK] This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services. The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases. The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes. This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters. When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. This document outlines the audio codec and processing requirements for WebRTC endpoints. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism. This document updates RFC 3261 by modifying the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to replace the obsolete MD5 algorithm. This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC). This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols. The framework for Web Real-Time Communication (WebRTC) provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context and gives requirements for which RTP features, profiles, and extensions need to be supported. This document describes the data transport protocols used by Web Real-Time Communication (WebRTC), including the protocols used for interaction with intermediate boxes such as firewalls, relays, and NAT boxes. This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. This document obsoletes RFCs 5245 and 6336. This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for real-time text using the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) and how the Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as a T.140 data channel. This document updates RFC 8373 to specify its use with WebRTC data channels. This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. This document provides enhancements of real-time text (as specified in RFC 4103) suitable for mixing in a centralized conference model, enabling source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the Contributing Source (CSRC) list in the Real-time Transport Protocol (RTP) packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two-party sessions. Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP-mixer model. The RTP-mixer model was selected to be used for the fully specified solution in this document because it can be applied to a wide range of existing RTP implementations. A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by the use of a Session Description Protocol (SDP) (RFC 8866) media attribute, "rtt-mixer". This document updates RFC 4103 ("RTP Payload for Text Conversation"). A specification for how a mixer can format text for the case when the endpoint is not multiparty aware is also provided. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. Informative References This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226.

Acknowledgements and provided many helpful edits to prior draft versions of this document. provided extensive reviews and comments.

Author's Address

470 Conrad Dr Mars PA 16046 United States of America br@brianrosen.net