rfc9248.original   rfc9248.txt 
rum B. Rosen Internet Engineering Task Force (IETF) B. Rosen
Internet-Draft 17 February 2022 Request for Comments: 9248 June 2022
Intended status: Standards Track Category: Standards Track
Expires: 21 August 2022 ISSN: 2070-1721
Interoperability Profile for Relay User Equipment Interoperability Profile for Relay User Equipment
draft-ietf-rum-rue-11
Abstract Abstract
Video Relay Service (VRS) is a term used to describe a method by Video Relay Service (VRS) is a term used to describe a method by
which a hearing person can communicate with a deaf, hard of hearing which a hearing person can communicate with a sign language speaker
or hearing impaired user using an interpreter ("Communications who is deaf, deafblind, or hard of hearing (HoH) or has a speech
Assistant") connected via a videophone to the deaf/hard of hearing/ disability using an interpreter (i.e., a Communications Assistant
hearing impaired user and an audio telephone call to the hearing (CA)) connected via a videophone to the sign language speaker and an
user. The CA interprets using sign language on the videophone link audio telephone call to the hearing user. The CA interprets using
and voice on the telephone link. Often the interpreters may be sign language on the videophone link and voice on the telephone link.
employed by a company or agency termed a "provider" in this document. Often the interpreters may be employed by a company or agency, termed
The provider also provides a video service that allows users to a "provider" in this document. The provider also provides a video
connect video devices to their service, and subsequently to CAs and service that allows users to connect video devices to their service
other deaf/hard of hearing/hearing impaired users. It is desirable and subsequently to CAs and other sign language speakers. It is
that the videophones used by the deaf, hard of hearing or hearing desirable that the videophones used by the sign language speaker
impaired user conform to a standard so that any device may be used conform to a standard so that any device may be used with any
with any provider and that direct video calls between deaf, hard of provider and that direct video calls between sign language speakers
hearing or hearing impaired users work. This document describes the work. This document describes the interface between a videophone and
interface between a videophone and a provider. a provider.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 21 August 2022. 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 Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Language
4. General Requirements . . . . . . . . . . . . . . . . . . . . 6 4. General Requirements
5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 5. SIP Signaling
5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Registration
5.2. Session Establishment . . . . . . . . . . . . . . . . . . 10 5.2. Session Establishment
5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 10 5.2.1. Normal Call Origination
5.2.2. Dial-Around Origination . . . . . . . . . . . . . . . 10 5.2.2. Dial-Around Origination
5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 12 5.2.3. RUE Contact Information
5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 12 5.2.4. Incoming Calls
5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 12 5.2.5. Emergency Calls
5.3. Mid-Call Signaling . . . . . . . . . . . . . . . . . . . 13 5.3. Mid-Call Signaling
5.4. URI Representation of Phone Numbers . . . . . . . . . . . 13 5.4. URI Representation of Phone Numbers
5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Transport
6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Media
6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 14 6.1. SRTP and SRTCP
6.2. Text-Based Communication . . . . . . . . . . . . . . . . 15 6.2. Text-Based Communication
6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Video
6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Audio
6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 15 6.5. DTMF Digits
6.6. Session Description Protocol . . . . . . . . . . . . . . 15 6.6. Session Description Protocol
6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.7. Privacy
6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 6.8. Negative Acknowledgement, Picture Loss Indicator, and Full
Intraframe Request Features . . . . . . . . . . . . . . . 16 Intraframe Request Features
7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Contacts
7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 16 7.1. CardDAV Login and Synchronization
7.2. Contacts Import/Export Service . . . . . . . . . . . . . 17 7.2. Contacts Import/Export Service
8. Video Mail . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Video Mail
9. Provisioning and Provider Selection . . . . . . . . . . . . . 18 9. Provisioning and Provider Selection
9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 18 9.1. RUE Provider Selection
9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 20 9.2. RUE Configuration Service
9.2.1. Provider Configuration . . . . . . . . . . . . . . . 21 9.2.1. Provider Configuration
9.2.2. RUE Configuration . . . . . . . . . . . . . . . . . . 21 9.2.2. RUE Configuration
9.2.3. Versions . . . . . . . . . . . . . . . . . . . . . . 23 9.2.3. Versions
9.2.4. Examples . . . . . . . . . . . . . . . . . . . . . . 24 9.2.4. Examples
9.2.5. Using the Provider Selection and RUE Configuration 9.2.5. Using the Provider Selection and RUE Configuration
Services Together . . . . . . . . . . . . . . . . . . 25 Services Together
9.3. OpenAPI Interface Descriptions . . . . . . . . . . . . . 26 9.3. OpenAPI Interface Descriptions
9.3.1. Provider List . . . . . . . . . . . . . . . . . . . . 26 9.3.1. Provider List
9.3.2. Configuration . . . . . . . . . . . . . . . . . . . . 27 9.3.2. Configuration
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations
10.1. RUE Provider List Registry . . . . . . . . . . . . . . . 33 10.1. RUE Provider List Registry
10.2. Registration of rue-owner Value of the purpose 10.2. Registration of Rue-Owner Value of the Purpose Parameter
Parameter . . . . . . . . . . . . . . . . . . . . . . . 33 11. Security Considerations
11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. Normative References
12. Normative References . . . . . . . . . . . . . . . . . . . . 34 13. Informative References
13. Informative References . . . . . . . . . . . . . . . . . . . 40 Acknowledgements
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41 Author's Address
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Video Relay Service (VRS) is a form of Telecommunications Relay Video Relay Service (VRS) is a form of Telecommunications Relay
Service (TRS) that enables persons with hearing disabilities who use Service (TRS) that enables people with hearing disabilities who use
sign language, such as American Sign Language (ASL), to communicate sign language, such as American Sign Language (ASL), to communicate
with voice telephone users through video equipment. These services with voice telephone users through video equipment. These services
also enable communication between such individuals directly in also enable communication between such individuals directly in
suitable modalities, including any combination of sign language via suitable modalities, including any combination of sign language via
video, real-time text (RTT), and speech. video, real-time text, and speech.
This Interoperability Profile for Relay User Equipment (RUE) is a This interoperability profile for Relay User Equipment (RUE) is a
profile of the Session Initiation Protocol (SIP) and related media profile of the Session Initiation Protocol (SIP) and related media
protocols that enables end-user equipment registration and calling protocols that enables end-user equipment registration and calling
for VRS calls. It specifies the minimal set of call flows, Internet for VRS calls. It specifies the minimal set of call flows and IETF
Engineering Task Force (IETF) and ITU-T standards that must be and ITU-T standards that must be supported, provides guidance where
supported, provides guidance where the standards leave multiple the standards leave multiple implementation options, and specifies
implementation options, and specifies minimal and extended minimal and extended capabilities for RUE calls.
capabilities for RUE calls.
Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/ Both subscriber-to-provider (interpreted) and direct subscriber-to-
HoH calls are supported on this interface. While there are some subscriber calls are supported on this interface. While there are
accommodations in this document to maximize backwards compatibility some accommodations in this document to maximize backwards
with other devices and services that are used to provide VRS service, compatibility with other devices and services that are used to
backwards compatibility is not a requirement, and some interwork may provide VRS service, backwards compatibility is not a requirement,
be required to allow direct video calls to older devices. This and some interwork may be required to allow direct video calls to
document only describes the interface between the device and the older devices. This document only describes the interface between
provider, and not any other interface the provider may have. 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 following illustrates a typical relay call. The RUE device and
the Commincations Assistant (sign language interpretter) have the communications assistant (sign language interpreter) have
videophones. The Hearing User has a telephone (mobile or fixed). videophones. The hearing user has a telephone (mobile or fixed).
||== RUE Interface (this document) ||== RUE Interface (this document)
|| ||
\/ \/
+----+ +------+ - +--------+ - +-------+ +------+ +------+ - +--------+ - +-------+
|Deaf| |RUE | ( ) |Provider| ( ) |Hearing| |User | |RUE | ( ) |Provider| ( ) |User |
|User|<->|Device|<-(Internet)->| |<-( PSTN )->|User | |who is| |Device|<-(Internet)->| | |who is |
+----+ +------+ -------- +--------+ ------ +-------+ |Deaf |<->| | | |<-( PSTN )->|Hearing|
+------+ +------+ -------- +--------+ ------ +-------+
^ ^
| |
+--------------+ +--------------+
|Communications| |Communications|
|Assistant | |Assistant |
+--------------+ +--------------+
2. Terminology 2. Terminology
Communication Assistant (CA): A sign-language interpreter working for Communications Assistant (CA):
a VRS provider, providing functionally equivalent phone service. A sign-language interpreter working for a VRS provider, providing
functionally equivalent phone service.
Communication modality (modality): A specific form of communication Communication modality (modality):
that may be employed by two users, e.g., English voice, Spanish A specific form of communication that may be employed by two
voice, American Sign Language, English lip-reading, or French real- users, e.g., English voice, Spanish voice, American Sign Language,
time-text. Here, one communication modality is assumed to encompass English lipreading, or French real-time text. Here, one
both the language and the way that language is exchanged. For communication modality is assumed to encompass both the language
example, English voice and French voice are two different and the way that language is exchanged. For example, English
communication modalities. voice and French voice are two different communication modalities.
Default video relay service: The video relay service operated by a Default video relay service:
subscriber's default VRS provider. The video relay service operated by a subscriber's default VRS
provider.
Default video relay service provider (default provider): The VRS Default video relay service provider (default provider):
provider that registers, and assigns a telephone number to a specific The VRS provider that registers and assigns a telephone number to
subscriber, and by default provides the VRS for incoming voice calls a specific subscriber and, by default, provides the VRS for
to the user. The default provider also by default provides VRS for incoming voice calls to the user. The default provider, also by
outgoing relay calls. The user can have more than one telephone default, provides the VRS for outgoing relay calls. The user can
number and each has a default provider. have more than one telephone number, and each has a default
provider.
Outbound Dial-around call: A relay call where the subscriber Outbound dial-around call:
specifies the use of a VRS provider other than the default VRS A relay call where the subscriber specifies the use of a VRS
provider. This can be accomplished by the user dialing a "front- provider other than the default VRS provider. This can be
door" number for a VRS provider and signing or texting a phone number accomplished by the user dialing a "front-door" number for a VRS
to call ("two-stage"). Alternatively, this can be accomplished by provider and signing or texting a phone number to call ("two-
the user's RUE software instructing the server of its default VRS stage"). Alternatively, this can be accomplished by the user's
provider to automatically route the call through the alternate RUE software instructing the server of its default VRS provider to
provider to the desired public switched telephone network (PSTN) automatically route the call through the alternate provider to the
directory number ("one-stage"). Dial-around is per-call -- for any desired Public Switched Telephone Network (PSTN) directory number
call, a user can use the default VRS provider or any dial-around VRS ("one-stage"). Dial-around is per call; for any call, a user can
provider. use the default VRS provider or any dial-around VRS provider.
Full Intra Request (FIR): A request to a video media sender, Full Intra Request (FIR):
requiring that media sender to send a Decoder Refresh Point at the A request to a video media sender, requiring that media sender to
earliest opportunity. FIR is sometimes known as "instantaneous send a decoder refresh point at the earliest opportunity. FIR is
decoder refresh request", "video fast update request", or "fast sometimes known as "instantaneous decoder refresh request", "video
update request". fast update request", or "fast update request".
Point-to-Point Call (P2P Call): A call between two RUEs, without Point-to-Point Call (P2P Call):
including a CA. A call between two RUEs, without including a CA.
Relay call: A call that allows persons with hearing or speech Relay call:
disabilities to use a RUE to talk to users of conventional voice A call that allows people with hearing or speech disabilities to
services with the aid of a communication assistant (CA) to relay the use a RUE to talk to users of conventional voice services with the
communication. aid of a CA to relay the communication.
Relay service (RS): A service that allow a registered subscriber to Relay service (RS):
use a RUE to make and receive relay calls, point-to-point calls, and A service that allows a registered subscriber to use a RUE to make
relay-to-relay calls. The functions provided by the relay service and receive relay calls, point-to-point calls, and relay-to-relay
include the provision of media links supporting the communication calls. The functions provided by the relay service include the
modalities used by the caller and callee, and user registration and provision of media links supporting the communication modalities
validation, authentication, authorization, automatic call distributor used by the caller and callee, user registration and validation,
(ACD) platform functions, routing (including emergency call routing), authentication, authorization, automatic call distributor (ACD)
call setup, mapping, call features (such as call forwarding and video platform functions, routing (including emergency call routing),
mail), and assignment of CAs to relay calls. 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 provider (provider):
relay service. A subscriber selects a relay service provider to An organization that operates a relay service. A subscriber
assign and register a telephone number for their use, to register selects a relay service provider to assign and register a
with for receipt of incoming calls, and to provide the default telephone number for their use, to register with for receipt of
service for outgoing calls. incoming calls, and to provide the default service for outgoing
calls.
Relay user: Please refer to "subscriber". Relay user:
Please refer to "subscriber".
Relay user E.164 Number (user E.164): The telephone number (in ITU-T Relay user E.164 Number (user E.164):
E.164 format) assigned to the user. 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 Relay User Equipment (RUE):
features to support a subscriber in requesting, receiving and using A SIP user agent (UA) enhanced with extra features to support a
relay calls. A RUE may take many forms, including a stand-alone subscriber in requesting, receiving, and using relay calls. A RUE
device; an application running on a general-purpose computing device may take many forms, including a stand-alone device; an
such as a laptop, tablet or smartphone; or proprietary equipment application running on a general-purpose computing device, such as
connected to a server that provides the RUE interface. 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 interface:
RUE and a VRS provider who supports it 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 Sign language:
to convey meaning including, but not limited to, American Sign A language that uses hand gestures and body language to convey
Language (ASL). meaning, including, but not limited to, American Sign Language
(ASL).
Subscriber: An individual who has registered with a provider and who Subscriber:
obtains service by using relay user equipment. This is the An individual who has registered with a provider and who obtains
conventional telecom term for an end-user customer, which in our case service by using a RUE. This is the conventional telecom term for
is a relay user. A user may be a subscriber to more than one VRS an end-user customer, which in this case is a relay user. A user
provider. may be a subscriber to more than one VRS provider.
Video relay service (VRS): A relay service for people with hearing or Video Relay Service (VRS):
speech disabilities who use sign language to communicate using video A relay service for people with hearing or speech disabilities who
equipment (video RUE) with other people in real time. The video link use sign language to communicate using video equipment (video RUE)
allows the CA to view and interpret the subscriber's signed with other people in real time. The video link allows the CA to
conversation and relay the conversation back and forth with the other view and interpret the subscriber's signed conversation and relay
party. the conversation back and forth with the other party.
3. Requirements Language 3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. Lower- or mixed-case uses of these key capitals, as shown here. Lower- or mixed-case uses of these key
words are not to be interpreted as carrying special significance. words are not to be interpreted as carrying special significance.
4. General Requirements 4. General Requirements
All HTTP/HTTPS [RFC7230] and [RFC2818] connections specified All HTTP/HTTPS [RFC7230] [RFC2818] connections specified throughout
throughout this document MUST use HTTPS. Both HTTPS and all SIP this document MUST use HTTPS. Both HTTPS and all SIP connections
connections MUST use TLS conforming to at least [RFC7525] and MUST MUST use TLS conforming to at least [RFC7525] and MUST support
support [RFC8446]. [RFC8446].
All text data payloads not otherwise constrained by a specification All text data payloads not otherwise constrained by a specification
in another standards document MUST be encoded as Unicode UTF-8. in another standards document MUST be encoded as Unicode UTF-8.
Implementations MUST support IPv4 and IPv6. Dual stack support is Implementations MUST support IPv4 and IPv6. Dual-stack support is
NOT required and provider implementations MAY support separate NOT required, and provider implementations MAY support separate
interfaces for IPv4 and IPv6 by having more than one server in the 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 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 each server DNS record but not both. The same version of IP MUST be
used for both signaling and media of a call unless ICE ([RFC8445]) is used for both signaling and media of a call unless Interactive
used, in which case candidates may explicitly offer IPv4, IPv6 or Connectivity Establishment (ICE) [RFC8445] is used; in which case,
both for any media stream. candidates may explicitly offer IPv4, IPv6, or both for any media
stream.
5. SIP Signaling 5. SIP Signaling
Implementations of the RUE Interface MUST conform to the following Implementations of the RUE interface MUST conform to the following
core SIP standards: core SIP standards:
* [RFC3261] (Base SIP) * [RFC3261] (Base SIP)
* [RFC3263] (Locating SIP Servers) * [RFC3263] (Locating SIP Servers)
* [RFC3264] (Offer/Answer) * [RFC3264] (Offer/Answer)
* [RFC3840] (User Agent Capabilities) * [RFC3840] (User Agent Capabilities)
* [RFC5626] (Outbound) * [RFC5626] (Outbound)
* [RFC8866] (Session Description Protocol) * [RFC8866] (Session Description Protocol)
* [RFC3323] (Privacy) * [RFC3323] (Privacy)
* [RFC3605] (RTCP Attribute in SDP) * [RFC3605] (RTCP Attribute in SDP)
* [RFC6665] (SIP Events)
* [RFC3311] (UPDATE Method) * [RFC3311] (UPDATE Method)
* [RFC5393] (Loop-Fix) * [RFC5393] (Loop-Fix)
* [RFC5658] (Record Route fix) * [RFC5658] (Record-Route Fix)
* [RFC5954] (ABNF fix) * [RFC5954] (ABNF Fix)
* [RFC3960] (Early Media) * [RFC3960] (Early Media)
* [RFC6442] (Geolocation header field) * [RFC6442] (Geolocation Header Field)
In the above documents the RUE device conforms to the requirements of In the above documents, the RUE device conforms to the requirements
a SIP user Agent, and the provider conforms to the requirements of of a SIP user agent, and the provider conforms to the requirements of
Registrar and Proxy Server where the document specifies different the registrar and proxy server where the document specifies different
behavior for different roles. The only requirement on providers for behavior for different roles. For providers offering a video mail
RFC6665 (Events) is support for the Message Waiting Indicator (See service, [RFC6665] (SIP Events) MUST be implemented to support the
Section 8), which is optional and providers not supporting video mail Message-Waiting Indicator (MWI) (see Section 8).
need not support RFC6665.
In addition, implementations MUST conform to: In addition, implementations MUST conform to:
* [RFC3327] (Path) * [RFC3327] (Path Header Field)
* [RFC8445] and [RFC8839] (ICE) * [RFC8445] and [RFC8839] (ICE)
* [RFC3326] (Reason header field)
* [RFC3326] (Reason Header Field)
* [RFC3515] (REFER Method) * [RFC3515] (REFER Method)
* [RFC3891] (Replaces Header field) * [RFC3891] (Replaces Header Field)
* [RFC3892] (Referred-By) * [RFC3892] (Referred-By Header Field)
Implementations MUST implement full ICE, although they MAY interwork Implementations MUST implement full ICE, although they MAY interwork
with User Agents that implement ICE-lite. with user agents that implement ICE-lite.
Implementations MUST include a "User-Agent" header field uniquely Implementations MUST include a "User-Agent" header field uniquely
identifying the RUE application, platform, and version in all SIP identifying the RUE application, platform, and version in all SIP
requests, and MUST include a "Server" header field with the same requests and MUST include a "Server" header field with the same
content in SIP responses. content in SIP responses.
Implementations intended to support mobile platforms MUST support Implementations intended to support mobile platforms MUST support
[RFC8599] and MUST use it as at least one way to support waking up [RFC8599] and MUST use it as at least one way to support waking up
the client from background state. the client from the background state.
The SIP signaling for registration and placing/receiving calls The SIP signaling for registration and placing/receiving calls
depends on configuration of various values into the RUE device. depends on the configuration of various values into the RUE device.
Section 9.2 describes the configuration mechanism which provides Section 9.2 describes the configuration mechanism that provides
values that are used in the signaling. When the device starts, the values that are used in the signaling. When the device starts, the
configuration mechanism is run which retrieves the configuration configuration mechanism is run, which retrieves the configuration
data, and then SIP registration occurs using the values from the data; then, SIP registration occurs using the values from the
configuration. After registration, calls may be sent or received by configuration. After registration, calls may be sent or received by
the RUE device. the RUE device.
5.1. Registration 5.1. Registration
The RUE MUST register with a SIP registrar, following [RFC3261] and The RUE MUST register with a SIP registrar, following [RFC3261] and
[RFC5626] at a provider it has an account with. If the configuration [RFC5626], at a provider it has an account with. If the
(see Section 9.2) contains multiple "outbound-proxies" in configuration (see Section 9.2) contains multiple "outbound-proxies"
"RueConfigurationData", then the RUE MUST use them as specified in in "RueConfigurationData", then the RUE MUST use them as specified in
[RFC5626] to establish multiple flows. [RFC5626] to establish multiple flows.
The Request-URI for the REGISTER request MUST contain the "provider- The Request-URI for the REGISTER request MUST contain the "provider-
domain" from the configuration. The To-URI and From-URI MUST be domain" from the configuration. The To URI and From URI MUST be
identical URIs, formatted as follows: identical URIs and formatted as follows:
* if "user-name" is provided:"username@provider-domain"; * if "user-name" is provided: "username@provider-domain"
* if "user-name" is not provided: as specified in Section 5.4, using * if "user-name" is not provided: as specified in Section 5.4, use
"phone-number" and "provider-domain" from the configuration. "phone-number" and "provider-domain" from the configuration
The RUE determines the URI to resolve by initially determining if one The RUE determines the URI to resolve by initially determining if one
or more outbound proxies are+ configured. If there are, the URI will or more "outbound-proxies" are configured. If they are configured,
be that of one of the "outbound-proxies". If no "outbound-proxies" the URI will be that of one of the "outbound-proxies". If no
are configured, the URI will be the Request-URI from the REGISTER "outbound-proxies" are configured, the URI will be the Request-URI
request. The RUE extracts the domain from that URI and consults the from the REGISTER request. The RUE extracts the domain from that URI
DNS record for that domain. The DNS entry MUST contain NAPTR records and consults the DNS record for that domain. The DNS entry MUST
conforming to RFC3263. One of those NAPTR records MUST specify TLS contain NAPTR records conforming to [RFC3263]. One of those NAPTR
as the preferred transport for SIP. For example, a DNS NAPTR query records MUST specify TLS as the preferred transport for SIP. For
for "sip: p1.red.example.net" could return: 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 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._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 If the RUE receives a 439 (First Hop Lacks Outbound Support) response
to a REGISTER request, it MUST re-attempt registration without using to a REGISTER request, it MUST reattempt registration without using
the outbound mechanism. the outbound mechanism.
The registrar MAY authenticate the RUE using SIP digest The registrar MAY authenticate the RUE using SIP digest
authentication. The credentials to be used MUST come from the authentication. The credentials to be used MUST come from the
configuration Section 9.2: "user-name" if provided or "phone-number" configuration in Section 9.2: "user-name" if provided or "phone-
if user-name is not provided, and "sip-password". This "user- number" if user-name is not provided, and "sip-password". This
name"/"sip-password" combination SHOULD NOT be the same as that used "user-name"/"sip-password" combination SHOULD NOT be the same as that
for other purposes, except as expressly described below, such as used for other purposes, except as expressly described below, such as
retrieving the RUE configuration or logging into the Provider's retrieving the RUE configuration or logging into the provider's
customer service portal. [RFC8760] MUST be supported by all customer service portal. [RFC8760] MUST be supported by all
implementations and SHA-512 digest algorithms MUST be supported. implementations, and SHA-512 digest algorithms MUST be supported.
If the registration request fails with an indication that credentials If the registration request fails with an indication that credentials
from the configuration are invalid, then the RUE MUST retrieve a from the configuration are invalid, then the RUE MUST retrieve a
fresh version of the configuration. If credentials from a freshly fresh version of the configuration. If credentials from a freshly
retrieved configuration are found to be invalid, then the RUE MUST retrieved configuration are found to be invalid, then the RUE MUST
cease attempts to register and inform the RUE User of the problem. cease attempts to register and inform the RUE user of the problem.
Support for multiple simultaneous registrations with multiple Support for multiple simultaneous registrations with multiple
providers by the RUE is OPTIONAL for the RUE (and providers do not providers by the RUE is OPTIONAL for the RUE (and providers do not
need any support for this option). need any support for this option).
Multiple simultaneous RUE SIP registrations from different RUE Multiple simultaneous RUE SIP registrations from different RUE
devices with the same SIP URI SHOULD be permitted by the provider. devices with the same SIP URI SHOULD be permitted by the provider.
The provider MAY limit the total number of simultaneous The provider MAY limit the total number of simultaneous
registrations. When a new registration request is received that registrations. When a new registration request is received that
results in exceeding the limit on simultaneous registrations, the results in exceeding the limit on simultaneous registrations, the
skipping to change at page 10, line 21 skipping to change at line 445
5.2.1. Normal Call Origination 5.2.1. Normal Call Origination
After initial SIP registration, the RUE adheres to SIP [RFC3261] After initial SIP registration, the RUE adheres to SIP [RFC3261]
basic call flows, as documented in [RFC3665]. basic call flows, as documented in [RFC3665].
A RUE device MUST route all outbound calls through an outbound proxy A RUE device MUST route all outbound calls through an outbound proxy
if configured. if configured.
The SIP URIs in the To field and the Request-URI MUST be formatted as The SIP URIs in the To field and the Request-URI MUST be formatted as
specified in subsection Section 5.4 using the destination phone specified in Section 5.4 using the destination phone number or as SIP
number, or as SIP URIs, as provided in the configuration URIs as provided in the configuration (Section 9.2). The domain
(Section 9.2). The domain field of the URIs SHOULD be the "provider- field of the URIs SHOULD be the "provider-domain" from the
domain" from the configuration (e.g., configuration (e.g., sip:+15551234567@red.example.com;user=phone),
sip:+15551234567@red.example.com;user=phone) except that an anonymous except that an anonymous call would not use the provider domain.
call would not use the provider domain.
Anonymous calls MUST be supported by all implementations. An Anonymous calls MUST be supported by all implementations. An
anonymous call is signaled per [RFC3323]. anonymous call is signaled per [RFC3323].
The From-URI MUST be formatted as specified in Section 5.4, using the The From URI MUST be formatted as specified in Section 5.4, using the
phone-number and "provider-domain" from the configuration. It SHOULD "phone-number" and "provider-domain" from the configuration. It
also contain the display-name from the configuration when present. SHOULD also contain the display-name from the configuration when
(Please refer to Section 9.2.) present. (Please refer to Section 9.2.)
Negotiated media MUST follow the requirements specified in Section 6 Negotiated media MUST follow the requirements specified in Section 6
of this document. of this document.
To allow time to time out an unanswered call and direct it to a 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 videomail server, the User Agent Client MUST NOT impose a time limit
less than the default SIP Invite transaction timeout of 3 minutes. less than the default SIP INVITE transaction timeout of 3 minutes.
5.2.2. Dial-Around Origination 5.2.2. Dial-Around Origination
Providers and RUE devices MUST support both One-Stage and Two-Stage Providers and RUE devices MUST support both one-stage and two-stage
dial-around dial-around.
Outbound dial-around calls allow a RUE user to select any provider to Outbound dial-around calls allow a RUE user to select any provider to
provide interpreting services for any call. "Two-stage" dial-around provide interpreting services for any call. "Two-stage" dial-around
calls involve the RUE calling a telephone number that reaches the calls involve the RUE calling a telephone number that reaches the
dial-around provider and using signing or DTMF to provide the called dial-around provider and using signing or dual-tone multi-frequency
party telephone number. In two-stage dial-around, the To URI is the (DTMF) to provide the called party's telephone number. In two-stage
"frontDoor" URI (see Section 9.2) in "ProviderConfigurationData" of dial-around, the To URI is the "front-door" URI (see Section 9.2) in
the dial-around provider. The RUE Provider Selection service "ProviderConfigurationData" of the dial-around provider. The RUE
(Section 9.1) can be used by the RUE to obtain a list of providers Provider Selection service (Section 9.1) can be used by the RUE to
and then the Provider Configuration (Section 9.2.1) can be used to obtain a list of providers; then, the provider configuration
find the front door URI for each of these providers. (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 telephone 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 number is provided in the To URI and the Request-URI, using the
domain of the dial-around provider. domain of the dial-around provider.
For one-stage dial-around, the RUE MUST follow the procedures in 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 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 SIP URIs in the To field and the Request-URI MUST be the domain of
the dial-around provider, discovered according to Section 9.1. the dial-around provider discovered as described in Section 9.1.
The following is a partial example of a one-stage dial-around call 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 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 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 relay service. Only important details of the messages are shown, and
many header fields have been omitted: many header fields have been omitted:
One-Stage Dial-Around
,-+-. ,----+----. ,-----+-----. ,-+-. ,----+----. ,-----+-----.
|RUE| |Default | |Dial-Around| |RUE| |Default | |Dial-Around|
| | |Provider | | Provider | | | |Provider | | Provider |
`-+-' `----+----' `-----+-----' `-+-' `----+----' `-----+-----'
| | | | | |
| [1] INVITE | | | [1] INVITE | |
|-------------->| [2] INVITE | |-------------->| [2] INVITE |
| |-------------->| | |-------------->|
Message Details: Message Details:
skipping to change at page 11, line 50 skipping to change at line 522
To: <sip:+15551234567@green.example.net;user=phone> To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" <sip:+15552220001@red.example.net;user=phone> From: "Bob Smith" <sip:+15552220001@red.example.net;user=phone>
[2] INVITE Default Provider -> Dial-Around Provider [2] INVITE Default Provider -> Dial-Around Provider
INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
To: <sip:+15551234567@green.example.net;user=phone> To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" sip:+15552220001@red.example.net;user=phone From: "Bob Smith" sip:+15552220001@red.example.net;user=phone
P-Asserted-Identity: sip:+15552220001@red.example.net P-Asserted-Identity: sip:+15552220001@red.example.net
Figure 1 Figure 1: One-Stage Dial-Around
5.2.3. RUE Contact Information 5.2.3. RUE Contact Information
To identify the owner of a RUE, the initial INVITE for a call from a 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 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 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 "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 latter is defined by [RFC2392] to locate message body parts. This
URI type is present in a SIP message to convey the RUE ownership 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 as a MIME body. The form of the RUE ownership
information is a xCard [RFC6351]. Please refer to [RFC6442] for an information is an xCard [RFC6351]. Please refer to [RFC6442] for an
example of using Content-Indirect URLs in SIP messages. Note that example of using content indirection URLs in SIP messages. Note that
use of the Content-Indirect URL usually implies multiple message use of the content indirection URL usually implies multiple message
bodies ("mime/multipart"). The RUE owner is the entity that has bodies ("mime/multipart"). The RUE owner is the entity that has
local control over the device which is not necessarily the legal local control over the device that is not necessarily the legal owner
owner of the equipment. It often is the user, but that is not of the equipment. It often is the user, but that is not necessarily
necessarily true. While no minimum fields in the xCard are true. While no minimum fields in the xCard are specified, the name,
specified, the name, address, phone number and email address of the address, phone number, and email address of the RUE owner are
RUE owner are expected to be supplied. expected to be supplied.
5.2.4. Incoming Calls 5.2.4. Incoming Calls
The RUE MUST only accept inbound calls sent to it by a proxy The RUE MUST only accept inbound calls sent to it by a proxy
mentioned in the configuration. mentioned in the configuration.
If Multiple simultaneous RUE SIP registrations from different RUE If multiple simultaneous RUE SIP registrations from different RUE
devices with the same SIP URI exist, the provider MUST parallel fork 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 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 The first RUE to reply with a 200 OK answers the call, and the
provider MUST CANCEL other call branches. provider MUST cancel other call branches using a CANCEL request.
5.2.5. Emergency Calls 5.2.5. Emergency Calls
Implementations MUST conform to [RFC6881] for handling of emergency Implementations MUST conform to [RFC6881] for handling of emergency
calls, except that if the device is unable to determine its own calls, except that if the device is unable to determine its own
location, it MAY send the emergency call without a Geolocation header location, it MAY send the emergency call without a Geolocation header
field and without a Route header field (since it would be unable to field and without a Route header field (since it would be unable to
query the LoST server for a route per RFC6881). If an emergency call query the Location-to-Service Translation (LoST) server for a route,
arrives at the provider without a Geolocation header field, the per [RFC6881]). If an emergency call arrives at the provider without
provider MUST supply location by adding the Geolocation header field, a Geolocation header field, the provider MUST supply location by
and MUST supply the route by querying the LoST server with that adding the Geolocation header field and MUST supply the route by
location. querying the LoST server with that location.
If the emergency call is to be handled using existing country If the emergency call is to be handled using existing country-
specific procedures, the provider is responsible for modifying the specific procedures, the provider is responsible for modifying the
INVITE to conform to the country-specific requirements. In this INVITE to conform to the country-specific requirements. In this
case, location MAY be extracted from the RFC6881 conformant INVITE case, the location MAY be extracted from the [RFC6881] conformant
and used to propagate it to the appropriate country-specific INVITE and used to propagate it to the appropriate country-specific
entities. If the configuration specifies it, an implementation of a entities. If the configuration specifies it, an implementation of a
RUE device MAY send a Geolocation header field containing its RUE device MAY send a Geolocation header field containing its
location in the REGISTER request. If implemented, users MUST be location in the REGISTER request. If implemented, users MUST be
offered an opt-out. Country-specific procedures might require the offered an opt-out. Country-specific procedures might require the
location to be pre-loaded in some entity prior to placing an location to be preloaded in some entity prior to placing an emergency
emergency call; however, the RUE may have a more accurate and timely call; however, the RUE may have a more accurate and timely device
device location than the manual, pre-loaded entry. That information location than the manual, preloaded entry. That information MAY be
MAY be used to populate the location to appropriate country-specific used to populate the location to appropriate country-specific
entities. Re-registration SHOULD be used to update the location, so entities. Re-registration SHOULD be used to update the location, so
long as the rate of re-registration is limited if the device is long as the rate of re-registration is limited if the device is
moving. moving.
Implementations MUST implement Additional Data, [RFC7852]. RUE Implementations MUST implement additional data [RFC7852]. RUE
devices MUST implement Data Provider, Device Information and Owner/ devices MUST implement data provider information, device information,
Subscriber Information blocks. and owner/subscriber information blocks.
5.3. Mid-Call Signaling 5.3. Mid-Call Signaling
Implementations MUST support re-INVITE to renegotiate media session Implementations MUST support re-INVITE to renegotiate media session
parameters (among other uses). Per Section 6.1, implementations MUST parameters (among other uses). Per Section 6.8, implementations MUST
be able to support an INFO request for full frame refresh for devices be able to support an INFO message for full frame refresh for devices
that do not support RTCP mechanisms (please refer to Section 6.8). that do not support SRTCP (please refer to Section 6.1).
Implementations MUST support an in-dialog REFER ([RFC3515] updated by Implementations MUST support an in-dialog REFER (as described in
[RFC7647] and including support for norefersub per [RFC4488]) with [RFC3515] and updated by [RFC7647], and including support for
the Replaces header field [RFC3891] to enable call transfer. norefersub per [RFC4488]) with the Replaces header field [RFC3891] to
enable call transfer.
5.4. URI Representation of Phone Numbers 5.4. URI Representation of Phone Numbers
SIP URIs constructed from non-URI sources (dial strings) and sent to SIP URIs constructed from non-URI sources (dial strings) and sent to
SIP proxies by the RUE MUST be represented as follows, depending on 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 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 "expressed as an E.164 number" includes numbers, such as toll-free
numbers that are not actually E.164 numbers, but have the same numbers that are not actually E.164 numbers but have the same format.
format.
A dial string that can be expressed as an E.164 phone number MUST be 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 represented as a SIP URI with a URI ";user=phone" tag. The user part
of the URI MUST be in conformance with 'global-number' defined in of the URI MUST be in conformance with "global-number", as defined in
[RFC3966]. The user part MUST NOT contain any 'visual-separator' [RFC3966]. The user part MUST NOT contain any "visual-separator"
characters, as defined in [RFC3966]. characters, as defined in [RFC3966].
Dial strings that cannot be expressed as E.164 numbers MUST be Dial strings that cannot be expressed as E.164 numbers MUST be
represented as dialstring URIs, as specified by [RFC4967], e.g., represented as dialstring URIs, as specified by [RFC4967], e.g.,
sip:411@red.example.net;user=dialstring. sip:411@red.example.net;user=dialstring.
The domain part of Relay Service URIs and User Address of Records The domain part of relay service URIs and User Address of Records
(AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or (AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or
IPv6 addresses. IPv6 addresses.
5.5. Transport 5.5. Transport
Implementations MUST conform to [RFC8835] except for its guidance on Implementations MUST conform to [RFC8835], except for its guidance on
the WebRTC data channel, which this specification does not use. See the WebRTC data channel, which this specification does not use. See
Section 6.2 for how RUE supports real-time text without the data Section 6.2 for how RUE supports real-time text without the data
channel. channel.
Implementations MUST support SIP outbound [RFC5626] (please also Implementations MUST support SIP outbound [RFC5626] (please also
refer to Section 5.1). refer to Section 5.1).
6. Media 6. Media
This specification adopts the media specifications for WebRTC This specification adopts the media specifications for WebRTC
([RFC8825]). Where WebRTC defines how interactive media [RFC8825]. Where WebRTC defines how interactive media communications
communications may be established using a browser as a client, this may be established using a browser as a client, this specification
specification assumes a normal SIP call. Various RTP, RTCP, SDP and assumes a normal SIP call. Various RTPs, RTCPs, SDPs, and specific
specific media requirements specified for WebRTC are adopted for this media requirements specified for WebRTC are adopted for this
document. Explicit requirements from the WebRTC suite of documents document. Explicit requirements from the WebRTC suite of documents
are described below . are described below .
To use WebRTC with this document, a gateway that presents a WebRTC To use WebRTC with this document, a gateway that presents a WebRTC
server interface towards a browser, and a RUE client interface server interface towards a browser and a RUE client interface towards
towards a provider is assumed. The gateway would interwork a provider is assumed. The gateway would interwork signaling and, as
signaling, and as noted below, interwork at least any real time text noted below, interwork at least any real-time text media in order to
media, in order to allow a standard browser based WebRTC client to be allow a standard browser-based WebRTC client to be a VRS client. The
a VRS client. The combination of the browser client and the gateway combination of the browser client and the gateway would be a RUE
would be a RUE user. This document does not specify the gateway. user. This document does not specify the gateway.
The following sections specify the WebRTC documents to which The following sections specify the WebRTC documents to which
conformance is required. "Mandatory to Implement" means a conforming conformance is required. "Mandatory to Implement" means a conforming
implementation MUST implement the specified capability. It does not implementation MUST implement the specified capability. It does not
mean that the capability must be used in every session. For example, mean that the capability must be used in every session. For example,
OPUS is a mandatory to implement audio codec, and all conforming Opus is a Mandatory-to-Implement audio codec, and all conforming
implementations must support OPUS. However, implementation implementations must support Opus. However, an implementation
presenting a call across the RUE Interface where the call originates presenting a call across the RUE interface (where the call originates
in the Public Switched Telephone Network, or an older, non-RUE- in the PSTN or an older, non-RUE-compatible device, which only offers
compatible device, which only offers G.711 audio, does not need to G.711 audio) does not need to include the Opus codec in the offer,
include the OPUS codec in the offer, since it cannot be used with since it cannot be used with that call. Conformance to this document
that call. Conformance to this document allows end-to-end RTCP and allows end-to-end RTCP and media congestion control for audio and
media congestion control for audio and video. video.
6.1. SRTP and SRTCP 6.1. SRTP and SRTCP
Implementations MUST support [RFC8834] except that MediaStreamTracks Implementations MUST support [RFC8834], except that MediaStreamTracks
are not used. Implementations MUST conform to Section 6.4 of are not used. Implementations MUST conform to Section 6.4 of
[RFC8827]. [RFC8827].
6.2. Text-Based Communication 6.2. Text-Based Communication
Implementations MUST support real-time text ([RFC4102] and [RFC4103]) Implementations MUST support real-time text [RFC4102] [RFC4103] via
via T.140 media. One original and two redundant generations MUST be T.140 media. One original and two redundant generations MUST be
transmitted and supported, with a 300 ms transmission interval. transmitted and supported with a 300 ms transmission interval.
Implementations MUST support [RFC9071] especially for emergency Implementations MUST support [RFC9071], especially for emergency
calls. Note that RFC4103 is not how real-time text is transmitted in calls. Note that [RFC4103] is not how real-time text is transmitted
WebRTC and some form of transcoder would be required to interwork 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 real-time text in the data channel of WebRTC to [RFC4103] real-time
text. text.
Transport of T.140 real-time text in WebRTC is specified in Transport of T.140 real-time text in WebRTC is specified in
[RFC8865], using the WebRTC data channel. RFC 8865 also has some [RFC8865], using the WebRTC data channel. [RFC8865] also has some
advice on how gateways between RFC 4103 and RFC 8865 should operate. advice on how gateways between [RFC4103] and [RFC8865] should
It is RECOMMENDED that RFC 8865 including multiparty support is used operate. It is RECOMMENDED that [RFC8865], including multiparty
for communication with browser-based WebRTC implementations. support, be used for communication with browser-based WebRTC
Implementations MUST support [RFC9071]. implementations. Implementations MUST support [RFC9071].
6.3. Video 6.3. Video
Implementations MUST conform to [RFC7742] with following exceptions: Implementations MUST conform to [RFC7742] with the following
only H.264, as specified in [RFC7742], is Mandatory to Implement, and exceptions: only H.264, as specified in [RFC7742], is Mandatory to
VP8 support is OPTIONAL at both the device and providers. This is Implement, and VP8 support is OPTIONAL at both the device and
because backwards compatibility is desirable, and older devices do providers. This is because backwards compatibility is desirable, and
not support VP8. older devices do not support VP8.
6.4. Audio 6.4. Audio
Implementations MUST conform to [RFC7874]. Implementations MUST conform to [RFC7874].
6.5. DTMF Digits 6.5. DTMF Digits
Implementations MUST support the "audio/telephone-event" [RFC4733] Implementations MUST support the "audio/telephone-event" [RFC4733]
media type. They MUST support conveying event codes 0 through 11 media type. They MUST support conveying event codes 0 through 11
(DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733].
skipping to change at page 16, line 9 skipping to change at line 714
6.6. Session Description Protocol 6.6. Session Description Protocol
The SDP offers and answers MUST conform to the SDP rules in [RFC8829] 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 except that the RUE interface uses SIP transport for SDP. The SDP
for real-time text MUST specify the T.140 payload type [RFC4103]. for real-time text MUST specify the T.140 payload type [RFC4103].
6.7. Privacy 6.7. Privacy
The RUE MUST provide for user privacy by implementing a local one-way The RUE MUST provide for user privacy by implementing a local one-way
mute, without signaling, for both audio and video. However, RUE MUST mute, without signaling, for both audio and video. However, RUE MUST
maintain any states in the network (e.g. NAT bindings) by maintain any states in the network (e.g., NAT bindings) by
periodically sending media packets on all active media sessions periodically sending media packets on all active media sessions
containing silence/comfort noise/black screen/etc. per [RFC6263]. containing silence, comfort noise, blank screen, etc., per [RFC6263].
6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 6.8. Negative Acknowledgement, Picture Loss Indicator, and Full
Intraframe Request Features Intraframe Request Features
The NACK, FIR and PLI features as described in [RFC4585] and The NACK, FIR, and Picture Loss Indicator (PLI) features, as
[RFC5104] MUST be implemented. Availability of these features MUST described in [RFC4585] and [RFC5104], MUST be implemented.
be announced with the "ccm" feedback value. NACK should be used when Availability of these features MUST be announced with the "ccm"
negotiated and conditions warrant its use and the other end supports feedback value. NACK should be used when negotiated and conditions
it. Signaling picture losses as Packet Loss Indicator (PLI) should warrant its use and the other end supports it. Signaling picture
be preferred. FIR should be used only in situations where not losses as a PLI should be preferred. FIR should be used only in
sending a decoder refresh point would render the video unusable for situations where not sending a decoder refresh point would render the
the users, as per RFC5104 subsection 4.3.1.2. video unusable for the users, as per Section 4.3.1.2 of [RFC5104].
For backwards compatibility with calling devices that do not support For backwards compatibility with calling devices that do not support
the foregoing methods, implementations MUST implement SIP INFO the foregoing methods, implementations MUST implement SIP INFO
messages to send and receive XML encoded Picture Fast Update messages messages to send and receive XML-encoded Picture Fast Update messages
according to [RFC5168]. according to [RFC5168].
7. Contacts 7. Contacts
7.1. CardDAV Login and Synchronization 7.1. CardDAV Login and Synchronization
Support of CardDAV by providers is OPTIONAL. Support of vCard Extensions to WebDAV (CardDAV) by providers is
OPTIONAL.
The RUE MUST and providers MAY be able to synchronize the user's The RUE MUST and providers MAY be able to synchronize the user's
contact directory between the RUE endpoint and one maintained by the contact directory between the RUE endpoint and one maintained by the
user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). user's VRS provider using CardDAV [RFC6352] [RFC6764].
The configuration (see Section Section 9.2) RueConfigurationData MAY The configuration (see Section 9.2) RueConfigurationData MAY supply a
supply a "carddav-username" and "carddav-domain" identifying a "carddav-username" and "carddav-domain" identifying a CardDAV server
CardDAV server and address book for this account, plus an optional and address book for this account, plus an optional "carddav-
"carddav-password". password".
To access the CardDAV server and address book, the RUE MUST follow To access the CardDAV server and address book, the RUE MUST follow
Section 6 of RFC6764, using the configured carddav-username and Section 6 of [RFC6764], using the configured carddav-username and
carddav-domain in place of an email address. If the request triggers carddav-domain in place of an email address. If the request triggers
a challenge for digest authentication credentials, the RUE MUST a challenge for digest authentication credentials, the RUE MUST
continue using matching carddav-username and carddav-password from continue using matching carddav-username and carddav-password from
the configuration. If no carddav-username and carddav-password are the configuration. If no carddav-username and carddav-password are
configured, the RUE MUST use the SIP user-name and sip-password from 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 configuration. If the SIP credentials fail, the RUE MUST query
the user. the user.
Synchronization using CardDAV MUST be a two-way synchronization Synchronization using CardDAV MUST be a two-way synchronization
service, with proper handling of asynchronous adds, changes, and service, with proper handling of asynchronous adds, changes, and
skipping to change at page 17, line 34 skipping to change at line 780
xCard [RFC6351] XML format. xCard [RFC6351] XML format.
The RUE accesses this service via the "contacts-uri" in the The RUE accesses this service via the "contacts-uri" in the
configuration. The URL MUST resolve to identify a web server configuration. The URL MUST resolve to identify a web server
resource that imports/exports contact lists for authorized users. resource that imports/exports contact lists for authorized users.
The RUE stores/retrieves the contact list (address book) by issuing The RUE stores/retrieves the contact list (address book) by issuing
an HTTPS POST or GET request. If the request triggers a challenge an HTTPS POST or GET request. If the request triggers a challenge
for digest authentication credentials, the RUE MUST attempt to for digest authentication credentials, the RUE MUST attempt to
continue using the "contacts-username" and "contacts-password" from continue using the "contacts-username" and "contacts-password" from
the configuration. If no contacts-username is configured, the sip the configuration. If no contacts-username is configured, the SIP
user-name from the configuration is used, and if the sip user-name is user-name from the configuration is used; if the SIP user-name is not
not configured, the phone-number is used. If user-name or phone- configured, the phone-number is used. If user-name or phone-number
number is used, the sip-password is used to authenticate to the is used, the sip-password is used to authenticate to the contact list
contact list server. server.
8. Video Mail 8. Video Mail
Support for video mail includes a retrieval mechanism and a Message Support for video mail includes a retrieval mechanism and a Message-
Waiting Indicator (MWI). Message storage is not specified by this Waiting Indicator (MWI). Message storage is not specified by this
document. RUE devices MUST support message retrieval using a SIP document. RUE devices MUST support message retrieval using a SIP
call to a specified SIP URI using DTMF to manage the mailbox, as well 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 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 provider supports video mail, at least one of these mechanisms MUST
supported. RUE devices MUST support both. See Section 9.2 for how be supported. RUE devices MUST support both. See Section 9.2 for
the URI to reach the retrieval interface is obtained. how the URI to reach the retrieval interface is obtained.
Implementations MUST support subscriptions to "message-summary" Implementations MUST support subscriptions to "message-summary"
events [RFC3842] to the URI specified in the configuration. events [RFC3842] to the URI specified in the configuration.
Providers MUST support MWI if they support video mail. RUE devices Providers MUST support MWI if they support video mail. RUE devices
MUST support MWI. MUST support MWI.
The "videomail" and "mwi" properties in the configuration (see The "videomail" and "mwi" properties in the configuration (see
RueConfigurationData in Section 9.2.2) gives the URIs for message RueConfigurationData in Section 9.2.2) give the URIs for message
retrieval and "message-summary" subscription. retrieval and "message-summary" subscription.
In notification bodies, if detailed message summaries are available, In notification bodies, if detailed message summaries are available,
messages with video MUST be reported using "message-context-class messages with video MUST be reported using "message-context-class
multimedia-message" defined in [RFC3458] . multimedia-message", as defined in [RFC3458] .
9. Provisioning and Provider Selection 9. Provisioning and Provider Selection
To simplify how users interact with RUE devices, the RUE interface To simplify how users interact with RUE devices, the RUE interface
separates provisioning into two parts. One provides a directory of separates provisioning into two parts. One provides a directory of
providers so that a user interface can allow easy provider selection providers so that a user interface can allow easy provider selection
either for registering or for dial-around. The other provides either for registering or for dial-around. The other provides
configuration data for the device for each provider. configuration data for the device for each provider.
9.1. RUE Provider Selection 9.1. RUE Provider Selection
To allow the user to select a relay service, the RUE MAY at any time 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 obtain (typically on startup) a list of providers that provide
service in a country. IANA has established a registry that contains service in a country. IANA has established a registry that contains
a two-letter country code and an entry point string (See a two-letter country code and a list entry point string (see
Section 10.1). The entry point, when used with the following OpenAPI Section 10.1). The entry point, when used with the following OpenAPI
interface, returns a list of provider names for a country code interface, returns a list of provider names for a country code
suitable for display, with a corresponding entry point to obtain suitable for display, with a corresponding entry point to obtain
information about that provider. No mechanism to determine the information about that provider. No mechanism to determine the
country the RUE is located is specified in this document. Typically country where the RUE is located is specified in this document.
the country is the home country of the user, but may be a local Typically, the country is the home country of the user but may be a
country while traveling. Some countries allow support from their local country while traveling. Some countries allow support from
home country when traveling abroad. Regardless, the RUE device will their home country when traveling abroad. Regardless, the RUE device
need to allow the user to choose the country. will need to allow the user to choose the country.
Each country that supports video relay service using this Each country that supports VRS using this specification MAY support
specification MAY support the provider list. This document does not the provider list. This document does not specify who maintains the
specify who maintains the list. Some possibilities are a regulator list. Some possibilities are a regulator or an entity designated by
or entity designated by a regulator, an agreement among providers to a regulator, an agreement among providers to provide the list, or a
provide the list, or a user group. user group.
The interface to obtain the list of providers is described by an The interface to obtain the list of providers is described by an
OpenApi [OpenApi] interface description. In that interface OpenAPI [OpenAPI] interface description. In that interface
description, the "servers" component includes an occurance of description, the "servers" component includes an occurrence of
"localhost". The value from the registry of the "list entry point" "localhost". The value from the registry of the "list entry point"
string for the desired country is substituted for "localhost" in the string for the desired country is substituted for "localhost" in the
"servers" component to obtain the server URI prefix of the interface "servers" component to obtain the server URI prefix of the interface
to be used to obtain the list of providers for that country. The 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 "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 list. For example, if the list entryPoint is "example.com/api",
the provider list would be obtained from the provider list would be obtained from
https://example.com/api/rum/v1/Providers. https://example.com/api/rum/v1/Providers.
The V1.0 "ProviderList" is a JSON object consisting of an array where The V1.0 "ProviderList" is a JSON object consisting of an array where
each entry describes one provider. Each entry consists of the each entry describes one provider. Each entry consists of the
following items: following items:
* name: This parameter contains the text label identifying the * name: This parameter contains the text label identifying the
provider and is meant to be displayed to the human VRS user. provider and is meant to be displayed to the human VRS user.
* providerEntryPoint: A string used for configuration purposes by * providerEntryPoint: A string used for configuration purposes by
the RUE (as discussed in Section 9.2). The string MUST start with the RUE (as discussed in Section 9.2). The string MUST start with
a domain, but MAY include other URI path elements after the a domain but MAY include other URI path elements after the domain.
domain.
The VRS user interacts with the RUE to select from the provider list 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 one or more providers with whom the user has already established an
account, wishes to establish an account, or wishes to use the account, wishes to establish an account, or wishes to use the
provider for a one-stage dial around. provider for a one-stage dial-around.
{ {
"providers": [ "providers": [
{ {
"name": "Red", "name": "Red",
"entryPoint": "red.example.net" "entryPoint": "red.example.net"
}, },
{ {
"name": "Green", "name": "Green",
"entryPoint": "green.example.net" "entryPoint": "green.example.net"
}, },
{ {
"name": "Blue", "name": "Blue",
"entryPoint": "blue.example.net" "entryPoint": "blue.example.net"
} }
] ]
} }
Figure 2: Example of a ProviderList JSON object Figure 2: Example of a ProviderList JSON Object
9.2. RUE Configuration Service 9.2. RUE Configuration Service
A RUE device may retrieve a provider configuration using a simple A RUE device may retrieve a provider configuration using a simple
HTTPs web service. There are two entry points. One is used without HTTPs web service. There are two entry points. One is used without
user credentials, and the response includes configuration data for user credentials, and the response includes configuration data for
new user sign up and dial around. The other uses locally stored new user signup and dial-around. The other uses a locally stored
username and password that results from a new user sign up to username and password that results from a new user signup to
authenticate to the interface and returns configuration data for the authenticate to the interface and returns configuration data for the
RUE. RUE.
The interface to obtain configuration data is described by an OpenApi The interface to obtain configuration data is described by an OpenAPI
[OpenApi] interface description. In that interface description, the [OpenAPI] interface description. In that interface description, the
"servers" component string includes an occurence of "localhost". The "servers" component string includes an occurrence of "localhost".
entry point string obtained from the provider list (Section 9.1) is The entry point string obtained from the provider list (Section 9.1)
substituted for "localhost" to obtain the server prefix of the is substituted for "localhost" to obtain the server prefix of the
interface. The path then specifies the rest of the URI used to interface. The path then specifies the rest of the URI used to
obtain the list. For example, if the entryPoint from the provider obtain the list. For example, if the entryPoint from the provider
list is "red.example.net", the provider configuration would be list is "red.example.net", the provider configuration would be
obtained from https://red.example.net/rum/V1/ProviderConfig and the obtained from https://red.example.net/rum/V1/ProviderConfig and the
RUE configuration would be obtained from RUE configuration would be obtained from
https://red.example.net/rum/V1/RueConfig. https://red.example.net/rum/V1/RueConfig.
In both the queries, an optional parameter may be provided to the In both the queries, an optional parameter may be provided to the
interface which is an API Key (apiKey). The implementation MAY have interface, which is an API Key (apiKey). The implementation MAY have
an apiKey obtained from the provider and specific to the an apiKey obtained from the provider and specific to the
implementation. The method used to obtain the apiKey is not implementation. The method used to obtain the apiKey is not
specified in this document. The provider MAY refuse to provide specified in this document. The provider MAY refuse to provide
service to an implementation presenting an apiKey it does not service to an implementation presenting an apiKey it does not
recognize. recognize.
Also in both queries, the RUE device provides a client provided, Also in both queries, the RUE device provides a client-provided,
required parameter, which contains an instance identifier required parameter, which contains an instance identifier
(instanceId). This parameter MUST be the same value each time this (instanceId). This parameter MUST be the same value each time this
instance (same implementation on same device) queries the interface. instance (same implementation on same device) queries the interface.
This MAY be used by the provider, for example, to associate a This MAY be used by the provider, for example, to associate a
location with the instance for emergency calls. This should be location with the instance for emergency calls. This should be
globally unique. A UUID is suggested. globally unique. A Universally Unique Identifier (UUID) is
suggested.
For example, a query for the RUE configuration could be For example, a query for the RUE configuration could be
https://red.example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisK https://red.example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisK
t8999"&instanceId="5595b5a3-0687-4b8e-9913-a7f2a04fb7bd" t8999"&instanceId="5595b5a3-0687-4b8e-9913-a7f2a04fb7bd"
The data returned is a JSON object consisting of key/value The data returned is a JSON object consisting of key/value
configuration parameters to be used by the RUE. configuration parameters to be used by the RUE.
The configuration data payload includes the following data items. The configuration data payload includes the following data items.
Items not noted as (OPTIONAL) are REQUIRED. If other unexpected Items not noted as (OPTIONAL) are REQUIRED. If other unexpected
items are found, they MUST be ignored. items are found, they MUST be ignored.
9.2.1. Provider Configuration 9.2.1. Provider Configuration
* signup: (OPTIONAL) an array of JSON objects consisting of: * signup: (OPTIONAL) an array of JSON objects consisting of:
- language: entry from the IANA language subtag registry - language: entry from the IANA "Language Subtag Registry"
(https://www.iana.org/assignments/language-subtag-registry/ (https://www.iana.org/assignments/language-subtag-registry).
language-subtag-registry). Normally, this would be a written Normally, this would be a written language tag.
language tag.
- uri: a URI to the website for creating a new account in the - uri: a URI to the website for creating a new account in the
supported language. The new user signup URI may only initiate supported language. The new user signup URI may only initiate
creation of a new account. Various vetting, approval and other creation of a new account. Various vetting, approval, and
processes may be needed, which could take time, before the other processes may be needed, which could take time, before
account is established. The result of creating a new account the account is established. The result of creating a new
would be account credentials (e.g. username and password), account would be account credentials (e.g., username and
which would be manually entered into the RUE device which form password), which would be manually entered into the RUE device
the authentication parameters for the RUE configuration service that forms the authentication parameters for the RUE
described below in Section 9.2.2. configuration service described below in Section 9.2.2.
* dialAround: an array of JSON objects consisting of: * dial-around: an array of JSON objects consisting of:
- language: entry from the IANA language subtag registry. - language: entry from the IANA "Language Subtag Registry".
Normally, this would be a sign language tag. Normally, this would be a sign language tag.
- frontDoor: a URI to a queue of interpreters supporting the - front-door: a URI to a queue of interpreters supporting the
specified language for a two-stage dial-around specified language for a two-stage dial-around.
- oneStage: a URI that can be used with a one-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 (Section 5.2.2) using an interpreter supporting the specified
language language.
* helpDesk: (OPTIONAL) an array of JSON objects consisting of: * helpDesk: (OPTIONAL) an array of JSON objects consisting of:
- language: entry from the IANA language subtag registry. - language: entry from the IANA "Language Subtag Registry".
Normally this would be a sign language tag, although it could Normally, this would be a sign language tag; although, it could
be a written language tag if the help desk only supports a chat be a written language tag if the help desk only supports a chat
interface interface.
- uri: URI that reaches a help desk for callers supporting the - uri: a URI that reaches a help desk for callers supporting the
specified language. The URI MAY be a SIP URI for help provided 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 with a SIP call or MAY be an HTTPS URI for help provided with a
a browser interface. browser interface.
A list is specified so that the provider can offer multiple A list is specified so that the provider can offer multiple
choices to users for language and interface styles. choices to users for language and interface styles.
9.2.2. RUE Configuration 9.2.2. RUE Configuration
* lifetime: (optional) Specifies how long (in seconds) the RUE MAY
* lifetime: (OPTIONAL) specifies how long (in seconds) the RUE MAY
cache the configuration values. Values may not be valid when cache the configuration values. Values may not be valid when
lifetime expires. If the RUE caches configuration values, it MUST lifetime expires. If the RUE caches configuration values, it MUST
cryptographically protect them against unauthorized disclosure cryptographically protect them against unauthorized disclosure
(e.g. by other applications on the platform the RUE is built on). (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 RUE SHOULD retrieve a fresh copy of the configuration before
the lifetime expires or as soon as possible after it expires. The the lifetime expires or as soon as possible after it expires. The
lifetime is not guaranteed: the configuration may change before lifetime is not guaranteed, i.e., the configuration may change
the lifetime value expires. In that case, the Provider MAY before the lifetime value expires. In that case, the provider MAY
indicate this by generating authorization challenges to requests indicate this by generating authorization challenges to requests
and/or prematurely terminating a registration. Emergency Calls and/or prematurely terminating a registration. Emergency calls
MUST continue to work. If not specified, the RUE MUST fetch new MUST continue to work. If not specified, the RUE MUST fetch new
configuration data every time it starts. configuration data every time it starts.
* sip-password: (optional) a password used for SIP, STUN and TURN * sip-password: (OPTIONAL) a password used for SIP, STUN, and TURN
authentication. The RUE device retains this data, which it MUST authentication. The RUE device retains this data, which it MUST
cryptographically protect against unauthorized disclosure (e.g. by cryptographically protect against unauthorized disclosure (e.g.,
other applications on the platform the RUE is built on). If it is by other applications on the platform the RUE is built on). If it
not supplied, but was supplied on a prior invocation of this is not supplied but was supplied on a prior invocation of this
interface, the most recently supplied password MUST be used. If interface, the most recently supplied password MUST be used. If
it was never supplied, the password used to authenticate to the it was never supplied, the password used to authenticate to the
configuration service is used for SIP, as well as STUN and TURN configuration service is used for SIP, as well as STUN and TURN
servers mentioned in this configuration. servers mentioned in this configuration.
* phone-number: The telephone number (in E.164 format) assigned to * phone-number: (REQUIRED) the telephone number (in E.164 format)
this subscriber. This becomes the user portion of the SIP URI assigned to this subscriber. This becomes the user portion of the
identifying the subscriber. SIP URI identifying the subscriber.
* user-name: (optional) a username used for authenticating to the * user-name: (OPTIONAL) a username used for authenticating to the
provider. If not provided, the phone-number is used. provider. If not provided, phone-number is used.
* display-name: (optional) a human readable display name for the * display-name: (OPTIONAL) a human-readable display name for the
subscriber subscriber.
* provider-domain: the domain for the provider. This becomes the * provider-domain: (REQUIRED) the domain for the provider. This
server portion of the SIP URI identifying the subscriber. becomes the server portion of the SIP URI identifying the
subscriber.
* outbound-proxies: (optional) An array of URIs of SIP proxies to be * outbound-proxies: (OPTIONAL) an array of URIs of SIP proxies to be
used when sending requests to the provider. used when sending requests to the provider.
* mwi: (optional) A URI identifying a SIP event server that * mwi: (OPTIONAL) a URI identifying a SIP event server that
generates "message-summary" events for this subscriber. generates "message-summary" events for this subscriber.
* videomail: (optional) An SIP or HTTPS URI that can be used to * videomail: (OPTIONAL) a SIP or HTTPS URI that can be used to
retrieve video mail messages. retrieve video mail messages.
* contacts: (optional) An HTTPS URI ("contacts-uri"), (optional) * contacts: (OPTIONAL) an HTTPS URI ("contacts-uri"), (OPTIONAL)
"contacts-username" and "contacts-password" that may be used to "contacts-username", and "contacts-password" that may be used to
export (retrieve) the subscriber's complete contact list managed export (retrieve) the subscriber's complete contact list managed
by the provider. At least the URI MUST be provided if the by the provider. At least the URI MUST be provided if the
subscriber has contacts. If contact-username and contacts- subscriber has contacts. If contact-username and contacts-
password are not supplied, the sip credentials are used. If the password are not supplied, the sip credentials are used. If the
contacts-username is provided, contacts-password MUST be provided. contacts-username is provided, contacts-password MUST be provided.
If contacts-password is provided, contacts-username MUST be If contacts-password is provided, contacts-username MUST be
provided. provided.
* carddav: (optional) An address ("carddav-domain"), (optional) * carddav: (OPTIONAL) an address ("carddav-domain"), (OPTIONAL)
"carddav-username" and "carddav-password" identifying a "CardDAV" "carddav-username", and "carddav-password" identifying a "CardDAV"
server and account that can be used to synchronize the RUE's server and account that can be used to synchronize the RUE's
contact list with the contact list managed by the provider. If contact list with the contact list managed by the provider. If
carddav-username and carddav-password are not supplied, the sip carddav-username and carddav-password are not supplied, the sip
credentials are used. If the carddav-username is provided, credentials are used. If the carddav-username is provided,
carddav-password MUST be provided. If carddav-password is carddav-password MUST be provided. If carddav-password is
provided, carddav-username MUST be provided. provided, carddav-username MUST be provided.
* sendLocationWithRegistration: (optional) True if the RUE should * sendLocationWithRegistration: (OPTIONAL) true if the RUE should
send a Geolocation header field with REGISTER, false if it should send a Geolocation header field with REGISTER; false if it should
not. Defaults to false if not present. not. Defaults to false if not present.
* ice-servers: (optional) An array of server types and URLs * ice-servers: (OPTIONAL) an array of server types and URLs
identifying STUN and TURN servers available for use by the RUE for identifying STUN and TURN servers available for use by the RUE for
establishing media streams in calls via the provider. If the same establishing media streams in calls via the provider. If the same
URL provides both STUN and TURN services, it MUST be listed twice, URL provides both STUN and TURN services, it MUST be listed twice,
each with different server types. each with different server types.
9.2.3. Versions 9.2.3. Versions
Both web services also have a simple version mechanism that returns a Both web services also have a simple version mechanism that returns a
list of versions of the web service it supports. This document list of versions of the web service it supports. This document
describes version 1.0. Versions are described as a major version, describes version 1.0. Versions are displayed as a major version,
the period "." and a minor version, where major and minor versions followed by a period ".", followed by a minor version, where the
are integers. A backwards compatible change within a major version major and minor versions are integers. A backwards compatible change
MAY increment only the minor version number. A non-backwards within a major version MAY increment only the minor version number.
compatible change MUST increment the major version number. Backwards A non-backwards, compatible change MUST increment the major version
compatibility applies to both the server and the client. Either may number. Backwards compatibility applies to both the server and the
have any higher or lower minor revision and interoperate with its client. Either may have any higher or lower minor revision and
counterpart with the same major version. To achieve backwards interoperate with its counterpart with the same major version. To
compatibility, implementations MUST ignore any object members they do achieve backwards compatibility, implementations MUST ignore any
not implement. Minor version definitions SHALL only add objects, object members they do not implement. Minor version definitions
non-required members of existing objects, and non-mandatory-to use SHALL only add objects, optional members of existing objects, and
functions and SHALL NOT delete or change any objects, members of non-mandatory-to-use functions and SHALL NOT delete or change any
objects or functions. This means an implementation of a specific objects, members of objects, or functions. This means an
major version and minor version is backwards compatible with all implementation of a specific major version and minor version is
minor versions of the major version. The version mechanism returns backwards compatible with all minor versions of the major version.
an array of supported versions, one for each major version supported, The version mechanism returns an array of supported versions, one for
with the minor version listed being the highest supported minor each major version supported, with the minor version listed being the
version. highest-supported minor version.
Unless the per-country provider list service is operated by a Unless the per-country provider list service is operated by a
provider at the same base URI as that provider's configuration provider at the same base URI as that provider's configuration
service, the version of the configuration service MAY be different service, the version of the configuration service MAY be different
from the version of the provider list service. from the version of the provider list service.
{ {
"versions": [ "versions": [
{ {
"major": 1, "major": 1,
skipping to change at page 24, line 30 skipping to change at line 1105
"major": 2, "major": 2,
"minor": 13 "minor": 13
}, },
{ {
"major": 3, "major": 3,
"minor": 2 "minor": 2
} }
] ]
} }
Figure 3: Example of a Version JSON object Figure 3: Example of a Version JSON Object
9.2.4. Examples 9.2.4. Examples
Example JSON provider configuration payload {
{ "signUp": [
"signUp": [ { "language" : "en", "uri" : "https:hello-en.example.net"},
{ "language" : "en", "uri" : "https:hello-en.example.net"}, { "language" : "es", "uri" : "https:hello-es.example.net"} ] ,
{ "language" : "es", "uri" : "https:hello-es.example.net"} ] , "dial-around": [
"dialAround": [ { "language" : "en", "front-door" : "sip:fd-en.example.net",
{ "language" : "en", "frontDoor" : "sip:fd-en.example.net", "oneStage" : "sip:1stg-eng.example.com" } ,
"oneStage" : "sip:1stg-eng.example.com" } , { "language" : "es", "front-door" : "sip:fd-es.example.net",
{ "language" : "es", "frontDoor" : "sip:fd-es.example.net", "oneStage" : "sip:1stg-spn.example.com" } ] ,
"oneStage" : "sip:1stg-spn.example.com" } ] , "helpDesk": [
"helpDesk": [ { "language" : "en", "uri" : "sip:help-en.example.net"} ,
{ "language" : "en", "uri" : "sip:help-en.example.net"} , { "language" : "es", "uri" : "sip:help-es.example.net"} ]
{ "language" : "es", "uri" : "sip:help-es.example.net"} ] }
}
Figure 4 Figure 4: Example JSON Provider Configuration Payload
Example JSON RUE configuration payload {
{ "lifetime": 86400,
"lifetime": 86400, "display-name" : "Bob Smith",
"display-name" : "Bob Smith", "phone-number": "+15551234567",
"phone-number": "+15551234567", "provider-domain": "red.example.net",
"provider-domain": "red.example.net", "outbound-proxies": [
"outbound-proxies": [ "sip:p1.red.example.net",
"sip:p1.red.example.net", "sip:p2.red.example.net" ],
"sip:p2.red.example.net" ], "mwi": "sip:+15551234567@red.example.net;user=phone",
"mwi": "sip:+15551234567@red.example.net;user=phone", "videomail": "sip:+15551234567@vm.red.example.net;user=phone",
"videomail": "sip:+15551234567@vm.red.example.net;user=phone", "contacts": {
"contacts": { "contacts-uri":
"contacts-uri": "https://red.example.net:443/c/3617b719-2c3a-46f4-9c13",
"https://red.example.net:443/c/3617b719-2c3a-46f4-9c13", "contacts-username": "bob",
"contacts-username": "bob", "contacts-password": "XhOT4ch@ZEi&3u2xEYQNMO^5UGb"
"contacts-password": "XhOT4ch@ZEi&3u2xEYQNMO^5UGb" },
}, "carddav": {
"carddav": { "carddav-domain": "carddav.example.com",
"carddav-domain": "carddav.example.com", "carddav-username": "bob",
"carddav-username": "bob", "carddav-password": "sj887%dd*jJty%87hyys5hHT"
"carddav-password": "sj887%dd*jJty%87hyys5hHT" },
}, "sendLocationWithRegistration": false,
"sendLocationWithRegistration": false, "ice-servers": [
"ice-servers": [ {"stun":"stun.red.example.com:19302" },
{"stun":"stun.red.example.com:19302" }, {"turn":"turn.red.example.com:3478"}
{"turn":"turn.red.example.com:3478"} ]
] }
}
Figure 5 Figure 5: Example JSON RUE Configuration Payload
9.2.5. Using the Provider Selection and RUE Configuration Services 9.2.5. Using the Provider Selection and RUE Configuration Services
Together Together
One way to use these two services is: One way to use these two services is:
* At startup, the RUE retrieves the provider list for the country it 1. At startup, the RUE retrieves the provider list for the country
is located in. it is located in.
* For each provider in the list: 2. For each provider in the list:
- If the RUE does not have credentials for that provider, if * If the RUE does not have credentials for that provider, if
requested by the user, use the ProviderConfig path without requested by the user, use the ProviderConfig path without
credentials to obtain signup, dial around and helpdesk credentials to obtain signup, dial-around, and help desk
information. information.
- If the RUE has credentials for that provider, use the RueConfig * If the RUE has credentials for that provider, use the
path with the locally stored credentials to configure the RUE RueConfig path with the locally stored credentials to
for that provider. configure the RUE for that provider.
9.3. OpenAPI Interface Descriptions 9.3. OpenAPI Interface Descriptions
The interfaces in Section 9.1 and Section 9.2 are formally specified The interfaces in Sections 9.1 and 9.2 are formally specified with
with OpenAPI 3.0 ([OpenApi]) descriptions in YAML form. OpenAPI 3.0 [OpenAPI] descriptions in YAML form.
The OpenAPI description below is normative. If there is any conflict The OpenAPI description below is normative. If there is any conflict
between the text or examples and this section, the OpenAPI between the text or examples and this section, the OpenAPI
description takes precedence. description takes precedence.
9.3.1. Provider List 9.3.1. Provider List
openapi: 3.0.1 openapi: 3.0.1
info: info:
title: RUM Provider List API title: RUM Provider List API
skipping to change at page 27, line 17 skipping to change at line 1235
providers: providers:
type: array type: array
items: items:
type: object type: object
required: required:
- name - name
- providerEntryPoint - providerEntryPoint
properties: properties:
name: name:
type: string type: string
description: Human readable provider name description: Human-readable provider name
providerEntryPoint: providerEntryPoint:
type: string type: string
description: provider entry point for interface description: Provider entry point for interface
VersionsArray: VersionsArray:
type: object type: object
required: required:
- versions - versions
properties: properties:
versions: versions:
type: array type: array
items: items:
type: object type: object
required: required:
skipping to change at page 27, line 43 skipping to change at line 1261
properties: properties:
major: major:
type: integer type: integer
format: int32 format: int32
description: Version major number description: Version major number
minor: minor:
type: integer type: integer
format: int32 format: int32
description: Version minor number description: Version minor number
Figure 6: Provider List OpenAPI description (RueProviderList.yaml) Figure 6: Provider List OpenAPI Description (RueProviderList.yaml)
9.3.2. Configuration 9.3.2. Configuration
openapi: 3.0.1 openapi: 3.0.1
info: info:
title: RUM Configuration API title: RUM Configuration API
version: "1.0" version: "1.0"
servers: servers:
- url: https://localhost/rum/v1 - url: https://localhost/rum/v1
paths: paths:
/ProviderConfig: /ProviderConfig:
get: get:
summary: Configuration data for one provider summary: Configuration data for one provider
skipping to change at page 28, line 30 skipping to change at line 1291
description: API Key assigned to this implementation description: API Key assigned to this implementation
- in: query - in: query
name: instanceId name: instanceId
schema: schema:
type: string type: string
required: true required: true
description: Unique string for this implementation description: Unique string for this implementation
on this device on this device
responses: responses:
'200': '200':
description: configuration object description: Configuration object
content: content:
application/json: application/json:
schema: schema:
$ref: $ref:
'#/components/schemas/ProviderConfigurationData' '#/components/schemas/ProviderConfigurationData'
/RueConfig: /RueConfig:
get: get:
summary: Configuration data for one RUE summary: Configuration data for one RUE
operationId: GetRueConfiguration operationId: GetRueConfiguration
parameters: parameters:
skipping to change at page 29, line 7 skipping to change at line 1316
description: API Key assigned to this implementation description: API Key assigned to this implementation
- in: query - in: query
name: instanceId name: instanceId
schema: schema:
type: string type: string
required: true required: true
description: Unique string for this implementation description: Unique string for this implementation
on this device on this device
responses: responses:
'200': '200':
description: configuration object description: Configuration object
content: content:
application/json: application/json:
schema: schema:
$ref: '#/components/schemas/RueConfigurationData' $ref: '#/components/schemas/RueConfigurationData'
/Versions: /Versions:
servers: servers:
- url: https://localhost/rum - url: https://localhost/rum
description: Override base path for Versions query description: Override base path for Versions query
get: get:
summary: Retrieves all supported versions summary: Retrieves all supported versions
skipping to change at page 29, line 31 skipping to change at line 1340
description: Versions supported description: Versions supported
content: content:
application/json: application/json:
schema: schema:
$ref: '#/components/schemas/VersionsArray' $ref: '#/components/schemas/VersionsArray'
components: components:
schemas: schemas:
ProviderConfigurationData: ProviderConfigurationData:
type: object type: object
required: required:
- dialAround - dial-around
properties: properties:
signup: signup:
type: array type: array
items: items:
type: object type: object
required: required:
- language - language
- uri - uri
properties: properties:
language: language:
type: string type: string
description: entry from IANA language-subtag-registry description: Entry from IANA "Language Subtag
Registry"
uri: uri:
type: string type: string
format: uri format: uri
description: URI to signup website supporting description: URI to signup website supporting
this language this language
dialAround: dial-around:
type: array type: array
items: items:
type: object type: object
required: required:
- language - language
- frontDoor - front-door
- oneStage - oneStage
properties: properties:
language: language:
type: string type: string
description: entry from IANA language-subtag-registry description: Entry from IANA "Language Subtag
frontDoor: Registry"
front-door:
type: string type: string
format: uri format: uri
description: SIP URI for two-stage dial around description: SIP URI for two-stage dial-around
oneStage: oneStage:
type: string type: string
format: uri format: uri
description: SIP URI for one-stage dial around description: SIP URI for one-stage dial-around
helpDesk: helpDesk:
type: array type: array
items: items:
type: object type: object
required: required:
- language - language
- uri - uri
properties: properties:
language: language:
type: string type: string
description: entry from IANA language-subtag-registry description: Entry from IANA "Language Subtag
Registry"
uri: uri:
type: string type: string
format: uri format: uri
description: SIP URI of helpdesk supporting language description: SIP URI of help desk supporting language
RueConfigurationData: RueConfigurationData:
type: object type: object
required: required:
- phone-number - phone-number
- provider-domain - provider-domain
properties: properties:
lifetime: lifetime:
type: integer type: integer
description: how long (in seconds) the RUE MAY cache the description: How long (in seconds) the RUE MAY cache the
configuration values configuration values
sip-password: sip-password:
type: string type: string
phone-number: phone-number:
type: string type: string
description: telephone number assigned this subscriber in description: Telephone number assigned this subscriber in
E.164 format E.164 format
user-name: user-name:
type: string type: string
description: a username assigned this subscriber. description: A username assigned to this subscriber
display-name: display-name:
type: string type: string
description: display name for the subscriber description: Display name for the subscriber
provider-domain: provider-domain:
type: string type: string
description: domain of the provider for this subscriber description: Domain of the provider for this subscriber
outbound-proxies: outbound-proxies:
type: array type: array
items: items:
type: string type: string
format: uri format: uri
description: SIP URI of a proxy to be used when sending description: SIP URI of a proxy to be used when sending
requests to the provider requests to the provider
mwi: mwi:
type: string type: string
format: uri format: uri
description: A URI identifying a SIP event server that description: A URI identifying a SIP event server that
generates "message-summary" events for this subscriber. generates "message-summary" events for this subscriber
videomail: videomail:
type: string type: string
format: uri format: uri
description: An HTTPS or SIP URI that can be used to description: An HTTPS or SIP URI that can be used to
retrieve video mail messages. retrieve video mail messages
contacts: contacts:
type: object type: object
description: server and credentials for contact description: Server and credentials for contact
import/export import/export
required: required:
- contacts-uri - contacts-uri
properties: properties:
contacts-uri: contacts-uri:
type: string type: string
format: uri format: uri
description: An HTTPS URI that may be used to export description: An HTTPS URI that may be used to export
(retrieve) the subscriber's complete contact list (retrieve) the subscriber's complete contact list
managed by the provider. managed by the provider
contacts-username: contacts-username:
type: string type: string
description: username for authentication with CardDAV description: Username for authentication with the
server. Use sip user-name if not provided CardDAV server. Use SIP user-name if not provided
contacts-password: contacts-password:
type: string type: string
description: password for authentication. Use provider description: Password for authentication. Use provider
sip-password if not provided sip-password if not provided
carddav: carddav:
type: object type: object
description: CardDAV server and user information that can description: CardDAV server and user information that can
be used to synchronize the RUE's contact list with be used to synchronize the RUE's contact list with
the contact list managed by the provider. the contact list managed by the provider
required: required:
- carddav-domain - carddav-domain
properties: properties:
carddav-domain: carddav-domain:
type: string type: string
description: CardDAV server address description: CardDAV server address
carddav-username: carddav-username:
type: string type: string
description: username for authentication with CardDAV description: Username for authentication with the
server. Use sip user-name if not provided CardDAV server. Use SIP user-name if not provided
carddav-password: carddav-password:
type: string type: string
description: password for authentication to the CardDAV description: Password for authentication to the CardDAV
server. Use provider sip-password if not provided server. Use provider sip-password if not provided
sendLocationWithRegistration: sendLocationWithRegistration:
type: boolean type: boolean
description: True if the RUE should send a Geolocation description: True if the RUE should send a Geolocation
header field with REGISTER, false if it should not. header field with REGISTER; false if it should not.
Defaults to false if not present. Defaults to false if not present
ice-servers: ice-servers:
type: array type: array
items: items:
type: object type: object
required: required:
- server-type - server-type
- uri - uri
properties: properties:
server-type: server-type:
type: string type: string
description: server type ("stun" or "turn") description: Server type ("stun" or "turn")
uri: uri:
type: string type: string
format: uri format: uri
description: URIs identifying STUN and TURN servers description: URIs identifying STUN and TURN servers
available for use by the RUE for establishing available for use by the RUE for establishing
media streams in calls via the provider. media streams in calls via the provider
VersionsArray: VersionsArray:
type: object type: object
required: required:
- versions - versions
properties: properties:
versions: versions:
type: array type: array
items: items:
type: object type: object
required: required:
- major - major
- minor - minor
properties: properties:
major: major:
type: integer type: integer
format: int32 format: int32
description: Version major number description: Version major number
minor: minor:
type: integer type: integer
format: int32 format: int32
description: Version minor number description: Version minor number
Figure 7: Configuration OpenAPI description (RueConfiguration.yaml) Figure 7: Configuration OpenAPI Description (RueConfiguration.yaml)
10. IANA Considerations 10. IANA Considerations
10.1. RUE Provider List Registry 10.1. RUE Provider List Registry
IANA has created the "RUE Provider List" registry. The management IANA has created the "RUE Provider List" registry. The registration
policy for this registry is "Expert Review" [RFC8126]. The expert policy is "Expert Review" [RFC8126]. A regulator operated or
should prefer a regulator operated or designated list interface designated list interface operator is preferred. Otherwise, evidence
operator. Otherwise, evidence that the proposed list interface that the proposed list interface operator will provide a complete
operator will provide a complete list of providers is required to add list of providers is required to add the entry to the registry.
the entry to the registry. Updates to the registry are permitted if Updates to the registry are permitted if the expert determines that
the expert judges the new proposed URI to provide a more accurate the proposed URI provides a more accurate list than the existing
list than the existing entry. Each entry has two fields, values for entry. Each entry has two fields; values for both MUST be provided
both of which MUST be provided when registering or updating an entry: when registering or updating an entry:
* country code: a two-letter ISO93166 country code * country code: a two-letter ISO93166 country code
* list entry point: a string is used to compose the URI to the * list entry point: a string is used to compose the URI to the
provider list interface for that country provider list interface for that country
10.2. Registration of rue-owner Value of the purpose Parameter 10.2. Registration of Rue-Owner Value of the Purpose Parameter
This document defines the new predefined value "rue-owner" for the This document defines the new predefined value "rue-owner" for the
"purpose" header field parameter of the Call-Info header field. The "purpose" header field parameter of the Call-Info header field. The
use for rue-owner is defined in Section 5.2.3. This modifies the use for rue-owner is defined in Section 5.2.3. IANA has added a
"Header Field Parameters and Parameter Values" subregistry of the reference to this document in the "Header Field Parameters and
"Session Initiation Protocol (SIP) Parameters" registry by adding Parameter Values" subregistry of the "Session Initiation Protocol
this RFC as a reference to the line for the header field "Call-Info" (SIP) Parameters" for the header field "Call-Info" and parameter name
and parameter name "purpose" "purpose".
* Header Field: Call-Info Header Field: Call-Info
* Parameter Name: purpose Parameter Name: purpose
* Predefined Values: Yes
Predefined Values: Yes
11. Security Considerations 11. Security Considerations
The RUE is required to communicate with servers on public IP The RUE is required to communicate with servers on public IP
addresses and specific ports to perform its required functions. If addresses and specific ports to perform its required functions. If
it is necessary for the RUE to function on a corporate or other it is necessary for the RUE to function on a corporate or other
network that operates a default-deny firewall between the RUE and network that operates a default-deny firewall between the RUE and
these services, the user must arrange with their network manager for these services, the user must arrange with their network manager for
passage of traffic through such a firewall in accordance with the passage of traffic through such a firewall in accordance with the
protocols and associated SRV records as exposed by the provider. protocols and associated SRV records as exposed by the provider.
Because VRS providers may use different ports for different services, Because VRS providers may use different ports for different services,
these port numbers may differ from provider to provider. these port numbers may differ from provider to provider.
This document requires implementation and use of a number of other This document requires implementation and use of a number of other
specifications in order to fulfill the RUE profile; the security specifications in order to fulfill the RUE profile; the security
considerations described in those documents apply accordingly to the considerations described in those documents apply accordingly to the
RUE interactions. RUE interactions.
When a CA participates in a conversation they have access to the When a CA participates in a conversation, they have access to the
content of the conversation even though it is nominally a content of the conversation even though it is nominally a
conversation between the two endpoints. There is an expectation that conversation between the two endpoints. There is an expectation that
the CA will keep the communication contents in confidence. This is the CA will keep the communication contents in confidence. This is
usually defined by contractual or legal requirements. usually defined by contractual or legal requirements.
Since different providers (within a given country) may have different Since different providers (within a given country) may have different
policies, RUE implementations MUST include a user interaction step to policies, RUE implementations MUST include a user interaction step to
select from available providers before proceeding to actually select from available providers before proceeding to actually
register with any given provider. register with any given provider.
12. 12. Normative References
Normative References
[OpenApi] Miller, D., Whitlock, J., Gardiner, M., Ralpson, M., [OpenAPI] Miller, D., Whitlock, J., Gardiner, M., Ralphson, M.,
Ratovsky, R., and U. Sarid, "OpenAPI Specification Ratovsky, R., and U. Sarid, "OpenAPI Specification
v3.0.1", December 2017, v3.0.1", December 2017,
<https://spec.openapis.org/oas/v3.0.1>. <https://spec.openapis.org/oas/v3.0.1>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
skipping to change at page 40, line 38 skipping to change at line 1873
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866, Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021, DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>. <https://www.rfc-editor.org/info/rfc8866>.
[RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real- [RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real-
Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021,
<https://www.rfc-editor.org/info/rfc9071>. <https://www.rfc-editor.org/info/rfc9071>.
13. 13. Informative References
Informative References
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
K. Summers, "Session Initiation Protocol (SIP) Basic Call K. Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665,
December 2003, <https://www.rfc-editor.org/info/rfc3665>. December 2003, <https://www.rfc-editor.org/info/rfc3665>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Acknowledgements Acknowledgements
Brett Henderson and Jim Malloy provided many helpful edits to prior Brett Henderson and Jim Malloy provided many helpful edits to prior
versions of this document. Paul Kyzivat provided extensive reviews draft versions of this document. Paul Kyzivat provided extensive
and comments. reviews and comments.
Author's Address Author's Address
Brian Rosen Brian Rosen
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
United States of America United States of America
Email: br@brianrosen.net Email: br@brianrosen.net
 End of changes. 207 change blocks. 
618 lines changed or deleted 622 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/