draft-ietf-rum-rue-01.txt   draft-ietf-rum-rue-02.txt 
rum B. Rosen rum B. Rosen
Internet-Draft 4 November 2019 Internet-Draft 29 January 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 7 May 2020 Expires: 1 August 2020
Interoperability Profile for Relay User Equipment Interoperability Profile for Relay User Equipment
draft-ietf-rum-rue-01 draft-ietf-rum-rue-02
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 7 May 2020. This Internet-Draft will expire on 1 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . 5
4. General Requirements . . . . . . . . . . . . . . . . . . . . 6 4. General Requirements . . . . . . . . . . . . . . . . . . . . 6
5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Session Establishment . . . . . . . . . . . . . . . . . . 8 5.2. Session Establishment . . . . . . . . . . . . . . . . . . 7
5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 8 5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 8
5.2.2. One-Stage Dial-Around Origination . . . . . . . . . . 8 5.2.2. One-Stage Dial-Around Origination . . . . . . . . . . 8
5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 10 5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 9
5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10 5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10
5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 10 5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 10
5.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 11 5.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 11
5.4. URI Representation of Phone Numbers . . . . . . . . . . . 11 5.4. URI Representation of Phone Numbers . . . . . . . . . . . 11
5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 12 6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 12
6.2. Text-Based Communication . . . . . . . . . . . . . . . . 12 6.2. Text-Based Communication . . . . . . . . . . . . . . . . 12
6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Session Description Protocol . . . . . . . . . . . . . . 13 6.6. Session Description Protocol . . . . . . . . . . . . . . 13
6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.8. Negative Acknowledgment, Packet Loss Indicator, and 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full
Full Intraframe Request Features . . . . . . . . . . . . 13 Intraframe Request Features . . . . . . . . . . . . . . . 13
7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 13 7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 13
7.2. Contacts Import/Export Service . . . . . . . . . . . . . 14 7.2. Contacts Import/Export Service . . . . . . . . . . . . . 14
8. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 14 8. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 14
9. Provisioning and Provider Selection . . . . . . . . . . . . . 14 9. Provisioning and Provider Selection . . . . . . . . . . . . . 14
9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 14 9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 15
9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 16 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 16
9.3. Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.3. Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22
13. Normative References . . . . . . . . . . . . . . . . . . . . 22 13. Normative References . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
skipping to change at page 5, line 17 skipping to change at page 5, line 17
Relay user E.164 Number (user E.164): The telephone number assigned Relay user E.164 Number (user E.164): The telephone number assigned
to the RUE in ITU-T E.164 format. to the RUE in ITU-T E.164 format.
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 and using relay calls.
A RUE may take many forms, including a stand-alone device; an A RUE may take many forms, including a stand-alone device; an
application running on a general-purpose computing device such as a application running on a general-purpose computing device such as a
laptop, tablet or smart phone; or proprietary equipment connected to laptop, tablet or smart phone; or proprietary equipment connected to
a server that provides the RUE interface. a server that provides the RUE interface.
RUE Interface: the SIP interface between a RUE and the 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. is a relay user.
Telecommunications relay services (TRS): Telephone transmission Telecommunications relay services (TRS): Telephone transmission
skipping to change at page 6, line 11 skipping to change at page 6, line 11
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
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]
During the establishment of secure connections with a provider, the
RUE MAY be asked by the server for a client certificate. In that
case it SHOULD provide the provisioned client certificate (See
Section 9.2. Providers MAY reject requests that fail to provide a
recognized certificate.
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.
5. SIP Signaling 5. SIP Signaling
The RUE and Providers MUST conform to the following core SIP Implementations of the RUE Interface MUST conform to the following
standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP Servers), core SIP standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP
[RFC3264] (Offer/Answer), [RFC3840] (User Agent Capabilities), Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent
[RFC5626] (Outbound), [RFC4566] (Session Description Protocol), Capabilities), [RFC5626] (Outbound), [RFC4566] (Session Description
[RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP), [RFC6665] Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP),
(SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop-Fix), [RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop-
[RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960] (Early Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960]
Media), and [RFC6442] (Geolocation Header). (Early Media), and [RFC6442] (Geolocation Header).
In addition, the RUE MUST, and Providers MAY, conform to [RFC3327] In addition, the implementations, conform to [RFC3327] (Path),
(Path), [RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER [RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER Method),
Method), [RFC3891] (Replaces Header), [RFC3892] (Referred-By). [RFC3891] (Replaces Header), [RFC3892] (Referred-By).
RUEs MUST include a "User-Agent" header field uniquely identifying Implementations MUST include a "User-Agent" header field uniquely
the RUE application, platform, and version in all SIP requests, and identifying the RUE application, platform, and version in all SIP
MUST include a "Server" header field with the same content in SIP requests, and MUST include a "Server" header field with the same
responses. content in SIP responses.
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]. If the configuration (please refer to Section 11) [RFC5626]. If the configuration (please refer to Section 11)
contains multiple "outbound-proxies", then the RUE MUST use them as contains multiple "outbound-proxies", then the RUE MUST use them as
specified in [RFC5626] to establish multiple flows. 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
skipping to change at page 7, line 30 skipping to change at page 7, line 22
the outbound mechanism. the outbound mechanism.
The registrar MAY authenticate using SIP MD5 digest authentication. The registrar MAY authenticate using SIP MD5 digest authentication.
The credentials to be used (username and password) MUST be supplied The credentials to be used (username and password) MUST be supplied
within the credentials section of the configuration and identified by within the credentials section of the configuration and identified by
the realm the registrar uses in a digest challenge. This username/ the realm the registrar uses in a digest challenge. This username/
password combination SHOULD NOT be the same as that used for other password combination SHOULD NOT be the same as that used for other
purposes, such as retrieving the RUE configuration or logging into purposes, such as retrieving the RUE configuration or logging into
the Provider's customer service portal. Because MD5 is considered the Provider's customer service portal. Because MD5 is considered
insecure, [I-D.yusef-sipcore-digest-scheme] SHOULD be implemented by insecure, [I-D.yusef-sipcore-digest-scheme] SHOULD be implemented by
both the RUE and Providers and SHA-based digest algorithms SHOULD be all implementations and SHA-based digest algorithms SHOULD be used
used for digest authentication. for digest authentication.
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 by Providers is Support for multiple simultaneous registrations is OPTIONAL.
OPTIONAL.
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 8 skipping to change at page 8, line 4
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].
The RUE MUST route all calls through the outbound proxy of the The all outbound calls MUST be routed through an outbound proxy if
default Provider. configured.
INVITE requests used to initiate calls SHOULD NOT contain Route INVITE requests used to initiate calls SHOULD NOT contain Route
headers. Route headers MAY be included in one-stage dial-around headers. Route headers MAY be included in one-stage dial-around
calls and emergency calls. The SIP URIs in the To field and the calls and emergency calls. The SIP URIs in the To field and the
Request-URI MUST be formatted as specified in subsection 6.4 using Request-URI MUST be formatted as specified in subsection 6.4 using
the destination phone number. The domain field of the URIs SHOULD be the destination phone number. The domain field of the URIs SHOULD be
the "provider-domain" from the configuration (e.g., the "provider-domain" from the configuration (e.g.,
sip:+13115552368@red.example.com;user=phone). The same exceptions sip:+13115552368@red.example.com;user=phone). The same exceptions
apply, including anonymous calls. apply, including anonymous calls.
Anonymous calls MUST be supported by both the RUE and Providers. 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.
skipping to change at page 9, line 20 skipping to change at page 9, line 13
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
,-+-. ,----+----. ,-----+-----. ,-+-. ,----+----. ,-----+-----.
|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 9, line 45 skipping to change at page 9, line 39
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 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: One Stage Dial-Around 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 with a purpose parameter of "rue-owner".
The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is
defined by [RFC2392] to locate message body parts. This URI type is defined by [RFC2392] to locate message body parts. This URI type is
present in a SIP message to convey the RUE ownership information as a present in a SIP message to convey the RUE ownership information as a
MIME body. The form of the RUE ownership information is an xCard MIME body. The form of the RUE ownership information is a jCard
[RFC6351]. Please refer to [RFC6442] for an example of using [RFC7095]. Please refer to [RFC6442] for an example of using
Content-Indirect URLs in SIP messages. Note that use of the Content- Content-Indirect URLs in SIP messages. Note that use of the Content-
Indirect URL usually implies multiple message bodies ("mime/ Indirect URL usually implies multiple message bodies ("mime/
multipart"). multipart").
5.2.4. Incoming Calls 5.2.4. Incoming Calls
The RUE MUST accept inbound calls sent to it by the proxy mentioned The RUE MUST accept inbound calls sent to it by the proxy mentioned
in the configuration. 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
The RUE MUST comply with [RFC6881] for handling of emergency calls. The implementations comply with [RFC6881] for handling of emergency
calls.
Providers MUST:
* Accept RUE emergency calls complying with the specifications in
this document;
* Recognize such calls as emergency calls and properly handle them
as such;
* Address other behavior not specified by RFC6881 as specified in If the emergency call is to be handled using existing country
Section 5.2. specific procedures, the Provider is responsible for modifying the
INVITE to conform to the country-specific requirements. In this
case, location MAY be extracted from the RFC6881 conformant INVITE
and used to propagate it to the appropriate country-specific
entities. Because the RUE may have a more accurate and timely
location of the device than the a manual entry location for nomadic
RUE devices, but country-specific procedures require the location to
be pre-loaded in some entity prior to placing an emergency call,
implementations MAY send a Geolocation header containing its location
in the REGISTER request if the configuration specifies it. That
information MAY be used to populate the location to appropriate
country-specific entities.
Specifically, if the emergency call is to be handled using existing Implementations MUST implement Additional Data, [RFC7852]. Clients
country specific procedures, the Provider is responsible for MUST implement Data Provider, Device Implementation and Owner/
modifying the INVITE to conform to the country-specific requirements. Subscriber Information blocks. Servers MUST implement Data Provider
In this case, location MAY be extracted from the RFC6881 conformant and Service Information blocks as the call is forwarded to the PSAP.
INVITE and used to propagate it to the VPC where possible with the
emergency call. Because the RUE may have a more accurate and timely
location of the device than the typical manual entry location for
nomadic RUE devices, the RUE MAY send a Geolocation header containing
its location in the REGISTER request if the configuration specifies
it. The Provider MAY use that information to populate the location
of the device in the VPC before any emergency call.
5.3. Mid Call Signaling 5.3. Mid Call Signaling
The RUE and Providers MUST support re-INVITE to renegotiate media Implementations MUST support re-INVITE to renegotiate media session
session parameters (among other uses). Per Section 6.1, the RUE parameters (among other uses). Per Section 6.1, implementations
MUST, and providers SHOULD, be able to support an INFO request for MUST, be able to support an INFO request for full frame refresh for
full frame refresh for devices in a call with the RUE that do not devices that do not support RTCP mechanisms (please refer to
support RTCP mechanisms (please refer to Section 6.8). The RUE MUST Section 6.8). Implementations MUST support an in-dialog REFER
support an in-dialog REFER ([RFC3515] updated by [RFC7647] and ([RFC3515] updated by [RFC7647] and including support for norefersub
including support for norefersub per [RFC4488]) with the Replaces per [RFC4488]) with the Replaces header [RFC3891] to enable call
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.
A dial string that can be written as an E.164 formatted phone number A dial string that can be written as an E.164 formatted phone number
MUST be represented as a SIP URI with a URI ";user=phone" tag. The MUST be represented as a SIP URI with a URI ";user=phone" tag. The
user part of the URI MUST be in conformance with 'global-number' user part of the URI MUST be in conformance with 'global-number'
skipping to change at page 11, line 42 skipping to change at page 11, line 39
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 (using resolve (in accord with [RFC3263]) to globally (AoR) MUST (using resolve (in accord with [RFC3263]) to globally
routable IPv4 addresses. The AoRs MAY also resolve to IPv6 routable IPv4 addresses. The AoRs MAY also resolve to IPv6
addresses. addresses.
5.5. Transport 5.5. Transport
The RUE and providers MUST conform to [I-D.ietf-rtcweb-transports] Implementations MUST conform to [I-D.ietf-rtcweb-transports] with the
with the understanding that this specification does not use the understanding that this specification does not use the WebRTC data
WebRTC data channel. channel.
The RUE and providers MUST support SIP outbound [RFC5626] (please Implementations MUST support SIP outbound [RFC5626] (please also
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
([I-D.ietf-rtcweb-overview]). Where WebRTC defines how interactive ([I-D.ietf-rtcweb-overview]). Where WebRTC defines how interactive
media communications may be established using a browser as a client, media communications may be established using a browser as a client,
this specification assumes a normal SIP call. The RTP, RTCP, SDP and this 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 noted
expressly below. 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 capabity 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, a call that originates implementations must support OPUS. However, implementation
in the Public Switched Telephone Network, which only offers G.711 presenting a call across the RUE Interface where the call originates
audio does not need to include the OPUS codec in the offer, since it in the Public Switched Telephone Network, or an older, non-RUE-
cannot be used with that call. compatible device, which only offers G.711 audio, does not need to
include the OPUS codec in the offer, since it cannot be used with
that call.
6.1. SRTP and SRTCP 6.1. SRTP and SRTCP
The RUE and Providers MUST support [I-D.ietf-rtcweb-rtp-usage] with Implementations MUST support [I-D.ietf-rtcweb-rtp-usage] with the
the understanding that RUE does not specify an API and therefore understanding that RUE Interface does not specify an API and
MediaStreamTracks are not used. Implementations MUST conform to therefore MediaStreamTracks are not used. Implementations MUST
Section 6.4 of [I-D.ietf-rtcweb-security-arch]. conform to Section 6.4 of [I-D.ietf-rtcweb-security-arch].
6.2. Text-Based Communication 6.2. Text-Based Communication
The RUE MUST and Providers MUST support real-time text ([RFC4102] and Implementations MUST support real-time text ([RFC4102] and [RFC4103])
[RFC4103]) via T.140 media. One original and two redundant via T.140 media. One original and two redundant generations MUST be
generations MUST be transmitted and supported, with a 300 ms transmitted and supported, with a 300 ms transmission interval. Note
transmission interval. Note that this is not how real time text is that this is not how real time text is transmitted in WebRTC and some
transmitted in WebRTC and some form of transcoder would be required form of transcoder would be required to interwork real time text in
to interwork real time text in the data channel of WebRTC to RFC4103 the data channel of WebRTC to RFC4103 real time text.
real time text.
6.3. Video 6.3. Video
The RUE and Providers MUST conform to [RFC7742] with the exception Implementations MUST conform to [RFC7742] with the exception that,
that, since backwards compatibility is desirable and older devices do since backwards compatibility is desirable and older devices do not
not support VP8, that only H.264, as specified in [RFC7742] is support VP8, that only H.264, as specified in [RFC7742] is Mandatory
Mandatory to Implement. to Implement.
6.4. Audio 6.4. Audio
The RUE and Providers MUST conform to [RFC7874]. Implementations MUST conform to [RFC7874].
6.5. DTMF Digits 6.5. DTMF Digits
The RUE and Providers MUST support the "audio/telephone-event" Implementations MUST support the "audio/telephone-event" [RFC4733]
[RFC4733] media type. They MUST support conveying event codes 0 media type. They MUST support conveying event codes 0 through 11
through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733].
[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 [I-D.ietf-rtcweb-jsep] with The SDP offers and answers MUST conform [I-D.ietf-rtcweb-jsep] with
the understanding that the RUE uses SIP transport for SDP. the understanding that the RUE Interface uses SIP transport for SDP.
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 13, line 37 skipping to change at page 13, line 30
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
refresh point would render the video unusable for the users, as per refresh point would render the video unusable for the users, as per
RFC5104 subsection 4.3.1.2. RFC5104 subsection 4.3.1.2.
For backwards compatibility with calling devices that do not support For backwards compatibility with calling devices that do not support
the foregoing methods, the RUE MUST implement and use 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
skipping to change at page 14, line 20 skipping to change at page 14, line 13
credentials are configured, the RUE MUST use the SIP credentials from credentials are configured, the RUE MUST use the SIP credentials from
the configuration. If the SIP credentials fail, the RUE MUST query the configuration. If the SIP credentials fail, the RUE MUST query
the user. the 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
Each Provider MUST supply a standard xCard import/export interface Implementations MUST be able to export/import the list of contacts in
and the RUE MUST be able to export/import the list of contacts in jCard [RFC7095] 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. Mail Waiting Indicator (MWI)
Support of MWI by Providers is OPTIONAL Support of MWI by Providers is OPTIONAL
The RUE MUST and Providers SHOULD support subscriptions to "message- Implementations MUST support subscriptions to "message-summary"
summary" events [RFC3842] to the URI specified in the configuration events [RFC3842] to the URI specified in the configuration.
if the Provider supports message waiting indicator on any endpoint.
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
defines a provisioning mechanism which consist of files stored on
server that are retrieved by the RUE device. Two files are
supported: one provides a directory of providers so that a user
interface that allows easy provider selection either for registering
or for dial-around. The other file provides configuration data for
the device. The RUE device would retrieve these files at boot time.
No mechanism for creating the files are specified. Each of the files
contains a single json object. The retrieval mechanism is HTTPS
download of that object from a provisioned location.
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 obtain, on
startup, a list of Providers from a configured accessible URL. startup, a list of Providers from a configured accessible URL. This
file is MAY be a single file per country, containing all the
providers authorized in that country, but MAY be any collection of
providers.
The provider list, formatted as JSON, contains: The provider list, formatted as JSON, contains:
* Version: Specifies the version number of the Provider list format. * Version: Specifies the version number of the Provider list format.
A new version number SHOULD only be used if the new version is not A new version number SHOULD only be used if the new version is not
backwards-compatible with the older version. A new version number backwards-compatible with the older version. A new version number
is not needed if new elements are optional and can be ignored by is not needed if new elements are optional and can be ignored by
older implementations. older implementations.
* Providers: An array where each entry describes one Provider. Each * Providers: An array where each entry describes one Provider. Each
skipping to change at page 15, line 30 skipping to change at page 15, line 40
(as discussed in Section 5.2.2). (as discussed in Section 5.2.2).
- operator: (OPTIONAL) The operator parameter is a SIP URL that - operator: (OPTIONAL) The operator parameter is a SIP URL that
identifies the operator "front-door" that VRS users may contact identifies the operator "front-door" that VRS users may contact
for manual (two-stage) dial-around calls. for manual (two-stage) dial-around calls.
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. account.
Example of a Provider list JSON object
{ {
"version": 1, "version": 1,
"providers": [ "providers": [
{ {
"name": "Red", "name": "Red",
"domain": "red.example.net", "domain": "red.example.net",
"operator": "sip:operator@red.example.net" "operator": "sip:operator@red.example.net"
}, },
{ {
"name": "Green", "name": "Green",
"domain": "green.example.net", "domain": "green.example.net",
"operator": "sip:+18885550123@green.example.net;user=phone" "operator": "sip:+18885550123@green.example.net;user=phone"
}, },
{ {
"name": "Blue", "name": "Blue",
"domain": "blue.example.net" "domain": "blue.example.net"
} }
] ]
} }
Figure 2: Example of a Provider list JSON object Figure 2
9.2. RUE Configuration Service 9.2. RUE Configuration Service
The RUE is provisioned with one or more URIs that may be queried for A RUE device may retrieve a configuration from a provisioned URL
configuration with HTTPS. using HTTPs.
The data returned will include a set of key/value configuration The data returned will include a set of key/value configuration
parameters to be used by the RUE, formatted as a JSON object and parameters to be used by the RUE, formatted as a single JSON object
identified by the associated [RFC7159] "application/json" MIME type, and identified by the associated [RFC7159] "application/json" MIME
to allow for other formats in the future. type, to allow for other formats in the future.
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.
* version: Identifies the version of the configuration data format. * version: Identifies the version of the configuration data format.
A new version number SHOULD only be used if the new version is not A new version number SHOULD only be used if the new version is not
backwards-compatible with the older version. A new version number backwards-compatible with the older version. A new version number
is not needed if new elements are optional and can be ignored by is not needed if new elements are optional and can be ignored by
older implementations. older implementations.
skipping to change at page 17, line 11 skipping to change at page 17, line 33
* carddav: (OPTIONAL) A username and domain name (separated by * carddav: (OPTIONAL) A username and domain name (separated by
""@"") identifying a "CardDAV" server and user name that can be ""@"") identifying a "CardDAV" server and user name that can be
used to synchronize the RUE's contact list with the contact list used to synchronize the RUE's contact list with the contact list
managed by the Provider. managed by the Provider.
* sendLocationWithRegistration: True if the RUE should send a * sendLocationWithRegistration: True if the RUE should send a
Geolocation Header with REGISTER, false if it should not. Geolocation Header with REGISTER, false if it should not.
Defaults to false if not present. Defaults to false if not present.
* turn-servers: (OPTIONAL) An array of URLs identifying STUN and * ice-servers: (OPTIONAL) An array of URLs identifying STUN and TURN
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.
* credentials: (OPTIONAL) TBD * credentials: (OPTIONAL) TBD
Example JSON configuration payload
{ {
"version": 1, "version": 1,
"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"
], ],
skipping to change at page 19, line 4 skipping to change at page 19, line 4
"username": "bob", "username": "bob",
"password": "vm-pw" "password": "vm-pw"
}, },
{ {
"realm": "stun-turn.red.example.net", "realm": "stun-turn.red.example.net",
"username": "bob", "username": "bob",
"password": "stun-turn-pw" "password": "stun-turn-pw"
} }
] ]
} }
Figure 3: Example JSON configuration payload Figure 3
The wire format of the data is in keeping with the standard JSON The wire format of the data is in keeping with the standard JSON
description in RFC7159. description in RFC7159.
The "lifetime" parameter in the configuration indicates how long the The "lifetime" parameter in the configuration indicates how long the
RUE MAY cache the configuration values. If the RUE caches RUE MAY cache the configuration values. If the RUE caches
configuration values, it MUST cryptographically protect them. The configuration values, it MUST cryptographically protect them. The
RUE SHOULD retrieve a fresh copy of the configuration before the RUE SHOULD retrieve a fresh copy of the configuration before the
lifetime expires or as soon as possible after it expires. The lifetime expires or as soon as possible after it expires. The
lifetime is not guaranteed: the configuration may change before the lifetime is not guaranteed: the configuration may change before the
skipping to change at page 19, line 35 skipping to change at page 19, line 35
situation, the RUE MAY retrieve a new copy of the configuration when situation, the RUE MAY retrieve a new copy of the configuration when
it knows the user is present, even if there is time before the it knows the user is present, even if there is time before the
lifetime expires. lifetime expires.
9.3. Schemas 9.3. Schemas
The following JSON schemas are for the Provider List and the RUE The following JSON schemas are for the Provider List and the RUE
Configuration. These are represented using the JSON Content Rules Configuration. These are represented using the JSON Content Rules
[JCR] schema notation. [JCR] schema notation.
Provider List JSON Schema
{ {
"version": 1, "version": 1,
"providers": [ "providers": [
1* 1*
{ {
"name": string, "name": string,
"domain": fqdn, "domain": fqdn,
?"operator": ; "front-door" access to provider ?"operator": ; "front-door" access to provider
uri, ; (sip uri) uri, ; (sip uri)
* /^.*$/ : any ; (allow future extensions) * /^.*$/ : any ; (allow future extensions)
} }
] , ] ,
* /^.*$/ : any ; (allow future extensions) * /^.*$/ : any ; (allow future extensions)
} }
Figure 4: Provider List JSON Schema Figure 4
RUE Configuration JSON Schema
{ {
"version": 1, ; Interface version "version": 1, ; Interface version
"lifetime": integer, ; Deadline (in seconds) for "lifetime": integer, ; Deadline (in seconds) for
; refreshing this config without ; refreshing this config without
; user input. ; user input.
"phone-number": /^\+[0-9]+$/ , ; E.164 phone number "phone-number": /^\+[0-9]+$/ , ; E.164 phone number
; for this user ; for this user
?"display-name" : string,; display name for From: header ?"display-name" : string,; display name for From: header
"provider-domain": fqdn, ; SHOULD match that in Provider List "provider-domain": fqdn, ; SHOULD match that in Provider List
?"outbound-proxies": [ 1* : uri ], ; sip URIs ?"outbound-proxies": [ 1* : uri ], ; sip URIs
skipping to change at page 20, line 31 skipping to change at page 20, line 32
[ 1* : uri ], ; (stun[s] & turn[s] URIs [ 1* : uri ], ; (stun[s] & turn[s] URIs
?"credentials": ; for digest authentication ?"credentials": ; for digest authentication
[ 1* { [ 1* {
"realm": string, "realm": string,
"username": string, "username": string,
"password": string "password": string
} ], } ],
* /^.*$/ : any ; (allow future extensions) * /^.*$/ : any ; (allow future extensions)
} }
Figure 5: RUE Configuration JSON Schema Figure 5
The following illustrates the message flow for retrieving a RUE The following illustrates the message flow for retrieving a RUE
automatic configuration using HTTPS Digest Authentication: automatic configuration using HTTPS Digest Authentication:
RUE Configuration Retrieval
,-. ,-.
`-' `-'
/|\ ,---. ,---. ,------------. ,----------------. ,---. /|\ ,---. ,---. ,------------. ,----------------. ,---.
| |RUE| |DNS| |HTTPS Server| | Provider | |CRM| | |RUE| |DNS| |HTTPS Server| | Provider | |CRM|
/ \ | | | | | | |Global Settings | | | / \ | | | | | | |Global Settings | | |
RUE User `-+-' `-+-' `-----+------' `--------+-------' `-+-' RUE User `-+-' `-+-' `-----+------' `--------+-------' `-+-'
| | | | | | | | | | | |
[1] Select a VRS Provider name | | | [1] Select a VRS Provider name | | |
| ------->| | | | | | ------->| | | | |
| | | | | | | | | | | |
skipping to change at page 22, line 7 skipping to change at page 22, line 9
[17] 200 OK + JSON merge subscriber + provider configs | [17] 200 OK + JSON merge subscriber + provider configs |
| |<----------------| | | | |<----------------| | |
| | | | | | | | | | | |
RUE User ,---. ,---. ,------------. ,----------------. ,---. RUE User ,---. ,---. ,------------. ,----------------. ,---.
,-. |RUE| |DNS| |HTTPS Server| | Provider | |CRM| ,-. |RUE| |DNS| |HTTPS Server| | Provider | |CRM|
`-' | | | | | | |Global Settings | | | `-' | | | | | | |Global Settings | | |
/|\ `-+-' `-+-' `-----+------' `--------+-------' `-+-' /|\ `-+-' `-+-' `-----+------' `--------+-------' `-+-'
| |
/ \ / \
Figure 6: RUE Configuration Retrieval Figure 6
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
This memo includes no request to IANA. This memo includes no request to IANA.
skipping to change at page 22, line 30 skipping to change at page 22, line 32
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. Normative References 13.
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 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
skipping to change at page 26, line 21 skipping to change at page 26, line 21
[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>.
[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>.
[RFC6351] Perreault, S., "xCard: vCard XML Representation", [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
RFC 6351, DOI 10.17487/RFC6351, August 2011, DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc6351>. <https://www.rfc-editor.org/info/rfc7095>.
[RFC3842] Mahy, R., "A Message Summary and Message Waiting [RFC3842] Mahy, R., "A Message Summary and Message Waiting
Indication Event Package for the Session Initiation Indication Event Package for the Session Initiation
Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August
2004, <https://www.rfc-editor.org/info/rfc3842>. 2004, <https://www.rfc-editor.org/info/rfc3842>.
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, Context for Internet Mail", RFC 3458,
DOI 10.17487/RFC3458, January 2003, DOI 10.17487/RFC3458, January 2003,
<https://www.rfc-editor.org/info/rfc3458>. <https://www.rfc-editor.org/info/rfc3458>.
skipping to change at page 26, line 50 skipping to change at page 26, line 50
"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 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling", Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
<https://www.rfc-editor.org/info/rfc6881>. <https://www.rfc-editor.org/info/rfc6881>.
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
J. Winterbottom, "Additional Data Related to an Emergency
Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
<https://www.rfc-editor.org/info/rfc7852>.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", Work in Progress, Internet- Browser-based Applications", Work in Progress, Internet-
Draft, draft-ietf-rtcweb-overview-19, 11 November 2017, Draft, draft-ietf-rtcweb-overview-19, 11 November 2017,
<http://www.ietf.org/internet-drafts/draft-ietf-rtcweb- <http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-
overview-19.txt>. overview-19.txt>.
[I-D.ietf-rtcweb-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
 End of changes. 59 change blocks. 
129 lines changed or deleted 147 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/