draft-ietf-rum-rue-07.txt   draft-ietf-rum-rue-08.txt 
rum B. Rosen rum B. Rosen
Internet-Draft 26 August 2021 Internet-Draft 1 October 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 27 February 2022 Expires: 4 April 2022
Interoperability Profile for Relay User Equipment Interoperability Profile for Relay User Equipment
draft-ietf-rum-rue-07 draft-ietf-rum-rue-08
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 persons can communicate with deaf/Hard of Hearing which a hearing person can communicate with a deaf, hard of hearing
user using an interpreter ("Communications Assistant") connected via or hearing impaired user using an interpreter ("Communications
a videophone to the deaf/HoH user and an audio telephone call to the Assistant") connected via a videophone to the deaf/HoH user and an
hearing user. The CA interprets using sign language on the audio telephone call to the hearing user. The CA interprets using
videophone link and voice on the telephone link. Often the sign language on the videophone link and voice on the telephone link.
interpreters may be supplied by a company or agency termed a Often the interpreters may be employed by a company or agency termed
"provider" in this document. The provider also provides a video a "provider" in this document. The provider also provides a video
service that allows users to connect video devices to their service, service that allows users to connect video devices to their service,
and subsequently to CAs and other deaf/HoH users. It is desirable and subsequently to CAs and other deaf/HoH users. It is desirable
that the videophones used by the deaf/HoH/H-I user conform to a that the videophones used by the deaf, hard of hearing or hearing
standard so that any device may be used with any provider and that impaired user conform to a standard so that any device may be used
video calls direct between deaf/HoH users work. This document with any provider and that direct video calls between deaf, hard of
describes the interface between a videophone and a provider. hearing or hearing impaired users work. This document describes the
interface between a videophone and a provider.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 27 February 2022. This Internet-Draft will expire on 4 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
4. General Requirements . . . . . . . . . . . . . . . . . . . . 6 4. General Requirements . . . . . . . . . . . . . . . . . . . . 6
5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Session Establishment . . . . . . . . . . . . . . . . . . 8 5.2. Session Establishment . . . . . . . . . . . . . . . . . . 9
5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 8 5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 9
5.2.2. Dial-Around Origination . . . . . . . . . . . . . . . 9 5.2.2. Dial-Around Origination . . . . . . . . . . . . . . . 10
5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 10 5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 11
5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10 5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 11
5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 11 5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 12
5.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 11 5.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 12
5.4. URI Representation of Phone Numbers . . . . . . . . . . . 12 5.4. URI Representation of Phone Numbers . . . . . . . . . . . 13
5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 13 6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 14
6.2. Text-Based Communication . . . . . . . . . . . . . . . . 13 6.2. Text-Based Communication . . . . . . . . . . . . . . . . 14
6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 15
6.6. Session Description Protocol . . . . . . . . . . . . . . 13 6.6. Session Description Protocol . . . . . . . . . . . . . . 15
6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full
Intraframe Request Features . . . . . . . . . . . . . . . 14 Intraframe Request Features . . . . . . . . . . . . . . . 15
7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 14 7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 15
7.2. Contacts Import/Export Service . . . . . . . . . . . . . 15 7.2. Contacts Import/Export Service . . . . . . . . . . . . . 16
8. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 15 8. Video Mail . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Provisioning and Provider Selection . . . . . . . . . . . . . 15 9. Provisioning and Provider Selection . . . . . . . . . . . . . 17
9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 16 9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 17
9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 18 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 19
9.2.1. Provider Configuration . . . . . . . . . . . . . . . 18 9.2.1. Provider Configuration . . . . . . . . . . . . . . . 20
9.2.2. RUE Configuration . . . . . . . . . . . . . . . . . . 19 9.2.2. RUE Configuration . . . . . . . . . . . . . . . . . . 21
9.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . 21 Services Together . . . . . . . . . . . . . . . . . . 23
9.3. OpenAPI Interface Descriptions . . . . . . . . . . . . . 21 9.3. OpenAPI Interface Descriptions . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10.1. RUE Provider List Registry . . . . . . . . . . . . . . . 28
11.1. RUE Provider List Registry . . . . . . . . . . . . . . . 27 10.2. Registration of rue-owner Value of the purpose
11.2. Registration of rue-owner purpose parameter . . . . . . 27 Parameter . . . . . . . . . . . . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. Normative References . . . . . . . . . . . . . . . . . . . . 27 12. Normative References . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 13. Informative References . . . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35
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 3, line 45 skipping to change at page 3, line 47
accommodations in this document to maximize backwards compatibility accommodations in this document to maximize backwards compatibility
with other devices and services that are used to provide VRS service, with other devices and services that are used to provide VRS service,
backwards compatibility is not a requirement, and some interwork may backwards compatibility is not a requirement, and some interwork may
be required to allow direct video calls to older devices. This be required to allow direct video calls to older devices. This
document only describes the interface between the device and the document only describes the interface between the device and the
provider, and not any other interface the provider may have. provider, and not any other interface the provider may have.
2. Terminology 2. Terminology
Communication Assistant (CA): A sign-language interpreter working for Communication Assistant (CA): A sign-language interpreter working for
a VRS Provider, providing functionally equivalent phone service. a VRS provider, providing functionally equivalent phone service.
Communication modality (modality): A specific form of communication Communication modality (modality): A specific form of communication
that may be employed by two users, e.g., English voice, Spanish that may be employed by two users, e.g., English voice, Spanish
voice, American Sign Language, English lip-reading, or French real- voice, American Sign Language, English lip-reading, or French real-
time-text. Here, one communication modality is assumed to encompass time-text. Here, one communication modality is assumed to encompass
both the language and the way that language is exchanged. For both the language and the way that language is exchanged. For
example, English voice and French voice are two different example, English voice and French voice are two different
communication modalities. communication modalities.
Default video relay service: The video relay service operated by a Default video relay service: The video relay service operated by a
subscriber's default VRS provider. subscriber's default VRS provider.
Default video relay service Provider (Default Provider): The VRS Default video relay service provider (default provider): The VRS
provider that registers, and assigns a telephone number to a specific provider that registers, and assigns a telephone number to a specific
subscriber, and by default provides the VRS for incoming voice calls subscriber, and by default provides the VRS for incoming voice calls
to the user. The default Provider also by default provides VRS for to the user. The default provider also by default provides VRS for
outgoing relay calls. The user can have more than one telephone outgoing relay calls. The user can have more than one telephone
number and each has a default provider. number and each has a default provider.
Outbound Dial-around call: A relay call where the subscriber Outbound Dial-around call: A relay call where the subscriber
specifies the use of a VRS provider other than the default VRS specifies the use of a VRS provider other than the default VRS
provider. This can be accomplished by the user dialing a "front- provider. This can be accomplished by the user dialing a "front-
door" number for a VRS provider and signing or texting a phone number door" number for a VRS provider and signing or texting a phone number
to call ("two-stage"). Alternatively, this can be accomplished by to call ("two-stage"). Alternatively, this can be accomplished by
the user's RUE software instructing the server of its default VRS the user's RUE software instructing the server of its default VRS
provider to automatically route the call through the alternate provider to automatically route the call through the alternate
Provider to the desired public switched telephone network (PSTN) provider to the desired public switched telephone network (PSTN)
directory number ("one-stage"). Dial-around is per-call -- for any directory number ("one-stage"). Dial-around is per-call -- for any
call, a user can use the default VRS provider or any dial-around VRS call, a user can use the default VRS provider or any dial-around VRS
provider. provider.
Full Intra Request (FIR): A request to a video media sender, Full Intra Request (FIR): A request to a video media sender,
requiring that media sender to send a Decoder Refresh Point at the requiring that media sender to send a Decoder Refresh Point at the
earliest opportunity. FIR is sometimes known as "instantaneous earliest opportunity. FIR is sometimes known as "instantaneous
decoder refresh request", "video fast update request", or "fast decoder refresh request", "video fast update request", or "fast
update request". Point-to-Point Call (P2P Call): A call between two update request".
RUEs, without including a CA.
Point-to-Point Call (P2P Call): A call between two RUEs, without
including a CA.
Relay call: A call that allows persons with hearing or speech Relay call: A call that allows persons with hearing or speech
disabilities to use a RUE to talk to users of traditional voice disabilities to use a RUE to talk to users of traditional voice
services with the aid of a communication assistant (CA) to relay the services with the aid of a communication assistant (CA) to relay the
communication. Please refer to FCC-VRS-GUIDE. communication.
Relay service (RS): A service that allow a registered subscriber to Relay service (RS): A service that allow a registered subscriber to
use a RUE to make and receive relay calls, point-to-point calls, and use a RUE to make and receive relay calls, point-to-point calls, and
relay-to-relay calls. The functions provided by the relay service relay-to-relay calls. The functions provided by the relay service
include the provision of media links supporting the communication include the provision of media links supporting the communication
modalities used by the caller and callee, and user registration and modalities used by the caller and callee, and user registration and
validation, authentication, authorization, automatic call distributor validation, authentication, authorization, automatic call distributor
(ACD) platform functions, routing (including emergency call routing), (ACD) platform functions, routing (including emergency call routing),
call setup, mapping, call features (such as call forwarding and video call setup, mapping, call features (such as call forwarding and video
mail), and assignment of CAs to relay calls. mail), and assignment of CAs to relay calls.
Relay service Provider (Provider): An organization that operates a Relay service provider (provider): An organization that operates a
relay service. A subscriber selects a relay service Provider to relay service. A subscriber selects a relay service provider to
assign and register a telephone number for their use, to register assign and register a telephone number for their use, to register
with for receipt of incoming calls, and to provide the default with for receipt of incoming calls, and to provide the default
service for outgoing calls. service for outgoing calls.
Relay user: Please refer to "subscriber". Relay user: Please refer to "subscriber".
Relay user E.164 Number (user E.164): The telephone number (in ITU-T Relay user E.164 Number (user E.164): The telephone number (in ITU-T
E.164 format) assigned to the user. E.164 format) assigned to the user.
Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra
skipping to change at page 5, line 33 skipping to change at page 5, line 40
such as a laptop, tablet or smart phone; or proprietary equipment such as a laptop, tablet or smart phone; or proprietary equipment
connected to a server that provides the RUE interface. connected to a server that provides the RUE interface.
RUE Interface: the interfaces described in this document between a RUE Interface: the interfaces described in this document between a
RUE and a VRS provider who supports it RUE and a VRS provider who supports it
Sign language: A language that uses hand gestures and body language Sign language: A language that uses hand gestures and body language
to convey meaning including, but not limited to, American Sign to convey meaning including, but not limited to, American Sign
Language (ASL). Language (ASL).
Subscriber: An individual who has registered with a Provider and who Subscriber: An individual who has registered with a provider and who
obtains service by using relay user equipment. This is the obtains service by using relay user equipment. This is the
traditional telecom term for an end-user customer, which in our case traditional telecom term for an end-user customer, which in our case
is a relay user. A user may be a subscriber to more than one VRS is a relay user. A user may be a subscriber to more than one VRS
provider. provider.
Video relay service (VRS): A relay service for people with hearing or Video relay service (VRS): A relay service for people with hearing or
speech disabilities who use sign language to communicate using video speech disabilities who use sign language to communicate using video
equipment (video RUE) with other people in real time. The video link equipment (video RUE) with other people in real time. The video link
allows the CA to view and interpret the subscriber's signed allows the CA to view and interpret the subscriber's signed
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 keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119] "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [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 in
this memo.
4. General Requirements 4. General Requirements
All HTTP/HTTPS connections specified throughout this document MUST All HTTP/HTTPS connections specified throughout this document MUST
use HTTPS. Both HTTPS and all SIP connections MUST use TLS use HTTPS. Both HTTPS and all SIP connections MUST use TLS
conforming to at least [RFC7525] and must support [RFC8446] 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 ([RFC5245]) is used for both signaling and media of a call unless ICE ([RFC8445]) is
used, in which case candidates may explicitly offer IPv4, IPv6 or used, in which case candidates may explicitly offer IPv4, IPv6 or
both for any media stream. both for any media stream.
5. SIP Signaling 5. SIP Signaling
Implementations of the RUE Interface MUST conform to the following Implementations of the RUE Interface MUST conform to the following
core SIP standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP core SIP standards:
Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent
Capabilities), [RFC5626] (Outbound), [RFC8866] (Session Description * [RFC3261] (Base SIP)
Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP),
[RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop- * [RFC3263] (Locating SIP Servers)
Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960]
(Early Media), and [RFC6442] (Geolocation Header). * [RFC3264] (Offer/Answer)
* [RFC3840] (User Agent Capabilities)
* [RFC5626] (Outbound)
* [RFC8866] (Session Description Protocol)
* [RFC3323] (Privacy)
* [RFC3605] (RTCP Attribute in SDP)
* [RFC6665] (SIP Events)
* [RFC3311] (UPDATE Method)
* [RFC5393] (Loop-Fix)
* [RFC5658] (Record Route fix)
* [RFC5954] (ABNF fix)
* [RFC3960] (Early Media)
* [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 Section 8), which is optional and providers not supporting Section 8), which is optional and providers not supporting voicemail
voicemail need not support RFC6665. need not support RFC6665.
In addition, implementation MUST conform to [RFC3327] (Path), In addition, implementation MUST conform to:
[RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER Method),
[RFC3891] (Replaces Header), [RFC3892] (Referred-By). * [RFC3327] (Path)
* [RFC8445] and [RFC8839] (ICE)
* [RFC3326] (Reason header field)
* [RFC3515] (REFER Method)
* [RFC3891] (Replaces Header field)
* [RFC3892] (Referred-By)
Implementations MUST include a "User-Agent" header field uniquely Implementations MUST include a "User-Agent" header field uniquely
identifying the RUE application, platform, and version in all SIP identifying the RUE application, platform, and version in all SIP
requests, and MUST include a "Server" header field with the same requests, and MUST include a "Server" header field with the same
content in SIP responses. content in SIP responses.
Implementations intended to support mobile platforms MUST support Implementations intended to support mobile platforms MUST support
[RFC8599] and MUST use it as at least one way to support waking up [RFC8599] and MUST use it as at least one way to support waking up
the client from background state. the client from background state.
5.1. Registration 5.1. Registration
The RUE MUST register with a SIP registrar, following [RFC3261] and The RUE MUST register with a SIP registrar, following [RFC3261] and
[RFC5626] at a provider it has an account with. If the configuration [RFC5626] at a provider it has an account with. If the configuration
(see Section 9.2) contains multiple "outbound-proxies", then the RUE (see Section 9.2) contains multiple "outbound-proxies", then the RUE
MUST use them as specified in [RFC5626] to establish multiple flows. MUST use them as specified in [RFC5626] to establish multiple flows.
The request-URI for the REGISTER request MUST contain the "provider- The Request-URI for the REGISTER request MUST contain the "provider-
domain" from the configuration. The To-URI and From-URI MUST be domain" from the configuration. The To-URI and From-URI MUST be
identical URIs, formatted as specified in Section 13, using the identical URIs, formatted as specified in Section 5.4, using the
"phone-number" and "provider-domain" from the configuration. "phone-number" and "provider-domain" from the configuration.
The RUE determines the URI to resolve by initially determining if an The RUE determines the URI to resolve by initially determining if an
outbound proxy is configured. If it is, the URI will be that of the outbound proxy is configured. If it is, the URI will be that of the
outbound proxy. If no outbound proxy is configured, the URI will be outbound proxy. If no outbound proxy is configured, the URI will be
the Request-URI from the REGISTER request. The RUE extracts the the Request-URI from the REGISTER request. The RUE extracts the
domain from that URI and consults the DNS record for that domain. domain from that URI and consults the DNS record for that domain.
The DNS entry MUST contain NAPTR records conforming to RFC3263. One The DNS entry MUST contain NAPTR records conforming to RFC3263. One
of those NAPTR records MUST specify TLS as the preferred transport of those NAPTR records MUST specify TLS as the preferred transport
for SIP. For example, a DNS NAPTR query for "sip: for SIP. For example, a DNS NAPTR query for "sip:
p1.red.example.netv" could return: p1.red.example.net" could return:
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net
If the RUE receives a 439 (First Hop Lacks Outbound Support) response If the RUE receives a 439 (First Hop Lacks Outbound Support) response
to a REGISTER request, it MUST re-attempt registration without using to a REGISTER request, it MUST re-attempt registration without using
the outbound mechanism. the outbound mechanism.
The registrar MAY authenticate using SIP digest authentication. The The registrar MAY authenticate using SIP digest authentication. The
credentials to be used (username and password) MUST be supplied credentials to be used (username and password) MUST be supplied
skipping to change at page 8, line 17 skipping to change at page 9, line 10
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 SHOULD 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
Provider MAY then prematurely terminate another registration; provider MAY then prematurely terminate another registration;
however, it SHOULD NOT do this if it would disconnect an active call. however, it SHOULD NOT do this if it would disconnect an active call.
If a Provider prematurely terminates a registration to reduce the If a provider prematurely terminates a registration to reduce the
total number of concurrent registrations with the same URI, it SHOULD total number of concurrent registrations with the same URI, it SHOULD
take some action to prevent the affected RUE from automatically re- take some action to prevent the affected RUE from automatically re-
registering and re-triggering the condition. registering and re-triggering the condition.
5.2. Session Establishment 5.2. Session Establishment
5.2.1. Normal Call Origination 5.2.1. Normal Call Origination
After initial SIP registration, the RUE adheres to SIP [RFC3261] After initial SIP registration, the RUE adheres to SIP [RFC3261]
basic call flows, as documented in [RFC3665]. basic call flows, as documented in [RFC3665].
A RUE device MUST route all outbound calls through an outbound proxy A RUE device MUST route all outbound calls through an outbound proxy
if configured. if configured.
The SIP URIs in the To field and the Request-URI MUST be formatted as The SIP URIs in the To field and the Request-URI MUST be formatted as
specified in subsection Section 5.4 using the destination phone specified in subsection Section 5.4 using the destination phone
number, or as SIP URIs, as provided in the configuration number, or as SIP URIs, as provided in the configuration
(Section 9.2. The domain field of the URIs SHOULD be the "provider- (Section 9.2). The domain field of the URIs SHOULD be the "provider-
domain" from the configuration (e.g., domain" from the configuration (e.g.,
sip:+13115552368@red.example.com;user=phone) except that an anonymous sip:+13115552368@red.example.com;user=phone) except that an anonymous
call would not use the provider domain. call would not use the provider domain.
Anonymous calls MUST be supported by all implementations. An Anonymous calls MUST be supported by all implementations. An
anonymous call is signaled per [RFC3323]. anonymous call is signaled per [RFC3323].
The From-URI MUST be formatted as specified in Section 5.4, using the The From-URI MUST be formatted as specified in Section 5.4, using the
phone-number and "provider-domain" from the configuration. It SHOULD phone-number and "provider-domain" from the configuration. It SHOULD
also contain the display-name from the configuration when present. also contain the display-name from the configuration when present.
skipping to change at page 9, line 22 skipping to change at page 10, line 14
To allow time to timeout an unanswered call and direct it to a To allow time to timeout an unanswered call and direct it to a
videomail server, the User Agent Client MUST NOT impose a time limit videomail server, the User Agent Client MUST NOT impose a time limit
less than the default SIP Invite transaction timeout of 3 minutes. less than the default SIP Invite transaction timeout of 3 minutes.
5.2.2. Dial-Around Origination 5.2.2. Dial-Around Origination
Providers and RUE devices MUST support both One-Stage and Two-Stage Providers and RUE devices MUST support both One-Stage and Two-Stage
dial-around dial-around
Outbound dial-around calls allow a RUE user to select any Provider to Outbound dial-around calls allow a RUE user to select any provider to
provide interpreting services for any call. "Two-stage" dial-around provide interpreting services for any call. "Two-stage" dial-around
calls involve the RUE calling a telephone number that reaches the calls involve the RUE calling a telephone number that reaches the
dial-around Provider and using signing or DTMF to provide the called dial-around provider and using signing or DTMF to provide the called
party telephone number. In two-stage dial-around, the To URI is the party telephone number. In two-stage dial-around, the To URI is the
front door URI (see Section Section 9.2 of the dial-around Provider front door URI (see Section 9.2) of the dial-around provider and the
and the domain of the URI is the Provider domain from the domain of the URI is the provider domain from the configuration. The
configuration. The provider list service (Section 9.1) can be used provider list service (Section 9.1) can be used by the RUE to obtain
to by the RUE to obtain a list of providers and then the a list of providers and then the configuration service
configuration service (xref target="providerConfig"/>) without (Section 9.2.1) without credentials can be used to find the front
credentials can be used to find the front door URI for each of these door URI for each of these providers.
providers.
One-stage dial-around is a method where the called party telephone One-stage dial-around is a method where the called party telephone
number is provided in the To URI and the Request-URI, using the number is provided in the To URI and the Request-URI, using the
domain of the dial-around Provider. domain of the dial-around provider.
For one-stage dial-around, the RUE MUST follow the procedures in For one-stage dial-around, the RUE MUST follow the procedures in
Section 5.2.1 with the following exception: the domain part of the Section 5.2.1 with the following exception: the domain part of the
SIP URIs in the To field and the Request-URI MUST be the domain of SIP URIs in the To field and the Request-URI MUST be the domain of
the dial-around Provider, discovered according to Section 9.1. the dial-around provider, discovered according to Section 9.1.
The following is a partial example of a one-stage dial-around call The following is a partial example of a one-stage dial-around call
from VRS user +1-555-222-0001 hosted by red.example.com to a hearing from VRS user +1-555-222-0001 hosted by red.example.com to a hearing
user +1-555-123-4567 using dial-around to green.example.com for the user +1-555-123-4567 using dial-around to green.example.com for the
relay service. Only important details of the messages are shown and relay service. Only important details of the messages are shown and
many header fields have been omitted: many header fields have been omitted:
One Stage Dial-Around One-Stage Dial-Around
,-+-. ,----+----. ,-----+-----. ,-+-. ,----+----. ,-----+-----.
|RUE| |Default | |Dial-Around| |RUE| |Default | |Dial-Around|
| | |Provider | | Provider | | | |Provider | | Provider |
`-+-' `----+----' `-----+-----' `-+-' `----+----' `-----+-----'
| | | | | |
| [1] INVITE | | | [1] INVITE | |
|-------------->| [2] INVITE | |-------------->| [2] INVITE |
| |-------------->| | |-------------->|
Message Details: Message Details:
skipping to change at page 10, line 34 skipping to change at page 11, line 34
To: <sip:+15551234567@green.example.net;user=phone> To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" sip:+18135551212@red.example.net;user=phone From: "Bob Smith" sip:+18135551212@red.example.net;user=phone
P-Asserted-Identity: sip:+18135551212@red.example.net P-Asserted-Identity: sip:+18135551212@red.example.net
Figure 1 Figure 1
5.2.3. RUE Contact Information 5.2.3. RUE Contact Information
To identify the owner of a RUE, the initial INVITE for a call from a To identify the owner of a RUE, the initial INVITE for a call from a
RUE, or the 200 OK accepting a call by a RUE, identifies the owner by RUE, or the 200 OK accepting a call by a RUE, identifies the owner by
sending a Call-Info header with a purpose parameter of "rue-owner". sending a Call-Info header field with a purpose parameter of "rue-
The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is owner". The URI MAY be an HTTPS URI or Content-Indirect URL. The
defined by [RFC2392] to locate message body parts. This URI type is latter is defined by [RFC2392] to locate message body parts. This
present in a SIP message to convey the RUE ownership information as a URI type is present in a SIP message to convey the RUE ownership
MIME body. The form of the RUE ownership information is a xCard information as a MIME body. The form of the RUE ownership
[RFC6351]. for an example of using Content-Indirect URLs in SIP information is a xCard [RFC6351]. Please refer to [RFC6442] for an
messages. Note that use of the Content-Indirect URL usually implies example of using Content-Indirect URLs in SIP messages. Note that
multiple message bodies ("mime/multipart"). use of the Content-Indirect URL usually implies multiple message
bodies ("mime/multipart").
5.2.4. Incoming Calls 5.2.4. Incoming Calls
The RUE MUST only accept inbound calls sent to it by a proxy The RUE MUST only accept inbound calls sent to it by a proxy
mentioned in the configuration. mentioned in the configuration.
If Multiple simultaneous RUE SIP registrations from different RUE If Multiple simultaneous RUE SIP registrations from different RUE
devices with the same SIP URI exist, the Provider MUST parallel fork devices with the same SIP URI exist, the provider MUST parallel fork
the call to all registered RUEs so that they ring at the same time. the call to all registered RUEs so that they ring at the same time.
The first RUE to reply with a 200 OK answers the call and the The first RUE to reply with a 200 OK answers the call and the
Provider MUST CANCEL other call branches. provider MUST CANCEL other call branches.
5.2.5. Emergency Calls 5.2.5. Emergency Calls
Implementations MUST conform to [RFC6881] for handling of emergency Implementations MUST conform to [RFC6881] for handling of emergency
calls, except that if the device is unable to determine its own calls, except that if the device is unable to determine its own
location, it MAY send the emergency call without a Geolocation header location, it MAY send the emergency call without a Geolocation header
and without a Route header (since it would be unable to query the field and without a Route header field (since it would be unable to
LoST server for a route per RFC6881). If an emergency call arrives query the LoST server for a route per RFC6881). If an emergency call
at the provider without a Geolocation header, the provider MUST arrives at the provider without a Geolocation header field, the
supply location by adding the Geolocation header, and MUST supply the provider MUST supply location by adding the Geolocation header field,
route by querying the LoST server with that location. and MUST supply the route by querying the LoST server with that
location.
If the emergency call is to be handled using existing country If the emergency call is to be handled using existing country
specific procedures, the Provider is responsible for modifying the specific procedures, the provider is responsible for modifying the
INVITE to conform to the country-specific requirements. In this INVITE to conform to the country-specific requirements. In this
case, location MAY be extracted from the RFC6881 conformant INVITE case, location MAY be extracted from the RFC6881 conformant INVITE
and used to propagate it to the appropriate country-specific and used to propagate it to the appropriate country-specific
entities. Because the RUE may have a more accurate and timely entities. If the configuration specifies it, an implementation of a
location of the device than the a manual entry location for nomadic RUE device MAY send a Geolocation header field containing its
RUE devices, but country-specific procedures require the location to location in the REGISTER request. If implemented, users MUST be
be pre-loaded in some entity prior to placing an emergency call, offered an opt-out. Country-specific procedures might require the
implementations of a RUE device MAY send a Geolocation header location to be pre-loaded in some entity prior to placing an
containing its location in the REGISTER request if the configuration emergency call; however, the RUE may have a more accurate and timely
specifies it. That information MAY be used to populate the location device location than the manual, pre-loaded entry. That information
to appropriate country-specific entities. Re-registration SHOULD be MAY be used to populate the location to appropriate country-specific
used to update the location, so long as the rate of re-registration entities. Re-registration SHOULD be used to update the location, so
is limited if the device is moving. long as the rate of re-registration is limited if the device is
moving.
Implementations MUST implement Additional Data, [RFC7852]. RUE Implementations MUST implement Additional Data, [RFC7852]. RUE
devices MUST implement Data Provider, Device Implementation and devices MUST implement Data Provider, Device Implementation and
Owner/Subscriber Information blocks. Owner/Subscriber Information blocks.
5.3. Mid Call Signaling 5.3. Mid Call Signaling
Implementations MUST support re-INVITE to renegotiate media session Implementations MUST support re-INVITE to renegotiate media session
parameters (among other uses). Per Section 6.1, implementations parameters (among other uses). Per Section 6.1, implementations MUST
MUST, be able to support an INFO request for full frame refresh for be able to support an INFO request for full frame refresh for devices
devices that do not support RTCP mechanisms (please refer to that do not support RTCP mechanisms (please refer to Section 6.8).
Section 6.8). Implementations MUST support an in-dialog REFER Implementations MUST support an in-dialog REFER ([RFC3515] updated by
([RFC3515] updated by [RFC7647] and including support for norefersub [RFC7647] and including support for norefersub per [RFC4488]) with
per [RFC4488]) with the Replaces header [RFC3891] to enable call the Replaces header field [RFC3891] to enable call transfer.
transfer.
5.4. URI Representation of Phone Numbers 5.4. URI Representation of Phone Numbers
SIP URIs constructed from non-URI sources (dial strings) and sent to SIP URIs constructed from non-URI sources (dial strings) and sent to
SIP proxies by the RUE MUST be represented as follows, depending on SIP proxies by the RUE MUST be represented as follows, depending on
whether they can be represented as an E.164 number. In this section whether they can be represented as an E.164 number. In this section
"expressed as an E.164 number" includes numbers such as toll free "expressed as an E.164 number" includes numbers such as toll free
numbers that are not actually E.164 numbers, but have the same numbers that are not actually E.164 numbers, but have the same
format. format.
skipping to change at page 12, line 30 skipping to change at page 13, line 30
Dial strings that cannot be expressed as E.164 numbers MUST be Dial strings that cannot be expressed as E.164 numbers MUST be
represented as dialstring URIs, as specified by [RFC4967], e.g., represented as dialstring URIs, as specified by [RFC4967], e.g.,
sip:411@red.example.net;user=dialstring. sip:411@red.example.net;user=dialstring.
The domain part of Relay Service URIs and User Address of Records The domain part of Relay Service URIs and User Address of Records
(AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or (AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or
IPv6 addresses. IPv6 addresses.
5.5. Transport 5.5. Transport
Implementations MUST conform to [RFC8835] except that that this Implementations MUST conform to [RFC8835] except for its guidance on
specification does not use the WebRTC data channel. See the WebRTC data channel, which this specification does not use. See
Section Section 6.2 for how RUE supports real time text without the Section 6.2 for how RUE supports real-time text without the data
data channel. channel.
Implementations MUST support SIP outbound [RFC5626] (please also Implementations MUST support SIP outbound [RFC5626] (please also
refer to Section 5.1). refer to Section 5.1).
6. Media 6. Media
This specification adopts the media specifications for WebRTC This specification adopts the media specifications for WebRTC
([RFC8825]). Where WebRTC defines how interactive media ([RFC8825]). Where WebRTC defines how interactive media
communications may be established using a browser as a client, this communications may be established using a browser as a client, this
specification assumes a normal SIP call. The RTP, RTCP, SDP and specification assumes a normal SIP call. The RTP, RTCP, SDP and
specific media requirements specified for WebRTC are adopted for this specific media requirements specified for WebRTC are adopted for this
document. The RUE is a WebRTC non-browser" endpoint, except as noted document. The RUE is a WebRTC "non-browser" endpoint, except as
expressly below. noted expressly below.
The following sections specify the WebRTC documents to which The following sections specify the WebRTC documents to which
conformance is required. "Mandatory to Implement" means a conforming conformance is required. "Mandatory to Implement" means a conforming
implementation must implement the specified capability. It does not implementation must implement the specified capability. It does not
mean that the capability must be used in every session. For example, mean that the capability must be used in every session. For example,
OPUS is a mandatory to implement audio codec, and all conforming OPUS is a mandatory to implement audio codec, and all conforming
implementations must support OPUS. However, implementation implementations must support OPUS. However, implementation
presenting a call across the RUE Interface where the call originates presenting a call across the RUE Interface where the call originates
in the Public Switched Telephone Network, or an older, non-RUE- in the Public Switched Telephone Network, or an older, non-RUE-
compatible device, which only offers G.711 audio, does not need to compatible device, which only offers G.711 audio, does not need to
skipping to change at page 13, line 21 skipping to change at page 14, line 21
6.1. SRTP and SRTCP 6.1. SRTP and SRTCP
Implementations MUST support [RFC8834] except that MediaStreamTracks Implementations MUST support [RFC8834] except that MediaStreamTracks
are not used. Implementations MUST conform to Section 6.4 of are not used. Implementations MUST conform to Section 6.4 of
[RFC8827]. [RFC8827].
6.2. Text-Based Communication 6.2. Text-Based Communication
Implementations MUST support real-time text ([RFC4102] and [RFC4103]) Implementations MUST support real-time text ([RFC4102] 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. Note transmitted and supported, with a 300 ms transmission interval.
that this is not how real time text is transmitted in WebRTC and some Implementations MUST support [RFC8865] especially for emergency
form of transcoder would be required to interwork real time text in calls. Note that RFC4103 is not how real-time text is transmitted in
the data channel of WebRTC to RFC4103 real time text. WebRTC and some form of transcoder would be required to interwork
real-time text in the data channel of WebRTC to RFC4103 real-time
text.
Transport of T.140 real-time text in WebRTC is specified in
[RFC8865], using the WebRTC data chanel. RFC 8865 also has some
advice on how gateways between RFC 4103 and RFC 8865 should operate.
It is RECOMMENDED that RFC 8865 is used for communication with
browser-based WebRTC implementations. Implementations MUST support
[RFC9071].
6.3. Video 6.3. Video
Implementations MUST conform to [RFC7742] with the exception that, Implementations MUST conform to [RFC7742] with following exceptions:
since backwards compatibility is desirable and older devices do not only H.264, as specified in [RFC7742], is Mandatory to Implement, and
support VP8, that only H.264, as specified in [RFC7742] is Mandatory VP8 support is OPTIONAL at both the device and providers. This is
to Implement and VP8 support is OPTIONAL at both the device and because backwards compatibility is desirable, and older devices do
providers. not support VP8.
6.4. Audio 6.4. Audio
Implementations MUST conform to [RFC7874]. Implementations MUST conform to [RFC7874].
6.5. DTMF Digits 6.5. DTMF Digits
Implementations MUST support the "audio/telephone-event" [RFC4733] Implementations MUST support the "audio/telephone-event" [RFC4733]
media type. They MUST support conveying event codes 0 through 11 media type. They MUST support conveying event codes 0 through 11
(DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733].
Handling of other tones is OPTIONAL. Handling of other tones is OPTIONAL.
6.6. Session Description Protocol 6.6. Session Description Protocol
The SDP offers and answers MUST conform to the SDP rules in [RFC8829] The SDP offers and answers MUST conform to the SDP rules in [RFC8829]
except that the RUE Interface uses SIP transport for SDP and the SDP except that the RUE interface uses SIP transport for SDP. The SDP
for real time text MUST specify [RFC4103]. for real-time text MUST specify the T.140 payload type [RFC4103].
6.7. Privacy 6.7. Privacy
The RUE MUST be able to control privacy of the user by implementing a The RUE MUST provide for user privacy by implementing a local one-way
one-way mute of audio and or video, without signaling, locally, but mute, without signaling, for both audio and video. However, RUE MUST
MUST maintain any NAT bindings by periodically sending media packets maintain any NAT bindings by periodically sending media packets on
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. NACK SHOULD be used when negotiated and conditions warrant its use.
Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be
preferred, as described in [RFC5104]. preferred, as described in [RFC5104].
FIR SHOULD be used only in situations where not sending a decoder FIR SHOULD be used only in situations where not sending a decoder
skipping to change at page 14, line 33 skipping to change at page 15, line 46
For backwards compatibility with calling devices that do not support For backwards compatibility with calling devices that do not support
the foregoing methods, implementations MUST implement SIP INFO the foregoing methods, implementations MUST implement SIP INFO
messages to send and receive XML encoded Picture Fast Update messages messages to send and receive XML encoded Picture Fast Update messages
according to [RFC5168]. according to [RFC5168].
7. Contacts 7. Contacts
7.1. CardDAV Login and Synchronization 7.1. CardDAV Login and Synchronization
Support of CardDAV by Providers is OPTIONAL. Support of CardDAV by providers is OPTIONAL.
The RUE MUST and Providers MAY be able to synchronize the user's The RUE MUST and providers MAY be able to synchronize the user's
contact directory between the RUE endpoint and one maintained by the contact directory between the RUE endpoint and one maintained by the
user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). user's VRS provider using CardDAV ([RFC6352] and [RFC6764]).
The configuration MAY supply a username and domain identifying a The configuration MAY supply a username and domain identifying a
CardDAV server and address book for this account. CardDAV server and address book for this account.
To access the CardDAV server and address book, the RUE MUST follow To access the CardDAV server and address book, the RUE MUST follow
Section 6 of RFC6764, using the chosen username and domain in place Section 6 of RFC6764, using the chosen username and domain in place
of an email address. If the request triggers a challenge for digest of an email address. If the request triggers a challenge for digest
authentication credentials, the RUE MUST attempt to continue using authentication credentials, the RUE MUST continue using matching
matching "credentials" from the configuration. If no matching "credentials" from the configuration. If no matching credentials are
credentials are configured, the RUE MUST use the SIP credentials from configured, the RUE MUST use the SIP credentials from the
the configuration. If the SIP credentials fail, the RUE MUST query configuration. If the SIP credentials fail, the RUE MUST query the
the user. user.
Synchronization using CardDAV MUST be a two-way synchronization Synchronization using CardDAV MUST be a two-way synchronization
service, with proper handling of asynchronous adds, changes, and service, with proper handling of asynchronous adds, changes, and
deletes at either end of the transport channel. deletes at either end of the transport channel.
7.2. Contacts Import/Export Service 7.2. Contacts Import/Export Service
Implementations MUST be able to export/import the list of contacts in Implementations MUST be able to export/import the list of contacts in
jCard [RFC6351] json format. xCard [RFC6351] xml format.
The RUE accesses this service via the "contacts" URI in the The RUE accesses this service via the "contacts" URI in the
configuration. The URL MUST resolve to identify a web server configuration. The URL MUST resolve to identify a web server
resource that imports/exports contact lists for authorized users. resource that imports/exports contact lists for authorized users.
The RUE stores/retrieves the contact list (address book) by issuing The RUE stores/retrieves the contact list (address book) by issuing
an HTTPS POST or GET request. If the request triggers a challenge an HTTPS POST or GET request. If the request triggers a challenge
for digest authentication credentials, the RUE MUST attempt to for digest authentication credentials, the RUE MUST attempt to
continue using 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. Mail Waiting Indicator (MWI) 8. Video Mail
Providers MUST support MWI if they support video mail. RUE devices Support for video mail includes a retrieval mechanism and a Message
MUST support MWI. Waiting Indicator (MWI). Message storage is NOT specified by this
document. RUE devices MUST support message retrieval using a SIP
call to a specified SIP URI using DTMF to manage the mailbox, as well
as a browser based interface reached at a specified HTTPS URI. If a
provider supports video mail at least one of these mechansism MUST be
supported. RUE devices MUST support both. See Section 9.2 for how
the URI to reach the retrieval interface is obtained.
Implementations MUST support subscriptions to "message-summary" Implementations MUST support subscriptions to "message-summary"
events [RFC3842] to the URI specified in the configuration. events [RFC3842] to the URI specified in the configuration.
Providers MUST support MWI if they support video mail. RUE devices
MUST support MWI.
In notification bodies, videomail messages SHOULD be reported using In notification bodies, videomail messages SHOULD be reported using
"message-context-class multimedia-message" defined in [RFC3458]. "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 that allows easy provider providers so that a user interface can allow easy provider selection
selection either for registering or for dial-around. The other either for registering or for dial-around. The other provides
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 a URI. The URI, when used with the
following interface, returns a list of provider names for a country following interface, returns a list of provider names for a country
code suitable for display, with a corresponding a URI to obtain code suitable for display, with a corresponding a URI to obtain
information about that provider. The provider URI is the entry point information about that provider. The provider URI is the entry point
skipping to change at page 16, line 31 skipping to change at page 17, line 42
provide the list, or a user group. provide the list, or a user group.
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 and 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
non-mandatory-to use functions and SHALL NOT delete any objects, non-mandatory-to use functions and SHALL NOT delete any objects,
members of objects or functions. This means an implementation of a members of objects or functions. This means an implementation of a
specific major version and minor version is backwards compatible with specific major version and minor version is backwards compatible with
all minor versions of the major version. The versions mechanism all minor versions of the major version. The versions mechanism
returns an array of supported versions, one for each major version returns an array of supported versions, one for each major version
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 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 * domain: The domain parameter is used for configuration purposes by
the RUE (as discussed in Section 9.2) the RUE (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", "domain": "red.example.net"
}, },
{ {
"name": "Green", "name": "Green",
"domain": "green.example.net", "domain": "green.example.net"
}, },
{ {
"name": "Blue", "name": "Blue",
"domain": "blue.example.net" "domain": "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,
"minor": 6, "minor": 6
}, },
{ {
"major": 2, "major": 2,
"minor": 13, "minor": 13
}, },
{ {
"major": 3, "major": 3,
"minor": 2 "minor": 2
} }
] ]
} }
Figure 3: Example of a Version JSON object Figure 3: Example of a Version JSON object
9.2. 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, the response includes configuration data for new user credentials or parameters, the response includes configuration
user sign up and dial around. The other uses the userid/password to data for new user sign up and dial around. The other uses the
authenticate to the interface and returns configuration data for the userid/password to authenticate to the interface and returns
RUE. configuration data for the RUE.
An optional parameter may be provided to the interface which is an In both the queries, an optional parameter may be provided to the
API Key. The implementation MAY have an API Key obtained from the interface which is an API Key. The implementation MAY have an API
provider and specific to the implementation. The method the API Key Key obtained from the provider and specific to the implementation.
is obtained is not specified in this document. The provider MAY The method the API Key is obtained is not specified in this document.
refuse to provide service to an implementation presenting an API Key The provider MAY refuse to provide service to an implementation
it does not recognize. presenting an API Key it does not recognize.
A required parameter which contains an instance identifier. This Also in both queries, the RUE device provides a required parameter
parameter MUST be the same value each time this instance (same which contains an instance identifier. This parameter MUST be the
implementation on same device) queries the interface. This may be same value each time this instance (same implementation on same
used by the provider, for example, to associate a location with the device) queries the interface. This MAY be used by the provider, for
instance for emergency calls. example, to associate a location with the instance for emergency
calls.
The data returned is a json object consisting of an array of key/ The data returned is a json object consisting of an array of key/
value configuration parameters to be used by the RUE. value configuration parameters to be used by the RUE.
The configuration API also provides the same version mechanism as The configuration API also provides the same version mechanism as
specified above in Section 9.1. The version of the configuration specified above in Section 9.1. The version of the configuration
service MAY be different than the version of the provider list service MAY be different than the version of the provider list
service. service.
The configuration data payload includes the following data items. The configuration data payload includes the following data items.
Items not noted as (OPTIONAL) are REQUIRED. If other unexpected Items not noted as (OPTIONAL) are REQUIRED. If other unexpected
items are found, they MUST be ignored. items are found, they MUST be ignored.
9.2.1. Provider Configuration 9.2.1. Provider Configuration
* signup: (OPTIONAL) an array of json objects consisting of: * signup: (OPTIONAL) an array of json objects consisting of:
- language: entry from the IANA language subtag registry - language: entry from the IANA language subtag registry.
Normally, this would be a written language tag.
- uri: a URI to the website for creating a new account in the - uri: a URI to the website for creating a new account in the
supported language. The new user signup URI may only initiate supported language. The new user signup URI may only initiate
creation of a new account. Various vetting, approval and other creation of a new account. Various vetting, approval and other
processes may be needed, which could take time, before the processes may be needed, which could take time, before the
account is established. The result of creating a new account account is established. The result of creating a new account
would be a username and password, which would be manually would be a username and password, which would be manually
entered into the RUE device to allow connection to the entered into the RUE device to allow connection to the
Provider. provider.
* dialAround: an array of json objects consisting of: * dialAround: an array of json objects consisting of:
- language: entry from the IANA language subtag registry - language: entry from the IANA language subtag registry.
Normally, this would be a sign language tag.
- frontDoor: a URI to a queue of interpreters supporting the - frontDoor: a URI to a queue of interpreters supporting the
specified language for a two stage dial-around specified language for a two-stage dial-around
- oneStage: a URI that can be used with a one-stage dial-around - oneStage: a URI that can be used with a one-stage dial-around
Section 5.2.2 using an interpreter supporting the specified Section 5.2.2 using an interpreter supporting the specified
language language
* helpDesk: (OPTIONAL) an array of json objets consisting of: * helpDesk: (OPTIONAL) an array of json objects consisting of:
- language: entry from the IANA language subtag registry - language: entry from the IANA language subtag registry.
Normally this would be a sign language tag, although it could
be a written language tag if the help desk only supports a chat
interface
- uri: URI that reaches a help desk for callers supporting the - uri: URI that reaches a help desk for callers supporting the
specified language. specified language. The URI MAY be a SIP URI for help provided
with a SIP call, or MAY be an HTTPS URI for help provided with
a browser interface.
A list is specified so that the provider can offer multiple
choices to users for language and interface styles.
9.2.2. RUE Configuration 9.2.2. RUE Configuration
* lifetime: Specifies how long (in seconds) the RUE MAY cache the * lifetime: (optional) Specifies how long (in seconds) the RUE MAY
configuration values. Values may not be valid when lifetime cache the configuration values. Values may not be valid when
expires. If the RUE caches configuration values, it MUST lifetime expires. If the RUE caches configuration values, it MUST
cryptographically protect them. The RUE SHOULD retrieve a fresh cryptographically protect them. The RUE SHOULD retrieve a fresh
copy of the configuration before the lifetime expires or as soon copy of the configuration before the lifetime expires or as soon
as possible after it expires. The lifetime is not guaranteed: the as possible after it expires. The lifetime is not guaranteed: the
configuration may change before the lifetime value expires. In configuration may change before the lifetime value expires. In
that case, the Provider MAY indicate this by generating that case, the Provider MAY indicate this by generating
authorization challenges to requests and/or prematurely authorization challenges to requests and/or prematurely
terminating a registration.Emergency Calls MUST continue to work. terminating a registration. Emergency Calls MUST continue to
work. If not specified, the RUE MUST fetch new configuration data
every time it starts.
* sip-password: (OPTIONAL) a password used for SIP, STUN and TURN * sip-password: (optional) a password used for SIP, STUN and TURN
authentication. The RUE device retains this data, which must be authentication. The RUE device retains this data, which must be
stored securely. If it is not supplied, but was supplied on a stored securely. If it is not supplied, but was supplied on a
prior invocation of this interface, the most recently supplied prior invocation of this interface, the most recently supplied
password MUST be used. If it was never supplied, the password password MUST be used. If it was never supplied, the password
used to authenticate to the configuration service is used for SIP, used to authenticate to the configuration service is used for SIP,
STUN and TURN. STUN and TURN.
* phone-number: (OPTIONAL) The telephone number (in E.164 format) * phone-number: The telephone number (in E.164 format) assigned to
assigned to this subscriber. This becomes the user portion of the this subscriber. This becomes the user portion of the SIP URI
SIP URI identifying the subscriber. identifying the subscriber.
* outbound-proxy: (OPTIONAL) A URI of a SIP proxy to be used when * outbound-proxy: (optional) A URI of a SIP proxy to be used when
sending requests to the Provider. sending requests to the provider.
* mwi: (OPTIONAL) A URI identifying a SIP event server that * mwi: (optional) A URI identifying a SIP event server that
generates "message-summary" events for this subscriber. generates "message-summary" events for this subscriber.
* videomail: (OPTIONAL) A SIP URI that can be called to retrieve * videomail: (optional) An SIP or HTTPS URI that can be called to
videomail messages. retrieve video mail messages.
* contacts: (CONDITIONAL) An HTTPS URI that may be used to export * contacts: (optional) An HTTPS URI that may be used to export
(retrieve) the subscriber's complete contact list managed by the (retrieve) the subscriber's complete contact list managed by the
Provider. provider. MUST be provided if the subscriber has contacts.
* carddav: (OPTIONAL) A username, password and domain name * carddav: (optional) A username, password and domain name
(separated by ""@"") identifying a "CardDAV" server that can be (separated by ""@"") identifying a "CardDAV" server and account
used to synchronize the RUE's contact list with the contact list that can be used to synchronize the RUE's contact list with the
managed by the Provider. Optionally contains a user name and/or contact list managed by the provider. If username or password are
password that may be used with the server. If username or not supplied, the main account credentials are used.
password are not supplied, the main account credentials are used.
* sendLocationWithRegistration: (OPTIONAL) True if the RUE should * sendLocationWithRegistration: (optional) True if the RUE should
send a Geolocation Header with REGISTER, false if it should not. send a Geolocation header field with REGISTER, false if it should
Defaults to false if not present. not. Defaults to false if not present.
* ice-servers: (OPTIONAL) An array of URLs identifying STUN and TURN * ice-servers: (optional) An array of URLs identifying STUN and TURN
servers available for use by the RUE for establishing media servers available for use by the RUE for establishing media
streams in calls via the Provider. streams in calls via the provider.
9.2.3. Examples 9.2.3. Examples
Example JSON provider configuration payload Example JSON provider configuration payload
{ {
"signUp": [ "signUp": [
{ "language" : "en", "uri" : "welcome-en.example.net"} , { "language" : "en", "uri" : "welcome-en.example.net"} ,
{ "language" : "es", "uri" : "welcome-es.example.net"} ] , { "language" : "es", "uri" : "welcome-es.example.net"} ] ,
"dialAround": [ "dialAround": [
{ "language" : "en", "frontDoor" : "fd-en.example.net", { "language" : "en", "frontDoor" : "fd-en.example.net",
"oneStage" : "1stg-eng.example.com" } , "oneStage" : "1stg-eng.example.com" } ,
{ "language" : "es", "frontDoor" : "fd-es.example.net", { "language" : "es", "frontDoor" : "fd-es.example.net",
"oneStage" : "1stg-spn.example.com" } ] , "oneStage" : "1stg-spn.example.com" } ] ,
"helpDesk": [ "helpDesk": [
{ "language" : "en", "uri" : "help-en.example.net"} , { "language" : "en", "uri" : "help-en.example.net"} ,
{ "language" : "es", "uri" : "help-es.example.net"} ] , { "language" : "es", "uri" : "help-es.example.net"} ]
}
Figure 4 Figure 4
Example JSON RUE configuration payload Example JSON RUE configuration payload
{ {
"lifetime": 86400, "lifetime": 86400,
"display-name" : "Bob Smith", "display-name" : "Bob Smith",
"phone-number": "+18135551212", "phone-number": "+18135551212",
"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:+18135551212@red.example.net", "mwi": "sip:+18135551212@red.example.net",
"videomail": "sip:+18135551212@vm.red.example.net", "videomail": "sip:+18135551212@vm.red.example.net",
"contacts": "https://red.example.net:443/contacts/1dess45awd", "contacts": "https://red.example.net:443/contacts/1dess45awd",
"carddav": "bob@red.example.com" , "carddav": "bob@red.example.com" ,
"sendLocationWithRegistration": false, "sendLocationWithRegistration": false,
"ice-servers": [ "ice-servers": [
{"stun":"stun.l.google.com:19302" }, {"stun":"stun.l.google.com:19302" },
{"turn":"turn.red.example.net:3478"} {"turn":"turn.red.example.net:3478"}
], ]
} }
Figure 5 Figure 5
9.2.4. Using the Provider Selection and RUE Configuration Services 9.2.4. Using the Provider Selection and RUE Configuration Services
Together Together
One way to use these two services is: One way to use these two services is:
* At startup, the RUE retrieves the provider list for the country it * At startup, the RUE retrieves the provider list for the country it
is located in. is located in.
skipping to change at page 21, line 46 skipping to change at page 23, line 25
- If the RUE does not have credentials for that provider, use the - If the RUE does not have credentials for that provider, use the
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 Sections Section 9.1 and Section 9.2 are formally The interfaces in Section 9.1 and Section 9.2 are formally specified
specified with OpenAPI 3.0 descriptions in yaml form. with OpenAPI 3.1 ([OpenApi]) descriptions in yaml form.
openapi: 3.0.1
info:
title: RUM API
version: "1.0"
servers:
- url: http://localhost/rum/v1
paths:
/Providers:
get:
summary: Get a list of providers and domains to get
config data from
operationId: GetProviderList
responses:
'200':
description: List of providers for a country
content:
application/json:
schema:
$ref: '#/components/schemas/ProviderList'
/ProviderConfig:
get:
summary: Configuration data for one provider
operationId: GetProviderConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: configuration object
content:
application/json:
schema:
$ref: '#/components/schemas/ProviderConfigurationData'
/RueConfig:
get:
summary: Configuration data for one RUE
operationId: GetRueConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: configuration object
content:
application/json:
schema:
$ref: '#/components/schemas/RueConfigurationData'
/Versions:
servers:
- url: https://api.example.com/rum
description: Override base path for Versions query
get:
summary: Retrieves all supported versions
operationId: RetrieveVersions
responses:
'200':
description: Versions supported
content:
application/json:
schema:
$ref: '#/components/schemas/VersionsArray'
components:
schemas:
ProviderList:
type: object
required:
- providers
properties:
providers:
type: array
items:
type: object
required:
- name
- domain
properties:
name:
type: string
description: Human readable provider name
domain:
type: string
description: provider domain for interface
VersionsArray:
type: object
required:
- versions
properties:
versions:
type: array
items:
type: object
required:
- major
- minor
properties:
major:
type: integer
format: int32
description: Version major number
minor:
type: integer
format: int32
description: Version minor number
ProviderConfigurationData:
type: object
properties:
signup:
type: object
required:
- language
- uri
properties:
language:
type: string
description: entry from IANA language-subtag-registry
uri:
type: string
format: uri
description: uri to signup website supporting language
dialAround:
type: object
required:
- language
- frontDoor
properties:
language:
type: string
description: entry from IANA language-subtag-registry
frontDoor:
type: string
format: uri
description: SIP uri for 2 stage dial around
oneStage:
type: string
format: uri
description: SIP uri for 1 stage dial around
helpDesk:
type: object
required:
- language
- uri
properties:
language:
type: string
description: entry from IANA language-subtag-registry
uri:
type: string
format: uri
description: SIP uri of helpdesk supporting language
RueConfigurationData:
type: object
properties:
lifetime:
type: integer
description: how long (in seconds) the RUE MAY cache the
configuration values
sip-password:
type: string
phone-number:
type: string
description: telephone number assigned this subscriber
outbound-proxy:
type: string
format: uri
description: SIP uri of proxy to be used when sending
requests to the Provider
mwi:
type: string
format: uri
description: A URI identifying a SIP event server that
generates "message-summary" events for this subscriber.
videomail:
type: string
format: uri
description: A SIP URI that can be called to retrieve
videomail messages.
contacts:
type: string
format: uri
description: An HTTPS URI that may be used to export
(retrieve) the subscriber's complete contact list
managed by the Provider.
carddav:
type: object
description: CardDAV server and user information that can be
used to synchronize the RUE's contact list with the
contact list managed by the Provider.
properties:
domain:
type: string
description: CardDAV server address
username:
type: string
description: username for authentication with CardDAV
server. Use provider username if not provided
password:
type: string
description: password for authentication to the CardDAV
server. Use provider password if not provided
sendLocationWithRegistration:
type: boolean
description: True if the RUE should send a Geolocation Header
with REGISTER, false if it should not.
Defaults to false if not present.
ice-servers:
type: array
items:
type: string
format: uri
description: URIs identifying STUN and TURN servers
available for use by the RUE for establishing
media streams in calls via the Provider.
Figure 6: Provider List OpenAPI description
10. Acknowledgements openapi: 3.0.1
info:
title: RUM API
version: "1.0"
servers:
- url: http://localhost/rum/v1
paths:
/Providers:
get:
summary: Get a list of providers and domains to get
config data from
operationId: GetProviderList
responses:
'200':
description: List of providers for a country
content:
application/json:
schema:
$ref: '#/components/schemas/ProviderList'
/ProviderConfig:
get:
summary: Configuration data for one provider
operationId: GetProviderConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: configuration object
content:
application/json:
schema:
$ref: '#/components/schemas/ProviderConfigurationData'
/RueConfig:
get:
summary: Configuration data for one RUE
operationId: GetRueConfiguration
parameters:
- in: query
name: apiKey
schema:
type: string
description: API Key assigned to this implementation
- in: query
name: instanceId
schema:
type: string
required: true
description: Unique string for this implementation
on this device
responses:
'200':
description: configuration object
content:
application/json:
schema:
$ref: '#/components/schemas/RueConfigurationData'
/Versions:
servers:
- url: https://api.example.com/rum
description: Override base path for Versions query
get:
summary: Retrieves all supported versions
operationId: RetrieveVersions
responses:
'200':
description: Versions supported
content:
application/json:
schema:
$ref: '#/components/schemas/VersionsArray'
components:
schemas:
ProviderList:
type: object
required:
- providers
properties:
providers:
type: array
items:
type: object
required:
- name
- domain
properties:
name:
type: string
description: Human readable provider name
domain:
type: string
description: provider domain for interface
VersionsArray:
type: object
required:
- versions
properties:
versions:
type: array
items:
type: object
required:
- major
- minor
properties:
major:
type: integer
format: int32
description: Version major number
minor:
type: integer
format: int32
description: Version minor number
ProviderConfigurationData:
type: object
properties:
signup:
type: object
required:
- language
- uri
properties:
language:
type: string
description: entry from IANA language-subtag-registry
uri:
type: string
format: uri
description: URI to signup website supporting language
dialAround:
type: object
required:
- language
- frontDoor
- oneStage
properties:
language:
type: string
description: entry from IANA language-subtag-registry
frontDoor:
type: string
format: uri
description: SIP URI for two-stage dial around
oneStage:
type: string
format: uri
description: SIP URI for one-stage dial around
helpDesk:
type: object
required:
- language
- uri
properties:
language:
type: string
description: entry from IANA language-subtag-registry
uri:
type: string
format: uri
description: SIP URI of helpdesk supporting language
RueConfigurationData:
type: object
required:
- phone-number
properties:
lifetime:
type: integer
description: how long (in seconds) the RUE MAY cache the
configuration values
sip-password:
type: string
phone-number:
type: string
description: telephone number assigned this subscriber
outbound-proxy:
type: string
format: uri
description: SIP URI of proxy to be used when sending
requests to the provider
mwi:
type: string
format: uri
description: A URI identifying a SIP event server that
generates "message-summary" events for this subscriber.
videomail:
type: string
format: uri
description: An HTTPS or SIP URI that can be called to
retrieve video mail messages.
contacts:
type: string
format: uri
description: An HTTPS URI that may be used to export
(retrieve) the subscriber's complete contact list
managed by the provider.
carddav:
type: object
description: CardDAV server and user information that can be
used to synchronize the RUE's contact list with the
contact list managed by the provider.
properties:
domain:
type: string
description: CardDAV server address
username:
type: string
description: username for authentication with CardDAV
server. Use provider username if not provided
password:
type: string
description: password for authentication to the CardDAV
server. Use provider password if not provided
sendLocationWithRegistration:
type: boolean
description: True if the RUE should send a Geolocation
header field with REGISTER, false if it should not.
Defaults to false if not present.
ice-servers:
type: array
items:
type: string
format: uri
description: URIs identifying STUN and TURN servers
available for use by the RUE for establishing
media streams in calls via the provider.
Brett Henderson and Jim Malloy provided many helpful edits to prior Figure 6: Provider List OpenAPI description
versions of this document.
11. IANA Considerations 10. IANA Considerations
11.1. RUE Provider List Registry 10.1. RUE Provider List Registry
IANA has created the "RUE Provider List" registry. The management IANA has created the "RUE Provider List" registry. The management
policy for this registry is "Expert Review" [RFC8126]. The expert policy for this registry is "Expert Review" [RFC8126]. The expert
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 be better than the existing the expert judges the new proposed URI to provide a more accurate
entry. Each entry has two fields, values for both of which MUST be list than the existing entry. Each entry has two fields, values for
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 uri: a URI that implements the provider list interface for
that country that country
11.2. Registration of rue-owner 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
12. Security Considerations 11. Security Considerations
The RUE is required to communicate with servers on public IP The RUE is required to communicate with servers on public IP
addresses and specific ports to perform its required functions. If addresses and specific ports to perform its required functions. If
it is necessary for the RUE to function on a corporate or other it is necessary for the RUE to function on a corporate or other
network that operates a default-deny firewall between the RUE and network that operates a default-deny firewall between the RUE and
these services, the user must arrange with their network manager for these services, the user must arrange with their network manager for
passage of traffic through such a firewall in accordance with the passage of traffic through such a firewall in accordance with the
protocols and associated SRV records as exposed by the Provider. protocols and associated SRV records as exposed by the provider.
Because VRS providers may use different ports for different services, Because VRS providers may use different ports for different services,
these port numbers may differ from Provider to Provider. these port numbers may differ from provider to provider.
13. 12.
Normative References Normative References
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc2392>.
[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>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
"Indicating User Agent Capabilities in the Session UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
Initiation Protocol (SIP)", RFC 3840, 2002, <https://www.rfc-editor.org/info/rfc3311>.
DOI 10.17487/RFC3840, August 2004,
<https://www.rfc-editor.org/info/rfc3840>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009,
<https://www.rfc-editor.org/info/rfc5626>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, Initiation Protocol (SIP)", RFC 3323,
DOI 10.17487/RFC3323, November 2002, DOI 10.17487/RFC3323, November 2002,
<https://www.rfc-editor.org/info/rfc3323>. <https://www.rfc-editor.org/info/rfc3323>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
in Session Description Protocol (SDP)", RFC 3605, Header Field for the Session Initiation Protocol (SIP)",
DOI 10.17487/RFC3605, October 2003, RFC 3326, DOI 10.17487/RFC3326, December 2002,
<https://www.rfc-editor.org/info/rfc3605>. <https://www.rfc-editor.org/info/rfc3326>.
[RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665,
DOI 10.17487/RFC6665, July 2012,
<https://www.rfc-editor.org/info/rfc6665>.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
2002, <https://www.rfc-editor.org/info/rfc3311>.
[RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B.
Campen, "Addressing an Amplification Vulnerability in
Session Initiation Protocol (SIP) Forking Proxies",
RFC 5393, DOI 10.17487/RFC5393, December 2008,
<https://www.rfc-editor.org/info/rfc5393>.
[RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing
Record-Route Issues in the Session Initiation Protocol
(SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009,
<https://www.rfc-editor.org/info/rfc5658>.
[RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed.,
"Essential Correction for IPv6 ABNF and URI Comparison in
RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010,
<https://www.rfc-editor.org/info/rfc5954>.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
Tone Generation in the Session Initiation Protocol (SIP)",
RFC 3960, DOI 10.17487/RFC3960, December 2004,
<https://www.rfc-editor.org/info/rfc3960>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442,
DOI 10.17487/RFC6442, December 2011,
<https://www.rfc-editor.org/info/rfc6442>.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent (SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002,
<https://www.rfc-editor.org/info/rfc3327>. <https://www.rfc-editor.org/info/rfc3327>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
(ICE): A Protocol for Network Address Translator (NAT) Context for Internet Mail", RFC 3458,
Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC3458, January 2003,
DOI 10.17487/RFC5245, April 2010, <https://www.rfc-editor.org/info/rfc3458>.
<https://www.rfc-editor.org/info/rfc5245>.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, DOI 10.17487/RFC3326, December 2002,
<https://www.rfc-editor.org/info/rfc3326>.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, Method", RFC 3515, DOI 10.17487/RFC3515, April 2003,
<https://www.rfc-editor.org/info/rfc3515>. <https://www.rfc-editor.org/info/rfc3515>.
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
(SIP) REFER Method Implicit Subscription", RFC 4488, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC4488, May 2006, DOI 10.17487/RFC3605, October 2003,
<https://www.rfc-editor.org/info/rfc4488>. <https://www.rfc-editor.org/info/rfc3605>.
[RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, "Indicating User Agent Capabilities in the Session
September 2015, <https://www.rfc-editor.org/info/rfc7647>. Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004,
<https://www.rfc-editor.org/info/rfc3840>.
[RFC3842] Mahy, R., "A Message Summary and Message Waiting
Indication Event Package for the Session Initiation
Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August
2004, <https://www.rfc-editor.org/info/rfc3842>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, Protocol (SIP) "Replaces" Header", RFC 3891,
DOI 10.17487/RFC3891, September 2004, DOI 10.17487/RFC3891, September 2004,
<https://www.rfc-editor.org/info/rfc3891>. <https://www.rfc-editor.org/info/rfc3891>.
[RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP)
Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892,
September 2004, <https://www.rfc-editor.org/info/rfc3892>. September 2004, <https://www.rfc-editor.org/info/rfc3892>.
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
K. Summers, "Session Initiation Protocol (SIP) Basic Call Tone Generation in the Session Initiation Protocol (SIP)",
Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, RFC 3960, DOI 10.17487/RFC3960, December 2004,
December 2003, <https://www.rfc-editor.org/info/rfc3665>. <https://www.rfc-editor.org/info/rfc3960>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004, RFC 3966, DOI 10.17487/RFC3966, December 2004,
<https://www.rfc-editor.org/info/rfc3966>. <https://www.rfc-editor.org/info/rfc3966>.
[RFC4967] Rosen, B., "Dial String Parameter for the Session
Initiation Protocol Uniform Resource Identifier",
RFC 4967, DOI 10.17487/RFC4967, July 2007,
<https://www.rfc-editor.org/info/rfc4967>.
[RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type",
RFC 4102, DOI 10.17487/RFC4102, June 2005, RFC 4102, DOI 10.17487/RFC4102, June 2005,
<https://www.rfc-editor.org/info/rfc4102>. <https://www.rfc-editor.org/info/rfc4102>.
[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
(SIP) REFER Method Implicit Subscription", RFC 4488,
DOI 10.17487/RFC4488, May 2006,
<https://www.rfc-editor.org/info/rfc4488>.
[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>.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC4967] Rosen, B., "Dial String Parameter for the Session
Keeping Alive the NAT Mappings Associated with RTP / RTP Initiation Protocol Uniform Resource Identifier",
Control Protocol (RTCP) Flows", RFC 6263, RFC 4967, DOI 10.17487/RFC4967, July 2007,
DOI 10.17487/RFC6263, June 2011, <https://www.rfc-editor.org/info/rfc4967>.
<https://www.rfc-editor.org/info/rfc6263>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <https://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for
Media Control", RFC 5168, DOI 10.17487/RFC5168, March Media Control", RFC 5168, DOI 10.17487/RFC5168, March
2008, <https://www.rfc-editor.org/info/rfc5168>. 2008, <https://www.rfc-editor.org/info/rfc5168>.
[RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B.
Campen, "Addressing an Amplification Vulnerability in
Session Initiation Protocol (SIP) Forking Proxies",
RFC 5393, DOI 10.17487/RFC5393, December 2008,
<https://www.rfc-editor.org/info/rfc5393>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009,
<https://www.rfc-editor.org/info/rfc5626>.
[RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing
Record-Route Issues in the Session Initiation Protocol
(SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009,
<https://www.rfc-editor.org/info/rfc5658>.
[RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed.,
"Essential Correction for IPv6 ABNF and URI Comparison in
RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010,
<https://www.rfc-editor.org/info/rfc5954>.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263,
DOI 10.17487/RFC6263, June 2011,
<https://www.rfc-editor.org/info/rfc6263>.
[RFC6351] Perreault, S., "xCard: vCard XML Representation",
RFC 6351, DOI 10.17487/RFC6351, August 2011,
<https://www.rfc-editor.org/info/rfc6351>.
[RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed
Authoring and Versioning (WebDAV)", RFC 6352, Authoring and Versioning (WebDAV)", RFC 6352,
DOI 10.17487/RFC6352, August 2011, DOI 10.17487/RFC6352, August 2011,
<https://www.rfc-editor.org/info/rfc6352>. <https://www.rfc-editor.org/info/rfc6352>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442,
DOI 10.17487/RFC6442, December 2011,
<https://www.rfc-editor.org/info/rfc6442>.
[RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665,
DOI 10.17487/RFC6665, July 2012,
<https://www.rfc-editor.org/info/rfc6665>.
[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>.
[RFC3842] Mahy, R., "A Message Summary and Message Waiting [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Indication Event Package for the Session Initiation Communications Services in Support of Emergency Calling",
Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
2004, <https://www.rfc-editor.org/info/rfc3842>. <https://www.rfc-editor.org/info/rfc6881>.
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458,
DOI 10.17487/RFC3458, January 2003,
<https://www.rfc-editor.org/info/rfc3458>.
[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>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for [RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of
Communications Services in Support of Emergency Calling", REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647,
BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, September 2015, <https://www.rfc-editor.org/info/rfc7647>.
<https://www.rfc-editor.org/info/rfc6881>.
[RFC7742] Roach, A.B., "WebRTC Video Processing and Codec
Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016,
<https://www.rfc-editor.org/info/rfc7742>.
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
J. Winterbottom, "Additional Data Related to an Emergency J. Winterbottom, "Additional Data Related to an Emergency
Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
<https://www.rfc-editor.org/info/rfc7852>. <https://www.rfc-editor.org/info/rfc7852>.
[RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016,
<https://www.rfc-editor.org/info/rfc7874>. <https://www.rfc-editor.org/info/rfc7874>.
[RFC7742] Roach, A.B., "WebRTC Video Processing and Codec [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
<https://www.rfc-editor.org/info/rfc7742>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC6351] Perreault, S., "xCard: vCard XML Representation", [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
RFC 6351, DOI 10.17487/RFC6351, August 2011, Connectivity Establishment (ICE): A Protocol for Network
<https://www.rfc-editor.org/info/rfc6351>. Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Writing an IANA Considerations Section in RFCs", BCP 26, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8446>.
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8599] Holmberg, C. and M. Arnold, "Push Notification with the
Session Initiation Protocol (SIP)", RFC 8599,
DOI 10.17487/RFC8599, May 2019,
<https://www.rfc-editor.org/info/rfc8599>.
[RFC8760] Shekh-Yusef, R., "The Session Initiation Protocol (SIP)
Digest Access Authentication Scheme", RFC 8760,
DOI 10.17487/RFC8760, March 2020,
<https://www.rfc-editor.org/info/rfc8760>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825, Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, January 2021, DOI 10.17487/RFC8825, January 2021,
<https://www.rfc-editor.org/info/rfc8825>. <https://www.rfc-editor.org/info/rfc8825>.
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
DOI 10.17487/RFC8827, January 2021, DOI 10.17487/RFC8827, January 2021,
<https://www.rfc-editor.org/info/rfc8827>. <https://www.rfc-editor.org/info/rfc8827>.
skipping to change at page 33, line 18 skipping to change at page 34, line 37
<https://www.rfc-editor.org/info/rfc8829>. <https://www.rfc-editor.org/info/rfc8829>.
[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
January 2021, <https://www.rfc-editor.org/info/rfc8834>. January 2021, <https://www.rfc-editor.org/info/rfc8834>.
[RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, [RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835,
DOI 10.17487/RFC8835, January 2021, DOI 10.17487/RFC8835, January 2021,
<https://www.rfc-editor.org/info/rfc8835>. <https://www.rfc-editor.org/info/rfc8835>.
[RFC8760] Shekh-Yusef, R., "The Session Initiation Protocol (SIP) [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen,
Digest Access Authentication Scheme", RFC 8760, A., and R. Shpount, "Session Description Protocol (SDP)
DOI 10.17487/RFC8760, March 2020, Offer/Answer Procedures for Interactive Connectivity
<https://www.rfc-editor.org/info/rfc8760>. Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839,
January 2021, <https://www.rfc-editor.org/info/rfc8839>.
[RFC8599] Holmberg, C. and M. Arnold, "Push Notification with the [RFC8865] Holmberg, C. and G. Hellström, "T.140 Real-Time Text
Session Initiation Protocol (SIP)", RFC 8599, Conversation over WebRTC Data Channels", RFC 8865,
DOI 10.17487/RFC8599, May 2019, DOI 10.17487/RFC8865, January 2021,
<https://www.rfc-editor.org/info/rfc8599>. <https://www.rfc-editor.org/info/rfc8865>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>.
[RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real-
Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021,
<https://www.rfc-editor.org/info/rfc9071>.
13.
Informative References
[OpenApi] Miller, D., Whitlock, J., Gardiner, M., Ralpson, M.,
Ratovsky, R., and U. Sarid, "OpenAPI Specification
v3.1.0", February 2021,
<https://spec.openapis.org/oas/v3.1.0>.
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
K. Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665,
December 2003, <https://www.rfc-editor.org/info/rfc3665>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgements
Brett Henderson and Jim Malloy provided many helpful edits to prior
versions of this document.
Author's Address Author's Address
Brian Rosen Brian Rosen
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
United States of America United States of America
Phone: +1 724 382 1051 Phone: +1 724 382 1051
Email: br@brianrosen.net Email: br@brianrosen.net
 End of changes. 128 change blocks. 
614 lines changed or deleted 711 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/