draft-ietf-rum-rue-05.txt   draft-ietf-rum-rue-06.txt 
rum B. Rosen rum B. Rosen
Internet-Draft 14 June 2021 Internet-Draft 29 July 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 16 December 2021 Expires: 30 January 2022
Interoperability Profile for Relay User Equipment Interoperability Profile for Relay User Equipment
draft-ietf-rum-rue-05 draft-ietf-rum-rue-06
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 persons can communicate with deaf/Hard of Hearing
user using an interpreter ("Communications Assistant") connected via user using an interpreter ("Communications Assistant") connected via
a videophone to the deaf/HoH user and an audio telephone call to the a videophone to the deaf/HoH user and an audio telephone call to the
hearing user. The CA interprets using sign language on the hearing user. The CA interprets using sign language on the
videophone link and voice on the telephone link. Often the videophone link and voice on the telephone link. Often the
interpreters may be supplied by a company or agency termed a interpreters may be supplied by a company or agency termed a
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 16 December 2021. This Internet-Draft will expire on 30 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . . . . 5
4. General Requirements . . . . . . . . . . . . . . . . . . . . 6 4. General Requirements . . . . . . . . . . . . . . . . . . . . 6
5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Session Establishment . . . . . . . . . . . . . . . . . . 8 5.2. Session Establishment . . . . . . . . . . . . . . . . . . 8
5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 8 5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 8
5.2.2. One-Stage Dial-Around Origination . . . . . . . . . . 9 5.2.2. Dial-Around Origination . . . . . . . . . . . . . . . 9
5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 10 5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 10
5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10 5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10
5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 11 5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 11
5.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 11 5.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 11
5.4. URI Representation of Phone Numbers . . . . . . . . . . . 12 5.4. URI Representation of Phone Numbers . . . . . . . . . . . 12
5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 13 6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 13
6.2. Text-Based Communication . . . . . . . . . . . . . . . . 13 6.2. Text-Based Communication . . . . . . . . . . . . . . . . 13
6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 2, line 46 skipping to change at page 2, line 46
6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 13
6.6. Session Description Protocol . . . . . . . . . . . . . . 13 6.6. Session Description Protocol . . . . . . . . . . . . . . 13
6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . 14
7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 14 7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 14
7.2. Contacts Import/Export Service . . . . . . . . . . . . . 15 7.2. Contacts Import/Export Service . . . . . . . . . . . . . 15
8. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 15 8. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 15
9. Provisioning and Provider Selection . . . . . . . . . . . . . 15 9. Provisioning and Provider Selection . . . . . . . . . . . . . 15
9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 15 9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 16
9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 17 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 18
9.3. Using the Provider List and Configuration Services 9.2.1. Provider Configuration . . . . . . . . . . . . . . . 18
Together . . . . . . . . . . . . . . . . . . . . . . . . 21 9.2.2. RUE Configuration . . . . . . . . . . . . . . . . . . 19
9.4. OpenAPI Interface Descriptions . . . . . . . . . . . . . 21 9.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 20
9.2.4. Using the Provider Selection and RUE Configuration
Services Together . . . . . . . . . . . . . . . . . . 21
9.3. OpenAPI Interface Descriptions . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11.1. RUE Provider List Registry . . . . . . . . . . . . . . . 27 11.1. RUE Provider List Registry . . . . . . . . . . . . . . . 27
11.2. Registration of rue-owner purpose parameter . . . . . . 27 11.2. Registration of rue-owner purpose parameter . . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27
13. Normative References . . . . . . . . . . . . . . . . . . . . 27 13. Normative References . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
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
skipping to change at page 3, line 32 skipping to change at page 3, line 36
protocols that enables end-user equipment registration and calling protocols that enables end-user equipment registration and calling
for VRS calls. It specifies the minimal set of call flows, Internet for VRS calls. It specifies the minimal set of call flows, Internet
Engineering Task Force (IETF) and ITU-T standards that must be Engineering Task Force (IETF) and ITU-T standards that must be
supported, provides guidance where the standards leave multiple supported, provides guidance where the standards leave multiple
implementation options, and specifies minimal and extended implementation options, and specifies minimal and extended
capabilities for RUE calls. capabilities for RUE calls.
Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/ Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/
HoH calls are supported on this interface. While there are some HoH calls are supported on this interface. While there are some
accommodations in this document to maximize backwards compatibility accommodations in this document to maximize backwards compatibility
with devices and services that conform to this document, backwards with other devices and services that are used to provide VRS service,
compatibility is not a requirement, and some interwork may be backwards compatibility is not a requirement, and some interwork may
required to allow direct video calls to older devices. This document be required to allow direct video calls to older devices. This
only describes the interface between the device and the provider, and document only describes the interface between the device and the
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
skipping to change at page 4, line 15 skipping to change at page 4, line 23
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.
Dial-around call: A relay call where the subscriber specifies the use Outbound Dial-around call: A relay call where the subscriber
of a VRS provider other than the default VRS provider. This can be specifies the use of a VRS provider other than the default VRS
accomplished by the user dialing a "front-door" number for a VRS provider. This can be accomplished by the user dialing a "front-
provider and signing or texting a phone number to call ("two-stage"). door" number for a VRS provider and signing or texting a phone number
Alternatively, this can be accomplished by the user's RUE software to call ("two-stage"). Alternatively, this can be accomplished by
instructing the server of its default VRS provider to automatically the user's RUE software instructing the server of its default VRS
route the call through the alternate Provider to the desired public provider to automatically route the call through the alternate
switched telephone network (PSTN) directory number ("one-stage"). Provider to the desired public switched telephone network (PSTN)
Dial-around is per-call -- for any call, a user can use the default directory number ("one-stage"). Dial-around is per-call -- for any
VRS provider or any dial-around VRS provider. call, a user can use the default VRS provider or any dial-around VRS
provider.
Full Intra Request (FIR): A request to a video media sender, Full Intra Request (FIR): 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". Point-to-Point Call (P2P Call): A call between two
RUEs, without including a CA. 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. Please refer to FCC-VRS-GUIDE.
Relay-to-relay call: A call between two subscribers each using
different forms of relay (video relay, IP relay, TTY), each with a
separate CA to assist in relaying the conversation.
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.
skipping to change at page 5, line 17 skipping to change at page 5, line 20
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
features to support a subscriber in requesting and using relay calls. features to support a subscriber in requesting, receiving and using
A RUE may take many forms, including a stand-alone device; an relay calls. A RUE may take many forms, including a stand-alone
application running on a general-purpose computing device such as a device; an application running on a general-purpose computing device
laptop, tablet or smart phone; or proprietary equipment connected to such as a laptop, tablet or smart phone; or proprietary equipment
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
skipping to change at page 6, line 18 skipping to change at page 6, line 18
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. each server DNS record but not both. The same version of IP MUST be
used for both signaling and media of a call.
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 [RFC3261] (Base SIP) [RFC3263] (Locating SIP
Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent
Capabilities), [RFC5626] (Outbound), [RFC8866] (Session Description Capabilities), [RFC5626] (Outbound), [RFC8866] (Session Description
Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP), Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP),
[RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop- [RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop-
Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960] Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960]
(Early Media), and [RFC6442] (Geolocation Header). (Early Media), and [RFC6442] (Geolocation Header).
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 Section 8), which is optional and providers not supporting
MWI need not support RFC6665. voicemail need not support RFC6665.
In addition, implementation MUST conform to [RFC3327] (Path), In addition, implementation MUST conform to [RFC3327] (Path),
[RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER Method), [RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER Method),
[RFC3891] (Replaces Header), [RFC3892] (Referred-By). [RFC3891] (Replaces Header), [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
(please refer to Section 11) contains multiple "outbound-proxies", (see Section 9.2) contains multiple "outbound-proxies", then the RUE
then the RUE MUST use them as specified in [RFC5626] to establish MUST use them as specified in [RFC5626] to establish multiple flows.
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 13, 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
skipping to change at page 7, line 52 skipping to change at page 8, line 5
by all implementations and SHA-512 digest algorithms MUST be by all implementations and SHA-512 digest algorithms MUST be
supported. supported.
If the registration request fails with an indication that credentials If the registration request fails with an indication that credentials
from the configuration are invalid, then the RUE SHOULD retrieve a from the configuration are invalid, then the RUE SHOULD retrieve a
fresh version of the configuration. If credentials from a freshly fresh version of the configuration. If credentials from a freshly
retrieved configuration are found to be invalid, then the RUE MUST retrieved configuration are found to be invalid, then the RUE MUST
cease attempts to register and SHOULD inform the RUE User of the cease attempts to register and SHOULD inform the RUE User of the
problem. problem.
Support for multiple simultaneous registrations is OPTIONAL. Support for multiple simultaneous registrations with multiple
providers by the RUE is OPTIONAL for the RUE (and providers do not
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
skipping to change at page 8, line 30 skipping to change at page 8, line 34
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. The domain field of the URIs SHOULD be the "provider-domain" number, or as SIP URIs, as provided in the configuration
from the configuration (e.g., (Section 9.2. The domain field of the URIs SHOULD be the "provider-
sip:+13115552368@red.example.com;user=phone). The same exceptions domain" from the configuration (e.g.,
apply, including anonymous calls. sip:+13115552368@red.example.com;user=phone) except that an anonymous
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.
(Please refer to Section 9.2.) (Please refer to Section 9.2.)
Negotiated media MUST follow the guidelines specified in Section 6 of Negotiated media MUST follow the guidelines specified in Section 6 of
this document. this document.
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. One-Stage Dial-Around Origination 5.2.2. Dial-Around Origination
Providers and RUE devices MUST support both One-Stage and Two-Stage
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
URI of the dial-around Provider and the domain of the URI is the front door URI (see Section Section 9.2 of the dial-around Provider
Provider domain from the configuration. and the domain of the URI is the Provider domain from the
configuration. The provider list service (Section 9.1) can be used
to by the RUE to obtain a list of providers and then the
configuration service (xref target="providerConfig"/>) without
credentials can be used to find the front door URI for each of these
providers.
One-stage dial-around is a method where the called party telephone One-stage dial-around is a method where the called party 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.
skipping to change at page 10, line 20 skipping to change at page 10, line 20
|-------------->| [2] INVITE | |-------------->| [2] INVITE |
| |-------------->| | |-------------->|
Message Details: Message Details:
[1] INVITE Rue -> Default Provider [1] INVITE Rue -> Default Provider
INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
To: <sip:+15551234567@green.example.net;user=phone> To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" <sip:+18135551212@red.example.net;user=phone> From: "Bob Smith" <sip:+18135551212@red.example.net;user=phone>
Route: sip:green.example.net
[2] INVITE Default Provider -> Dial-Around Provider [2] INVITE Default Provider -> Dial-Around Provider
INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
To: <sip:+15551234567@green.example.net;user=phone> To: <sip:+15551234567@green.example.net;user=phone>
From: "Bob Smith" sip:+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
skipping to change at page 12, line 9 skipping to change at page 12, line 9
devices that do not support RTCP mechanisms (please refer to devices that do not support RTCP mechanisms (please refer to
Section 6.8). Implementations MUST support an in-dialog REFER Section 6.8). Implementations MUST support an in-dialog REFER
([RFC3515] updated by [RFC7647] and including support for norefersub ([RFC3515] updated by [RFC7647] and including support for norefersub
per [RFC4488]) with the Replaces header [RFC3891] to enable call per [RFC4488]) with the Replaces header [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. whether they can be represented as an E.164 number. In this section
"expressed as an E.164 number" includes numbers such as toll free
numbers that are not actually E.164 numbers, but have the same
format.
A dial string that can be written as an E.164 formatted phone number A dial string that can be expressed as an E.164 phone number MUST be
MUST be represented as a SIP URI with a URI ";user=phone" tag. The represented as a SIP URI with a URI ";user=phone" tag. The user part
user part of the URI MUST be in conformance with 'global-number' of the URI MUST be in conformance with 'global-number' defined in
defined in [RFC3966]. The user part MUST NOT contain any 'visual- [RFC3966]. The user part MUST NOT contain any 'visual-separator'
separator' characters. characters.
Dial strings that cannot be written 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 that that this
skipping to change at page 13, line 44 skipping to change at page 13, line 47
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 [RFC8829] except that the The SDP offers and answers MUST conform to the SDP rules in [RFC8829]
RUE Interface uses SIP transport for SDP. except that the RUE Interface uses SIP transport for SDP and the SDP
for real time text MUST specify [RFC4103].
note: parts of 8829 are not applicable. Need text to handle that,
and possibly require conformance to 8866/3264
6.7. Privacy 6.7. Privacy
The RUE MUST be able to control privacy of the user by implementing a The RUE MUST be able to control privacy of the user by implementing a
one-way mute of audio and or video, without signaling, locally, but one-way mute of audio and or video, without signaling, locally, but
MUST maintain any NAT bindings by periodically sending media packets MUST maintain any NAT bindings by periodically sending media packets
on all active media sessions containing silence/comfort noise/black on 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
skipping to change at page 15, line 26 skipping to change at page 15, line 26
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. Mail Waiting Indicator (MWI)
Support of MWI by Providers is OPTIONAL Providers MUST support MWI if they support video mail. RUE devices
MUST support MWI.
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.
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 that allows easy provider
selection either for registering or for dial-around. The other selection either for registering or for dial-around. The other
provides configuration data for the device for each provider. provides 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 obtain, on To allow the user to select a relay service, the RUE MAY at any time
startup, a list of Providers that provide service in a country. IANA obtain (typically on startup) a list of Providers that provide
has established a registry that contains a two letter country code service in a country. IANA has established a registry that contains
and a URI. The URI, when used with the following interface, returns a two letter country code and a URI. The URI, when used with the
a list of provider names for a country code suitable for display, following interface, returns a list of provider names for a country
with a corresponding a URI to obtain information about that provider. code suitable for display, with a corresponding a URI to obtain
The provider URI is the entry point of a simple web service that information about that provider. The provider URI is the entry point
returns contact information for that provider. of a simple web service that returns contact information for that
provider.
Each country that supports video relay service using this Each country that supports video relay service using this
specification MAY support the provider list. This document does not specification MAY support the provider list. This document does not
specify who maintains the list. Some possibilities are a regulator specify who maintains the list. Some possibilities are a regulator
or entity designated by a regulator, an agreement among providers to or entity designated by a regulator, an agreement among providers to
provide the list, or a user group. provide the list, or a user group.
The 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,
skipping to change at page 17, line 46 skipping to change at page 18, line 8
"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. The device uses the userid/password to HTTPs web service. There are two entry points. One is used without
authenticate to the interface if it has credentials for that user credentials, the response includes configuration data for new
provider. Without user credentials, the response includes user sign up and dial around. The other uses the userid/password to
configuration data for new user sign up and dial around. authenticate to the interface and returns configuration data for the
RUE.
An optional parameter may be provided to the interface which is an An optional parameter may be provided to the interface which is an
API Key. The implementation MAY have an API Key obtained from the API Key. The implementation MAY have an API Key obtained from the
provider and specific to the implementation. The method the API Key provider and specific to the implementation. The method the API Key
is obtained is not specified in this document. The provider MAY is obtained is not specified in this document. The provider MAY
refuse to provide service to an implementation presenting an API Key refuse to provide service to an implementation presenting an API Key
it does not recognize. it does not recognize.
A required parameter which contains an instance identifier. This A required parameter which contains an instance identifier. This
parameter MUST be the same value each time this instance (same parameter MUST be the same value each time this instance (same
implementation on same device) queries the interface. This may be implementation on same device) queries the interface. This may be
used by the provider, for example, to associate a location with the used by the provider, for example, to associate a location with the
instance for emergency calls. 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
specified above in Section 9.1. The version of the configuration
service MAY be different than the version of the provider list
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
* 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
- 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
- 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: (OPTIONAL) a URI that can be used with a one-stage - oneStage: a URI that can be used with a one-stage dial-around
dial-around Section 5.2.2 using an interpreter supporting the Section 5.2.2 using an interpreter supporting the specified
specified language language
* helpDesk: (OPTIONAL) an array of json objets consisting of: * helpDesk: (OPTIONAL) an array of json objets consisting of:
- language: entry from the IANA language subtag registry - language: entry from the IANA language subtag registry
- 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.
9.2.2. RUE Configuration
* lifetime: Specifies how long (in seconds) the RUE MAY cache the * lifetime: Specifies how long (in seconds) the RUE MAY cache the
configuration values. Values may not be valid when lifetime configuration values. Values may not be valid when lifetime
expires. Emergency Calls MUST continue to work. expires. If the RUE caches configuration values, it MUST
cryptographically protect them. The RUE SHOULD retrieve a fresh
copy of the configuration before the lifetime expires or as soon
as possible after it expires. The lifetime is not guaranteed: the
configuration may change before the lifetime value expires. In
that case, the Provider MAY indicate this by generating
authorization challenges to requests and/or prematurely
terminating a registration.Emergency Calls MUST continue to work.
* 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: (OPTIONAL) The telephone number (in E.164 format)
skipping to change at page 20, line 5 skipping to change at page 20, line 27
password are 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 with REGISTER, false if it should not.
Defaults to false if not present. 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.
The configuration API also provides the same version mechanism as 9.2.3. Examples
specified above in Section 9.1. The version of the configuration
service MAY be different than the version of the provider list
service.
Example JSON 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
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 4 Figure 5
The "lifetime" parameter in the configuration indicates how long the
RUE MAY cache the configuration values. If the RUE caches
configuration values, it MUST cryptographically protect them. The
RUE SHOULD retrieve a fresh copy of the configuration before the
lifetime expires or as soon as possible after it expires. The
lifetime is not guaranteed: the configuration may change before the
lifetime value expires. In that case, the Provider MAY indicate this
by generating authorization challenges to requests and/or prematurely
terminating a registration.
9.3. Using the Provider List and Configuration Services Together 9.2.4. Using the Provider Selection and RUE Configuration Services
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.
* For each provider in the list: * For each provider in the list:
- 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.4. OpenAPI Interface Descriptions 9.3. OpenAPI Interface Descriptions
The interfaces in Sections Section 9.1 and Section 9.2 are formally The interfaces in Sections Section 9.1 and Section 9.2 are formally
specified with OpenAPI 3.0 descriptions in yaml form. specified with OpenAPI 3.0 descriptions in yaml form.
openapi: 3.0.1 openapi: 3.0.1
info: info:
title: RUM API title: RUM API
version: "1.0" version: "1.0"
servers: servers:
- url: http://localhost/rum/v1 - url: http://localhost/rum/v1
paths: paths:
/Providers: /Providers:
get: get:
summary: Get a list of providers to get config data from summary: Get a list of providers and domains to get
operationId: GetProviderList config data from
responses: operationId: GetProviderList
'200': responses:
description: List of providers for a country '200':
content: description: List of providers for a country
application/json: content:
schema: application/json:
$ref: '#/components/schemas/ProviderList' schema:
/Versions: $ref: '#/components/schemas/ProviderList'
servers: /ProviderConfig:
- url: https://api.example.com/rum get:
description: Override base path for Versions query summary: Configuration data for one provider
get: operationId: GetProviderConfiguration
summary: Retrieves all supported versions parameters:
operationId: RetrieveVersions - in: query
responses: name: apiKey
schema:
'200': type: string
description: Versions supported description: API Key assigned to this implementation
content: - in: query
application/json: name: instanceId
schema: schema:
$ref: '#/components/schemas/VersionsArray' type: string
components: required: true
schemas: description: Unique string for this implementation
ProviderList: on this device
type: object responses:
required: '200':
- providers description: configuration object
properties: content:
providers: application/json:
type: array schema:
items: $ref: '#/components/schemas/ProviderConfigurationData'
type: object /RueConfig:
required: get:
- name summary: Configuration data for one RUE
- domain operationId: GetRueConfiguration
properties: parameters:
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
Figure 5: Provider List OpenAPI description - 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:
openapi: 3.0.1 name:
info: type: string
title: RUM API description: Human readable provider name
version: "1.0" domain:
servers: type: string
- url: http://localhost/rum/v1 description: provider domain for interface
paths: VersionsArray:
/Configuration: type: object
get: required:
summary: Configuration data for one provider - versions
operationId: GetConfiguration properties:
parameters: versions:
- in: query type: array
name: apiKey items:
schema: type: object
type: string required:
description: API Key assigned to this implementation - major
- in: query - minor
name: instanceId properties:
schema: major:
type: string type: integer
required: true format: int32
description: Unique string for this implementation on this description: Version major number
device minor:
responses: type: integer
'200': format: int32
description: configuration object description: Version minor number
content: ProviderConfigurationData:
application/json: type: object
schema: properties:
$ref: '#/components/schemas/ConfigurationData' signup:
/Versions: type: object
servers: required:
- url: https://api.example.com/rum - language
description: Override base path for Versions query - uri
get: properties:
summary: Retrieves all supported versions language:
operationId: RetrieveVersions type: string
responses: description: entry from IANA language-subtag-registry
'200': uri:
description: Versions supported type: string
content: format: uri
application/json: description: uri to signup website supporting language
schema: dialAround:
$ref: '#/components/schemas/VersionsArray' type: object
components: required:
- language
- frontDoor
schemas: properties:
ConfigurationData: language:
type: object type: string
properties: description: entry from IANA language-subtag-registry
signup: frontDoor:
type: object type: string
required: format: uri
- language description: SIP uri for 2 stage dial around
- uri oneStage:
properties: type: string
language: format: uri
type: string description: SIP uri for 1 stage dial around
description: entry from IANA language-subtag-registry helpDesk:
uri: type: object
type: string required:
format: uri - language
description: uri to signup website supporting language - uri
dialAround: properties:
type: object language:
required: type: string
- language description: entry from IANA language-subtag-registry
- frontDoor uri:
properties: type: string
language: format: uri
type: string description: SIP uri of helpdesk supporting language
description: entry from IANA language-subtag-registry RueConfigurationData:
frontDoor: type: object
type: string properties:
format: uri lifetime:
description: SIP uri for 2 stage dial around type: integer
oneStage: description: how long (in seconds) the RUE MAY cache the
type: string configuration values
format: uri sip-password:
description: SIP uri for 1 stage dial around type: string
helpDesk: phone-number:
type: object type: string
required: description: telephone number assigned this subscriber
- language outbound-proxy:
- uri type: string
properties: format: uri
language: description: SIP uri of proxy to be used when sending
type: string requests to the Provider
description: entry from IANA language-subtag-registry mwi:
uri: type: string
type: string format: uri
format: uri description: A URI identifying a SIP event server that
description: SIP uri of helpdesk supporting language generates "message-summary" events for this subscriber.
sip-password: videomail:
type: string type: string
phone-number: format: uri
type: string description: A SIP URI that can be called to retrieve
description: telephone number assigned this subscriber videomail messages.
outbound-proxy: contacts:
type: string type: string
format: uri format: uri
description: SIP uri of proxy to be used when sending requests description: An HTTPS URI that may be used to export
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 (retrieve) the subscriber's complete contact list
managed by the Provider. managed by the Provider.
carddav: carddav:
type: object type: object
description: CardDAV server and user information that can be description: CardDAV server and user information that can be
used to synchronize the RUE's contact list with the used to synchronize the RUE's contact list with the
contact list managed by the Provider. contact list managed by the Provider.
properties: properties:
domain: domain:
type: string type: string
description: CardDAV server address description: CardDAV server address
username: username:
type: string type: string
description: username for authentication with CardDAV description: username for authentication with CardDAV
server. Use provider username if not provided server. Use provider username if not provided
password: password:
type: string type: string
description: password for authentication to the CardDAV description: password for authentication to the CardDAV
server. Use provider password if not provided server. Use provider password if not provided
sendLocationWithRegistration: sendLocationWithRegistration:
type: boolean type: boolean
description: True if the RUE should send a Geolocation Header description: True if the RUE should send a Geolocation Header
with REGISTER, false if it should not. Defaults to false with REGISTER, false if it should not.
if not present. Defaults to false if not present.
ice-servers: ice-servers:
type: array
type: array items:
items: type: string
type: string format: uri
format: uri description: URIs identifying STUN and TURN servers
description: URIs identifying STUN and TURN servers available for use by the RUE for establishing
available for use by the RUE for establishing media media streams in calls via the Provider.
streams in calls via the Provider.
VersionsArray:
type: object
required:
- versions
properties:
versions:
type: array
items:
type: object
required:
- major
- minor
properties:
major:
type: integer
format: int32
description: Version major number
minor:
type: integer
format: int32
description: Version minor number
Figure 6: Configuration OpenAPI description Figure 6: Provider List OpenAPI description
10. Acknowledgements 10. Acknowledgements
Brett Henderson and Jim Malloy provided many helpful edits to prior Brett Henderson and Jim Malloy provided many helpful edits to prior
versions of this document. versions of this document.
11. IANA Considerations 11. IANA Considerations
11.1. RUE Provider List Registry 11.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 be better than the existing
entry. Each entry has two fields, values for both of which MUST be entry. Each entry has two fields, values for both of which MUST be
skipping to change at page 33, line 28 skipping to change at page 33, line 28
[RFC8760] Shekh-Yusef, R., "The Session Initiation Protocol (SIP) [RFC8760] Shekh-Yusef, R., "The Session Initiation Protocol (SIP)
Digest Access Authentication Scheme", RFC 8760, Digest Access Authentication Scheme", RFC 8760,
DOI 10.17487/RFC8760, March 2020, DOI 10.17487/RFC8760, March 2020,
<https://www.rfc-editor.org/info/rfc8760>. <https://www.rfc-editor.org/info/rfc8760>.
[RFC8599] Holmberg, C. and M. Arnold, "Push Notification with the [RFC8599] Holmberg, C. and M. Arnold, "Push Notification with the
Session Initiation Protocol (SIP)", RFC 8599, Session Initiation Protocol (SIP)", RFC 8599,
DOI 10.17487/RFC8599, May 2019, DOI 10.17487/RFC8599, May 2019,
<https://www.rfc-editor.org/info/rfc8599>. <https://www.rfc-editor.org/info/rfc8599>.
[pip] SIPForum, "VRS US Providers Profile TWG-6-1.0", 2015,
<https://www.sipforum.org/download/vrs-us-providers-
profile-twg-6-1-0-pdf/#>.
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. 48 change blocks. 
345 lines changed or deleted 352 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/