draft-ietf-rum-rue-08.txt   draft-ietf-rum-rue-09.txt 
rum B. Rosen rum B. Rosen
Internet-Draft 1 October 2021 Internet-Draft 11 October 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 4 April 2022 Expires: 14 April 2022
Interoperability Profile for Relay User Equipment Interoperability Profile for Relay User Equipment
draft-ietf-rum-rue-08 draft-ietf-rum-rue-09
Abstract Abstract
Video Relay Service (VRS) is a term used to describe a method by Video Relay Service (VRS) is a term used to describe a method by
which a hearing person can communicate with a deaf, hard of hearing which a hearing person can communicate with a deaf, hard of hearing
or hearing impaired user using an interpreter ("Communications or hearing impaired user using an interpreter ("Communications
Assistant") connected via a videophone to the deaf/HoH user and an Assistant") connected via a videophone to the deaf/HoH user and an
audio telephone call to the hearing user. The CA interprets using audio telephone call to the hearing user. The CA interprets using
sign language on the videophone link and voice on the telephone link. sign language on the videophone link and voice on the telephone link.
Often the interpreters may be employed by a company or agency termed Often the interpreters may be employed by a company or agency termed
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 April 2022. This Internet-Draft will expire on 14 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 7 skipping to change at page 3, line 7
9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 17 9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 17
9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 19 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 19
9.2.1. Provider Configuration . . . . . . . . . . . . . . . 20 9.2.1. Provider Configuration . . . . . . . . . . . . . . . 20
9.2.2. RUE Configuration . . . . . . . . . . . . . . . . . . 21 9.2.2. RUE Configuration . . . . . . . . . . . . . . . . . . 21
9.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 22 9.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 22
9.2.4. Using the Provider Selection and RUE Configuration 9.2.4. Using the Provider Selection and RUE Configuration
Services Together . . . . . . . . . . . . . . . . . . 23 Services Together . . . . . . . . . . . . . . . . . . 23
9.3. OpenAPI Interface Descriptions . . . . . . . . . . . . . 23 9.3. OpenAPI Interface Descriptions . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10.1. RUE Provider List Registry . . . . . . . . . . . . . . . 28 10.1. RUE Provider List Registry . . . . . . . . . . . . . . . 29
10.2. Registration of rue-owner Value of the purpose 10.2. Registration of rue-owner Value of the purpose
Parameter . . . . . . . . . . . . . . . . . . . . . . . 28 Parameter . . . . . . . . . . . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
12. Normative References . . . . . . . . . . . . . . . . . . . . 29 12. Normative References . . . . . . . . . . . . . . . . . . . . 29
13. Informative References . . . . . . . . . . . . . . . . . . . 35 13. Informative References . . . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Video Relay Service (VRS) is a form of Telecommunications Relay Video Relay Service (VRS) is a form of Telecommunications Relay
Service (TRS) that enables persons with hearing disabilities who use Service (TRS) that enables persons with hearing disabilities who use
sign language, such as American Sign Language (ASL), to communicate sign language, such as American Sign Language (ASL), to communicate
with voice telephone users through video equipment. These services with voice telephone users through video equipment. These services
also enable communication between such individuals directly in also enable communication between such individuals directly in
suitable modalities, including any combination of sign language via suitable modalities, including any combination of sign language via
video, real-time text (RTT), and speech. video, real-time text (RTT), and speech.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
conversation and relay the conversation back and forth with the other conversation and relay the conversation back and forth with the other
party. party.
3. Requirements Language 3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. Lower- or mixed-case uses of these key capitals, as shown here. Lower- or mixed-case uses of these key
words are not to be interpreted as carrying special significance in words are not to be interpreted as carrying special significance.
this memo.
4. General Requirements 4. General Requirements
All HTTP/HTTPS connections specified throughout this document MUST All HTTP/HTTPS [RFC7230] and [RFC2818] connections specified
use HTTPS. Both HTTPS and all SIP connections MUST use TLS throughout this document MUST use HTTPS. Both HTTPS and all SIP
conforming to at least [RFC7525] and MUST support [RFC8446]. connections MUST use TLS conforming to at least [RFC7525] and MUST
support [RFC8446].
All text data payloads not otherwise constrained by a specification All text data payloads not otherwise constrained by a specification
in another standards document MUST be encoded as Unicode UTF-8. in another standards document MUST be encoded as Unicode UTF-8.
Implementations MUST support IPv4 and IPv6. Dual stack support is Implementations MUST support IPv4 and IPv6. Dual stack support is
NOT required and provider implementations MAY support separate NOT required and provider implementations MAY support separate
interfaces for IPv4 and IPv6 by having more than one server in the interfaces for IPv4 and IPv6 by having more than one server in the
appropriate SRV record where there is either an A or AAAA record in appropriate SRV record where there is either an A or AAAA record in
each server DNS record but not both. The same version of IP MUST be each server DNS record but not both. The same version of IP MUST be
used for both signaling and media of a call unless ICE ([RFC8445]) is used for both signaling and media of a call unless ICE ([RFC8445]) is
skipping to change at page 7, line 23 skipping to change at page 7, line 23
* [RFC3960] (Early Media) * [RFC3960] (Early Media)
* [RFC6442] (Geolocation header field) * [RFC6442] (Geolocation header field)
In the above documents the RUE device conforms to the requirements of In the above documents the RUE device conforms to the requirements of
a SIP user Agent, and the provider conforms to the requirements of a SIP user Agent, and the provider conforms to the requirements of
Registrar and Proxy Server where the document specifies different Registrar and Proxy Server where the document specifies different
behavior for different roles. The only requirement on providers for behavior for different roles. The only requirement on providers for
RFC6655 (Events) is support for the Message Waiting Indicator (See RFC6655 (Events) is support for the Message Waiting Indicator (See
Section 8), which is optional and providers not supporting voicemail Section 8), which is optional and providers not supporting video mail
need not support RFC6665. need not support RFC6665.
In addition, implementation MUST conform to: In addition, implementations MUST conform to:
* [RFC3327] (Path) * [RFC3327] (Path)
* [RFC8445] and [RFC8839] (ICE) * [RFC8445] and [RFC8839] (ICE)
* [RFC3326] (Reason header field) * [RFC3326] (Reason header field)
* [RFC3515] (REFER Method) * [RFC3515] (REFER Method)
* [RFC3891] (Replaces Header field) * [RFC3891] (Replaces Header field)
skipping to change at page 8, line 45 skipping to change at page 8, line 45
credentials to be used (username and password) MUST be supplied credentials to be used (username and password) MUST be supplied
within the credentials section of the configuration and identified by within the credentials section of the configuration and identified by
the realm the registrar uses in a digest challenge. This username/ the realm the registrar uses in a digest challenge. This username/
password combination SHOULD NOT be the same as that used for other password combination SHOULD NOT be the same as that used for other
purposes, such as retrieving the RUE configuration or logging into purposes, such as retrieving the RUE configuration or logging into
the Provider's customer service portal. [RFC8760] MUST be supported the Provider's customer service portal. [RFC8760] MUST be supported
by all implementations and SHA-512 digest algorithms MUST be by all implementations and SHA-512 digest algorithms MUST be
supported. supported.
If the registration request fails with an indication that credentials If the registration request fails with an indication that credentials
from the configuration are invalid, then the RUE SHOULD retrieve a from the configuration are invalid, then the RUE MUST retrieve a
fresh version of the configuration. If credentials from a freshly fresh version of the configuration. If credentials from a freshly
retrieved configuration are found to be invalid, then the RUE MUST retrieved configuration are found to be invalid, then the RUE MUST
cease attempts to register and SHOULD inform the RUE User of the cease attempts to register and inform the RUE User of the problem.
problem.
Support for multiple simultaneous registrations with multiple Support for multiple simultaneous registrations with multiple
providers by the RUE is OPTIONAL for the RUE (and providers do not providers by the RUE is OPTIONAL for the RUE (and providers do not
need any support for this option). need any support for this option).
Multiple simultaneous RUE SIP registrations from different RUE Multiple simultaneous RUE SIP registrations from different RUE
devices with the same SIP URI SHOULD be permitted by the provider. devices with the same SIP URI SHOULD be permitted by the provider.
The provider MAY limit the total number of simultaneous The provider MAY limit the total number of simultaneous
registrations. When a new registration request is received that registrations. When a new registration request is received that
results in exceeding the limit on simultaneous registrations, the results in exceeding the limit on simultaneous registrations, the
skipping to change at page 13, line 18 skipping to change at page 13, line 18
SIP proxies by the RUE MUST be represented as follows, depending on SIP proxies by the RUE MUST be represented as follows, depending on
whether they can be represented as an E.164 number. In this section whether they can be represented as an E.164 number. In this section
"expressed as an E.164 number" includes numbers such as toll free "expressed as an E.164 number" includes numbers such as toll free
numbers that are not actually E.164 numbers, but have the same numbers that are not actually E.164 numbers, but have the same
format. format.
A dial string that can be expressed as an E.164 phone number MUST be A dial string that can be expressed as an E.164 phone number MUST be
represented as a SIP URI with a URI ";user=phone" tag. The user part represented as a SIP URI with a URI ";user=phone" tag. The user part
of the URI MUST be in conformance with 'global-number' defined in of the URI MUST be in conformance with 'global-number' defined in
[RFC3966]. The user part MUST NOT contain any 'visual-separator' [RFC3966]. The user part MUST NOT contain any 'visual-separator'
characters. characters, as defined in [RFC3966].
Dial strings that cannot be expressed as E.164 numbers MUST be Dial strings that cannot be expressed as E.164 numbers MUST be
represented as dialstring URIs, as specified by [RFC4967], e.g., represented as dialstring URIs, as specified by [RFC4967], e.g.,
sip:411@red.example.net;user=dialstring. sip:411@red.example.net;user=dialstring.
The domain part of Relay Service URIs and User Address of Records The domain part of Relay Service URIs and User Address of Records
(AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or (AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or
IPv6 addresses. IPv6 addresses.
5.5. Transport 5.5. Transport
skipping to change at page 14, line 22 skipping to change at page 14, line 22
Implementations MUST support [RFC8834] except that MediaStreamTracks Implementations MUST support [RFC8834] except that MediaStreamTracks
are not used. Implementations MUST conform to Section 6.4 of are not used. Implementations MUST conform to Section 6.4 of
[RFC8827]. [RFC8827].
6.2. Text-Based Communication 6.2. Text-Based Communication
Implementations MUST support real-time text ([RFC4102] and [RFC4103]) Implementations MUST support real-time text ([RFC4102] and [RFC4103])
via T.140 media. One original and two redundant generations MUST be via T.140 media. One original and two redundant generations MUST be
transmitted and supported, with a 300 ms transmission interval. transmitted and supported, with a 300 ms transmission interval.
Implementations MUST support [RFC8865] especially for emergency Implementations MUST support [RFC9071] especially for emergency
calls. Note that RFC4103 is not how real-time text is transmitted in calls. Note that RFC4103 is not how real-time text is transmitted in
WebRTC and some form of transcoder would be required to interwork WebRTC and some form of transcoder would be required to interwork
real-time text in the data channel of WebRTC to RFC4103 real-time real-time text in the data channel of WebRTC to RFC4103 real-time
text. text.
Transport of T.140 real-time text in WebRTC is specified in Transport of T.140 real-time text in WebRTC is specified in
[RFC8865], using the WebRTC data chanel. RFC 8865 also has some [RFC8865], using the WebRTC data chanel. RFC 8865 also has some
advice on how gateways between RFC 4103 and RFC 8865 should operate. advice on how gateways between RFC 4103 and RFC 8865 should operate.
It is RECOMMENDED that RFC 8865 is used for communication with It is RECOMMENDED that RFC 8865 including multiparty support is used
browser-based WebRTC implementations. Implementations MUST support for communication with browser-based WebRTC implementations.
[RFC9071]. Implementations MUST support [RFC9071].
6.3. Video 6.3. Video
Implementations MUST conform to [RFC7742] with following exceptions: Implementations MUST conform to [RFC7742] with following exceptions:
only H.264, as specified in [RFC7742], is Mandatory to Implement, and only H.264, as specified in [RFC7742], is Mandatory to Implement, and
VP8 support is OPTIONAL at both the device and providers. This is VP8 support is OPTIONAL at both the device and providers. This is
because backwards compatibility is desirable, and older devices do because backwards compatibility is desirable, and older devices do
not support VP8. not support VP8.
6.4. Audio 6.4. Audio
skipping to change at page 15, line 29 skipping to change at page 15, line 29
The RUE MUST provide for user privacy by implementing a local one-way The RUE MUST provide for user privacy by implementing a local one-way
mute, without signaling, for both audio and video. However, RUE MUST mute, without signaling, for both audio and video. However, RUE MUST
maintain any NAT bindings by periodically sending media packets on maintain any NAT bindings by periodically sending media packets on
all active media sessions containing silence/comfort noise/black all active media sessions containing silence/comfort noise/black
screen/etc. per [RFC6263]. screen/etc. per [RFC6263].
6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full
Intraframe Request Features Intraframe Request Features
NACK SHOULD be used when negotiated and conditions warrant its use. The NACK, FIR and PLI features as described in [RFC4585] and
Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be [RFC5104] MUST be implemented. Availability of these features MUST
preferred, as described in [RFC5104]. be announced with the "ccm" feedback value. NACK should be used when
negotiated and conditions warrant its use and the other end supports
FIR SHOULD be used only in situations where not sending a decoder it. Signaling picture losses as Packet Loss Indicator (PLI) should
refresh point would render the video unusable for the users, as per be preferred. FIR should be used only in situations where not
RFC5104 subsection 4.3.1.2. sending a decoder refresh point would render the video unusable for
the users, as per RFC5104 subsection 4.3.1.2.
For backwards compatibility with calling devices that do not support For backwards compatibility with calling devices that do not support
the foregoing methods, implementations MUST implement SIP INFO the foregoing methods, implementations MUST implement SIP INFO
messages to send and receive XML encoded Picture Fast Update messages messages to send and receive XML encoded Picture Fast Update messages
according to [RFC5168]. according to [RFC5168].
7. Contacts 7. Contacts
7.1. CardDAV Login and Synchronization 7.1. CardDAV Login and Synchronization
skipping to change at page 16, line 39 skipping to change at page 16, line 39
The RUE stores/retrieves the contact list (address book) by issuing The RUE stores/retrieves the contact list (address book) by issuing
an HTTPS POST or GET request. If the request triggers a challenge an HTTPS POST or GET request. If the request triggers a challenge
for digest authentication credentials, the RUE MUST attempt to for digest authentication credentials, the RUE MUST attempt to
continue using matching "credentials" from the configuration. If no continue using matching "credentials" from the configuration. If no
credentials are configured, the RUE MUST query the user. credentials are configured, the RUE MUST query the user.
8. Video Mail 8. Video Mail
Support for video mail includes a retrieval mechanism and a Message Support for video mail includes a retrieval mechanism and a Message
Waiting Indicator (MWI). Message storage is NOT specified by this Waiting Indicator (MWI). Message storage is not specified by this
document. RUE devices MUST support message retrieval using a SIP document. RUE devices MUST support message retrieval using a SIP
call to a specified SIP URI using DTMF to manage the mailbox, as well call to a specified SIP URI using DTMF to manage the mailbox, as well
as a browser based interface reached at a specified HTTPS URI. If a as a browser based interface reached at a specified HTTPS URI. If a
provider supports video mail at least one of these mechansism MUST be provider supports video mail at least one of these mechansism MUST be
supported. RUE devices MUST support both. See Section 9.2 for how supported. RUE devices MUST support both. See Section 9.2 for how
the URI to reach the retrieval interface is obtained. the URI to reach the retrieval interface is obtained.
Implementations MUST support subscriptions to "message-summary" Implementations MUST support subscriptions to "message-summary"
events [RFC3842] to the URI specified in the configuration. events [RFC3842] to the URI specified in the configuration.
Providers MUST support MWI if they support video mail. RUE devices Providers MUST support MWI if they support video mail. RUE devices
MUST support MWI. MUST support MWI.
In notification bodies, videomail messages SHOULD be reported using In notification bodies, if detailed message summaries are available,
"message-context-class multimedia-message" defined in [RFC3458]. messages with video MUST be reported using "message-context-class
multimedia-message" defined in [RFC3458] .
9. Provisioning and Provider Selection 9. Provisioning and Provider Selection
To simplify how users interact with RUE devices, the RUE interface To simplify how users interact with RUE devices, the RUE interface
separates provisioning into two parts. One provides a directory of separates provisioning into two parts. One provides a directory of
providers so that a user interface can allow easy provider selection providers so that a user interface can allow easy provider selection
either for registering or for dial-around. The other provides either for registering or for dial-around. The other provides
configuration data for the device for each provider. configuration data for the device for each provider.
9.1. RUE Provider Selection 9.1. RUE Provider Selection
To allow the user to select a relay service, the RUE MAY at any time To allow the user to select a relay service, the RUE MAY at any time
obtain (typically on startup) a list of Providers that provide obtain (typically on startup) a list of Providers that provide
service in a country. IANA has established a registry that contains service in a country. IANA has established a registry that contains
a two letter country code and a URI. The URI, when used with the a two letter country code and an entry point string. The entry
following interface, returns a list of provider names for a country point, when used with the following interface, returns a list of
code suitable for display, with a corresponding a URI to obtain provider names for a country code suitable for display, with a
information about that provider. The provider URI is the entry point corresponding a entry point to obtain information about that
of a simple web service that returns contact information for that
provider. provider.
Each country that supports video relay service using this Each country that supports video relay service using this
specification MAY support the provider list. This document does not specification MAY support the provider list. This document does not
specify who maintains the list. Some possibilities are a regulator specify who maintains the list. Some possibilities are a regulator
or entity designated by a regulator, an agreement among providers to or entity designated by a regulator, an agreement among providers to
provide the list, or a user group. provide the list, or a user group.
The interface to obtain the list of providers is described by an
OpenApi [OpenApi] interface description. In that interface
description, the "servers" component is specified as "localhost".
The entry point in the registry is substituted for "localhost" to
obtain the server prefix of the interface. The "Providers" path then
specifies the rest of the URI used to obtain the list. For example,
if the entryPoint is "example.com", the provider list would be
obtained from https://example.com/rum/V1/Providers.
The web service also has a simple version mechanism that returns a The web service also has a simple version mechanism that returns a
list of versions of the web service it supports. This document list of versions of the web service it supports. This document
describes version 1.0. Versions are described as a major version, describes version 1.0. Versions are described as a major version,
the period "." and a minor version, where major and minor versions the period "." and a minor version, where major and minor versions
are integers. A backwards compatible change within a major version are integers. A backwards compatible change within a major version
MAY increment only the minor version number. A non-backwards MAY increment only the minor version number. A non-backwards
compatible change MUST increment the major version number. To compatible change MUST increment the major version number. To
achieve backwards compatibility, implementations MUST ignore any achieve backwards compatibility, implementations MUST ignore any
object members they do not implement. Minor version definitions object members they do not implement. Minor version definitions
SHALL only add objects, non-required members of existing objects, and SHALL only add objects, non-required members of existing objects, and
skipping to change at page 18, line 12 skipping to change at page 18, line 19
supported, with the minor version listed being the highest supported supported, with the minor version listed being the highest supported
minor version. minor version.
The V1.0 provider list is a json object consisting of an array where The V1.0 provider list is a json object consisting of an array where
each entry describes one provider. Each entry consists of the each entry describes one provider. Each entry consists of the
following items: following items:
* name: This parameter contains the text label identifying the * name: This parameter contains the text label identifying the
provider and is meant to be displayed to the human VRS user. provider and is meant to be displayed to the human VRS user.
* domain: The domain parameter is used for configuration purposes by * entryPoint: A string used for configuration purposes by the RUE
the RUE (as discussed in Section 9.2) (as discussed in Section 9.2)
The VRS user interacts with the RUE to select from the provider list The VRS user interacts with the RUE to select from the provider list
one or more providers with whom the user has already established an one or more providers with whom the user has already established an
account, wishes to establish an account, or wishes to use the account, wishes to establish an account, or wishes to use the
provider for a one-stage dial around. provider for a one-stage dial around.
{ {
"providers": [ "providers": [
{ {
"name": "Red", "name": "Red",
"domain": "red.example.net" "entryPoint": "red.example.net"
}, },
{ {
"name": "Green", "name": "Green",
"domain": "green.example.net" "entryPoint": "green.example.net"
}, },
{ {
"name": "Blue", "name": "Blue",
"domain": "blue.example.net" "entryPoint": "blue.example.net"
} }
] ]
} }
Figure 2: Example of a provider list JSON object Figure 2: Example of a provider list JSON object
{ {
"versions": [ "versions": [
{ {
"major": 1, "major": 1,
skipping to change at page 19, line 33 skipping to change at page 19, line 33
9.2. RUE Configuration Service 9.2. RUE Configuration Service
A RUE device may retrieve a provider configuration the using a simple A RUE device may retrieve a provider configuration the using a simple
HTTPs web service. There are two entry points. One is used without HTTPs web service. There are two entry points. One is used without
user credentials or parameters, the response includes configuration user credentials or parameters, the response includes configuration
data for new user sign up and dial around. The other uses the data for new user sign up and dial around. The other uses the
userid/password to authenticate to the interface and returns userid/password to authenticate to the interface and returns
configuration data for the RUE. configuration data for the RUE.
The interface to obtain configuration data is described by an OpenApi
[OpenApi] interface description. In that interface description, the
"servers" component is specified as "localhost". The entry point
obtained from the provider list (Section 9.1) is substituted for
"localhost" to obtain the server prefix of the interface. The path
then specifies the rest of the URI used to obtain the list. For
example, if the entryPoint from the provider list is
"redexample.net", the provider configuration would be obtained from
https://red.example.net/rum/V1/ProviderConfig.
In both the queries, an optional parameter may be provided to the In both the queries, an optional parameter may be provided to the
interface which is an API Key. The implementation MAY have an API interface which is an API Key. The implementation MAY have an API
Key obtained from the provider and specific to the implementation. Key obtained from the provider and specific to the implementation.
The method the API Key is obtained is not specified in this document. The method the API Key is obtained is not specified in this document.
The provider MAY refuse to provide service to an implementation The provider MAY refuse to provide service to an implementation
presenting an API Key it does not recognize. presenting an API Key it does not recognize.
Also in both queries, the RUE device provides a required parameter Also in both queries, the RUE device provides a required parameter
which contains an instance identifier. This parameter MUST be the which contains an instance identifier. This parameter MUST be the
same value each time this instance (same implementation on same same value each time this instance (same implementation on same
skipping to change at page 23, line 26 skipping to change at page 23, line 46
configuration service without credentials to obtain signup, configuration service without credentials to obtain signup,
dial around and helpdesk information. dial around and helpdesk information.
- If the RUE has credentials for that provider, use the - If the RUE has credentials for that provider, use the
configuration service with credentials to obtain all configuration service with credentials to obtain all
configuration data. configuration data.
9.3. OpenAPI Interface Descriptions 9.3. OpenAPI Interface Descriptions
The interfaces in Section 9.1 and Section 9.2 are formally specified The interfaces in Section 9.1 and Section 9.2 are formally specified
with OpenAPI 3.1 ([OpenApi]) descriptions in yaml form. with OpenAPI 3.0 ([OpenApi]) descriptions in yaml form.
openapi: 3.0.1 openapi: 3.0.1
info: info:
title: RUM API title: RUM API
version: "1.0" version: "1.0"
servers: servers:
- url: http://localhost/rum/v1 - url: http://localhost/rum/v1
paths: paths:
/Providers: /Providers:
get: get:
skipping to change at page 25, line 27 skipping to change at page 26, line 4
- providers - providers
properties: properties:
providers: providers:
type: array type: array
items: items:
type: object type: object
required: required:
- name - name
- domain - domain
properties: properties:
name: name:
type: string type: string
description: Human readable provider name description: Human readable provider name
domain: entryPoint:
type: string type: string
description: provider domain for interface description: provider entry point for interface
VersionsArray: VersionsArray:
type: object type: object
required: required:
- versions - versions
properties: properties:
versions: versions:
type: array type: array
items: items:
type: object type: object
required: required:
skipping to change at page 28, line 41 skipping to change at page 29, line 18
should prefer a regulator operated or designated list interface should prefer a regulator operated or designated list interface
operator. Otherwise, evidence that the proposed list interface operator. Otherwise, evidence that the proposed list interface
operator will provide a complete list of providers is required to add operator will provide a complete list of providers is required to add
the entry to the registry. Updates to the registry are permitted if the entry to the registry. Updates to the registry are permitted if
the expert judges the new proposed URI to provide a more accurate the expert judges the new proposed URI to provide a more accurate
list than the existing entry. Each entry has two fields, values for list than the existing entry. Each entry has two fields, values for
both of which MUST be provided when registering or updating an entry: both of which MUST be provided when registering or updating an entry:
* country code: a two letter ISO93166 country code * country code: a two letter ISO93166 country code
* list uri: a URI that implements the provider list interface for * list entry point: a string is used to compose the uri to the
that country provider list interface for that country
10.2. Registration of rue-owner Value of the purpose Parameter 10.2. Registration of rue-owner Value of the purpose Parameter
This document defines the new predefined value "rue-owner" for the This document defines the new predefined value "rue-owner" for the
"purpose" header field parameter of the Call-Info header field. This "purpose" header field parameter of the Call-Info header field. This
modifies the "Header Field Parameters and Parameter Values" modifies the "Header Field Parameters and Parameter Values"
subregistry of the "Session Initiation Protocol (SIP) Parameters" subregistry of the "Session Initiation Protocol (SIP) Parameters"
registry by adding this RFC as a reference to the line for the header registry by adding this RFC as a reference to the line for the header
field "Call-Info" and parameter name "purpose" field "Call-Info" and parameter name "purpose"
* Header Field: Call-Info * Header Field: Call-Info
* Parameter Name: purpose * Parameter Name: purpose
* Predefined Values: Yes * Predefined Values: Yes
11. Security Considerations 11. Security Considerations
The RUE is required to communicate with servers on public IP The RUE is required to communicate with servers on public IP
addresses and specific ports to perform its required functions. If addresses and specific ports to perform its required functions. If
skipping to change at page 29, line 34 skipping to change at page 30, line 14
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>. <https://www.rfc-editor.org/info/rfc2392>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
DOI 10.17487/RFC3263, June 2002, DOI 10.17487/RFC3263, June 2002,
<https://www.rfc-editor.org/info/rfc3263>. <https://www.rfc-editor.org/info/rfc3263>.
skipping to change at page 31, line 31 skipping to change at page 32, line 14
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
<https://www.rfc-editor.org/info/rfc4103>. <https://www.rfc-editor.org/info/rfc4103>.
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol [RFC4488] Levin, O., "Suppression of Session Initiation Protocol
(SIP) REFER Method Implicit Subscription", RFC 4488, (SIP) REFER Method Implicit Subscription", RFC 4488,
DOI 10.17487/RFC4488, May 2006, DOI 10.17487/RFC4488, May 2006,
<https://www.rfc-editor.org/info/rfc4488>. <https://www.rfc-editor.org/info/rfc4488>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733, Digits, Telephony Tones, and Telephony Signals", RFC 4733,
DOI 10.17487/RFC4733, December 2006, DOI 10.17487/RFC4733, December 2006,
<https://www.rfc-editor.org/info/rfc4733>. <https://www.rfc-editor.org/info/rfc4733>.
[RFC4967] Rosen, B., "Dial String Parameter for the Session [RFC4967] Rosen, B., "Dial String Parameter for the Session
Initiation Protocol Uniform Resource Identifier", Initiation Protocol Uniform Resource Identifier",
RFC 4967, DOI 10.17487/RFC4967, July 2007, RFC 4967, DOI 10.17487/RFC4967, July 2007,
<https://www.rfc-editor.org/info/rfc4967>. <https://www.rfc-editor.org/info/rfc4967>.
skipping to change at page 33, line 15 skipping to change at page 33, line 49
[RFC6764] Daboo, C., "Locating Services for Calendaring Extensions [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions
to WebDAV (CalDAV) and vCard Extensions to WebDAV to WebDAV (CalDAV) and vCard Extensions to WebDAV
(CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013,
<https://www.rfc-editor.org/info/rfc6764>. <https://www.rfc-editor.org/info/rfc6764>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling", Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
<https://www.rfc-editor.org/info/rfc6881>. <https://www.rfc-editor.org/info/rfc6881>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of [RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of
REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647,
September 2015, <https://www.rfc-editor.org/info/rfc7647>. September 2015, <https://www.rfc-editor.org/info/rfc7647>.
skipping to change at page 35, line 14 skipping to change at page 36, line 7
[RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real- [RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real-
Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021,
<https://www.rfc-editor.org/info/rfc9071>. <https://www.rfc-editor.org/info/rfc9071>.
13. 13.
Informative References Informative References
[OpenApi] Miller, D., Whitlock, J., Gardiner, M., Ralpson, M., [OpenApi] Miller, D., Whitlock, J., Gardiner, M., Ralpson, M.,
Ratovsky, R., and U. Sarid, "OpenAPI Specification Ratovsky, R., and U. Sarid, "OpenAPI Specification
v3.1.0", February 2021, v3.0.1", December 2017,
<https://spec.openapis.org/oas/v3.1.0>. <https://spec.openapis.org/oas/v3.0.1>.
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
K. Summers, "Session Initiation Protocol (SIP) Basic Call K. Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665,
December 2003, <https://www.rfc-editor.org/info/rfc3665>. December 2003, <https://www.rfc-editor.org/info/rfc3665>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
 End of changes. 36 change blocks. 
50 lines changed or deleted 86 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/