rfc9248.original.xml   rfc9248.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" > <!DOCTYPE rfc [
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie <!ENTITY nbsp "&#160;">
tf-rum-rue-11" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" x <!ENTITY zwsp "&#8203;">
ml:lang="en" tocDepth="4" sortRefs="true" symRefs="true" version="3" consensus=" <!ENTITY nbhy "&#8209;">
yes"> <!ENTITY wj "&#8288;">
<!-- ***** FRONT MATTER ***** --> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-rum-rue-11"
number="9248" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" ca
tegory="std" consensus="yes" xml:lang="en" tocDepth="4" tocInclude="true" sortRe
fs="true" symRefs="true" version="3">
<front> <front>
<title abbrev="Relay User Equipment Profile">Interoperability Profile for Re lay User Equipment</title> <title abbrev="Relay User Equipment Profile">Interoperability Profile for Re lay User Equipment</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rum-rue-11"/> <seriesInfo name="RFC" value="9248"/>
<author fullname="Brian Rosen" initials="B." surname="Rosen"> <author fullname="Brian Rosen" initials="B." surname="Rosen">
<address> <address>
<postal> <postal>
<street>470 Conrad Dr</street> <street>470 Conrad Dr</street>
<!-- Reorder these if your country does things differently -->
<city>Mars</city> <city>Mars</city>
<region>PA</region> <region>PA</region>
<code>16046</code> <code>16046</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>br@brianrosen.net</email> <email>br@brianrosen.net</email>
</address> </address>
</author> </author>
<date year="2022"/> <date year="2022" month="June"/>
<area>art</area> <area>art</area>
<workgroup>rum</workgroup> <workgroup>rum</workgroup>
<keyword>rue</keyword> <keyword>rue</keyword>
<keyword>relay user equipment</keyword>
<abstract> <abstract>
<t>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 or hearing impaire d user using an interpreter ("Communications Assistant") connected via a videoph one to the deaf/hard of hearing/hearing impaired user and an audio telephone cal l to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency termed a "provider" in this document. The provider also pr ovides a video service that allows users to connect video devices to their servi ce, and subsequently to CAs and other deaf/hard of hearing/hearing impaired user s. It is desirable that the videophones used by the deaf, hard of hearing or hea ring impaired user 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 i mpaired users work. This document describes the interface between a videophon e and a provider.</t> <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, deafb lind, or hard of hearing (HoH) or has a speech disability using an interpreter ( i.e., a Communications Assistant (CA)) connected via a videophone to the sign la nguage speaker and an audio telephone call to the hearing user. The CA interpre ts using sign language on the videophone link and voice on the telephone link. Often the interpreters may be employed by a company or agency, termed a "provide r" in this document. The provider also provides a video service that allows use rs to connect video devices to their service and subsequently to CAs and other s ign language speakers. It is desirable that the videophones used by the sign lan guage speaker conform to a standard so that any device may be used with any prov ider and that direct video calls between sign language speakers work. This docu ment describes the interface between a videophone and a provider.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Introduction</name> <name>Introduction</name>
<t>Video Relay Service (VRS) is a form of Telecommunications Relay Service <t>Video Relay Service (VRS) is a form of Telecommunications Relay Service
(TRS) that enables persons with hearing disabilities who use sign language, (TRS) that enables people with hearing disabilities who use sign language,
such as American Sign Language (ASL), to communicate with voice telepho such as American Sign Language (ASL), to communicate with voice telephone
ne users through video equipment. These services also enable communication betwe users through video equipment.
en such These services also enable communication between such
individuals directly in suitable modalities, including any combination individuals directly in suitable modalities, including any combination
of sign language via video, real-time text (RTT), and speech. of sign language via video, real-time text, and speech.
</t> </t>
<t> <t>
This Interoperability Profile for Relay User Equipment (RUE) is a profil This interoperability profile for Relay User Equipment (RUE) is a profil
e of the Session Initiation Protocol (SIP) and related media protocols that e of the Session Initiation Protocol (SIP) and related media protocols that
enables end-user equipment registration and calling for VRS calls. It sp enables end-user equipment registration and calling for VRS calls. It sp
ecifies the minimal set of call flows, Internet Engineering Task Force (IETF) ecifies the minimal set of call flows and IETF
and ITU-T standards that must be supported, provides guidance where the standards leave multiple implementation options, and specifies minimal and exten ded capabilities for RUE calls.</t> and ITU-T standards that must be supported, provides guidance where the standards leave multiple implementation options, and specifies minimal and exten ded capabilities for RUE calls.</t>
<t> <t>
Both subscriber-to-provider (interpreted) and direct subscriber-to-subscriber
Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/HoH calls ar calls are supported on this interface.
e supported on this interface. While there are some accommodations in this docu While there are some accommodations in this document to maximize backwards compa
ment to maximize backwards compatibility with other devices and services that ar tibility with other devices and services that are used to provide VRS service, b
e used to provide VRS service, backwards compatibility is not a requirement, and ackwards compatibility is not a requirement, and some interwork may be required
some interwork may be required to allow direct video calls to older devices. T to allow direct video calls to older devices. This document only describes the
his document only describes the interface between the device and the provider, a interface between the device and the provider, not any other interface the provi
nd not any other interface the provider may have. </t> der may have. </t>
<t>The following illustrates a typical relay call. The RUE device and the <t>The following illustrates a typical relay call. The RUE device and the commu
Commincations Assistant (sign language interpretter) have videophones. The Hea nications assistant (sign language interpreter) have videophones. The hearing u
ring User has a telephone (mobile or fixed).</t> ser has a telephone (mobile or fixed).</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
||== 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 |
+--------------+ +--------------+
]]></artwork> ]]></artwork>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Terminology</name> <name>Terminology</name>
<t> <dl newline="true" spacing="normal">
Communication Assistant (CA): A sign-language interpreter working for a <dt>Communications Assistant (CA):</dt>
VRS provider, providing functionally equivalent phone service. <dd>A sign-language interpreter working for a VRS provider, providing fun
</t> ctionally equivalent phone service.</dd>
<t> <dt>Communication modality (modality):</dt>
Communication modality (modality): A specific form of communication that <dd>A specific form of communication that may be employed by two users, e
may be employed by two users, e.g., English voice, Spanish voice, .g., English voice, Spanish voice,
American Sign Language, English lip-reading, or French real-time-text. H American Sign Language, English lipreading, or French real-time text. He
ere, one communication modality is assumed to encompass both the re, one communication modality is assumed to encompass both the
language and the way that language is exchanged. For example, English vo language and the way that language is exchanged. For example, English vo
ice and French voice are two different communication modalities. ice and French voice are two different communication modalities.</dd>
</t> <dt>Default video relay service:</dt>
<t> <dd>The video relay service operated by a subscriber's default VRS provid
Default video relay service: The video relay service operated by a subsc er.</dd>
riber's default VRS provider. <dt>Default video relay service provider (default provider):</dt>
</t> <dd>The VRS
<t> provider that registers and assigns a telephone number to a
Default video relay service provider (default provider): The VRS specific subscriber and, by default, provides the
provider that registers, and assigns a telephone number to a
specific subscriber, and by default provides the
VRS for incoming voice calls to the user. The default VRS for incoming voice calls to the user. The default
provider also by default provides VRS for outgoing relay calls. The provider, also by default, provides the VRS for outgoing relay calls. The
user can have more than one telephone number and each has a default user can have more than one telephone number, and each has a default
provider. provider.</dd>
</t> <dt>Outbound dial-around call:</dt>
<t> <dd>A relay call where the subscriber specifies the use of a VRS provider
Outbound Dial-around call: A relay call where the subscriber specifies t other than the default VRS provider.
he 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"). 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 instr Alternatively, this can be accomplished by the user's RUE software instr
ucting the server of its default VRS provider to automatically route the call th ucting the server of its default VRS provider to automatically route the call th
rough the alternate provider to the desired public switched telephone network (P rough the alternate provider to the desired Public Switched Telephone Network (P
STN) directory number ("one-stage"). Dial-around is per-call -- for any call, a STN) directory number ("one-stage"). Dial-around is per call; for any call, a u
user can use the default VRS provider or any dial-around VRS provider. ser can use the default VRS provider or any dial-around VRS provider.
</t> </dd>
<t> <dt>Full Intra Request (FIR):</dt>
Full Intra Request (FIR): A request to a video media sender, requiring t <dd>A request to a video media sender, requiring that media sender to send
hat media sender to send a Decoder Refresh Point at the earliest opportunity. FI a decoder refresh point at the earliest opportunity. FIR is sometimes known as
R is sometimes known as "instantaneous decoder refresh request", "video fast upd "instantaneous decoder refresh request", "video fast update request", or "fast u
ate request", or "fast update request". pdate request".</dd>
</t><t> <dt>Point-to-Point Call (P2P Call):</dt>
Point-to-Point Call (P2P Call): A call between two RUEs, without includi <dd>A call between two RUEs, without including a CA.</dd>
ng a CA. <dt>Relay call:</dt>
</t> <dd>A call that allows people with hearing or speech disabilities to use a
<t> RUE to talk to users of conventional voice services with the aid of a CA to rel
Relay call: A call that allows persons with hearing or speech disabiliti ay the communication.</dd>
es to use a RUE to talk to users of conventional voice services with the aid of <dt>Relay service (RS):</dt>
a communication assistant (CA) to relay the communication. <dd>A service that allows a registered subscriber to use a RUE to make and
</t> receive relay calls, point-to-point calls, and relay-to-relay calls. The functi
<t> ons provided by the relay service include the provision of media links supportin
Relay service (RS): A service that allow a registered subscriber to use g the communication modalities used by the caller and callee, user registration
a RUE to make and receive relay calls, point-to-point calls, and relay-to-relay and validation, authentication, authorization, automatic call distributor (ACD)
calls. The functions provided by the relay service include the provision of medi platform functions, routing (including emergency call routing), call setup, mapp
a links supporting the communication modalities used by the caller and callee, a ing, call features (such as call forwarding and video mail), and assignment of C
nd user registration and validation, authentication, authorization, automatic ca As to relay calls.</dd>
ll distributor (ACD) platform functions, routing (including emergency call routi <dt>Relay service provider (provider):</dt>
ng), call setup, mapping, call features (such as call forwarding and video mail) <dd>An organization that operates a relay service. A subscriber selects a
, and assignment of CAs to relay calls. relay service provider to assign and register a telephone number for their use,
</t> to register with for receipt of incoming calls, and to provide the default servi
<t> ce for outgoing calls.</dd>
Relay service provider (provider): An organization that operates a relay <dt>Relay user:</dt>
service. A subscriber selects a relay service provider to assign and register a <dd>Please refer to "subscriber".</dd>
telephone number for their use, to register with for receipt of incoming calls, <dt>Relay user E.164 Number (user E.164):</dt>
and to provide the default service for outgoing calls. <dd>The telephone number (in ITU-T E.164 format) assigned to the user.</dd
</t> >
<t> <dt>Relay User Equipment (RUE):</dt>
Relay user: Please refer to "subscriber". <dd>A SIP user agent (UA) enhanced with extra features to support a subscr
</t> iber in requesting, receiving, and using relay calls. A RUE may take many forms,
<t> including a stand-alone device; an application running on a general-purpose com
Relay user E.164 Number (user E.164): The telephone number (in ITU-T E.1 puting device, such as a laptop, tablet, or smartphone; or proprietary equipment
64 format) assigned to the user. connected to a server that provides the RUE interface.</dd>
</t> <dt>RUE interface:</dt>
<t> <dd>The interfaces described in this document between a RUE and a VRS prov
Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra fe ider who supports it.</dd>
atures to support a subscriber in requesting, receiving and using relay calls. A <dt>Sign language:</dt>
RUE may take many forms, including a stand-alone device; an application running <dd>A language that uses hand gestures and body language to convey meaning
on a general-purpose computing device such as a laptop, tablet or smartphone; o , including, but not limited to, American Sign Language (ASL).</dd>
r proprietary equipment connected to a server that provides the RUE interface. <dt>Subscriber:</dt>
</t> <dd>An individual who has registered with a provider and who obtains servi
<t> ce by using a RUE. This is the conventional telecom term for an end-user custome
RUE Interface: the interfaces described in this document between a RUE an r, which in this case is a relay user. A user may be a subscriber to more than
d a VRS provider who supports it one VRS provider.</dd>
</t> <dt>Video Relay Service (VRS):</dt>
<t> <dd>A relay service for people with hearing or speech disabilities who use
Sign language: A language that uses hand gestures and body language to c sign language to communicate using video equipment (video RUE) with other peopl
onvey meaning including, but not limited to, American Sign Language (ASL). e in real time. The video link allows the CA to view and interpret the subscribe
</t> r's signed conversation and relay the conversation back and forth with the other
<t> party.</dd>
Subscriber: An individual who has registered with a provider and who obt </dl>
ains service by using relay user equipment. This is the conventional telecom ter
m for an end-user customer, which in our case is a relay user. A user may be a
subscriber to more than one VRS provider.
</t>
<t>
Video relay service (VRS): A relay service for people with hearing or sp
eech disabilities who use sign language to communicate using video equipment (vi
deo RUE) with other people in real time. The video link allows the CA to view an
d interpret the subscriber's signed conversation and relay the conversation back
and forth with the other party.
</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only wh NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
en, they appear in all RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
capitals, as shown here. Lower- or mixed-case uses of these key "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
words are not to be interpreted as carrying special significance. be interpreted as
</t> described in BCP&nbsp;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>
<section anchor="general" numbered="true" toc="default"> <section anchor="general" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>General Requirements</name> <name>General Requirements</name>
<t> <t>All HTTP/HTTPS <xref target="RFC7230"/> <xref target="RFC2818"/> connec
All HTTP/HTTPS <xref target="RFC7230"/> and <xref target="RFC2818"/> tions specified throughout this document <bcp14>MUST</bcp14> use HTTPS. Both HTT
connections specified throughout this document MUST use HTTPS. Both HTTPS and al PS and all SIP connections <bcp14>MUST</bcp14> use TLS conforming to at least <x
l SIP connections MUST use TLS conforming to at least <xref target="RFC7525" for ref target="RFC7525" format="default"/> and <bcp14>MUST</bcp14> support <xref ta
mat="default"/> and MUST support <xref target="RFC8446" format="default"/>. rget="RFC8446" format="default"/>.
</t> </t>
<t> <t>
All text data payloads not otherwise constrained by a specification i n another standards document MUST be encoded as Unicode UTF-8. All text data payloads not otherwise constrained by a specification i n another standards document <bcp14>MUST</bcp14> be encoded as Unicode UTF-8.
</t> </t>
<t>Implementations MUST support IPv4 and IPv6. Dual stack support is NOT required and provider implementations MAY support separate interfaces for IPv4 and IPv6 by having more than one server in the appropriate SRV record where ther e is either an A or AAAA record in each server DNS record but not both. The sam e version of IP MUST be used for both signaling and media of a call unless ICE ( <xref target="RFC8445" format="default"/>) is used, in which case candidates may explicitly offer IPv4, IPv6 or both for any media stream.</t> <t>Implementations <bcp14>MUST</bcp14> support IPv4 and IPv6. Dual-stack support is NOT required, and provider implementations <bcp14>MAY</bcp14> suppor t separate interfaces for IPv4 and IPv6 by having more than one server in the ap propriate SRV record where there is either an A or AAAA record in each server DN S record but not both. The same version of IP <bcp14>MUST</bcp14> be used for b oth signaling and media of a call unless Interactive Connectivity Establishment (ICE) <xref target="RFC8445" format="default"/> is used; in which case, candidat es may explicitly offer IPv4, IPv6, or both for any media stream.</t>
</section> </section>
<section anchor="sip" numbered="true" toc="default"> <section anchor="sip" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>SIP Signaling</name> <name>SIP Signaling</name>
<t> <t>Implementations of the RUE interface <bcp14>MUST</bcp14> conform to the
Implementations of the RUE Interface MUST conform to the following co following core SIP standards:</t>
re SIP standards:</t><ul>
<li> <xref target="RFC3261" format="default"/> (Base SIP)</li> <ul spacing="normal">
<li> <xref target="RFC3263" format="default"/> (Locating SIP Serv <li> <xref target="RFC3261" format="default"/> (Base SIP)</li>
ers)</li> <li> <xref target="RFC3263" format="default"/> (Locating SIP Servers)</l
<li> <xref target="RFC3264" format="default"/> (Offer/Answer)</l i>
i> <li> <xref target="RFC3264" format="default"/> (Offer/Answer)</li>
<li> <xref target="RFC3840" format="default"/> (User Agent Capab <li> <xref target="RFC3840" format="default"/> (User Agent Capabilities
ilities)</li> )</li>
<li> <xref target="RFC5626" format="default"/> (Outbound)</li> <li> <xref target="RFC5626" format="default"/> (Outbound)</li>
<li> <xref target="RFC8866" format="default"/> (Session Descript <li> <xref target="RFC8866" format="default"/> (Session Description Pro
ion Protocol)</li> tocol)</li>
<li> <xref target="RFC3323" format="default"/> (Privacy)</li> <li> <xref target="RFC3323" format="default"/> (Privacy)</li>
<li> <xref target="RFC3605" format="default"/> (RTCP Attribute i <li> <xref target="RFC3605" format="default"/> (RTCP Attribute in SDP)<
n SDP)</li> /li>
<li> <xref target="RFC6665" format="default"/> (SIP Events)</li> <li> <xref target="RFC3311" format="default"/> (UPDATE Method)</li>
<li> <xref target="RFC3311" format="default"/> (UPDATE Method)</ <li> <xref target="RFC5393" format="default"/> (Loop-Fix)</li>
li> <li> <xref target="RFC5658" format="default"/> (Record-Route Fix)</li>
<li> <xref target="RFC5393" format="default"/> (Loop-Fix)</li> <li> <xref target="RFC5954" format="default"/> (ABNF Fix)</li>
<li> <xref target="RFC5658" format="default"/> (Record Route fix <li> <xref target="RFC3960" format="default"/> (Early Media)</li>
)</li> <li> <xref target="RFC6442" format="default"/> (Geolocation Header Fiel
<li> <xref target="RFC5954" format="default"/> (ABNF fix)</li> d)</li>
<li> <xref target="RFC3960" format="default"/> (Early Media)</li </ul>
>
<li> <xref target="RFC6442" format="default"/> (Geolocation head
er field)</li>
</ul>
<t> <t>
In the above documents the RUE device conforms to the requirements of a SIP user Agent, and the provider conforms to the requirements of Registrar and Proxy Ser ver where the document specifies different behavior for different roles. The on ly requirement on providers for RFC6665 (Events) is support for the Message Wait ing Indicator (See <xref target="mwi"/>), which is optional and providers not su pporting video mail need not support RFC6665. In the above documents, the RUE device conforms to the requirements of a SIP use r agent, and the provider conforms to the requirements of the registrar and prox y server where the document specifies different behavior for different roles. For providers offering a video mail service, <xref target="RFC6665" format="defa ult"/> (SIP Events) <bcp14>MUST</bcp14> be implemented to support the Message-W aiting Indicator (MWI) (see <xref target="mwi"/>).
</t> </t>
<t> <t>In addition, implementations <bcp14>MUST</bcp14> conform to:</t>
In addition, implementations MUST conform to:</t> <ul spacing="normal">
<ul> <li> <xref target="RFC3327" format="default"/> (Path Header Field)</li
<li> <xref target="RFC3327" format="default"/> (Path)</li> >
<li> <xref target="RFC8445" format="default"/> and <xref target="RFC8 839"/> (ICE)</li> <li> <xref target="RFC8445" format="default"/> and <xref target="RFC8 839"/> (ICE)</li>
<li> <xref target="RFC3326" format="default"/> (Reason header field)< /li> <li> <xref target="RFC3326" format="default"/> (Reason Header Field)< /li>
<li> <xref target="RFC3515" format="default"/> (REFER Method)</li> <li> <xref target="RFC3515" format="default"/> (REFER Method)</li>
<li> <xref target="RFC3891" format="default"/> (Replaces Header field <li> <xref target="RFC3891" format="default"/> (Replaces Header Field
)</li> )</li>
<li> <xref target="RFC3892" format="default"/> (Referred-By)</li> <li> <xref target="RFC3892" format="default"/> (Referred-By Header Fi
eld)</li>
</ul> </ul>
<t>Implementations MUST implement full ICE, although they MAY interwork w ith User Agents that implement ICE-lite.</t> <t>Implementations <bcp14>MUST</bcp14> implement full ICE, although they <bcp14>MAY</bcp14> interwork with user agents that implement ICE-lite.</t>
<t> <t>
Implementations MUST include a "User-Agent" header field uniquely ide ntifying the RUE application, platform, and version in all SIP requests, and MUS T include a "Server" header field with the same content in SIP responses. Implementations <bcp14>MUST</bcp14> include a "User-Agent" header fie ld uniquely identifying the RUE application, platform, and version in all SIP re quests and <bcp14>MUST</bcp14> include a "Server" header field with the same con tent in SIP responses.
</t> </t>
<t>Implementations intended to support mobile platforms MUST support <xref targe <t>Implementations intended to support mobile platforms <bcp14>MUST</bcp14> supp
t="RFC8599"/> and MUST use it as at least one way to support waking up the clien ort <xref target="RFC8599"/> and <bcp14>MUST</bcp14> use it as at least one way
t from background state. </t> to support waking up the client from the background state. </t>
<t>The SIP signaling for registration and placing/receiving calls depends on con <t>The SIP signaling for registration and placing/receiving calls depends on the
figuration of various values into the RUE device. <xref target="config"/> descr configuration of various values into the RUE device. <xref target="config"/> d
ibes the configuration mechanism which provides values that are used in the sign escribes the configuration mechanism that provides values that are used in the s
aling. When the device starts, the configuration mechanism is run which retriev ignaling. When the device starts, the configuration mechanism is run, which ret
es the configuration data, and then SIP registration occurs using the values fro rieves the configuration data; then, SIP registration occurs using the values fr
m the configuration. After registration, calls may be sent or received by the R om the configuration. After registration, calls may be sent or received by the
UE device.</t> RUE device.</t>
<section anchor="register" numbered="true" toc="default"> <section anchor="register" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Registration</name> <name>Registration</name>
<t> <t>
The RUE MUST register with a SIP registrar, following <xref target="RFC3 261" format="default"/> and <xref target="RFC5626" format="default"/> at a provi der it has an account with. If the configuration (see <xref target="config"/>) c ontains multiple "outbound-proxies" in "RueConfigurationData", then the RUE MUST use them as specified in [RFC5626] to establish multiple flows. The RUE <bcp14>MUST</bcp14> register with a SIP registrar, following <xr ef target="RFC3261" format="default"/> and <xref target="RFC5626" format="defaul t"/>, at a provider it has an account with. If the configuration (see <xref targ et="config"/>) contains multiple "outbound-proxies" in "RueConfigurationData", t hen the RUE <bcp14>MUST</bcp14> use them as specified in <xref target="RFC5626" format="default"/> to establish multiple flows.
</t> </t>
<t> <t>
The Request-URI for the REGISTER request MUST contain the "provider-doma The Request-URI for the REGISTER request <bcp14>MUST</bcp14> contain the
in" from the configuration. The To-URI and From-URI MUST be identical URIs, form "provider-domain" from the configuration. The To URI and From URI <bcp14>MUST</
atted as follows:</t> bcp14> be identical URIs and formatted as follows:</t>
<ul><li>if "user-name" is provided:"username@provider-domain"; </li> <ul spacing="normal">
<li>if "user-name" is not provided: as specified in <xref target="ur <li>if "user-name" is provided: "username@provider-domain"</li>
iphone"/>, using "phone-number" and "provider-domain" from the configuration.</l <li>if "user-name" is not provided: as specified in <xref target="urip
i></ul> hone"/>, use "phone-number" and "provider-domain" from the configuration</li>
</ul>
<t> <t>
The RUE determines the URI to resolve by initially determining if one or more outbound proxies are+ configured. If there are, the URI will be that of on e of the "outbound-proxies". If no "outbound-proxies" are configured, the URI wi ll be the Request-URI from the REGISTER request. The RUE extracts the domain fro m that URI and consults the DNS record for that domain. The DNS entry MUST conta in NAPTR records conforming to RFC3263. One of those NAPTR records MUST specify TLS as the preferred transport for SIP. For example, a DNS NAPTR query for "sip: p1.red.example.net" could return: The RUE determines the URI to resolve by initially determining if one or more "outbound-proxies" are configured. If they are configured, the URI will be that of one of the "outbound-proxies". If no "outbound-proxies" are configured, the URI will be the Request-URI from the REGISTER request. The RUE extracts the domain from that URI and consults the DNS record for that domain. The DNS entry <bcp14>MUST</bcp14> contain NAPTR records conforming to <xref target="RFC3263" format="default"/>. One of those NAPTR records <bcp14>MUST</bcp14> specify TLS a s the preferred transport for SIP. For example, a DNS NAPTR query for "sip: p1.r ed.example.net" could return:
</t> </t>
<!-- v2v3: </> promoted to be child of <section/>, and the enclosing <t/
> split. --> <sourcecode name="dns-rr" type=""><![CDATA[
<sourcecode name="dns-rr" type=""><![CDATA[ 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
]]></sourcecode> ]]></sourcecode>
<t> <t>
If the RUE receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it MUST re-attempt registration without using the outbound mechanism. If the RUE receives a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it <bcp14>MUST</bcp14> reattempt registration without using the outbound mechanism.
</t> </t>
<t> <t>
The registrar MAY authenticate the RUE using SIP digest authentication. The registrar <bcp14>MAY</bcp14> authenticate the RUE using SIP digest a
The credentials to be used MUST come from the configuration <xref target="config uthentication. The credentials to be used <bcp14>MUST</bcp14> come from the conf
"/>: "user-name" if provided or "phone-number" if user-name is not provided, and iguration in <xref target="config"/>: "user-name" if provided or "phone-number"
"sip-password". This "user-name"/"sip-password" combination SHOULD NOT be the s if user-name is not provided, and "sip-password". This "user-name"/"sip-password
ame as " combination <bcp14>SHOULD NOT</bcp14> be the same as
that used for other purposes, except as expressly described below, such that used for other purposes, except as expressly described below, such
as retrieving the RUE configuration or logging into the Provider's customer serv as retrieving the RUE configuration or logging into the provider's customer serv
ice portal. <xref target="RFC8760" format="default"/> MUST be supported by all i ice portal.
mplementations and SHA-512 digest algorithms MUST be supported. <xref target="RFC8760" format="default"/> <bcp14>MUST</bcp14> be supported by al
l implementations, and SHA-512 digest algorithms <bcp14>MUST</bcp14> be supporte
d.
</t> </t>
<t> <t>
If the registration request fails with an indication that credentials fr om the configuration are invalid, If the registration request fails with an indication that credentials fr om the configuration are invalid,
then the RUE MUST retrieve a fresh version of the configuration. then the RUE <bcp14>MUST</bcp14> retrieve a fresh version of the configu ration.
If credentials from a freshly retrieved configuration are found to be in valid, If credentials from a freshly retrieved configuration are found to be in valid,
then the RUE MUST cease attempts to register and inform the RUE User of the problem. then the RUE <bcp14>MUST</bcp14> cease attempts to register and inform t he RUE user of the problem.
</t> </t>
<t> <t>
Support for multiple simultaneous registrations with multiple providers by the RUE is OPTIONAL for the RUE (and providers do not need any support for th is option). Support for multiple simultaneous registrations with multiple providers by the RUE is <bcp14>OPTIONAL</bcp14> for the RUE (and providers do not need any support for this option).
</t> </t>
<t> <t>
Multiple simultaneous RUE SIP registrations from different RUE devices w ith the same SIP URI SHOULD be permitted by the provider. The provider MAY limit the total number of simultaneous registrations. When a new registration request is received that results in exceeding the limit on simultaneous registrations, the provider MAY then prematurely terminate another registration; however, it SH OULD NOT do this if it would disconnect an active call. Multiple simultaneous RUE SIP registrations from different RUE devices w ith the same SIP URI <bcp14>SHOULD</bcp14> be permitted by the provider. The pro vider <bcp14>MAY</bcp14> limit the total number of simultaneous registrations. W hen a new registration request is received that results in exceeding the limit o n simultaneous registrations, the provider <bcp14>MAY</bcp14> then prematurely t erminate another registration; however, it <bcp14>SHOULD NOT</bcp14> do this if it would disconnect an active call.
</t> </t>
<t> <t>
If a provider prematurely terminates a registration to reduce the total number of concurrent registrations with the same URI, it SHOULD take some action to prevent the affected RUE from automatically re-registering and re-triggering the condition. If a provider prematurely terminates a registration to reduce the total number of concurrent registrations with the same URI, it <bcp14>SHOULD</bcp14> t ake some action to prevent the affected RUE from automatically re-registering an d re-triggering the condition.
</t> </t>
</section> </section>
<section anchor="session" numbered="true" toc="default"> <section anchor="session" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Session Establishment</name> <name>Session Establishment</name>
<section anchor="normalcall" numbered="true" toc="default"> <section anchor="normalcall" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Normal Call Origination</name> <name>Normal Call Origination</name>
<t> <t>
After initial SIP registration, the RUE adheres to SIP <xref target="R FC3261" format="default"/> basic call flows, as documented in <xref target="RFC3 665" format="default"/>. After initial SIP registration, the RUE adheres to SIP <xref target="R FC3261" format="default"/> basic call flows, as documented in <xref target="RFC3 665" format="default"/>.
</t> </t>
<t> <t>
A RUE device MUST route all outbound calls through an outbound proxy i f configured. A RUE device <bcp14>MUST</bcp14> route all outbound calls through an o utbound proxy if configured.
</t> </t>
<t> <t>
The SIP URIs in the To field and the Request-URI MUST be formatted as specified in subsection <xref target='uriphone'/> using the destination phone nu mber, or as SIP URIs, as provided in the configuration (<xref target="config"/>) . The domain field of the URIs SHOULD be the "provider-domain" from the configur ation (e.g., sip:+15551234567@red.example.com;user=phone) except that an anonymo us call would not use the provider domain. The SIP URIs in the To field and the Request-URI <bcp14>MUST</bcp14> b e formatted as specified in <xref target='uriphone'/> using the destination phon e number or as SIP URIs as provided in the configuration (<xref target="config"/ >). The domain field of the URIs <bcp14>SHOULD</bcp14> be the "provider-domain" from the configuration (e.g., sip:+15551234567@red.example.com;user=phone), exce pt that an anonymous call would not use the provider domain.
</t> </t>
<t> <t>
Anonymous calls MUST be supported by all implementations. An anonymous call is signaled per <xref target="RFC3323" format="default"/>. Anonymous calls <bcp14>MUST</bcp14> be supported by all implementation s. An anonymous call is signaled per <xref target="RFC3323" format="default"/>.
</t> </t>
<t> <t>
The From-URI MUST be formatted as specified in <xref target="uriphone" format="default"/>, using the phone-number and "provider-domain" from the confi guration. It SHOULD also contain the display-name from the configuration when pr esent. (Please refer to <xref target="config" format="default"/>.) The From URI <bcp14>MUST</bcp14> be formatted as specified in <xref ta rget="uriphone" format="default"/>, using the "phone-number" and "provider-domai n" from the configuration. It <bcp14>SHOULD</bcp14> also contain the display-nam e from the configuration when present. (Please refer to <xref target="config" fo rmat="default"/>.)
</t> </t>
<t> <t>
Negotiated media MUST follow the requirements specified in <xref targe t="media" format="default"/> of this document. Negotiated media <bcp14>MUST</bcp14> follow the requirements specified in <xref target="media" format="default"/> of this document.
</t> </t>
<t> <t>
To allow time to time out an unanswered call and direct it to a videom ail server, the User Agent Client MUST NOT impose a time limit less than the def ault SIP Invite transaction timeout of 3 minutes. To allow time for an unanswered call to time out and direct it to a vi deomail server, the User Agent Client <bcp14>MUST NOT</bcp14> impose a time limi t less than the default SIP INVITE transaction timeout of 3 minutes.
</t> </t>
</section> </section>
<section anchor="onestage" numbered="true" toc="default"> <section anchor="onestage" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Dial-Around Origination</name> <name>Dial-Around Origination</name>
<t>Providers and RUE devices MUST support both One-Stage and Two-Stage dial-around</t> <t>Providers and RUE devices <bcp14>MUST</bcp14> support both one-stag e and two-stage dial-around.</t>
<t> <t>
Outbound dial-around calls allow a RUE user to select any provider t o provide interpreting services for any call. Outbound dial-around calls allow a RUE user to select any provider t o provide interpreting services for any call.
"Two-stage" dial-around calls involve the RUE calling a telephone nu mber that reaches the dial-around provider and "Two-stage" dial-around calls involve the RUE calling a telephone nu mber that reaches the dial-around provider and
using signing or DTMF to provide the called party telephone number. using signing or dual-tone multi-frequency (DTMF) to provide the cal
In two-stage dial-around, the To URI is the "frontDoor" URI (see <xref target="c led party's telephone number. In two-stage dial-around, the To URI is the "front
onfig"/>) in "ProviderConfigurationData" of -door" URI (see <xref target="config"/>) in "ProviderConfigurationData" of
the dial-around provider. The RUE Provider Selection service (<xref the dial-around provider. The RUE Provider Selection service (<xref
target="providerselect"/>) can be used by the RUE to obtain a list of providers target="providerselect"/>) can be used by the RUE to obtain a list of providers
and then the Provider Configuration (<xref target="providerConfig"/>) can be us ; then, the provider configuration (<xref target="providerConfig"/>) can be used
ed to find the front door URI for each of these providers. to find the front-door URI for each of these providers.
</t> </t>
<t> <t>
One-stage dial-around is a method where the called party telephone n umber is provided in the To URI and the Request-URI, One-stage dial-around is a method where the called party's telephone number is provided in the To URI and the Request-URI,
using the domain of the dial-around provider. using the domain of the dial-around provider.
</t> </t>
<t> <t>
For one-stage dial-around, the RUE MUST follow the procedures in <xr For one-stage dial-around, the RUE <bcp14>MUST</bcp14> follow the pr
ef target="normalcall" format="default"/> with the ocedures in <xref target="normalcall" format="default"/> with the
following exception: the domain part of the SIP URIs in the To field following exception: the domain part of the SIP URIs in the To field
and the Request-URI MUST be the domain of the and the Request-URI <bcp14>MUST</bcp14> be the domain of the
dial-around provider, discovered according to <xref target="provider dial-around provider discovered as described in <xref target="provid
select" format="default"/>. erselect" format="default"/>.
</t> </t>
<t> <t>
The following is a partial example of a one-stage dial-around call f rom VRS user +1-555-222-0001 hosted by red.example.com The following is a partial example of a one-stage dial-around call f rom 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 to a hearing user +1-555-123-4567 using dial-around to green.example .com for the relay service. Only important details of the
messages are shown and many header fields have been omitted: messages are shown, and many header fields have been omitted:
</t> </t>
<!-- v2v3: <figure/> promoted to be child of <section/>, and the enclo sing <t/> split. -->
<figure> <figure>
<!-- v2v3: Moved attribute title to <name/> -->
<name>One-Stage Dial-Around</name> <name>One-Stage Dial-Around</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
,-+-. ,----+----. ,-----+-----. ,-+-. ,----+----. ,-----+-----.
|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 line 314 skipping to change at line 301
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
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="contact" numbered="true" toc="default"> <section anchor="contact" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>RUE Contact Information</name> <name>RUE Contact Information</name>
<t> <t>
To identify the owner of a RUE, the initial INVITE for a cal l from a RUE, or the 200 OK the RUE uses to accept a call, To identify the owner of a RUE, the initial INVITE for a cal l from a RUE, or the 200 OK the RUE uses to accept a call,
identifies the owner by sending a Call-Info header field wit h a purpose parameter of "rue-owner". identifies the owner by sending a Call-Info header field wit h a purpose parameter of "rue-owner".
The URI MAY be an HTTPS URI or Content-ID URL. The latter is defined by <xref target="RFC2392" format="default"/> to locate The URI <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 messag e to convey the RUE ownership information as a message body parts. This URI type is present in a SIP messag e to convey the RUE ownership information as a
MIME body. The form of the RUE ownership information is a xC MIME body. The form of the RUE ownership information is an x
ard <xref target="RFC6351" format="default"/>. Card <xref target="RFC6351" format="default"/>.
Please refer to <xref target="RFC6442"/> for an example of u Please refer to <xref target="RFC6442"/> for an example of u
sing Content-Indirect URLs in SIP messages. Note that use of the Content-Indirec sing content indirection URLs in SIP messages. Note that use of the content indi
t URL rection URL
usually implies multiple message bodies ("mime/multipart"). usually implies multiple message bodies ("mime/multipart").
The RUE owner is the entity that has local control over the device which is not The RUE owner is the entity that has local control over the device that is not n
necessarily the legal owner of the equipment. It often is the user, but that is ecessarily 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 not necessarily true. While no minimum fields in the xCard are specified, the n
name, address, phone number and email address of the RUE owner are expected to b ame, address, phone number, and email address of the RUE owner are expected to b
e supplied. e supplied.
</t> </t>
</section> </section>
<section anchor="incoming" numbered="true" toc="default"> <section anchor="incoming" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Incoming Calls</name> <name>Incoming Calls</name>
<t> <t>The RUE <bcp14>MUST</bcp14> only accept inbound calls sent to it by
The RUE MUST only accept inbound calls sent to it by a proxy a proxy mentioned in the configuration.
mentioned in the configuration.
</t> </t>
<t> <t>If multiple simultaneous RUE SIP registrations from different RUE d
If Multiple simultaneous RUE SIP registrations from differen evices with the same SIP URI exist,
t RUE devices with the same SIP URI exist, the provider <bcp14>MUST</bcp14> parallel fork the call to a
the provider MUST parallel fork the call to all registered R ll registered RUEs so that they ring at the same time.
UEs 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 th provider <bcp14>MUST</bcp14> cancel other call branches using a CANCEL reques
e provider MUST CANCEL other call branches. t.
</t> </t>
</section> </section>
<section anchor="emergency" numbered="true" toc="default"> <section anchor="emergency" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Emergency Calls</name> <name>Emergency Calls</name>
<t> <t>Implementations <bcp14>MUST</bcp14> conform to <xref target="RFC688
Implementations MUST conform to <xref target="RFC6881" format="d 1" format="default"/> for handling of emergency calls, except that if the device
efault"/> for handling of emergency calls, except that if the device is unable t is unable to determine its own location, it <bcp14>MAY</bcp14> send the emergen
o determine its own location, it MAY send the emergency call without a Geolocati cy call without a Geolocation header field and without a Route header field (sin
on header field and without a Route header field (since it would be unable to qu ce it would be unable to query the Location-to-Service Translation (LoST) server
ery the LoST server for a route per RFC6881). If an emergency call arrives at th for a route, per <xref target="RFC6881" format="default"/>). If an emergency ca
e provider without a Geolocation header field, the provider MUST supply location ll arrives at the provider without a Geolocation header field, the provider <bcp
by adding the Geolocation header field, and MUST supply the route by querying t 14>MUST</bcp14> supply location by adding the Geolocation header field and <bcp1
he LoST server with that location. 4>MUST</bcp14> supply the route by querying the LoST server with that location.
</t> </t>
<t> <t>
If the emergency call is to be handled using existing country spec ific procedures, If the emergency call is to be handled using existing country-spec ific procedures,
the provider is responsible for modifying the INVITE to conf orm to the country-specific requirements. the provider is responsible for modifying the INVITE to conf orm to the country-specific requirements.
In this case, location MAY be extracted from the RFC6881 con formant INVITE and used to In this case, the location <bcp14>MAY</bcp14> be extracted f rom the <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 propagate it to the appropriate country-specific entities. If the configuration specifies it, an implementation of a RUE device
MAY send a Geolocation header field containing its location <bcp14>MAY</bcp14> send a Geolocation header field containin
in the g its location in the
REGISTER request. If implemented, users MUST be offered an o REGISTER request. If implemented, users <bcp14>MUST</bcp14>
pt-out. Country-specific procedures might require the location to be offered an opt-out. Country-specific procedures might require the location to
be pre-loaded in some entity prior to placing an emergency c be preloaded in some entity prior to placing an emergency ca
all; ll;
however, the RUE may have a more accurate and timely device location however, the RUE may have a more accurate and timely device location
than the manual, pre-loaded entry. That information MAY be u sed to populate the location to appropriate country-specific entities. Re-regis tration SHOULD be used to update the location, so long as the rate of re-registr ation is limited if the device is moving. than the manual, preloaded entry. That information <bcp14>MA Y</bcp14> be used to populate the location to appropriate country-specific entit ies. Re-registration <bcp14>SHOULD</bcp14> be used to update the location, so l ong as the rate of re-registration is limited if the device is moving.
</t> </t>
<t>Implementations MUST implement Additional Data, <xref target="RFC7852"/>. RU E devices MUST implement Data Provider, Device Information and Owner/Subscriber Information blocks. </t> <t>Implementations <bcp14>MUST</bcp14> implement additional data <xref target="R FC7852"/>. RUE devices <bcp14>MUST</bcp14> implement data provider information, device information, and owner/subscriber information blocks. </t>
</section> </section>
</section> </section>
<section anchor="midcall" numbered="true" toc="default"> <section anchor="midcall" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Mid-Call Signaling</name> <name>Mid-Call Signaling</name>
<t> <t>
Implementations MUST support re-INVITE to renegotiate media Implementations <bcp14>MUST</bcp14> support re-INVITE to renegotiate m
session parameters (among other uses). Per <xref target="srtp" format="default"/ edia session parameters (among other uses).
>, implementations MUST be able to support an INFO request for full frame refres Per <xref target="mediafeat" format="default"/>, implementations <bcp14
h for devices that do not support RTCP mechanisms (please refer to <xref target= >MUST</bcp14> be able to support an INFO message for full frame refresh for devi
"mediafeat" format="default"/>). Implementations MUST support an in-dialog REFER ces that do not support SRTCP (please refer to <xref target="srtp" format="defau
(<xref target="RFC3515" format="default"/> updated by <xref target="RFC7647" fo lt"/>).
rmat="default"/> and including support for norefersub per <xref target="RFC4488" Implementations <bcp14>MUST</bcp14> support an in-dialog REFER (as described in
format="default"/>) with the Replaces header field <xref target="RFC3891" forma <xref target="RFC3515" format="default"/> and updated by <xref target="RFC7647"
t="default"/> to enable call transfer. format="default"/>, and including support for norefersub per <xref target="RFC44
88" format="default"/>) with the Replaces header field <xref target="RFC3891" fo
rmat="default"/> to enable call transfer.
</t> </t>
</section> </section>
<section anchor="uriphone" numbered="true" toc="default"> <section anchor="uriphone" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>URI Representation of Phone Numbers</name> <name>URI Representation of Phone Numbers</name>
<t> <t>
SIP URIs constructed from non-URI sources (dial strings) and sent to SIP proxies by the RUE MUST be represented as follows, depending on whe ther they can be represented as an E.164 number. In this section "expressed as an E.164 number" includes numbers such as toll-free numbers that are not actuall y E.164 numbers, but have the same format. SIP URIs constructed from non-URI sources (dial strings) and sent to SIP proxies by the RUE <bcp14>MUST</bcp14> be represented as follows, d epending on whether they can be represented as an E.164 number. In this section , "expressed as an E.164 number" includes numbers, such as toll-free numbers tha t are not actually E.164 numbers but have the same format.
</t> </t>
<t> <t>
A dial string that can be expressed as an E.164 phone number MUS T be represented as a SIP URI with a URI ";user=phone" tag. The user part of the URI MUST be in conformance with 'global-number' defined in <xref target="RFC396 6" format="default"/>. The user part MUST NOT contain any 'visual-separator' cha racters, as defined in <xref target="RFC3966"/>. A dial string that can be expressed as an E.164 phone number <bc p14>MUST</bcp14> be represented as a SIP URI with a URI ";user=phone" tag. The u ser part of the URI <bcp14>MUST</bcp14> be in conformance with "global-number", as defined in <xref target="RFC3966" format="default"/>. The user part <bcp14>MU ST NOT</bcp14> contain any "visual-separator" characters, as defined in <xref ta rget="RFC3966"/>.
</t> </t>
<t> <t>
Dial strings that cannot be expressed as E.164 numbers MUST be represented as dialstring URIs, as specified by <xref target="RFC4967" format ="default"/>, e.g., sip:411@red.example.net;user=dialstring. Dial strings that cannot be expressed as E.164 numbers <bcp1 4>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>
<t> <t>
The domain part of Relay Service URIs and User Address of Re cords (AoR) MUST resolve (per <xref target="RFC3263" format="default"/>) to glob ally routable IPv4 and/or IPv6 addresses. The domain part of relay service URIs and User Address of Re cords (AoR) <bcp14>MUST</bcp14> resolve (per <xref target="RFC3263" format="defa ult"/>) to globally routable IPv4 and/or IPv6 addresses.
</t> </t>
</section> </section>
<section anchor="nat" numbered="true" toc="default"> <section anchor="nat" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Transport</name> <name>Transport</name>
<t> <t>
Implementations MUST conform to <xref target="RFC8835" forma t="default"/> except for its guidance on the WebRTC data channel, which this spe cification does not use. See <xref target="text"/> for how RUE supports real-tim e text without the data channel. Implementations <bcp14>MUST</bcp14> conform to <xref target= "RFC8835" format="default"/>, except for its guidance on the WebRTC data channel , which this specification does not use. See <xref target="text"/> for how RUE s upports real-time text without the data channel.
</t> </t>
<t> <t>
Implementations MUST support SIP outbound <xref target="RFC5 626" format="default"/> (please also refer to <xref target="register" format="de fault"/>). Implementations <bcp14>MUST</bcp14> support SIP outbound <xr ef target="RFC5626" format="default"/> (please also refer to <xref target="regis ter" format="default"/>).
</t> </t>
</section> </section>
</section> </section>
<section anchor="media" numbered="true" toc="default"> <section anchor="media" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Media</name> <name>Media</name>
<t>This specification adopts the media specifications for WebRTC (<xref ta rget="RFC8825" format="default"/>). <t>This specification adopts the media specifications for WebRTC <xref tar get="RFC8825" format="default"/>.
Where WebRTC defines how interactive media communications may be established using a browser as a client, this specification assumes a normal SI P call. Where WebRTC defines how interactive media communications may be established using a browser as a client, this specification assumes a normal SI P call.
Various RTP, RTCP, SDP and specific media requirements specified Various RTPs, RTCPs, SDPs, and specific media requirements speci
for WebRTC are adopted for this document. Explicit requirements from the WebRTC fied for WebRTC are adopted for this document. Explicit requirements from the We
suite of documents are described below . </t> bRTC suite of documents are described below . </t>
<t>To use WebRTC with this document, a gateway that presents a WebRTC serv <t>To use WebRTC with this document, a gateway that presents a WebRTC serv
er interface towards a browser, and a RUE client interface towards a provider is er interface towards a browser and a RUE client interface towards a provider is
assumed. The gateway would interwork signaling, and as noted below, interwork assumed. The gateway would interwork signaling and, as noted below, interwork a
at least any real time text media, in order to allow a standard browser based We t least any real-time text media in order to allow a standard browser-based WebR
bRTC client to be a VRS client. The combination of the browser client and the g TC client to be a VRS client. The combination of the browser client and the gat
ateway would be a RUE user. This document does not specify the gateway.</t> eway would be a RUE user. This document does not specify the gateway.</t>
<t> The following sections specify the WebRTC documents to which conformanc <t> The following sections specify the WebRTC documents to which conformanc
e is required. "Mandatory to Implement" means a conforming implementation MUST e is required. "Mandatory to Implement" means a conforming implementation <bcp1
implement the 4>MUST</bcp14> implement the
specified capability. It does not mean that the capability must specified capability. It does not mean that the capability must
be used in every session. For example, OPUS is a mandatory to implement audio be used in every session. For example, Opus is a Mandatory-to-Implement audio
codec, and all conforming codec, and all conforming
implementations must support OPUS. However, implementation pres implementations must support Opus.
enting a call across the RUE Interface where the call originates in the Public S However, an implementation presenting a call across the RUE inter
witched Telephone Network, or an older, non-RUE-compatible device, which only of face (where the call originates in the PSTN or an older, non-RUE-compatible devi
fers G.711 audio, does not need to ce, which only offers G.711 audio) does not need to
include the OPUS codec in the offer, since it cannot be used wit include the Opus codec in the offer, since it cannot be used wit
h that call. Conformance to this document allows end-to-end RTCP and media conge h that call. Conformance to this document allows end-to-end RTCP and media conge
stion control for audio and video.</t> stion control for audio and video.</t>
<section anchor="srtp" numbered="true" toc="default"> <section anchor="srtp" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>SRTP and SRTCP</name> <name>SRTP and SRTCP</name>
<t> <t>
Implementations MUST support <xref target="RFC8834" format=" default"/> except that MediaStreamTracks are not used. Implementations MUST con form to Section 6.4 of <xref target="RFC8827" format="default"/>. Implementations <bcp14>MUST</bcp14> support <xref target="RF C8834" format="default"/>, except that MediaStreamTracks are not used. Implemen tations <bcp14>MUST</bcp14> conform to <xref target="RFC8827" sectionFormat="of" section="6.4"/>.
</t> </t>
</section> </section>
<section anchor="text" numbered="true" toc="default"> <section anchor="text" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Text-Based Communication</name> <name>Text-Based Communication</name>
<t> <t>
Implementations MUST support real-time text (<xref target="RFC4 Implementations <bcp14>MUST</bcp14> support real-time text <xre
102" format="default"/> and <xref target="RFC4103" format="default"/>) via T.140 f target="RFC4102" format="default"/> <xref target="RFC4103" format="default"/>
media. via T.140 media.
One original and two redundant generations MUST be transmitted One original and two redundant generations <bcp14>MUST</bcp14>
and supported, with a 300 ms transmission interval. Implementations MUST suppor be transmitted and supported with a 300 ms transmission interval. Implementatio
t <xref target="RFC9071"/> especially for emergency calls. Note that RFC4103 is ns <bcp14>MUST</bcp14> support <xref target="RFC9071"/>, especially for emergenc
not how real-time text is transmitted in WebRTC and some form o y calls. Note that <xref target="RFC4103" format="default"/> is
f transcoder would be required to interwork real-time text in the data channel not how real-time text is transmitted in WebRTC, and some form
of WebRTC to RFC4103 real-time text. of transcoder would be required to interwork real-time text in the data channel
of WebRTC to <xref target="RFC4103" format="default"/> real-tim
e text.
</t> </t>
<t> <t>
Transport of T.140 real-time text in WebRTC is specified in <xref ta rget="RFC8865"/>, using Transport of T.140 real-time text in WebRTC is specified in <xref ta rget="RFC8865"/>, using
the WebRTC data channel. RFC 8865 also has some advice on how gate the WebRTC data channel. <xref target="RFC8865" format="default"/>
ways also has some advice on how gateways
between RFC 4103 and RFC 8865 should operate. It is RECOMMENDED th between <xref target="RFC4103" format="default"/> and <xref target
at ="RFC8865" format="default"/> should operate. It is <bcp14>RECOMMENDED</bcp14> t
RFC 8865 including multiparty support is used for communication wi hat
th browser-based WebRTC implementations. Implementations MUST support <xref tar <xref target="RFC8865" format="default"/>, including multiparty su
get="RFC9071"/>. pport, be used for communication with browser-based WebRTC implementations. Imp
lementations <bcp14>MUST</bcp14> support <xref target="RFC9071"/>.
</t> </t>
</section> </section>
<section anchor="video" numbered="true" toc="default"> <section anchor="video" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Video</name> <name>Video</name>
<t> <t>Implementations <bcp14>MUST</bcp14> conform to <xref
Implementations MUST conform to <xref target="RFC7742" f target="RFC7742" format="default"/> with the following exceptions:
ormat="default"/> with following exceptions: only H.264, as specified in <xref target="RFC7742"/>, is Mandatory to
only H.264, as specified in <xref target= Implement, and VP8 support is <bcp14>OPTIONAL</bcp14> at both the
"RFC7742"/>, is Mandatory to Implement, and device and providers. This is because backwards compatibility is
VP8 support is OPTIONAL at both the device and providers desirable, and older devices do not support VP8.
. This is
because backwards compatibility is desirable, and older
devices do
not support VP8.
</t> </t>
</section> </section>
<section anchor="audio" numbered="true" toc="default"> <section anchor="audio" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Audio</name> <name>Audio</name>
<t> <t>Implementations <bcp14>MUST</bcp14> conform to <xref
Implementations MUST conform to <xref target="RFC7874" f target="RFC7874" format="default"/>.
ormat="default"/>.
</t> </t>
</section> </section>
<section anchor="dtmf" numbered="true" toc="default"> <section anchor="dtmf" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>DTMF Digits</name> <name>DTMF Digits</name>
<t> <t>
Implementations MUST support the "audio/telephone-event" Implementations <bcp14>MUST</bcp14> support the "audio/t
<xref target="RFC4733" format="default"/> media type. They MUST support elephone-event" <xref target="RFC4733" format="default"/> media type. They <bcp1
conveying event codes 0 through 11 (DTMF digits "0"-"9", 4>MUST</bcp14> support
"*","#") defined in Table 7 of [RFC4733]. Handling of other tones is OPTIONAL. conveying event codes 0 through 11 (DTMF digits "0"-"9",
"*","#") defined in Table 7 of <xref target="RFC4733"/>. Handling of other tone
s is <bcp14>OPTIONAL</bcp14>.
</t> </t>
</section> </section>
<section anchor="SDP" numbered="true" toc="default"> <section anchor="SDP" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Session Description Protocol</name> <name>Session Description Protocol</name>
<t> <t>
The SDP offers and answers MUST conform to the SDP rules in <xref ta rget="RFC8829"/> The SDP offers and answers <bcp14>MUST</bcp14> conform to the SDP ru les in <xref target="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 <xref targe t="RFC4103"/>. for real-time text <bcp14>MUST</bcp14> specify the T.140 payload t ype <xref target="RFC4103"/>.
</t> </t>
</section> </section>
<section anchor="privacy" numbered="true" toc="default"> <section anchor="privacy" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Privacy</name> <name>Privacy</name>
<t> <t>
The RUE MUST provide for user privacy by implementing a local The RUE <bcp14>MUST</bcp14> provide for user privacy by implementing
one-way mute, without signaling, for both audio and video. However a local
, RUE one-way mute, without signaling, for both audio and video.
MUST maintain any states in the network (e.g. NAT bindings) by per However, RUE
iodically sending media packets <bcp14>MUST</bcp14> maintain any states in the network (e.g., NAT
on all active media sessions containing silence/comfort noise/blac bindings) by periodically sending media packets
k on all active media sessions containing silence, comfort noise, bl
screen/etc. per <xref target="RFC6263" format="default"/>. ank
screen, etc., per <xref target="RFC6263" format="default"/>.
</t> </t>
</section> </section>
<section anchor="mediafeat" numbered="true" toc="default"> <section anchor="mediafeat" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> --> <name>Negative Acknowledgement, Picture Loss Indicator, and Full Intrafr
<name>Negative Acknowledgment, Packet Loss Indicator, and Full Intrafram ame Request Features</name>
e Request Features</name> <t>The NACK, FIR, and Picture Loss Indicator (PLI) features, as describe
<t>The NACK, FIR and PLI features as described in <xref target = "RFC458 d in <xref target = "RFC4585"/> and <xref target="RFC5104"/>, <bcp14>MUST</bcp14
5"/> and <xref target="RFC5104"/> MUST be implemented. Availability of these fe > be implemented. Availability of these features <bcp14>MUST</bcp14> be announc
atures MUST be announced with the "ccm" feedback value. NACK should be used whe ed with the "ccm" feedback value. NACK should be used when negotiated and condi
n negotiated and conditions warrant its use and the other end supports it. Sign tions warrant its use and the other end supports it. Signaling picture losses a
aling picture losses as Packet Loss Indicator (PLI) should be preferred. FIR sh s a PLI should be preferred. FIR should be used only in situations where not se
ould be used only in situations where not sending a decoder refresh point would nding a decoder refresh point would render the video unusable for the users, as
render the video unusable for the users, as per RFC5104 subsection 4.3.1.2. per <xref target="RFC5104" sectionFormat="of" section="4.3.1.2"/>.</t>
</t> <t>For backwards compatibility with calling devices that do not support
<t> the foregoing methods, implementations <bcp14>MUST</bcp14> implement SIP INFO me
For backwards compatibility with calling devices that do not support the ssages to send and receive XML-encoded Picture Fast Update messages according to
foregoing methods, implementations MUST implement SIP INFO messages to send and <xref target="RFC5168" format="default"/>.
receive XML encoded Picture Fast Update messages according to <xref target="RFC
5168" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="contacts" numbered="true" toc="default"> <section anchor="contacts" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Contacts</name> <name>Contacts</name>
<section anchor="carddav" numbered="true" toc="default"> <section anchor="carddav" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>CardDAV Login and Synchronization</name> <name>CardDAV Login and Synchronization</name>
<t> <t>Support of vCard Extensions to WebDAV (CardDAV) by providers is <bcp1
Support of CardDAV by providers is OPTIONAL. 4>OPTIONAL</bcp14>.</t>
</t> <t>The RUE <bcp14>MUST</bcp14> and providers <bcp14>MAY</bcp14> be able
<t> to synchronize the user's contact directory between the RUE endpoint and one mai
The RUE MUST and providers MAY be able to synchronize the us ntained by the user's VRS provider using CardDAV <xref target="RFC6352" format="
er's contact directory between the RUE endpoint and one maintained default"/> <xref target="RFC6764" format="default"/>.</t>
by the user's VRS provider using CardDAV (<xref target="RFC6 <t>The configuration (see <xref target="config"/>) RueConfigurationData
352" format="default"/> and <xref target="RFC6764" format="default"/>). <bcp14>MAY</bcp14> supply a "carddav-username" and "carddav-domain" identifying
</t> a CardDAV server and address book for this account, plus an optional "carddav-pa
<t> ssword".</t>
The configuration (see Section <xref target="config"/>) RueC <t>To access the CardDAV server and address book, the RUE <bcp14>MUST</b
onfigurationData MAY cp14> follow <xref target="RFC6764" sectionFormat="of" section="6"/>, using the
supply a "carddav-username" and "carddav-domain" identifying configured carddav-username and carddav-domain in place of an email address. If
a the request triggers a challenge for digest authentication credentials, the RUE
CardDAV server and address book for this account, plus an op <bcp14>MUST</bcp14> continue using matching carddav-username and carddav-passwor
tional d from the configuration. If no carddav-username and carddav-password are config
"carddav-password". ured, the RUE <bcp14>MUST</bcp14> use the SIP user-name and sip-password from th
</t> e configuration. If the SIP credentials fail, the RUE <bcp14>MUST</bcp14> query
<t> the user.</t>
To access the CardDAV server and address book, the RUE MUST <t>Synchronization using CardDAV <bcp14>MUST</bcp14> be a two-way synchr
follow Section 6 of RFC6764, using the configured carddav-username and carddav-d onization service, with proper handling of asynchronous adds, changes, and delet
omain in place of an email address. If the request triggers a challenge for dige es at either end of the transport channel.</t>
st authentication credentials, the RUE MUST continue using matching carddav-user <t>The RUE <bcp14>MAY</bcp14> support other CardDAV services.</t>
name and carddav-password from the configuration. If no carddav-username and car
ddav-password are configured, the RUE MUST use the SIP user-name and sip-passwor
d from the configuration. If the SIP credentials fail, the RUE MUST query the us
er.
</t>
<t>
Synchronization using CardDAV MUST be a two-way synchronizat
ion service, with proper handling of asynchronous adds, changes, and deletes at
either end of the transport channel.
</t>
<t>The RUE MAY support other CardDAV services.</t>
</section> </section>
<section anchor="import" numbered="true" toc="default"> <section anchor="import" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Contacts Import/Export Service</name> <name>Contacts Import/Export Service</name>
<t> <t>Implementations <bcp14>MUST</bcp14> be able to export/import the list
Implementations MUST be able to export/import the list of co of contacts in xCard <xref target="RFC6351" format="default"/> XML format.</t>
ntacts in xCard <xref target="RFC6351" format="default"/> XML format. <t>The RUE accesses this service via the "contacts-uri" in the configura
</t> tion. The URL <bcp14>MUST</bcp14> resolve to identify a web server resource that
<t> imports/exports contact lists for authorized users.</t>
The RUE accesses this service via the "contacts-uri" in the <t>The RUE stores/retrieves the contact list (address book) by issuing a
configuration. The URL MUST resolve to identify a web server resource that impor n HTTPS POST or GET request. If the request triggers a challenge for digest auth
ts/exports contact lists for authorized users. entication credentials, the RUE <bcp14>MUST</bcp14> attempt to continue using th
</t> e "contacts-username" and "contacts-password" from the configuration. If no cont
<t> acts-username is configured, the SIP user-name from the configuration is used; i
The RUE stores/retrieves the contact list (address book) by f the SIP user-name is not configured, the phone-number is used. If user-name o
issuing an HTTPS POST or GET request. If the request triggers a challenge for di r phone-number is used, the sip-password is used to authenticate to the contact
gest authentication credentials, the RUE MUST attempt to continue using the "con list server.</t>
tacts-username" and "contacts-password" from the configuration. If no contacts-u
sername is configured, the sip user-name from the configuration is used, and if
the sip user-name is not configured, the phone-number is used. If user-name or
phone-number is used, the sip-password is used to authenticate to the contact li
st server.
</t>
</section> </section>
</section> </section>
<section anchor="mwi" numbered="true" toc="default"> <section anchor="mwi" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Video Mail</name> <name>Video Mail</name>
<t> <t>Support for video mail includes a retrieval mechanism and a Message-Wai
Support for video mail includes a retrieval mechanism and a Message Wa ting Indicator (MWI). Message storage is not specified by this document. RUE d
iting Indicator (MWI). Message storage is not specified by this document. RUE evices <bcp14>MUST</bcp14> support message retrieval using a SIP call to a speci
devices MUST support message retrieval using a SIP call to a specified SIP URI u fied SIP URI using DTMF to manage the mailbox, as well as a browser-based interf
sing DTMF to manage the mailbox, as well as a browser based interface reached at ace reached at a specified HTTPS URI. If a provider supports video mail, at lea
a specified HTTPS URI. If a provider supports video mail at least one of these st one of these mechanisms <bcp14>MUST</bcp14> be supported. RUE devices <bcp14
mechanisms MUST be supported. RUE devices MUST support both. See <xref target >MUST</bcp14> support both. See <xref target="config" /> for how the URI to rea
="config" /> for how the URI to reach the retrieval interface is obtained. ch the retrieval interface is obtained.</t>
</t> <t>Implementations <bcp14>MUST</bcp14> support subscriptions to "message-s
<t> ummary" events <xref target="RFC3842" format="default"/> to the URI specified in
Implementations MUST support subscriptions to "message-summary" ev the configuration. Providers <bcp14>MUST</bcp14> support MWI if they support vi
ents <xref target="RFC3842" format="default"/> to the URI specified in the confi deo mail. RUE devices <bcp14>MUST</bcp14> support MWI.</t>
guration. Providers MUST support MWI if they support video mail. RUE devices MU <t>The "videomail" and "mwi" properties in the configuration (see RueConfi
ST support MWI. gurationData in <xref target="rueConfig"/>) give the URIs for message retrieval
</t> and "message-summary" subscription.</t>
<t> <t>In notification bodies, if detailed message summaries are available, me
The "videomail" and "mwi" properties in the configuration (see ssages with video <bcp14>MUST</bcp14> be reported using "message-context-class m
RueConfigurationData in <xref target="rueConfig"/>) gives the URIs for ultimedia-message", as defined in <xref target="RFC3458" format="default"/> .</t
message >
retrieval and "message-summary" subscription.
</t>
<t>
In notification bodies, if detailed message summaries are availabl
e, messages with video MUST be reported using "message-context-class multimedia-
message" defined in <xref target="RFC3458" format="default"/> .
</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Provisioning and Provider Selection</name> <name>Provisioning and Provider Selection</name>
<t>To simplify how users interact with RUE devices, the RUE interface sepa rates provisioning into two parts. One provides a directory of providers so tha t a user interface can allow easy provider selection either for registering or f or dial-around. The other provides configuration data for the device for each p rovider.</t> <t>To simplify how users interact with RUE devices, the RUE interface sepa rates provisioning into two parts. One provides a directory of providers so tha t a user interface can allow easy provider selection either for registering or f or dial-around. The other provides configuration data for the device for each p rovider.</t>
<section anchor="providerselect" numbered="true" toc="default"> <section anchor="providerselect" numbered="true" toc="default">
<name>RUE Provider Selection</name> <name>RUE Provider Selection</name>
<t> <t>To allow the user to select a relay service, the RUE <bcp14>MAY</bcp1
To allow the user to select a relay service, the RUE MAY at any time obtain 4> at any time obtain (typically on startup) a list of providers that provide se
(typically on startup) a list of Providers that provide service in a country. I rvice in a country.
ANA has established a registry that contains a two-letter country code and an en IANA has established a registry that contains a two-letter country code and a li
try point string (See <xref target="plist"/>). The entry point, when used with st entry point string (see <xref target="plist"/>). The entry point, when used
the following OpenAPI interface, returns a list of provider names for a country with the following OpenAPI interface, returns a list of provider names for a cou
code suitable for display, with a corresponding entry point to obtain informatio ntry code suitable for display, with a corresponding entry point to obtain infor
n about that provider. No mechanism to determine the country the RUE is located mation about that provider. No mechanism to determine the country where the RUE
is specified in this document. Typically the country is the home country of th is located is specified in this document. Typically, the country is the home c
e user, but may be a local country while traveling. Some countries allow suppor ountry of the user but may be a local country while traveling. Some countries a
t from their home country when traveling abroad. Regardless, the RUE device wil llow support from their home country when traveling abroad. Regardless, the RUE
l need to allow the user to choose the country. device will need to allow the user to choose the country.
</t> </t>
<t> <t>
Each country that supports video relay service using this specification MAY supp ort the provider list. This document does not specify who maintains the list. Some possibilities are a regulator or entity designated by a regulator, an agree ment among providers to provide the list, or a user group. Each country that supports VRS using this specification <bcp14>MAY</bcp14> suppo rt the provider list. This document does not specify who maintains the list. S ome possibilities are a regulator or an entity designated by a regulator, an agr eement among providers to provide the list, or a user group.
</t><t> </t><t>
The interface to obtain the list of providers is described by an Ope The interface to obtain the list of providers is described by an Ope
nApi <xref target= nAPI <xref target=
"OpenApi"/> interface description. In that interface descriptio "OpenAPI"/> interface description. In that interface descriptio
n, the "servers" component includes an occurance of "localhost". The value fro n, the "servers" component includes an occurrence of "localhost". The value fr
m the registry of the "list entry point" string for the om the registry of the "list entry point" string for the
desired country is substituted for "localhost" in the "servers" desired country is substituted for "localhost" in the "servers"
component to obtain the server URI prefix of the interface to be component to obtain the server URI prefix of the interface to be
used to obtain the list of providers for that country. The "Pro viders" path then specifies the rest of the URI used to obtain the list. For ex ample, if the list entryPoint is "example.com/api", the provider list would be o btained from https://example.com/api/rum/v1/Providers. used to obtain the list of providers for that country. The "Pro viders" path then specifies the rest of the URI used to obtain the list. For ex ample, if the list entryPoint is "example.com/api", the provider list would be o btained from https://example.com/api/rum/v1/Providers.
</t> </t>
<t> <t>
The V1.0 "ProviderList" is a JSON object consisting of an array where ea ch entry describes one provider. Each entry consists of the following items:</t> The V1.0 "ProviderList" is a JSON object consisting of an array where ea ch entry describes one provider. Each entry consists of the following items:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>name: This parameter contains the text label identifying the p <li>name: This parameter contains the text label identifying the
rovider and is meant to be displayed to the human VRS user.</li> provider and is meant to be displayed to the human VRS user.</li>
<li>providerEntryPoint: A string used for configuration purposes <li>providerEntryPoint: A string used for configuration purposes
by the RUE (as discussed in <xref target="config" format="default"/>). The stri by the RUE (as discussed in <xref target="config" format="default"/>). The stri
ng MUST start with a domain, but MAY include other URI path elements after the d ng <bcp14>MUST</bcp14> start with a domain but <bcp14>MAY</bcp14> include other
omain. </li> URI path elements after the domain. </li>
</ul> </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, wis hes to establish an account, or wishes to use the provider for a one-stage dial around.</t> <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, wis hes to establish an account, or wishes to use the provider for a one-stage dial- around.</t>
<figure> <figure>
<name>Example of a ProviderList JSON object</name> <name>Example of a ProviderList JSON Object</name>
<sourcecode name="" type="json"><![CDATA[ <sourcecode name="" type="json"><![CDATA[
{ {
"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"
} }
] ]
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="config" numbered="true" toc="default"> <section anchor="config" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>RUE Configuration Service</name> <name>RUE Configuration Service</name>
<t> <t>
A RUE device may retrieve a provider configuration using a simpl e HTTPs web service. There are two entry points. One is used without user crede ntials, and the response includes configuration data for new user sign up and di al around. The other uses locally stored username and password that results fro m a new user sign up to authenticate to the interface and returns configuration data for the RUE. A RUE device may retrieve a provider configuration using a simpl e HTTPs web service. There are two entry points. One is used without user crede ntials, and the response includes configuration data for new user signup and dia l-around. The other uses a locally stored username and password that results fr om a new user signup to authenticate to the interface and returns configuration data for the RUE.
</t> </t>
<t>The interface to obtain configuration data is described by an OpenApi <xr <t>The interface to obtain configuration data is described by an OpenAPI <xr
ef target= ef target="OpenAPI"/> interface description. In that interface description, the
"OpenApi"/> interface description. In that interface description, the " "servers" component string includes an occurrence of "localhost". The entry po
servers" component string includes an occurence of "localhost". The entry point int string obtained from the provider list (<xref target="providerselect"/>) is
string obtained from the provider list (<xref target="providerselect"/>) is sub substituted for "localhost" to obtain the server prefix of the interface. The p
stituted for "localhost" to obtain the server prefix of the interface. The path ath then specifies the rest of the URI used to obtain the list. For example, if
then specifies the rest of the URI used to obtain the list. For example, if th the entryPoint from the provider list is "red.example.net", the provider config
e entryPoint from the provider list is "red.example.net", the provider configura uration would be obtained from https://red.example.net/rum/V1/ProviderConfig and
tion would be obtained from https://red.example.net/rum/V1/ProviderConfig and th the RUE configuration would be obtained from https://red.example.net/rum/V1/Rue
e RUE configuration would be obtained from https://red.example.net/rum/V1/RueCon Config.
fig.
</t> </t>
<t> <t>
In both the queries, an optional parameter may be provided to the interfa ce which is an API Key (apiKey). The implementation MAY have an apiKey obtained from the provider and specific to the implementation. The method used to obtai n the apiKey is not specified in this document. The provider MAY refuse to prov ide service to an implementation presenting an apiKey it does not recognize. In both the queries, an optional parameter may be provided to the interfa ce, which is an API Key (apiKey). The implementation <bcp14>MAY</bcp14> have an apiKey obtained from the provider and specific to the implementation. The meth od used to obtain the apiKey is not specified in this document. The provider <b cp14>MAY</bcp14> refuse to provide service to an implementation presenting an ap iKey it does not recognize.
</t> </t>
<t> <t>
Also in both queries, the RUE device provides a client provided, required parame ter, which contains an instance identifier (instanceId). This parameter MUST be the same value each time this instance (same implementation on same device) que ries the interface. This MAY be used by the provider, for example, to associate a location with the instance for emergency calls. This should be globally uniq ue. A UUID is suggested. Also in both queries, the RUE device provides a client-provided, required parame ter, which contains an instance identifier (instanceId). This parameter <bcp14> MUST</bcp14> be the same value each time this instance (same implementation on s ame device) queries the interface. This <bcp14>MAY</bcp14> be used by the provi der, for example, to associate a location with the instance for emergency calls. This should be globally unique. A Universally Unique Identifier (UUID) is sug gested.
</t> </t>
<t> <t>
For example, a query for the RUE configuration could be https://red. For example, a query for the RUE configuration could be
example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisKt8999"&amp;instanceId=" https://red.example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisKt8999"&amp;
5595b5a3-0687-4b8e-9913-a7f2a04fb7bd" instanceId="5595b5a3-0687-4b8e-9913-a7f2a04fb7bd"
</t> </t>
<t> <t>
The data returned is a JSON object consisting of key/value confi guration parameters to be used by the RUE. The data returned is a JSON object consisting of key/value confi guration parameters to be used by the RUE.
</t> </t>
<t> <t>
The configuration data payload includes the following data items . Items not noted as (OPTIONAL) are REQUIRED. If other unexpected items are foun d, they MUST be ignored. The configuration data payload includes the following data items . Items not noted as (<bcp14>OPTIONAL</bcp14>) are <bcp14>REQUIRED</bcp14>. If o ther unexpected items are found, they <bcp14>MUST</bcp14> be ignored.
</t> </t>
<section anchor="providerConfig" numbered="true" toc="default"> <section anchor="providerConfig" numbered="true" toc="default">
<name>Provider Configuration</name> <name>Provider Configuration</name>
<ul spacing="normal"> <ul spacing="normal">
<li><t>signup: (OPTIONAL) an array of JSON objects consisting of:</t> <li><t>signup: (<bcp14>OPTIONAL</bcp14>) an array of JSON objects cons
<ul spacing="normal"> isting of:</t>
<li>language: entry from the IANA language subtag registry (https <ul spacing="normal">
://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). <li>language: entry from the IANA "Language Subtag Registry" (<ere
Normally, this would be a written language tag.</li> f target="https://www.iana.org/assignments/language-subtag-registry"/>). Normall
<li>uri: a URI to the website for creating a new account in the s y, this would be a written language tag.</li>
upported language. The new user signup URI may only initiate creation of a new a
ccount. Various vetting, approval and other processes may be needed, which coul
d take time, before the account is established. The result of creating a new ac
count would be account credentials (e.g. username and password), which would be
manually entered into the RUE device which form the authentication parameters fo
r the RUE configuration service described below in <xref target="rueConfig"/>.
</li>
</ul>
</li>
<li><t>dialAround: an array of JSON objects consisting of:</t>
<ul spacing="normal">
<li>language: entry from the IANA language subtag registry. Norm
ally, this would be a sign language tag.</li>
<li>frontDoor: a URI to a queue of interpreters supporting the sp
ecified language for a two-stage dial-around</li>
<li>oneStage: a URI that can be used with a one-stage dial-around
<xref target="onestage" /> using an interpreter supporting the specified langua
ge</li>
</ul></li>
<li><t>helpDesk: (OPTIONAL) an array of JSON objects consisting of:</t> <li>uri: a URI to the website for creating a new account in the su
<ul spacing = "normal"> pported language. The new user signup URI may only initiate creation of a new ac
<li>language: entry from the IANA language subtag registry. Norma count. Various vetting, approval, and other processes may be needed, which coul
lly this would be a sign language tag, although it could be a written language t d take time, before the account is established. The result of creating a new ac
ag if the help desk only supports a chat interface</li> count would be account credentials (e.g., username and password), which would be
<li>uri: URI that reaches a help desk for callers supporting the manually entered into the RUE device that forms the authentication parameters f
specified language. The URI MAY be a SIP URI for help provided with a SIP call, or the RUE configuration service described below in <xref target="rueConfig"/>.<
or MAY be an HTTPS URI for help provided with a browser interface.</li> /li>
</ul> </ul>
</li>
<li><t>dial-around: an array of JSON objects consisting of:</t>
<ul spacing="normal">
<li>language: entry from the IANA "Language Subtag Registry". Normal
ly, this would be a sign language tag.</li>
<li>front-door: a URI to a queue of interpreters supporting the speci
fied language for a two-stage dial-around.</li>
<li>oneStage: a URI that can be used with a one-stage dial-around (<x
ref target="onestage"/>) using an interpreter supporting the specified language.
</li>
</ul>
</li>
<li><t>helpDesk: (<bcp14>OPTIONAL</bcp14>) an array of JSON objects c
onsisting of:</t>
<ul spacing="normal">
<li>language: entry from the IANA "Language Subtag Registry". Nor
mally, this would be a sign language tag; although, it could be a written langua
ge tag if the help desk only supports a chat interface.</li>
<li>uri: a URI that reaches a help desk for callers supporting th
e specified language. The URI <bcp14>MAY</bcp14> be a SIP URI for help provided
with a SIP call or <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> <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"> <section anchor="rueConfig" numbered="true" toc="default">
<name>RUE Configuration</name> <name>RUE Configuration</name>
<ul spacing="normal"> <ul spacing="normal">
<li>lifetime: (optional) Specifies how long (in seconds) the RUE MAY c <li>lifetime: (<bcp14>OPTIONAL</bcp14>) specifies how long (in seconds
ache the configuration values. Values may not be valid when lifetime expires. ) the RUE <bcp14>MAY</bcp14> cache the configuration values. Values may not be
If the RUE caches configuration values, it MUST cryptographically protect them a valid when lifetime expires. If the RUE caches configuration values, it <bcp14>
gainst unauthorized disclosure (e.g. by other applications on the platform the R MUST</bcp14> cryptographically protect them against unauthorized disclosure (e.g
UE is built on). The RUE SHOULD retrieve a fresh copy of the configuration befor ., by other applications on the platform the RUE is built on). The RUE <bcp14>SH
e the lifetime expires or as soon as possible after it expires. The lifetime is OULD</bcp14> retrieve a fresh copy of the configuration before the lifetime expi
not guaranteed: the configuration may change before the lifetime value expires. res or as soon as possible after it expires. The lifetime is not guaranteed, i.e
In that case, the Provider MAY indicate this by generating authorization challen ., the configuration may change before the lifetime value expires. In that case,
ges to requests and/or prematurely terminating a registration. Emergency Calls M the provider <bcp14>MAY</bcp14> indicate this by generating authorization chall
UST continue to work. If not specified, the RUE MUST fetch new configuration da enges to requests and/or prematurely terminating a registration. Emergency calls
ta every time it starts. <bcp14>MUST</bcp14> continue to work. If not specified, the RUE <bcp14>MUST</b
</li> cp14> fetch new configuration data every time it starts.</li>
<li>sip-password: (optional) a password used for SIP, STUN and TURN a <li>sip-password: (<bcp14>OPTIONAL</bcp14>) a password used for SIP, S
uthentication. The RUE device retains this data, which it MUST cryptographicall TUN, and TURN authentication. The RUE device retains this data, which it <bcp14
y protect against unauthorized disclosure (e.g. by other applications on the pla >MUST</bcp14> cryptographically protect against unauthorized disclosure (e.g., b
tform the RUE is built on). If it is not supplied, but was supplied on a prior y other applications on the platform the RUE is built on). If it is not supplie
invocation of this interface, the most recently supplied password MUST be used. d but was supplied on a prior invocation of this interface, the most recently su
If it was never supplied, the password used to authenticate to the configuratio pplied password <bcp14>MUST</bcp14> be used. If it was never supplied, the pass
n service is used for SIP, as well as STUN and TURN servers mentioned in this co word used to authenticate to the configuration service is used for SIP, as well
nfiguration.</li> as STUN and TURN servers mentioned in this configuration.</li>
<li>phone-number: The telephone number (in E.164 format) assigned to <li>phone-number: (<bcp14>REQUIRED</bcp14>) the telephone number (in E
this subscriber. This becomes the user portion of the SIP URI identifying the su .164 format) assigned to this subscriber. This becomes the user portion of the S
bscriber. IP URI identifying the subscriber.</li>
</li> <li>user-name: (<bcp14>OPTIONAL</bcp14>) a username used for authentic
<li>user-name: (optional) a username used for authenticating to the p ating to the provider. If not provided, phone-number is used.</li>
rovider. If not provided, the phone-number is used.</li> <li>display-name: (<bcp14>OPTIONAL</bcp14>) a human-readable display n
<li>display-name: (optional) a human readable display name for the sub ame for the subscriber.</li>
scriber</li> <li>provider-domain: (<bcp14>REQUIRED</bcp14>) the domain for the prov
<li>provider-domain: the domain for the provider. This becomes the se ider. This becomes the server portion of the SIP URI identifying the subscriber
rver portion of the SIP URI identifying the subscriber. .</li>
</li> <li>outbound-proxies: (<bcp14>OPTIONAL</bcp14>) an array of URIs of SI
<li>outbound-proxies: (optional) An array of URIs of SIP proxies to be P proxies to be used when sending requests to the provider.</li>
used when sending requests to the provider. <li>mwi: (<bcp14>OPTIONAL</bcp14>) a URI identifying a SIP event serve
</li> r that generates "message-summary" events for this subscriber.</li>
<li>mwi: (optional) A URI identifying a SIP event server that generate <li>videomail: (<bcp14>OPTIONAL</bcp14>) a SIP or HTTPS URI that can b
s "message-summary" events for this subscriber. e used to retrieve video mail messages.</li>
</li> <li>contacts: (<bcp14>OPTIONAL</bcp14>) an HTTPS URI ("contacts-uri"),
<li>videomail: (optional) An SIP or HTTPS URI that can be used to retr (<bcp14>OPTIONAL</bcp14>) "contacts-username", and "contacts-password" that may
ieve video mail messages. be used to export (retrieve) the subscriber's complete contact list managed by
</li> the provider. At least the URI <bcp14>MUST</bcp14> be provided if the subscriber
<li>contacts: (optional) An HTTPS URI ("contacts-uri"), (optional) "co has contacts. If contact-username and contacts-password are not supplied, the s
ntacts-username" and "contacts-password" that may be used to export (retrieve) t ip credentials are used. If the contacts-username is provided, contacts-password
he subscriber's complete contact list managed by the provider. At least the URI <bcp14>MUST</bcp14> be provided. If contacts-password is provided, contacts-us
MUST be provided if the subscriber has contacts. If contact-username and contact ername <bcp14>MUST</bcp14> be provided.</li>
s-password are not supplied, the sip credentials are used. If the contacts-usern <li>carddav: (<bcp14>OPTIONAL</bcp14>) an address ("carddav-domain"),
ame is provided, contacts-password MUST be provided. If contacts-password is pr (<bcp14>OPTIONAL</bcp14>) "carddav-username", and "carddav-password" identifying
ovided, contacts-username MUST be provided. a "CardDAV" server and account that can be used to synchronize the RUE's contac
</li> t list with the contact list managed by the provider. If carddav-username and c
<li>carddav: (optional) An address ("carddav-domain"), (optional) "car arddav-password are not supplied, the sip credentials are used. If the carddav-u
ddav-username" and "carddav-password" identifying a "CardDAV" server and account sername is provided, carddav-password <bcp14>MUST</bcp14> be provided. If cardd
that can be used to synchronize the RUE's contact list with the contact list ma av-password is provided, carddav-username <bcp14>MUST</bcp14> be provided.</li>
naged by the provider. If carddav-username and carddav-password are not supplie <li>sendLocationWithRegistration: (<bcp14>OPTIONAL</bcp14>) true if th
d, the sip credentials are used. If the carddav-username is provided, carddav-pa e RUE should send a Geolocation header field with REGISTER; false if it should n
ssword MUST be provided. If carddav-password is provided, carddav-username MUST ot. Defaults to false if not present.</li>
be provided. <li>ice-servers: (<bcp14>OPTIONAL</bcp14>) an array of server types an
</li> d URLs identifying STUN and TURN servers available for use by the RUE for establ
<li>sendLocationWithRegistration: (optional) True if the RUE should se ishing media streams in calls via the provider. If the same URL provides both ST
nd a Geolocation header field with REGISTER, false if it should not. Defaults to UN and TURN services, it <bcp14>MUST</bcp14> be listed twice, each with differen
false if not present. t server types.</li>
</li> </ul>
<li>ice-servers: (optional) An array of server types and URLs identif </section>
ying STUN and TURN servers available for use by the RUE for establishing media s <section anchor="versions">
treams in calls via the provider. If the same URL provides both STUN and TURN se <name>Versions</name>
rvices, it MUST be listed twice, each with different server types.</li>
</ul></section>
<section anchor="versions"><name>Versions</name>
<t> <t>
Both web services also have a simple version mechanism that returns a list of ve Both web services also have a simple version mechanism that returns
rsions of the web service it supports. This document describes version 1.0. Ver a list of versions of the web service it supports.
sions are described as a major version, the period &quot;.&quot; and a minor ver This document describes version 1.0.
sion, where major and minor versions are integers. A backwards compatible chang Versions are displayed as a major version, followed by
e within a major version MAY increment only the minor version number. A non-bac a period &quot;.&quot;, followed by a minor version, where the major and minor
kwards compatible change MUST increment the major version number. Backwards com versions are integers. A backwards compatible change within a major version <bcp
patibility applies to both the server and the client. Either may have any highe 14>MAY</bcp14> increment only the minor version number. A non-backwards, compat
r or lower minor revision and interoperate with its counterpart with the same ma ible change <bcp14>MUST</bcp14> increment the major version number. Backwards c
jor version. To achieve backwards compatibility, implementations MUST ignore an ompatibility applies to both the server and the client. Either may have any hig
y object members they do not implement. Minor version definitions SHALL only ad her or lower minor revision and interoperate with its counterpart with the same
d objects, non-required members of existing objects, and non-mandatory-to use fu major version. To achieve backwards compatibility, implementations <bcp14>MUST<
nctions and SHALL NOT delete or change any objects, members of objects or functi /bcp14> ignore any object members they do not implement. Minor version definitio
ons. This means an implementation of a specific major version and minor version ns <bcp14>SHALL</bcp14> only add objects, optional members of existing objects,
is backwards compatible with all minor versions of the major version. The vers and non-mandatory-to-use functions and <bcp14>SHALL NOT</bcp14> delete or change
ion mechanism returns an array of supported versions, one for each major version any objects, members of objects, or functions. This means an implementation of
supported, with the minor version listed being the highest supported minor vers a specific major version and minor version is backwards compatible with all min
ion.</t> or versions of the major version. The version mechanism returns an array of sup
<t>Unless the per-country provider list service is operated by a provider at the ported versions, one for each major version supported, with the minor version li
same base URI as that provider’s configuration service, the version of the conf sted being the highest-supported minor version.</t>
iguration service MAY be different from the version of the provider list service <t>Unless the per-country provider list service is operated by a provider at the
.</t> same base URI as that provider's configuration service, the version of the conf
iguration service <bcp14>MAY</bcp14> be different from the version of the provid
er list service.</t>
<figure> <figure>
<name>Example of a Version JSON object</name> <name>Example of a Version JSON Object</name>
<sourcecode name="" type="json"><![CDATA[ <sourcecode name="" type="json"><![CDATA[
{ {
"versions": [ "versions": [
{ {
"major": 1, "major": 1,
"minor": 6 "minor": 6
}, },
{ {
"major": 2, "major": 2,
"minor": 13 "minor": 13
}, },
{ {
"major": 3, "major": 3,
"minor": 2 "minor": 2
} }
] ]
}]]></sourcecode> }
]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="configExamples"><name>Examples</name> <section anchor="configExamples"><name>Examples</name>
<!-- v2v3: <figure/> promoted to be child of <section/>, and the enclosi ng <t/> split. -->
<figure> <figure>
<!-- v2v3: Moved attribute title to <name/> --> <name>Example JSON Provider Configuration Payload</name>
<name>Example JSON provider configuration payload</name>
<sourcecode name="" type="json"><![CDATA[ <sourcecode name="" type="json"><![CDATA[
{ {
"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"} ] ,
"dialAround": [ "dial-around": [
{ "language" : "en", "frontDoor" : "sip:fd-en.example.net", { "language" : "en", "front-door" : "sip:fd-en.example.net",
"oneStage" : "sip:1stg-eng.example.com" } , "oneStage" : "sip:1stg-eng.example.com" } ,
{ "language" : "es", "frontDoor" : "sip:fd-es.example.net", { "language" : "es", "front-door" : "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"} ]
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<!-- v2v3: Moved attribute title to <name/> --> <name>Example JSON RUE Configuration Payload</name>
<name>Example JSON RUE configuration payload</name>
<sourcecode name="" type="json"><![CDATA[ <sourcecode name="" type="json"><![CDATA[
{ {
"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"}
] ]
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="configExplain"> <section anchor="configExplain">
<name>Using the Provider Selection and RUE Configuration Services Togeth er</name> <name>Using the Provider Selection and RUE Configuration Services Togeth er</name>
<t>One way to use these two services is:</t> <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 count <li>At startup, the RUE retrieves the provider list for the country it
ry it is located in.</li> is located in.</li>
<li><t>For each provider in the list:</t> <li><t>For each provider in the list:</t>
<ul> <ul spacing="normal">
<li>If the RUE does not have credentials for that provide <li>If the RUE does not have credentials for that provider, if reques
r, if requested by the user, use the ted by the user, use the ProviderConfig path without credentials to obtain signu
ProviderConfig path without credentials to obtain signup, dial a p, dial-around, and help desk information. </li>
round and helpdesk <li>If the RUE has credentials for that provider, use the RueConf
information. </li> ig path with the locally stored credentials to configure the RUE for that provid
<li>If the RUE has credentials for that provider, use the er.</li>
RueConfig path with the locally stored credentials to configure the RUE for tha </ul>
t provider.</li> </li>
</ul> </ol>
</li>
</ul>
</section></section> </section></section>
<section anchor="schema" numbered="true" toc="default"> <section anchor="schema" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>OpenAPI Interface Descriptions</name> <name>OpenAPI Interface Descriptions</name>
<t> <t>The interfaces in Sections <xref target='providerselect' format="coun
The interfaces in <xref target='providerselect'/> and <x ter"/> and <xref target='config' format="counter"/> are formally specified with
ref target='config'/> are formally specified with OpenAPI 3.0 (<xref target="Ope OpenAPI 3.0 <xref target="OpenAPI"/> descriptions in YAML form.</t>
nApi"/>) descriptions in YAML 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 pr ecedence.</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 pr ecedence.</t>
<section anchor="listSchema"><name>Provider List</name><figure> <section anchor="listSchema"><name>Provider List</name><figure>
<name>Provider List OpenAPI description (RueProviderList.yaml)</name> <name>Provider List OpenAPI Description (RueProviderList.yaml)</name>
<sourcecode name="" type="yaml"><![CDATA[ <sourcecode name="" type="yaml"><![CDATA[
openapi: 3.0.1 openapi: 3.0.1
info: info:
title: RUM Provider List API title: RUM Provider List API
version: "1.0" version: "1.0"
servers: servers:
- url: https://localhost/rum/v1 - url: https://localhost/rum/v1
paths: paths:
/Providers: /Providers:
get: get:
skipping to change at line 824 skipping to change at line 751
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 line 849 skipping to change at line 776
- 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
]]></sourcecode> ]]></sourcecode>
</figure></section> </figure></section>
<section anchor="configSchema"><name>Configuration</name><figure> <section anchor="configSchema">
<name>Configuration OpenAPI description (RueConfiguration.yaml)</name> <name>Configuration</name>
<figure>
<name>Configuration OpenAPI Description (RueConfiguration.yaml)</nam
e>
<sourcecode name="" type="yaml"><![CDATA[ <sourcecode name="" type="yaml"><![CDATA[
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:
skipping to change at line 880 skipping to change at line 809
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 line 905 skipping to change at line 834
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 line 929 skipping to change at line 858
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:
skipping to change at line 1108 skipping to change at line 1040
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
]]></sourcecode> ]]></sourcecode>
</figure></section> </figure>
</section>
</section> </section>
</section> </section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="plist" numbered="true" toc="default"> <section anchor="plist" numbered="true" toc="default">
<name>RUE Provider List Registry</name> <name>RUE Provider List Registry</name>
<t>IANA has created the "RUE Provider List" registry. The management pol <t>IANA has created the "RUE Provider List" registry. The registration p
icy for this registry is "Expert Review" <xref target="RFC8126"/>. The expert sh olicy is "Expert Review" <xref target="RFC8126"/>.
ould prefer a regulator operated or designated list interface operator. Otherwi A regulator operated or designated list interface operator is preferred.
se, evidence that the proposed list interface operator will provide a complete l Otherwise, evidence that the proposed list interface operator will provide a com
ist of providers is required to add the entry to the registry. Updates to the r plete list of providers is required to add the entry to the registry.
egistry are permitted if the expert judges the new proposed URI to provide a mor Updates to the registry are permitted if
e accurate list than the existing entry. Each entry has two fields, values for the expert determines that the proposed URI provides a more accurate
both of which MUST be provided when registering or updating an entry:</t> list than the existing entry.
<ul> Each entry has two fields; values for both <bcp14>MUST</bcp14> be provided when
registering or updating an entry:</t>
<ul spacing="normal">
<li>country code: a two-letter ISO93166 country code</li> <li>country code: a two-letter ISO93166 country code</li>
<li>list entry point: a string is used to compose the URI to the provid er list interface for that country</li> <li>list entry point: a string is used to compose the URI to the provid er list interface for that country</li>
</ul> </ul>
</section> </section>
<section anchor="purpose"> <section anchor="purpose">
<name> Registration of rue-owner Value of the purpose Parameter</name> <name> Registration of Rue-Owner Value of the Purpose Parameter</name>
<t>This document defines the new predefined value "rue-owner" for the "purpose" <t>This document defines the new predefined value "rue-owner" for the "pu
header field parameter of the Call-Info header field. The use for rue-owner is d rpose" header field parameter of the Call-Info header field. The use for rue-own
efined in <xref target="contact"/>. This modifies the "Header Field Parameters a er is defined in <xref target="contact"/>. IANA has added a reference to this do
nd Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Param cument in the "Header Field Parameters and Parameter Values" subregistry of the
eters" registry by adding this RFC as a reference to the line for the header fie "Session Initiation Protocol (SIP) Parameters" for the header field "Call-Info"
ld "Call-Info" and parameter name "purpose"</t> and parameter name "purpose".</t>
<ul> <dl newline="false" spacing="normal">
<li>Header Field: Call-Info</li> <dt>Header Field:</dt>
<li>Parameter Name: purpose</li> <dd>Call-Info</dd>
<li>Predefined Values: Yes</li> <dt>Parameter Name:</dt>
</ul> <dd>purpose</dd>
<dt>Predefined Values:</dt>
<dd>Yes</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <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 fi rewall between the RUE and these services, the user must arrange with their netw ork manager for passage of traffic through such a firewall in accordance with th e protocols and associated SRV records as exposed by the provider. Because VRS p roviders may use different ports for different services, these port numbers may differ from provider to provider. 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 fi rewall between the RUE and these services, the user must arrange with their netw ork manager for passage of traffic through such a firewall in accordance with th e protocols and associated SRV records as exposed by the provider. Because VRS p roviders may use different ports for different services, these port numbers may differ from provider to provider.
</t> </t>
<t>This document <t>This document
requires implementation and use of a number of other specifications in requires implementation and use of a number of other specifications in
order to fulfill the RUE profile; the security considerations describe d order to fulfill the RUE profile; the security considerations describe d
in those documents apply accordingly to the RUE interactions.</t> in those documents apply accordingly to the RUE interactions.</t>
<t> When a CA participates in a conversation they <t> When a CA participates in a conversation, they
have access to the content of the conversation even though it is have access to the content of the conversation even though it is
nominally a conversation between the two endpoints. There is an nominally a conversation between the two endpoints. There is an
expectation that the CA will keep the communication contents in expectation that the CA will keep the communication contents in
confidence. This is usually defined by contractual or legal requireme nts.</t> confidence. This is usually defined by contractual or legal requireme nts.</t>
<t>Since different providers (within a given country) may have different <t>Since different providers (within a given country) may have different
policies, RUE implementations MUST include a user policies, RUE implementations <bcp14>MUST</bcp14> include a user
interaction step to select from available providers before proceeding to actually register with any given interaction step to select from available providers before proceeding to actually register with any given
provider.</t> provider.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie
s:
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.x
ml")
Both are cited textually in the same manner: by using xref elements. <back>
If you use the PI option, xml2rfc will, by default, try to find included fil
es in the same
directory as the including file. You can also define the XML_LIBRARY environ
ment 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> <references>
<!-- v2v3: Moved attribute title to <name/> -->
<name>Normative References</name> <name>Normative References</name>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
9.xml"?> .2119.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.281 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
8.xml"?> .2818.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.844 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
6.xml"?> .8446.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.326 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
1.xml"?> .3261.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.326 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
3.xml"?> .3263.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.326 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
4.xml"?> .3264.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.384 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
0.xml"?> .3840.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.562 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
6.xml"?> .5626.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.886 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
6.xml"?> .8866.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.332 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
3.xml"?> .3323.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.360 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
5.xml"?> .3605.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.666 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
5.xml"?> .6665.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.331 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
1.xml"?> .3311.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.458 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
5.xml"?> .4585.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.539 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
3.xml"?> .5393.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.565 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
8.xml"?> .5658.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.595 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
4.xml"?> .5954.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.396 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
0.xml"?> .3960.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.644 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
2.xml"?> .6442.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.332 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
7.xml"?> .3327.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.844 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
5.xml"?> .8445.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.883 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
9.xml"?> .8839.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.332 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
6.xml"?> .3326.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.351 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
5.xml"?> .3515.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.448 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
8.xml"?> .4488.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.764 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
7.xml"?> .7647.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.389 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
1.xml"?> .3891.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.389 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
2.xml"?> .3892.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.239 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
2.xml"?> .2392.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.396 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
6.xml"?> .3966.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.496 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
7.xml"?> .4967.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.410 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
2.xml"?> .4102.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.410 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
3.xml"?> .4103.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.473 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
3.xml"?> .4733.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.626 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
3.xml"?> .6263.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.510 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
4.xml"?> .5104.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.516 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
8.xml"?> .5168.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.635 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
2.xml"?> .6352.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.676 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
4.xml"?> .6764.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.384 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
2.xml"?> .3842.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.345 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
8.xml"?> .3458.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.752 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
5.xml"?> .7525.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.688 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
1.xml"?> .6881.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.723 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
0.xml"?> .7230.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.785 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
2.xml"?> .7852.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.787 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
4.xml"?> .7874.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.774 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
2.xml"?> .7742.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.635 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
1.xml"?> .6351.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.81 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
74.xml"?> .8174.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.882 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
5.xml"?> .8825.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.882 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
7.xml"?> .8827.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.882 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
9.xml"?> .8829.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.883 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
4.xml"?> .8834.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.883 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
5.xml"?> .8835.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.876 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
0.xml"?> .8760.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.886 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
5.xml"?> .8865.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.859 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
9.xml"?> .8599.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.907 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
1.xml"?> .9071.xml"/>
<reference anchor="OpenApi" target="https://spec.openapis.org/oas/v3.0.1"
> <reference anchor="OpenAPI" target="https://spec.openapis.org/oas/v3.0.1"
>
<front> <front>
<title>OpenAPI Specification v3.0.1</title> <title>OpenAPI Specification v3.0.1</title>
<!-- v2v3: Moved <seriesInfo/> inside <front/> element -->
<author initials="D." surname="Miller" fullname="Darrel Miller"> <author initials="D." surname="Miller" fullname="Darrel Miller">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Whitlock" fullname="Jeremy Whitlock"> <author initials="J." surname="Whitlock" fullname="Jeremy Whitlock">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Gardiner" fullname="Marsh Gardiner"> <author initials="M." surname="Gardiner" fullname="Marsh Gardiner">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Ralpson" fullname="Mike Ralphson"> <author initials="M." surname="Ralphson" fullname="Mike Ralphson">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Ratovsky" fullname="Ron Ratovsky"> <author initials="R." surname="Ratovsky" fullname="Ron Ratovsky">
<organization/> <organization/>
</author> </author>
<author initials="U." surname="Sarid" fullname="Uri Sarid"> <author initials="U." surname="Sarid" fullname="Uri Sarid">
<organization/> <organization/>
</author> </author>
<date year="2017" month="December"/> <date year="2017" month="December"/>
</front> </front>
</reference> </reference>
</references> </references>
<references> <references>
<!-- v2v3: Moved attribute title to <name/> -->
<name>Informative References</name> <name>Informative References</name>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3 <xi:include href="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
665.xml"?> .3665.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.81 <xi:include href="http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
26.xml"?> .8126.xml"/>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default"> <section anchor="Acknowledgements" numbered="false" toc="default">
<!-- v2v3: Moved attribute title to <name/> -->
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Brett Henderson and Jim Malloy provided many helpful edits to prior ver sions of this document. Paul Kyzivat provided extensive reviews and comments.</ t> <t><contact fullname="Brett Henderson"/> and <contact fullname="Jim Malloy "/> provided many helpful edits to prior draft versions of this document. <cont act fullname="Paul Kyzivat"/> provided extensive reviews and comments.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 196 change blocks. 
974 lines changed or deleted 898 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/