<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" > [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-rum-rue-11" number="9248" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="yes" xml:lang="en" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" version="3" consensus="yes">
<!-- ***** FRONT MATTER ***** --> version="3">
<front>
<title abbrev="Relay User Equipment Profile">Interoperability Profile for Relay User Equipment</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rum-rue-11"/> name="RFC" value="9248"/>
<author fullname="Brian Rosen" initials="B." surname="Rosen">
<address>
<postal>
<street>470 Conrad Dr</street>
<!-- Reorder these if your country does things differently -->
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>US</country>
<country>United States of America</country>
</postal>
<email>br@brianrosen.net</email>
</address>
</author>
<date year="2022"/> year="2022" month="June"/>
<area>art</area>
<workgroup>rum</workgroup>
<keyword>rue</keyword>
<keyword>relay user equipment</keyword>
<abstract>
<t>Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or hearing impaired user has a speech disability using an interpreter ("Communications Assistant") (i.e., a Communications Assistant (CA)) connected via a videophone to the deaf/hard of hearing/hearing impaired user sign language speaker and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency agency, termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, service and subsequently to CAs and other deaf/hard of hearing/hearing impaired users. sign language speakers. It is desirable that the videophones used by the deaf, hard of hearing or hearing impaired user sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between deaf, hard of hearing or hearing impaired users sign language speakers work. This document describes the interface between a videophone and a provider.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Introduction</name>
<t>Video Relay Service (VRS) is a form of Telecommunications Relay Service (TRS) that enables persons people with hearing disabilities who use sign language,
such as American Sign Language (ASL), to communicate with voice telephone users through video equipment.
These services also enable communication between such
individuals directly in suitable modalities, including any combination of sign language via video, real-time text (RTT), text, and speech.
</t>
<t>
This Interoperability Profile interoperability profile for Relay User Equipment (RUE) is a profile of the Session Initiation Protocol (SIP) and related media protocols that
enables end-user equipment registration and calling for VRS calls. It specifies the minimal set of call flows, Internet Engineering Task Force (IETF) flows and IETF
and ITU-T standards that must be supported, provides guidance where the standards leave multiple implementation options, and specifies minimal and extended capabilities for RUE calls.</t>
<t>
Both deaf/HoH to provider subscriber-to-provider (interpreted) and direct deaf/HoH to deaf/HoH subscriber-to-subscriber
calls are supported on this interface.
While there are some accommodations in this document to maximize backwards compatibility with other devices and services that are used to provide VRS service, backwards compatibility is not a requirement, and some interwork may be required to allow direct video calls to older devices. This document only describes the interface between the device and the provider, and not any other interface the provider may have. </t>
<t>The following illustrates a typical relay call. The RUE device and the Commincations Assistant communications assistant (sign language interpretter) interpreter) have videophones. The Hearing User hearing user has a telephone (mobile or fixed).</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
||== RUE Interface (this document)
||
\/
+----+
+------+ +------+ - +--------+ - +-------+
|Deaf|
|User | |RUE | ( ) |Provider| ( ) |Hearing|
|User|<->|Device|<-(Internet)->| |User |
|who is| |Device|<-(Internet)->| | |who is |
|Deaf |<->| | | |<-( PSTN )->|User |
+----+ )->|Hearing|
+------+ +------+ -------- +--------+ ------ +-------+
^
|
+--------------+
|Communications|
|Assistant |
+--------------+
]]></artwork>
</section>
<section numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Terminology</name>
<t>
Communication
<dl newline="true" spacing="normal">
<dt>Communications Assistant (CA): A (CA):</dt>
<dd>A sign-language interpreter working for a VRS provider, providing functionally equivalent phone service.
</t>
<t>
Communication service.</dd>
<dt>Communication modality (modality): A (modality):</dt>
<dd>A specific form of communication that may be employed by two users, e.g., English voice, Spanish voice,
American Sign Language, English lip-reading, lipreading, or French real-time-text. real-time text. Here, one communication modality is assumed to encompass both the
language and the way that language is exchanged. For example, English voice and French voice are two different communication modalities.
</t>
<t>
Default modalities.</dd>
<dt>Default video relay service: The service:</dt>
<dd>The video relay service operated by a subscriber's default VRS provider.
</t>
<t>
Default provider.</dd>
<dt>Default video relay service provider (default provider): The provider):</dt>
<dd>The VRS
provider that registers, registers and assigns a telephone number to a
specific subscriber, and subscriber and, by default default, provides the
VRS for incoming voice calls to the user. The default
provider
provider, also by default default, provides the VRS for outgoing relay calls. The
user can have more than one telephone number number, and each has a default
provider.
</t>
<t>
Outbound Dial-around call: A
provider.</dd>
<dt>Outbound dial-around call:</dt>
<dd>A relay call where the subscriber specifies the use of a VRS provider other than the default VRS provider.
This can be accomplished by the user dialing a "front-door" number for a VRS provider and signing or texting a phone number to call ("two-stage").
Alternatively, this can be accomplished by the user's RUE software instructing the server of its default VRS provider to automatically route the call through the alternate provider to the desired public switched telephone network Public Switched Telephone Network (PSTN) directory number ("one-stage"). Dial-around is per-call -- per call; for any call, a user can use the default VRS provider or any dial-around VRS provider.
</t>
<t>
Full
</dd>
<dt>Full Intra Request (FIR): A (FIR):</dt>
<dd>A request to a video media sender, requiring that media sender to send a Decoder Refresh Point decoder refresh point at the earliest opportunity. FIR is sometimes known as "instantaneous decoder refresh request", "video fast update request", or "fast update request".
</t><t>
Point-to-Point request".</dd>
<dt>Point-to-Point Call (P2P Call): A Call):</dt>
<dd>A call between two RUEs, without including a CA.
</t>
<t>
Relay call: A CA.</dd>
<dt>Relay call:</dt>
<dd>A call that allows persons people with hearing or speech disabilities to use a RUE to talk to users of conventional voice services with the aid of a communication assistant (CA) CA to relay the communication.
</t>
<t>
Relay communication.</dd>
<dt>Relay service (RS): A (RS):</dt>
<dd>A service that allow allows a registered subscriber to use a RUE to make and receive relay calls, point-to-point calls, and relay-to-relay calls. The functions provided by the relay service include the provision of media links supporting the communication modalities used by the caller and callee, and user registration and validation, authentication, authorization, automatic call distributor (ACD) platform functions, routing (including emergency call routing), call setup, mapping, call features (such as call forwarding and video mail), and assignment of CAs to relay calls.
</t>
<t>
Relay calls.</dd>
<dt>Relay service provider (provider): An (provider):</dt>
<dd>An organization that operates a relay service. A subscriber selects a relay service provider to assign and register a telephone number for their use, to register with for receipt of incoming calls, and to provide the default service for outgoing calls.
</t>
<t>
Relay user: Please calls.</dd>
<dt>Relay user:</dt>
<dd>Please refer to "subscriber".
</t>
<t>
Relay "subscriber".</dd>
<dt>Relay user E.164 Number (user E.164): The E.164):</dt>
<dd>The telephone number (in ITU-T E.164 format) assigned to the user.
</t>
<t>
Relay user equipment (RUE): A user.</dd>
<dt>Relay User Equipment (RUE):</dt>
<dd>A SIP user agent (UA) enhanced with extra features to support a subscriber in requesting, receiving receiving, and using relay calls. A RUE may take many forms, including a stand-alone device; an application running on a general-purpose computing device device, such as a laptop, tablet tablet, or smartphone; or proprietary equipment connected to a server that provides the RUE interface.
</t>
<t>
RUE Interface: the interface.</dd>
<dt>RUE interface:</dt>
<dd>The interfaces described in this document between a RUE and a VRS provider who supports it
</t>
<t>
Sign language: A it.</dd>
<dt>Sign language:</dt>
<dd>A language that uses hand gestures and body language to convey meaning meaning, including, but not limited to, American Sign Language (ASL).
</t>
<t>
Subscriber: An (ASL).</dd>
<dt>Subscriber:</dt>
<dd>An individual who has registered with a provider and who obtains service by using relay user equipment. a RUE. This is the conventional telecom term for an end-user customer, which in our this case is a relay user. A user may be a subscriber to more than one VRS provider.
</t>
<t>
Video relay service (VRS): A provider.</dd>
<dt>Video Relay Service (VRS):</dt>
<dd>A relay service for people with hearing or speech disabilities who use sign language to communicate using video equipment (video RUE) with other people in real time. The video link allows the CA to view and interpret the subscriber's signed conversation and relay the conversation back and forth with the other party.
</t> party.</dd>
</dl>
</section>
<section numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Requirements Language</name>
<t>The
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and
"OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP
14 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
Lower- or mixed-case uses of these key
words are not to be interpreted as carrying special significance.
</t>
</section>
<section anchor="general" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>General Requirements</name>
<t>
All
<t>All HTTP/HTTPS <xref target="RFC7230"/> and <xref target="RFC2818"/> connections specified throughout this document MUST <bcp14>MUST</bcp14> use HTTPS. Both HTTPS and all SIP connections MUST <bcp14>MUST</bcp14> use TLS conforming to at least <xref target="RFC7525" format="default"/> and MUST <bcp14>MUST</bcp14> support <xref target="RFC8446" format="default"/>.
</t>
<t>
All text data payloads not otherwise constrained by a specification in another standards document MUST <bcp14>MUST</bcp14> be encoded as Unicode UTF-8.
</t>
<t>Implementations MUST <bcp14>MUST</bcp14> support IPv4 and IPv6. Dual stack Dual-stack support is NOT required required, and provider implementations MAY <bcp14>MAY</bcp14> support separate interfaces for IPv4 and IPv6 by having more than one server in the appropriate SRV record where there is either an A or AAAA record in each server DNS record but not both. The same version of IP MUST <bcp14>MUST</bcp14> be used for both signaling and media of a call unless ICE (<xref Interactive Connectivity Establishment (ICE) <xref target="RFC8445" format="default"/>) format="default"/> is used, used; in which case case, candidates may explicitly offer IPv4, IPv6 IPv6, or both for any media stream.</t>
</section>
<section anchor="sip" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>SIP Signaling</name>
<t>
Implementations
<t>Implementations of the RUE Interface MUST interface <bcp14>MUST</bcp14> conform to the following core SIP standards:</t><ul> standards:</t>
<ul spacing="normal">
<li> <xref target="RFC3261" format="default"/> (Base SIP)</li>
<li> <xref target="RFC3263" format="default"/> (Locating SIP Servers)</li>
<li> <xref target="RFC3264" format="default"/> (Offer/Answer)</li>
<li> <xref target="RFC3840" format="default"/> (User Agent Capabilities)</li>
<li> <xref target="RFC5626" format="default"/> (Outbound)</li>
<li> <xref target="RFC8866" format="default"/> (Session Description Protocol)</li>
<li> <xref target="RFC3323" format="default"/> (Privacy)</li>
<li> <xref target="RFC3605" format="default"/> (RTCP Attribute in SDP)</li>
<li> <xref target="RFC6665" format="default"/> (SIP Events)</li>
<li> <xref target="RFC3311" format="default"/> (UPDATE Method)</li>
<li> <xref target="RFC5393" format="default"/> (Loop-Fix)</li>
<li> <xref target="RFC5658" format="default"/> (Record Route fix)</li> (Record-Route Fix)</li>
<li> <xref target="RFC5954" format="default"/> (ABNF fix)</li> Fix)</li>
<li> <xref target="RFC3960" format="default"/> (Early Media)</li>
<li> <xref target="RFC6442" format="default"/> (Geolocation header field)</li> Header Field)</li>
</ul>
<t>
In the above documents documents, the RUE device conforms to the requirements of a SIP user Agent, agent, and the provider conforms to the requirements of Registrar the registrar and Proxy Server proxy server where the document specifies different behavior for different roles. The only requirement on For providers for RFC6665 (Events) is offering a video mail service, <xref target="RFC6665" format="default"/> (SIP Events) <bcp14>MUST</bcp14> be implemented to support for the Message Waiting Message-Waiting Indicator (See (MWI) (see <xref target="mwi"/>), which is optional and providers not supporting video mail need not support RFC6665. target="mwi"/>).
</t>
<t>
In
<t>In addition, implementations MUST <bcp14>MUST</bcp14> conform to:</t>
<ul>
<ul spacing="normal">
<li> <xref target="RFC3327" format="default"/> (Path)</li> (Path Header Field)</li>
<li> <xref target="RFC8445" format="default"/> and <xref target="RFC8839"/> (ICE)</li>
<li> <xref target="RFC3326" format="default"/> (Reason header field)</li> Header Field)</li>
<li> <xref target="RFC3515" format="default"/> (REFER Method)</li>
<li> <xref target="RFC3891" format="default"/> (Replaces Header field)</li> Field)</li>
<li> <xref target="RFC3892" format="default"/> (Referred-By)</li> (Referred-By Header Field)</li>
</ul>
<t>Implementations MUST <bcp14>MUST</bcp14> implement full ICE, although they MAY <bcp14>MAY</bcp14> interwork with User Agents user agents that implement ICE-lite.</t>
<t>
Implementations MUST <bcp14>MUST</bcp14> include a "User-Agent" header field uniquely identifying the RUE application, platform, and version in all SIP requests, requests and MUST <bcp14>MUST</bcp14> include a "Server" header field with the same content in SIP responses.
</t>
<t>Implementations intended to support mobile platforms MUST <bcp14>MUST</bcp14> support <xref target="RFC8599"/> and MUST <bcp14>MUST</bcp14> use it as at least one way to support waking up the client from the background state. </t>
<t>The SIP signaling for registration and placing/receiving calls depends on the configuration of various values into the RUE device. <xref target="config"/> describes the configuration mechanism which that provides values that are used in the signaling. When the device starts, the configuration mechanism is run run, which retrieves the configuration data, and then data; then, SIP registration occurs using the values from the configuration. After registration, calls may be sent or received by the RUE device.</t>
<section anchor="register" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Registration</name>
<t>
The RUE MUST <bcp14>MUST</bcp14> register with a SIP registrar, following <xref target="RFC3261" format="default"/> and <xref target="RFC5626" format="default"/> format="default"/>, at a provider it has an account with. If the configuration (see <xref target="config"/>) contains multiple "outbound-proxies" in "RueConfigurationData", then the RUE MUST <bcp14>MUST</bcp14> use them as specified in [RFC5626] <xref target="RFC5626" format="default"/> to establish multiple flows.
</t>
<t>
The Request-URI for the REGISTER request MUST <bcp14>MUST</bcp14> contain the "provider-domain" from the configuration. The To-URI To URI and From-URI MUST From URI <bcp14>MUST</bcp14> be identical URIs, URIs and formatted as follows:</t>
<ul><li>if
<ul spacing="normal">
<li>if "user-name" is provided:"username@provider-domain"; </li> provided: "username@provider-domain"</li>
<li>if "user-name" is not provided: as specified in <xref target="uriphone"/>, using use "phone-number" and "provider-domain" from the configuration.</li></ul> configuration</li>
</ul>
<t>
The RUE determines the URI to resolve by initially determining if one or more outbound proxies are+ "outbound-proxies" are configured. If there are, they are configured, the URI will be that of one of the "outbound-proxies". If no "outbound-proxies" are configured, the URI will be the Request-URI from the REGISTER request. The RUE extracts the domain from that URI and consults the DNS record for that domain. The DNS entry MUST <bcp14>MUST</bcp14> contain NAPTR records conforming to RFC3263. <xref target="RFC3263" format="default"/>. One of those NAPTR records MUST <bcp14>MUST</bcp14> specify TLS as the preferred transport for SIP. For example, a DNS NAPTR query for "sip: p1.red.example.net" could return:
</t>
<!-- v2v3: </> promoted to be child of <section/>, and the enclosing <t/> split. -->
<sourcecode name="dns-rr" type=""><![CDATA[
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
]]></sourcecode>
<t>
If the RUE receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it MUST re-attempt <bcp14>MUST</bcp14> reattempt registration without using the outbound mechanism.
</t>
<t>
The registrar MAY <bcp14>MAY</bcp14> authenticate the RUE using SIP digest authentication. The credentials to be used MUST <bcp14>MUST</bcp14> come from the configuration in <xref target="config"/>: "user-name" if provided or "phone-number" if user-name is not provided, and "sip-password". This "user-name"/"sip-password" combination SHOULD NOT <bcp14>SHOULD NOT</bcp14> be the same as
that used for other purposes, except as expressly described below, such as retrieving the RUE configuration or logging into the Provider's provider's customer service portal.
<xref target="RFC8760" format="default"/> MUST <bcp14>MUST</bcp14> be supported by all implementations implementations, and SHA-512 digest algorithms MUST <bcp14>MUST</bcp14> be supported.
</t>
<t>
If the registration request fails with an indication that credentials from the configuration are invalid,
then the RUE MUST <bcp14>MUST</bcp14> retrieve a fresh version of the configuration.
If credentials from a freshly retrieved configuration are found to be invalid,
then the RUE MUST <bcp14>MUST</bcp14> cease attempts to register and inform the RUE User user of the problem.
</t>
<t>
Support for multiple simultaneous registrations with multiple providers by the RUE is OPTIONAL <bcp14>OPTIONAL</bcp14> for the RUE (and providers do not need any support for this option).
</t>
<t>
Multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI SHOULD <bcp14>SHOULD</bcp14> be permitted by the provider. The provider MAY <bcp14>MAY</bcp14> limit the total number of simultaneous registrations. When a new registration request is received that results in exceeding the limit on simultaneous registrations, the provider MAY <bcp14>MAY</bcp14> then prematurely terminate another registration; however, it SHOULD NOT <bcp14>SHOULD NOT</bcp14> do this if it would disconnect an active call.
</t>
<t>
If a provider prematurely terminates a registration to reduce the total number of concurrent registrations with the same URI, it SHOULD <bcp14>SHOULD</bcp14> take some action to prevent the affected RUE from automatically re-registering and re-triggering the condition.
</t>
</section>
<section anchor="session" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Session Establishment</name>
<section anchor="normalcall" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Normal Call Origination</name>
<t>
After initial SIP registration, the RUE adheres to SIP <xref target="RFC3261" format="default"/> basic call flows, as documented in <xref target="RFC3665" format="default"/>.
</t>
<t>
A RUE device MUST <bcp14>MUST</bcp14> route all outbound calls through an outbound proxy if configured.
</t>
<t>
The SIP URIs in the To field and the Request-URI MUST <bcp14>MUST</bcp14> be formatted as specified in subsection <xref target='uriphone'/> using the destination phone number, number or as SIP URIs, URIs as provided in the configuration (<xref target="config"/>). The domain field of the URIs SHOULD <bcp14>SHOULD</bcp14> be the "provider-domain" from the configuration (e.g., sip:+15551234567@red.example.com;user=phone) sip:+15551234567@red.example.com;user=phone), except that an anonymous call would not use the provider domain.
</t>
<t>
Anonymous calls MUST <bcp14>MUST</bcp14> be supported by all implementations. An anonymous call is signaled per <xref target="RFC3323" format="default"/>.
</t>
<t>
The From-URI MUST From URI <bcp14>MUST</bcp14> be formatted as specified in <xref target="uriphone" format="default"/>, using the phone-number "phone-number" and "provider-domain" from the configuration. It SHOULD <bcp14>SHOULD</bcp14> also contain the display-name from the configuration when present. (Please refer to <xref target="config" format="default"/>.)
</t>
<t>
Negotiated media MUST <bcp14>MUST</bcp14> follow the requirements specified in <xref target="media" format="default"/> of this document.
</t>
<t>
To allow time to time out for an unanswered call to time out and direct it to a videomail server, the User Agent Client MUST NOT <bcp14>MUST NOT</bcp14> impose a time limit less than the default SIP Invite INVITE transaction timeout of 3 minutes.
</t>
</section>
<section anchor="onestage" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Dial-Around Origination</name>
<t>Providers and RUE devices MUST <bcp14>MUST</bcp14> support both One-Stage one-stage and Two-Stage dial-around</t> two-stage dial-around.</t>
<t>
Outbound dial-around calls allow a RUE user to select any provider to provide interpreting services for any call.
"Two-stage" dial-around calls involve the RUE calling a telephone number that reaches the dial-around provider and
using signing or DTMF dual-tone multi-frequency (DTMF) to provide the called party party's telephone number. In two-stage dial-around, the To URI is the "frontDoor" "front-door" URI (see <xref target="config"/>) in "ProviderConfigurationData" of
the dial-around provider. The RUE Provider Selection service (<xref target="providerselect"/>) can be used by the RUE to obtain a list of providers and then providers; then, the Provider Configuration provider configuration (<xref target="providerConfig"/>) can be used to find the front door front-door URI for each of these providers.
</t>
<t>
One-stage dial-around is a method where the called party party's telephone number is provided in the To URI and the Request-URI,
using the domain of the dial-around provider.
</t>
<t>
For one-stage dial-around, the RUE MUST <bcp14>MUST</bcp14> follow the procedures in <xref target="normalcall" format="default"/> with the
following exception: the domain part of the SIP URIs in the To field and the Request-URI MUST <bcp14>MUST</bcp14> be the domain of the
dial-around provider, provider discovered according to as described in <xref target="providerselect" format="default"/>.
</t>
<t>
The following is a partial example of a one-stage dial-around call from VRS user +1-555-222-0001 hosted by red.example.com
to a hearing user +1-555-123-4567 using dial-around to green.example.com for the relay service. Only important details of the
messages are shown shown, and many header fields have been omitted:
</t>
<!-- v2v3: <figure/> promoted to be child of <section/>, and the enclosing <t/> split. -->
<figure>
<!-- v2v3: Moved attribute title to <name/> -->
<name>One-Stage Dial-Around</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
,-+-. ,----+----. ,-----+-----.
|RUE| |Default | |Dial-Around|
| | |Provider | | Provider |
`-+-' `----+----' `-----+-----'
| | |
| [1] INVITE | |
|-------------->| [2] INVITE |
| |-------------->|
Message Details:
[1] INVITE Rue -> Default Provider
INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" <sip:+15552220001@red.example.net;user=phone>
[2] INVITE Default Provider -> Dial-Around Provider
INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" sip:+15552220001@red.example.net;user=phone
P-Asserted-Identity: sip:+15552220001@red.example.net
]]></artwork>
</figure>
</section>
<section anchor="contact" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>RUE Contact Information</name>
<t>
To identify the owner of a RUE, the initial INVITE for a call from a RUE, or the 200 OK the RUE uses to accept a call,
identifies the owner by sending a Call-Info header field with a purpose parameter of "rue-owner".
The URI MAY <bcp14>MAY</bcp14> be an HTTPS URI or Content-ID URL. The latter is defined by <xref target="RFC2392" format="default"/> to locate
message body parts. This URI type is present in a SIP message to convey the RUE ownership information as a
MIME body. The form of the RUE ownership information is a an xCard <xref target="RFC6351" format="default"/>.
Please refer to <xref target="RFC6442"/> for an example of using Content-Indirect content indirection URLs in SIP messages. Note that use of the Content-Indirect content indirection URL
usually implies multiple message bodies ("mime/multipart"). The RUE owner is the entity that has local control over the device which that is not necessarily the legal owner of the equipment. It often is the user, but that is not necessarily true. While no minimum fields in the xCard are specified, the name, address, phone number number, and email address of the RUE owner are expected to be supplied.
</t>
</section>
<section anchor="incoming" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Incoming Calls</name>
<t>
The
<t>The RUE MUST <bcp14>MUST</bcp14> only accept inbound calls sent to it by a proxy mentioned in the configuration.
</t>
<t>
If Multiple
<t>If multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI exist,
the provider MUST <bcp14>MUST</bcp14> parallel fork the call to all registered RUEs so that they ring at the same time.
The first RUE to reply with a 200 OK answers the call call, and the
provider MUST CANCEL <bcp14>MUST</bcp14> cancel other call branches. branches using a CANCEL request.
</t>
</section>
<section anchor="emergency" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Emergency Calls</name>
<t>
Implementations MUST
<t>Implementations <bcp14>MUST</bcp14> conform to <xref target="RFC6881" format="default"/> for handling of emergency calls, except that if the device is unable to determine its own location, it MAY <bcp14>MAY</bcp14> send the emergency call without a Geolocation header field and without a Route header field (since it would be unable to query the LoST Location-to-Service Translation (LoST) server for a route route, per RFC6881). <xref target="RFC6881" format="default"/>). If an emergency call arrives at the provider without a Geolocation header field, the provider MUST <bcp14>MUST</bcp14> supply location by adding the Geolocation header field, field and MUST <bcp14>MUST</bcp14> supply the route by querying the LoST server with that location.
</t>
<t>
If the emergency call is to be handled using existing country specific country-specific procedures,
the provider is responsible for modifying the INVITE to conform to the country-specific requirements.
In this case, the location MAY <bcp14>MAY</bcp14> be extracted from the RFC6881 <xref target="RFC6881" format="default"/> conformant INVITE and used to
propagate it to the appropriate country-specific entities. If the configuration specifies it, an implementation of a RUE device
MAY
<bcp14>MAY</bcp14> send a Geolocation header field containing its location in the
REGISTER request. If implemented, users MUST <bcp14>MUST</bcp14> be offered an opt-out. Country-specific procedures might require the location to
be pre-loaded preloaded in some entity prior to placing an emergency call;
however, the RUE may have a more accurate and timely device location
than the manual, pre-loaded preloaded entry. That information MAY <bcp14>MAY</bcp14> be used to populate the location to appropriate country-specific entities. Re-registration SHOULD <bcp14>SHOULD</bcp14> be used to update the location, so long as the rate of re-registration is limited if the device is moving.
</t>
<t>Implementations MUST <bcp14>MUST</bcp14> implement Additional Data, additional data <xref target="RFC7852"/>. RUE devices MUST <bcp14>MUST</bcp14> implement Data Provider, Device Information data provider information, device information, and Owner/Subscriber Information owner/subscriber information blocks. </t>
</section>
</section>
<section anchor="midcall" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Mid-Call Signaling</name>
<t>
Implementations MUST <bcp14>MUST</bcp14> support re-INVITE to renegotiate media session parameters (among other uses).
Per <xref target="srtp" target="mediafeat" format="default"/>, implementations MUST <bcp14>MUST</bcp14> be able to support an INFO request message for full frame refresh for devices that do not support RTCP mechanisms SRTCP (please refer to <xref target="mediafeat" target="srtp" format="default"/>).
Implementations MUST <bcp14>MUST</bcp14> support an in-dialog REFER (<xref (as described in <xref target="RFC3515" format="default"/> and updated by <xref target="RFC7647" format="default"/> format="default"/>, and including support for norefersub per <xref target="RFC4488" format="default"/>) with the Replaces header field <xref target="RFC3891" format="default"/> to enable call transfer.
</t>
</section>
<section anchor="uriphone" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>URI Representation of Phone Numbers</name>
<t>
SIP URIs constructed from non-URI sources (dial strings) and sent to SIP proxies by the RUE MUST <bcp14>MUST</bcp14> be represented as follows, depending on whether they can be represented as an E.164 number. In this section section, "expressed as an E.164 number" includes numbers numbers, such as toll-free numbers that are not actually E.164 numbers, numbers but have the same format.
</t>
<t>
A dial string that can be expressed as an E.164 phone number MUST <bcp14>MUST</bcp14> be represented as a SIP URI with a URI ";user=phone" tag. The user part of the URI MUST <bcp14>MUST</bcp14> be in conformance with 'global-number' "global-number", as defined in <xref target="RFC3966" format="default"/>. The user part MUST NOT <bcp14>MUST NOT</bcp14> contain any 'visual-separator' "visual-separator" characters, as defined in <xref target="RFC3966"/>.
</t>
<t>
Dial strings that cannot be expressed as E.164 numbers MUST <bcp14>MUST</bcp14> be represented as dialstring URIs, as specified by <xref target="RFC4967" format="default"/>, e.g., sip:411@red.example.net;user=dialstring.
</t>
<t>
The domain part of Relay Service relay service URIs and User Address of Records (AoR) MUST <bcp14>MUST</bcp14> resolve (per <xref target="RFC3263" format="default"/>) to globally routable IPv4 and/or IPv6 addresses.
</t>
</section>
<section anchor="nat" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Transport</name>
<t>
Implementations MUST <bcp14>MUST</bcp14> conform to <xref target="RFC8835" format="default"/> format="default"/>, except for its guidance on the WebRTC data channel, which this specification does not use. See <xref target="text"/> for how RUE supports real-time text without the data channel.
</t>
<t>
Implementations MUST <bcp14>MUST</bcp14> support SIP outbound <xref target="RFC5626" format="default"/> (please also refer to <xref target="register" format="default"/>).
</t>
</section>
</section>
<section anchor="media" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Media</name>
<t>This specification adopts the media specifications for WebRTC (<xref <xref target="RFC8825" format="default"/>). format="default"/>.
Where WebRTC defines how interactive media communications may be established using a browser as a client, this specification assumes a normal SIP call.
Various RTP, RTCP, SDP RTPs, RTCPs, SDPs, and specific media requirements specified for WebRTC are adopted for this document. Explicit requirements from the WebRTC suite of documents are described below . </t>
<t>To use WebRTC with this document, a gateway that presents a WebRTC server interface towards a browser, browser and a RUE client interface towards a provider is assumed. The gateway would interwork signaling, and signaling and, as noted below, interwork at least any real time real-time text media, media in order to allow a standard browser based browser-based WebRTC client to be a VRS client. The combination of the browser client and the gateway would be a RUE user. This document does not specify the gateway.</t>
<t> The following sections specify the WebRTC documents to which conformance is required. "Mandatory to Implement" means a conforming implementation MUST <bcp14>MUST</bcp14> implement the
specified capability. It does not mean that the capability must be used in every session. For example, OPUS Opus is a mandatory to implement Mandatory-to-Implement audio codec, and all conforming
implementations must support OPUS. Opus.
However, an implementation presenting a call across the RUE Interface where interface (where the call originates in the Public Switched Telephone Network, PSTN or an older, non-RUE-compatible device, which only offers G.711 audio, audio) does not need to
include the OPUS Opus codec in the offer, since it cannot be used with that call. Conformance to this document allows end-to-end RTCP and media congestion control for audio and video.</t>
<section anchor="srtp" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>SRTP and SRTCP</name>
<t>
Implementations MUST <bcp14>MUST</bcp14> support <xref target="RFC8834" format="default"/> format="default"/>, except that MediaStreamTracks are not used. Implementations MUST <bcp14>MUST</bcp14> conform to Section 6.4 of <xref target="RFC8827" format="default"/>. sectionFormat="of" section="6.4"/>.
</t>
</section>
<section anchor="text" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Text-Based Communication</name>
<t>
Implementations MUST <bcp14>MUST</bcp14> support real-time text (<xref <xref target="RFC4102" format="default"/> and <xref target="RFC4103" format="default"/>) format="default"/> via T.140 media.
One original and two redundant generations MUST <bcp14>MUST</bcp14> be transmitted and supported, supported with a 300 ms transmission interval. Implementations MUST <bcp14>MUST</bcp14> support <xref target="RFC9071"/> target="RFC9071"/>, especially for emergency calls. Note that RFC4103 <xref target="RFC4103" format="default"/> is
not how real-time text is transmitted in WebRTC WebRTC, and some form of transcoder would be required to interwork real-time text in the data channel
of WebRTC to RFC4103 <xref target="RFC4103" format="default"/> real-time text.
</t>
<t>
Transport of T.140 real-time text in WebRTC is specified in <xref target="RFC8865"/>, using
the WebRTC data channel. RFC 8865 <xref target="RFC8865" format="default"/> also has some advice on how gateways
between RFC 4103 <xref target="RFC4103" format="default"/> and RFC 8865 <xref target="RFC8865" format="default"/> should operate. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that
RFC 8865
<xref target="RFC8865" format="default"/>, including multiparty support is support, be used for communication with browser-based WebRTC implementations. Implementations MUST <bcp14>MUST</bcp14> support <xref target="RFC9071"/>.
</t>
</section>
<section anchor="video" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Video</name>
<t>
Implementations MUST
<t>Implementations <bcp14>MUST</bcp14> conform to <xref
target="RFC7742" format="default"/> with the following exceptions:
only H.264, as specified in <xref target=
"RFC7742"/>, target="RFC7742"/>, is Mandatory to
Implement, and VP8 support is OPTIONAL <bcp14>OPTIONAL</bcp14> at both the
device and providers. This is because backwards compatibility is
desirable, and older devices do not support VP8.
</t>
</section>
<section anchor="audio" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Audio</name>
<t>
Implementations MUST
<t>Implementations <bcp14>MUST</bcp14> conform to <xref
target="RFC7874" format="default"/>.
</t>
</section>
<section anchor="dtmf" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>DTMF Digits</name>
<t>
Implementations MUST <bcp14>MUST</bcp14> support the "audio/telephone-event" <xref target="RFC4733" format="default"/> media type. They MUST <bcp14>MUST</bcp14> support
conveying event codes 0 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. <xref target="RFC4733"/>. Handling of other tones is OPTIONAL. <bcp14>OPTIONAL</bcp14>.
</t>
</section>
<section anchor="SDP" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Session Description Protocol</name>
<t>
The SDP offers and answers MUST <bcp14>MUST</bcp14> conform to the SDP rules in <xref target="RFC8829"/>
except that the RUE interface uses SIP transport for SDP. The SDP
for real-time text MUST <bcp14>MUST</bcp14> specify the T.140 payload type <xref target="RFC4103"/>.
</t>
</section>
<section anchor="privacy" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Privacy</name>
<t>
The RUE MUST <bcp14>MUST</bcp14> provide for user privacy by implementing a local
one-way mute, without signaling, for both audio and video.
However, RUE
MUST
<bcp14>MUST</bcp14> maintain any states in the network (e.g. (e.g., NAT bindings) by periodically sending media packets
on all active media sessions containing silence/comfort noise/black
screen/etc. silence, comfort noise, blank
screen, etc., per <xref target="RFC6263" format="default"/>.
</t>
</section>
<section anchor="mediafeat" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Negative Acknowledgment, Packet Acknowledgement, Picture Loss Indicator, and Full Intraframe Request Features</name>
<t>The NACK, FIR FIR, and PLI features Picture Loss Indicator (PLI) features, as described in <xref target = "RFC4585"/> and <xref target="RFC5104"/> MUST target="RFC5104"/>, <bcp14>MUST</bcp14> be implemented. Availability of these features MUST <bcp14>MUST</bcp14> be announced with the "ccm" feedback value. NACK should be used when negotiated and conditions warrant its use and the other end supports it. Signaling picture losses as Packet Loss Indicator (PLI) a PLI should be preferred. FIR should be used only in situations where not sending a decoder refresh point would render the video unusable for the users, as per RFC5104 subsection 4.3.1.2.
</t>
<t>
For <xref target="RFC5104" sectionFormat="of" section="4.3.1.2"/>.</t>
<t>For backwards compatibility with calling devices that do not support the foregoing methods, implementations MUST <bcp14>MUST</bcp14> implement SIP INFO messages to send and receive XML encoded XML-encoded Picture Fast Update messages according to <xref target="RFC5168" format="default"/>.
</t>
</section>
</section>
<section anchor="contacts" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Contacts</name>
<section anchor="carddav" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>CardDAV Login and Synchronization</name>
<t>
Support
<t>Support of CardDAV vCard Extensions to WebDAV (CardDAV) by providers is OPTIONAL.
</t>
<t>
The <bcp14>OPTIONAL</bcp14>.</t>
<t>The RUE MUST <bcp14>MUST</bcp14> and providers MAY <bcp14>MAY</bcp14> be able to synchronize the user's contact directory between the RUE endpoint and one maintained by the user's VRS provider using CardDAV (<xref <xref target="RFC6352" format="default"/> and <xref target="RFC6764" format="default"/>).
</t>
<t>
The format="default"/>.</t>
<t>The configuration (see Section <xref target="config"/>) RueConfigurationData MAY <bcp14>MAY</bcp14> supply a "carddav-username" and "carddav-domain" identifying a CardDAV server and address book for this account, plus an optional
"carddav-password".
</t>
<t>
To "carddav-password".</t>
<t>To access the CardDAV server and address book, the RUE MUST <bcp14>MUST</bcp14> follow Section 6 of RFC6764, <xref target="RFC6764" sectionFormat="of" section="6"/>, using the configured carddav-username and carddav-domain in place of an email address. If the request triggers a challenge for digest authentication credentials, the RUE MUST <bcp14>MUST</bcp14> continue using matching carddav-username and carddav-password from the configuration. If no carddav-username and carddav-password are configured, the RUE MUST <bcp14>MUST</bcp14> use the SIP user-name and sip-password from the configuration. If the SIP credentials fail, the RUE MUST <bcp14>MUST</bcp14> query the user.
</t>
<t>
Synchronization user.</t>
<t>Synchronization using CardDAV MUST <bcp14>MUST</bcp14> be a two-way synchronization service, with proper handling of asynchronous adds, changes, and deletes at either end of the transport channel.
</t> channel.</t>
<t>The RUE MAY <bcp14>MAY</bcp14> support other CardDAV services.</t>
</section>
<section anchor="import" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Contacts Import/Export Service</name>
<t>
Implementations MUST
<t>Implementations <bcp14>MUST</bcp14> be able to export/import the list of contacts in xCard <xref target="RFC6351" format="default"/> XML format.
</t>
<t>
The format.</t>
<t>The RUE accesses this service via the "contacts-uri" in the configuration. The URL MUST <bcp14>MUST</bcp14> resolve to identify a web server resource that imports/exports contact lists for authorized users.
</t>
<t>
The users.</t>
<t>The RUE stores/retrieves the contact list (address book) by issuing an HTTPS POST or GET request. If the request triggers a challenge for digest authentication credentials, the RUE MUST <bcp14>MUST</bcp14> attempt to continue using the "contacts-username" and "contacts-password" from the configuration. If no contacts-username is configured, the sip SIP user-name from the configuration is used, and used; if the sip SIP user-name is not configured, the phone-number is used. If user-name or phone-number is used, the sip-password is used to authenticate to the contact list server.
</t> server.</t>
</section>
</section>
<section anchor="mwi" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Video Mail</name>
<t>
Support
<t>Support for video mail includes a retrieval mechanism and a Message Waiting Message-Waiting Indicator (MWI). Message storage is not specified by this document. RUE devices MUST <bcp14>MUST</bcp14> support message retrieval using a SIP call to a specified SIP URI using DTMF to manage the mailbox, as well as a browser based browser-based interface reached at a specified HTTPS URI. If a provider supports video mail mail, at least one of these mechanisms MUST <bcp14>MUST</bcp14> be supported. RUE devices MUST <bcp14>MUST</bcp14> support both. See <xref target="config" /> for how the URI to reach the retrieval interface is obtained.
</t>
<t>
Implementations MUST obtained.</t>
<t>Implementations <bcp14>MUST</bcp14> support subscriptions to "message-summary" events <xref target="RFC3842" format="default"/> to the URI specified in the configuration. Providers MUST <bcp14>MUST</bcp14> support MWI if they support video mail. RUE devices MUST <bcp14>MUST</bcp14> support MWI.
</t>
<t>
The MWI.</t>
<t>The "videomail" and "mwi" properties in the configuration (see RueConfigurationData in <xref target="rueConfig"/>) gives give the URIs for message retrieval and "message-summary" subscription.
</t>
<t>
In subscription.</t>
<t>In notification bodies, if detailed message summaries are available, messages with video MUST <bcp14>MUST</bcp14> be reported using "message-context-class multimedia-message" multimedia-message", as defined in <xref target="RFC3458" format="default"/> .
</t> .</t>
</section>
<section numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Provisioning and Provider Selection</name>
<t>To simplify how users interact with RUE devices, the RUE interface separates provisioning into two parts. One provides a directory of providers so that a user interface can allow easy provider selection either for registering or for dial-around. The other provides configuration data for the device for each provider.</t>
<section anchor="providerselect" numbered="true" toc="default">
<name>RUE Provider Selection</name>
<t>
To
<t>To allow the user to select a relay service, the RUE MAY <bcp14>MAY</bcp14> at any time obtain (typically on startup) a list of Providers providers that provide service in a country.
IANA has established a registry that contains a two-letter country code and an a list entry point string (See (see <xref target="plist"/>). The entry point, when used with the following OpenAPI interface, returns a list of provider names for a country code suitable for display, with a corresponding entry point to obtain information about that provider. No mechanism to determine the country where the RUE is located is specified in this document. Typically Typically, the country is the home country of the user, user but may be a local country while traveling. Some countries allow support from their home country when traveling abroad. Regardless, the RUE device will need to allow the user to choose the country.
</t>
<t>
Each country that supports video relay service VRS using this specification MAY <bcp14>MAY</bcp14> support the provider list. This document does not specify who maintains the list. Some possibilities are a regulator or an entity designated by a regulator, an agreement among providers to provide the list, or a user group.
</t><t>
The interface to obtain the list of providers is described by an OpenApi OpenAPI <xref target=
"OpenApi"/>
"OpenAPI"/> interface description. In that interface description, the "servers" component includes an occurance occurrence of "localhost". The value from the registry of the "list entry point" string for the
desired country is substituted for "localhost" in the "servers"
component to obtain the server URI prefix of the interface to be
used to obtain the list of providers for that country. The "Providers" path then specifies the rest of the URI used to obtain the list. For example, if the list entryPoint is "example.com/api", the provider list would be obtained from https://example.com/api/rum/v1/Providers.
</t>
<t>
The V1.0 "ProviderList" is a JSON object consisting of an array where each entry describes one provider. Each entry consists of the following items:</t>
<ul spacing="normal">
<li>name: This parameter contains the text label identifying the provider and is meant to be displayed to the human VRS user.</li>
<li>providerEntryPoint: A string used for configuration purposes by the RUE (as discussed in <xref target="config" format="default"/>). The string MUST <bcp14>MUST</bcp14> start with a domain, domain but MAY <bcp14>MAY</bcp14> include other URI path elements after the domain. </li>
</ul>
<t>The VRS user interacts with the RUE to select from the provider list one or more providers with whom the user has already established an account, wishes to establish an account, or wishes to use the provider for a one-stage dial around.</t> dial-around.</t>
<figure>
<name>Example of a ProviderList JSON object</name> Object</name>
<sourcecode name="" type="json"><![CDATA[
{
"providers": [
{
"name": "Red",
"entryPoint": "red.example.net"
},
{
"name": "Green",
"entryPoint": "green.example.net"
},
{
"name": "Blue",
"entryPoint": "blue.example.net"
}
]
}
]]></sourcecode>
</figure>
</section>
<section anchor="config" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>RUE Configuration Service</name>
<t>
A RUE device may retrieve a provider configuration using a simple HTTPs web service. There are two entry points. One is used without user credentials, and the response includes configuration data for new user sign up signup and dial around. dial-around. The other uses a locally stored username and password that results from a new user sign up signup to authenticate to the interface and returns configuration data for the RUE.
</t>
<t>The interface to obtain configuration data is described by an OpenApi OpenAPI <xref target=
"OpenApi"/> target="OpenAPI"/> interface description. In that interface description, the "servers" component string includes an occurence occurrence of "localhost". The entry point string obtained from the provider list (<xref target="providerselect"/>) is substituted for "localhost" to obtain the server prefix of the interface. The path then specifies the rest of the URI used to obtain the list. For example, if the entryPoint from the provider list is "red.example.net", the provider configuration would be obtained from https://red.example.net/rum/V1/ProviderConfig and the RUE configuration would be obtained from https://red.example.net/rum/V1/RueConfig.
</t>
<t>
In both the queries, an optional parameter may be provided to the interface interface, which is an API Key (apiKey). The implementation MAY <bcp14>MAY</bcp14> have an apiKey obtained from the provider and specific to the implementation. The method used to obtain the apiKey is not specified in this document. The provider MAY <bcp14>MAY</bcp14> refuse to provide service to an implementation presenting an apiKey it does not recognize.
</t>
<t>
Also in both queries, the RUE device provides a client provided, client-provided, required parameter, which contains an instance identifier (instanceId). This parameter MUST <bcp14>MUST</bcp14> be the same value each time this instance (same implementation on same device) queries the interface. This MAY <bcp14>MAY</bcp14> be used by the provider, for example, to associate a location with the instance for emergency calls. This should be globally unique. A UUID Universally Unique Identifier (UUID) is suggested.
</t>
<t>
For example, a query for the RUE configuration could be
https://red.example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisKt8999"&instanceId="5595b5a3-0687-4b8e-9913-a7f2a04fb7bd"
</t>
<t>
The data returned is a JSON object consisting of key/value configuration parameters to be used by the RUE.
</t>
<t>
The configuration data payload includes the following data items. Items not noted as (OPTIONAL) (<bcp14>OPTIONAL</bcp14>) are REQUIRED. <bcp14>REQUIRED</bcp14>. If other unexpected items are found, they MUST <bcp14>MUST</bcp14> be ignored.
</t>
<section anchor="providerConfig" numbered="true" toc="default">
<name>Provider Configuration</name>
<ul spacing="normal">
<li><t>signup: (OPTIONAL) (<bcp14>OPTIONAL</bcp14>) an array of JSON objects consisting of:</t>
<ul spacing="normal">
<li>language: entry from the IANA language subtag registry (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). "Language Subtag Registry" (<eref target="https://www.iana.org/assignments/language-subtag-registry"/>). Normally, this would be a written language tag.</li>
<li>uri: a URI to the website for creating a new account in the supported language. The new user signup URI may only initiate creation of a new account. Various vetting, approval approval, and other processes may be needed, which could take time, before the account is established. The result of creating a new account would be account credentials (e.g. (e.g., username and password), which would be manually entered into the RUE device which form that forms the authentication parameters for the RUE configuration service described below in <xref target="rueConfig"/>.
</li> target="rueConfig"/>.</li>
</ul>
</li>
<li><t>dialAround:
<li><t>dial-around: an array of JSON objects consisting of:</t>
<ul spacing="normal">
<li>language: entry from the IANA language subtag registry. "Language Subtag Registry". Normally, this would be a sign language tag.</li>
<li>frontDoor:
<li>front-door: a URI to a queue of interpreters supporting the specified language for a two-stage dial-around</li> dial-around.</li>
<li>oneStage: a URI that can be used with a one-stage dial-around <xref target="onestage" /> (<xref target="onestage"/>) using an interpreter supporting the specified language</li>
</ul></li> language.</li>
</ul>
</li>
<li><t>helpDesk: (OPTIONAL) (<bcp14>OPTIONAL</bcp14>) an array of JSON objects consisting of:</t>
<ul spacing = "normal"> spacing="normal">
<li>language: entry from the IANA language subtag registry. Normally "Language Subtag Registry". Normally, this would be a sign language tag, although tag; although, it could be a written language tag if the help desk only supports a chat interface</li> interface.</li>
<li>uri: a URI that reaches a help desk for callers supporting the specified language. The URI MAY <bcp14>MAY</bcp14> be a SIP URI for help provided with a SIP call, call or MAY <bcp14>MAY</bcp14> be an HTTPS URI for help provided with a browser interface.</li>
</ul>
<t>A list is specified so that the provider can offer multiple choices to users for language and interface styles.</t>
</li></ul></section>
</li></ul>
</section>
<section anchor="rueConfig" numbered="true" toc="default">
<name>RUE Configuration</name>
<ul spacing="normal">
<li>lifetime: (optional) Specifies (<bcp14>OPTIONAL</bcp14>) specifies how long (in seconds) the RUE MAY <bcp14>MAY</bcp14> cache the configuration values. Values may not be valid when lifetime expires. If the RUE caches configuration values, it MUST <bcp14>MUST</bcp14> cryptographically protect them against unauthorized disclosure (e.g. (e.g., by other applications on the platform the RUE is built on). The RUE SHOULD <bcp14>SHOULD</bcp14> retrieve a fresh copy of the configuration before the lifetime expires or as soon as possible after it expires. The lifetime is not guaranteed: guaranteed, i.e., the configuration may change before the lifetime value expires. In that case, the Provider MAY provider <bcp14>MAY</bcp14> indicate this by generating authorization challenges to requests and/or prematurely terminating a registration. Emergency Calls MUST calls <bcp14>MUST</bcp14> continue to work. If not specified, the RUE MUST <bcp14>MUST</bcp14> fetch new configuration data every time it starts.
</li> starts.</li>
<li>sip-password: (optional) (<bcp14>OPTIONAL</bcp14>) a password used for SIP, STUN STUN, and TURN authentication. The RUE device retains this data, which it MUST <bcp14>MUST</bcp14> cryptographically protect against unauthorized disclosure (e.g. (e.g., by other applications on the platform the RUE is built on). If it is not supplied, supplied but was supplied on a prior invocation of this interface, the most recently supplied password MUST <bcp14>MUST</bcp14> be used. If it was never supplied, the password used to authenticate to the configuration service is used for SIP, as well as STUN and TURN servers mentioned in this configuration.</li>
<li>phone-number: The (<bcp14>REQUIRED</bcp14>) the telephone number (in E.164 format) assigned to this subscriber. This becomes the user portion of the SIP URI identifying the subscriber.
</li> subscriber.</li>
<li>user-name: (optional) (<bcp14>OPTIONAL</bcp14>) a username used for authenticating to the provider. If not provided, the phone-number is used.</li>
<li>display-name: (optional) (<bcp14>OPTIONAL</bcp14>) a human readable human-readable display name for the subscriber</li> subscriber.</li>
<li>provider-domain: (<bcp14>REQUIRED</bcp14>) the domain for the provider. This becomes the server portion of the SIP URI identifying the subscriber.
</li> subscriber.</li>
<li>outbound-proxies: (optional) An (<bcp14>OPTIONAL</bcp14>) an array of URIs of SIP proxies to be used when sending requests to the provider.
</li> provider.</li>
<li>mwi: (optional) A (<bcp14>OPTIONAL</bcp14>) a URI identifying a SIP event server that generates "message-summary" events for this subscriber.
</li> subscriber.</li>
<li>videomail: (optional) An (<bcp14>OPTIONAL</bcp14>) a SIP or HTTPS URI that can be used to retrieve video mail messages.
</li> messages.</li>
<li>contacts: (optional) An (<bcp14>OPTIONAL</bcp14>) an HTTPS URI ("contacts-uri"), (optional) "contacts-username" (<bcp14>OPTIONAL</bcp14>) "contacts-username", and "contacts-password" that may be used to export (retrieve) the subscriber's complete contact list managed by the provider. At least the URI MUST <bcp14>MUST</bcp14> be provided if the subscriber has contacts. If contact-username and contacts-password are not supplied, the sip credentials are used. If the contacts-username is provided, contacts-password MUST <bcp14>MUST</bcp14> be provided. If contacts-password is provided, contacts-username MUST <bcp14>MUST</bcp14> be provided.
</li> provided.</li>
<li>carddav: (optional) An (<bcp14>OPTIONAL</bcp14>) an address ("carddav-domain"), (optional) "carddav-username" (<bcp14>OPTIONAL</bcp14>) "carddav-username", and "carddav-password" identifying a "CardDAV" server and account that can be used to synchronize the RUE's contact list with the contact list managed by the provider. If carddav-username and carddav-password are not supplied, the sip credentials are used. If the carddav-username is provided, carddav-password MUST <bcp14>MUST</bcp14> be provided. If carddav-password is provided, carddav-username MUST <bcp14>MUST</bcp14> be provided.
</li> provided.</li>
<li>sendLocationWithRegistration: (optional) True (<bcp14>OPTIONAL</bcp14>) true if the RUE should send a Geolocation header field with REGISTER, REGISTER; false if it should not. Defaults to false if not present.
</li> present.</li>
<li>ice-servers: (optional) An (<bcp14>OPTIONAL</bcp14>) an array of server types and URLs identifying STUN and TURN servers available for use by the RUE for establishing media streams in calls via the provider. If the same URL provides both STUN and TURN services, it MUST <bcp14>MUST</bcp14> be listed twice, each with different server types.</li>
</ul></section>
</ul>
</section>
<section anchor="versions"><name>Versions</name> anchor="versions">
<name>Versions</name>
<t>
Both web services also have a simple version mechanism that returns a list of versions of the web service it supports.
This document describes version 1.0.
Versions are described displayed as a major version, the followed by
a period "." and ".", followed by a minor version, where the major and minor
versions are integers. A backwards compatible change within a major version MAY <bcp14>MAY</bcp14> increment only the minor version number. A non-backwards non-backwards, compatible change MUST <bcp14>MUST</bcp14> increment the major version number. Backwards compatibility applies to both the server and the client. Either may have any higher or lower minor revision and interoperate with its counterpart with the same major version. To achieve backwards compatibility, implementations MUST <bcp14>MUST</bcp14> ignore any object members they do not implement. Minor version definitions SHALL <bcp14>SHALL</bcp14> only add objects, non-required optional members of existing objects, and non-mandatory-to use non-mandatory-to-use functions and SHALL NOT <bcp14>SHALL NOT</bcp14> delete or change any objects, members of objects objects, or functions. This means an implementation of a specific major version and minor version is backwards compatible with all minor versions of the major version. The version mechanism returns an array of supported versions, one for each major version supported, with the minor version listed being the highest supported highest-supported minor version.</t>
<t>Unless the per-country provider list service is operated by a provider at the same base URI as that provider’s provider's configuration service, the version of the configuration service MAY <bcp14>MAY</bcp14> be different from the version of the provider list service.</t>
<figure>
<name>Example of a Version JSON object</name> Object</name>
<sourcecode name="" type="json"><![CDATA[
{
"versions": [
{
"major": 1,
"minor": 6
},
{
"major": 2,
"minor": 13
},
{
"major": 3,
"minor": 2
}
]
}]]></sourcecode>
}
]]></sourcecode>
</figure>
</section>
<section anchor="configExamples"><name>Examples</name>
<!-- v2v3: <figure/> promoted to be child of <section/>, and the enclosing <t/> split. -->
<figure>
<!-- v2v3: Moved attribute title to <name/> -->
<name>Example JSON provider configuration payload</name> Provider Configuration Payload</name>
<sourcecode name="" type="json"><![CDATA[
{
"signUp": [
{ "language" : "en", "uri" : "https:hello-en.example.net"},
{ "language" : "es", "uri" : "https:hello-es.example.net"} ] ,
"dialAround":
"dial-around": [
{ "language" : "en", "frontDoor" "front-door" : "sip:fd-en.example.net",
"oneStage" : "sip:1stg-eng.example.com" } ,
{ "language" : "es", "frontDoor" "front-door" : "sip:fd-es.example.net",
"oneStage" : "sip:1stg-spn.example.com" } ] ,
"helpDesk": [
{ "language" : "en", "uri" : "sip:help-en.example.net"} ,
{ "language" : "es", "uri" : "sip:help-es.example.net"} ]
}
]]></sourcecode>
</figure>
<figure>
<!-- v2v3: Moved attribute title to <name/> -->
<name>Example JSON RUE configuration payload</name> Configuration Payload</name>
<sourcecode name="" type="json"><![CDATA[
{
"lifetime": 86400,
"display-name" : "Bob Smith",
"phone-number": "+15551234567",
"provider-domain": "red.example.net",
"outbound-proxies": [
"sip:p1.red.example.net",
"sip:p2.red.example.net" ],
"mwi": "sip:+15551234567@red.example.net;user=phone",
"videomail": "sip:+15551234567@vm.red.example.net;user=phone",
"contacts": {
"contacts-uri":
"https://red.example.net:443/c/3617b719-2c3a-46f4-9c13",
"contacts-username": "bob",
"contacts-password": "XhOT4ch@ZEi&3u2xEYQNMO^5UGb"
},
"carddav": {
"carddav-domain": "carddav.example.com",
"carddav-username": "bob",
"carddav-password": "sj887%dd*jJty%87hyys5hHT"
},
"sendLocationWithRegistration": false,
"ice-servers": [
{"stun":"stun.red.example.com:19302" },
{"turn":"turn.red.example.com:3478"}
]
}
]]></sourcecode>
</figure>
</section>
<section anchor="configExplain">
<name>Using the Provider Selection and RUE Configuration Services Together</name>
<t>One way to use these two services is:</t>
<ul>
<ol type="1" spacing="normal">
<li>At startup, the RUE retrieves the provider list for the country it is located in.</li>
<li><t>For each provider in the list:</t>
<ul>
<ul spacing="normal">
<li>If the RUE does not have credentials for that provider, if requested by the user, use the ProviderConfig path without credentials to obtain signup, dial around dial-around, and helpdesk help desk information. </li>
<li>If the RUE has credentials for that provider, use the RueConfig path with the locally stored credentials to configure the RUE for that provider.</li>
</ul>
</li>
</ul>
</ol>
</section></section>
<section anchor="schema" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>OpenAPI Interface Descriptions</name>
<t>
The
<t>The interfaces in Sections <xref target='providerselect'/> target='providerselect' format="counter"/> and <xref target='config'/> target='config' format="counter"/> are formally specified with OpenAPI 3.0 (<xref target="OpenApi"/>) <xref target="OpenAPI"/> descriptions in YAML form.
</t> form.</t>
<t>The OpenAPI description below is normative. If there is any conflict between the text or examples and this section, the OpenAPI description takes precedence.</t>
<section anchor="listSchema"><name>Provider List</name><figure>
<name>Provider List OpenAPI description Description (RueProviderList.yaml)</name>
<sourcecode name="" type="yaml"><![CDATA[
openapi: 3.0.1
info:
title: RUM Provider List API
version: "1.0"
servers:
- url: https://localhost/rum/v1
paths:
/Providers:
get:
summary: Get a list of providers and domains to get
config data from
operationId: GetProviderList
responses:
'200':
description: List of providers for a country
content:
application/json:
schema:
$ref: '#/components/schemas/ProviderList'
/Versions:
servers:
- url: https://localhost/rum
description: Override base path for Versions query
get:
summary: Retrieves all supported versions
operationId: RetrieveVersions
responses:
'200':
description: Versions supported
content:
application/json:
schema:
$ref: '#/components/schemas/VersionsArray'
components:
schemas:
ProviderList:
type: object
required:
- providers
properties:
providers:
type: array
items:
type: object
required:
- name
- providerEntryPoint
properties:
name:
type: string
description: Human readable Human-readable provider name
providerEntryPoint:
type: string
description: provider Provider entry point for interface
VersionsArray:
type: object
required:
- versions
properties:
versions:
type: array
items:
type: object
required:
- major
- minor
properties:
major:
type: integer
format: int32
description: Version major number
minor:
type: integer
format: int32
description: Version minor number
]]></sourcecode>
</figure></section>
<section anchor="configSchema"><name>Configuration</name><figure> anchor="configSchema">
<name>Configuration</name>
<figure>
<name>Configuration OpenAPI description Description (RueConfiguration.yaml)</name>
<sourcecode name="" type="yaml"><![CDATA[
openapi: 3.0.1
info:
title: RUM Configuration API
version: "1.0"
servers:
- url: https://localhost/rum/v1
paths:
/ProviderConfig:
get:
summary: Configuration data for one provider
operationId: GetProviderConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: configuration Configuration object
content:
application/json:
schema:
$ref:
'#/components/schemas/ProviderConfigurationData'
/RueConfig:
get:
summary: Configuration data for one RUE
operationId: GetRueConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: configuration Configuration object
content:
application/json:
schema:
$ref: '#/components/schemas/RueConfigurationData'
/Versions:
servers:
- url: https://localhost/rum
description: Override base path for Versions query
get:
summary: Retrieves all supported versions
operationId: RetrieveVersions
responses:
'200':
description: Versions supported
content:
application/json:
schema:
$ref: '#/components/schemas/VersionsArray'
components:
schemas:
ProviderConfigurationData:
type: object
required:
- dialAround dial-around
properties:
signup:
type: array
items:
type: object
required:
- language
- uri
properties:
language:
type: string
description: entry Entry from IANA language-subtag-registry "Language Subtag
Registry"
uri:
type: string
format: uri
description: URI to signup website supporting
this language
dialAround:
dial-around:
type: array
items:
type: object
required:
- language
- frontDoor front-door
- oneStage
properties:
language:
type: string
description: entry Entry from IANA language-subtag-registry
frontDoor: "Language Subtag
Registry"
front-door:
type: string
format: uri
description: SIP URI for two-stage dial around dial-around
oneStage:
type: string
format: uri
description: SIP URI for one-stage dial around dial-around
helpDesk:
type: array
items:
type: object
required:
- language
- uri
properties:
language:
type: string
description: entry Entry from IANA language-subtag-registry "Language Subtag
Registry"
uri:
type: string
format: uri
description: SIP URI of helpdesk help desk supporting language
RueConfigurationData:
type: object
required:
- phone-number
- provider-domain
properties:
lifetime:
type: integer
description: how How long (in seconds) the RUE MAY cache the
configuration values
sip-password:
type: string
phone-number:
type: string
description: telephone Telephone number assigned this subscriber in
E.164 format
user-name:
type: string
description: a A username assigned to this subscriber. subscriber
display-name:
type: string
description: display Display name for the subscriber
provider-domain:
type: string
description: domain Domain of the provider for this subscriber
outbound-proxies:
type: array
items:
type: string
format: uri
description: SIP URI of a proxy to be used when sending
requests to the provider
mwi:
type: string
format: uri
description: A URI identifying a SIP event server that
generates "message-summary" events for this subscriber. subscriber
videomail:
type: string
format: uri
description: An HTTPS or SIP URI that can be used to
retrieve video mail messages. messages
contacts:
type: object
description: server Server and credentials for contact
import/export
required:
- contacts-uri
properties:
contacts-uri:
type: string
format: uri
description: An HTTPS URI that may be used to export
(retrieve) the subscriber's complete contact list
managed by the provider. provider
contacts-username:
type: string
description: username Username for authentication with the
CardDAV server. Use sip SIP user-name if not provided
contacts-password:
type: string
description: password Password for authentication. Use provider
sip-password if not provided
carddav:
type: object
description: CardDAV server and user information that can
be used to synchronize the RUE's contact list with
the contact list managed by the provider. provider
required:
- carddav-domain
properties:
carddav-domain:
type: string
description: CardDAV server address
carddav-username:
type: string
description: username Username for authentication with the
CardDAV server. Use sip SIP user-name if not provided
carddav-password:
type: string
description: password Password for authentication to the CardDAV
server. Use provider sip-password if not provided
sendLocationWithRegistration:
type: boolean
description: True if the RUE should send a Geolocation
header field with REGISTER, REGISTER; false if it should not.
Defaults to false if not present. present
ice-servers:
type: array
items:
type: object
required:
- server-type
- uri
properties:
server-type:
type: string
description: server Server type ("stun" or "turn")
uri:
type: string
format: uri
description: URIs identifying STUN and TURN servers
available for use by the RUE for establishing
media streams in calls via the provider. provider
VersionsArray:
type: object
required:
- versions
properties:
versions:
type: array
items:
type: object
required:
- major
- minor
properties:
major:
type: integer
format: int32
description: Version major number
minor:
type: integer
format: int32
description: Version minor number
]]></sourcecode>
</figure></section>
</figure>
</section>
</section>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>IANA Considerations</name>
<section anchor="plist" numbered="true" toc="default">
<name>RUE Provider List Registry</name>
<t>IANA has created the "RUE Provider List" registry. The management registration policy for this registry is "Expert Review" <xref target="RFC8126"/>. The expert should prefer a
A regulator operated or designated list interface operator. operator is preferred.
Otherwise, evidence that the proposed list interface operator will provide a complete list of providers is required to add the entry to the registry.
Updates to the registry are permitted if
the expert judges determines that the new proposed URI to provide provides a more accurate
list than the existing entry.
Each entry has two fields, fields; values for both of which MUST <bcp14>MUST</bcp14> be provided when registering or updating an entry:</t>
<ul>
<ul spacing="normal">
<li>country code: a two-letter ISO93166 country code</li>
<li>list entry point: a string is used to compose the URI to the provider list interface for that country</li>
</ul>
</section>
<section anchor="purpose">
<name> Registration of rue-owner Rue-Owner Value of the purpose Purpose Parameter</name>
<t>This document defines the new predefined value "rue-owner" for the "purpose" header field parameter of the Call-Info header field. The use for rue-owner is defined in <xref target="contact"/>. This modifies IANA has added a reference to this document in the "Header Field Parameters and Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Parameters" registry by adding this RFC as a reference to the line for the header field "Call-Info" and parameter name "purpose"</t>
<ul>
<li>Header Field: Call-Info</li>
<li>Parameter Name: purpose</li>
<li>Predefined Values: Yes</li>
</ul> "purpose".</t>
<dl newline="false" spacing="normal">
<dt>Header Field:</dt>
<dd>Call-Info</dd>
<dt>Parameter Name:</dt>
<dd>purpose</dd>
<dt>Predefined Values:</dt>
<dd>Yes</dd>
</dl>
</section>
</section>
<section anchor="Security" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Security Considerations</name>
<t>
The RUE is required to communicate with servers on public IP addresses and specific ports to perform its required functions. If it is necessary for the RUE to function on a corporate or other network that operates a default-deny firewall between the RUE and these services, the user must arrange with their network manager for passage of traffic through such a firewall in accordance with the protocols and associated SRV records as exposed by the provider. Because VRS providers may use different ports for different services, these port numbers may differ from provider to provider.
</t>
<t>This document
requires implementation and use of a number of other specifications in
order to fulfill the RUE profile; the security considerations described
in those documents apply accordingly to the RUE interactions.</t>
<t> When a CA participates in a conversation conversation, they
have access to the content of the conversation even though it is
nominally a conversation between the two endpoints. There is an
expectation that the CA will keep the communication contents in
confidence. This is usually defined by contractual or legal requirements.</t>
<t>Since different providers (within a given country) may have different
policies, RUE implementations MUST <bcp14>MUST</bcp14> include a user
interaction step to select from available providers before proceeding to actually register with any given
provider.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references>
<!-- v2v3: Moved attribute title to <name/> -->
<name>Normative References</name>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8446.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3840.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5626.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8866.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3323.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3605.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6665.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3311.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5393.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5658.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5954.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3960.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6442.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3327.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8445.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8839.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3326.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3515.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4488.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7647.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3891.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3892.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2392.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4967.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4102.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4103.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4733.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6263.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5104.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5168.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6352.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6764.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3842.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3458.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7525.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6881.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7852.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7874.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7742.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6351.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8825.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8827.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8829.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8834.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8835.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8760.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8865.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8599.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.9071.xml"?>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3263.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3840.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5626.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8866.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3323.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3605.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6665.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3311.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5393.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5658.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5954.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6442.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3327.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8839.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3326.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3515.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4488.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7647.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3891.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3892.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2392.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3966.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4967.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4102.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4103.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4733.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6263.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5104.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5168.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6352.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6764.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3842.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3458.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6881.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7852.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7874.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7742.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6351.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8825.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8827.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8829.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8834.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8835.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8760.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8865.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8599.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9071.xml"/>
<reference anchor="OpenApi" anchor="OpenAPI" target="https://spec.openapis.org/oas/v3.0.1" >
<front>
<title>OpenAPI Specification v3.0.1</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<author initials="D." surname="Miller" fullname="Darrel Miller">
<organization/>
</author>
<author initials="J." surname="Whitlock" fullname="Jeremy Whitlock">
<organization/>
</author>
<author initials="M." surname="Gardiner" fullname="Marsh Gardiner">
<organization/>
</author>
<author initials="M." surname="Ralpson" surname="Ralphson" fullname="Mike Ralphson">
<organization/>
</author>
<author initials="R." surname="Ratovsky" fullname="Ron Ratovsky">
<organization/>
</author>
<author initials="U." surname="Sarid" fullname="Uri Sarid">
<organization/>
</author>
<date year="2017" month="December"/>
</front>
</reference>
</references>
<references>
<!-- v2v3: Moved attribute title to <name/> -->
<name>Informative References</name>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3665.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"?>
<xi:include href="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3665.xml"/>
<xi:include href="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Acknowledgements</name>
<t>Brett Henderson and Jim Malloy
<t><contact fullname="Brett Henderson"/> and <contact fullname="Jim Malloy"/> provided many helpful edits to prior draft versions of this document. Paul Kyzivat <contact fullname="Paul Kyzivat"/> provided extensive reviews and comments.</t>
</section>
</back>
</rfc>