draft-ietf-rum-rue-02.txt   draft-ietf-rum-rue-03.txt 
rum B. Rosen rum B. Rosen
Internet-Draft 29 January 2020 Internet-Draft 25 August 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 1 August 2020 Expires: 26 February 2021
Interoperability Profile for Relay User Equipment Interoperability Profile for Relay User Equipment
draft-ietf-rum-rue-02 draft-ietf-rum-rue-03
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 1 August 2020. This Internet-Draft will expire on 26 February 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . 8 5.2.2. One-Stage Dial-Around Origination . . . . . . . . . . 9
5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 9 5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 10
5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10 5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10
5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . 11 5.4. URI Representation of Phone Numbers . . . . . . . . . . . 12
5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 12 6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 13
6.2. Text-Based Communication . . . . . . . . . . . . . . . . 12 6.2. Text-Based Communication . . . . . . . . . . . . . . . . 13
6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 12 6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 13
6.6. Session Description Protocol . . . . . . . . . . . . . . 13 6.6. Session Description Protocol . . . . . . . . . . . . . . 13
6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . 13 Intraframe Request Features . . . . . . . . . . . . . . . 14
7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 13 7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 14
7.2. Contacts Import/Export Service . . . . . . . . . . . . . 14 7.2. Contacts Import/Export Service . . . . . . . . . . . . . 15
8. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 14 8. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 15
9. Provisioning and Provider Selection . . . . . . . . . . . . . 14 9. Provisioning and Provider Selection . . . . . . . . . . . . . 15
9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 15 9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 16
9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 16 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 17
9.3. Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.3. Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13. Normative References . . . . . . . . . . . . . . . . . . . . 22 13. Normative References . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Video Relay Service (VRS) is a form of Telecommunications Relay Video Relay Service (VRS) is a form of Telecommunications Relay
Service (TRS) that enables persons with hearing disabilities who use Service (TRS) that enables persons with hearing disabilities who use
sign language, such as American Sign Language (ASL), to communicate sign language, such as American Sign Language (ASL), to communicate
with voice telephone users through video equipment. These services with voice telephone users through video equipment. These services
also enable communication between such individuals directly in also enable communication between such individuals directly in
suitable modalities, including any combination of sign language via suitable modalities, including any combination of sign language via
video, real-time text (RTT), and speech. video, real-time text (RTT), and speech.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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), [RFC4566] (Session Description Capabilities), [RFC5626] (Outbound), [RFC4566] (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 addition, the implementations, conform to [RFC3327] (Path), In the above documents the RUE device conforms to the requirements of
a SIP user Agent, and the provider conforms to the requirements of
Registrar and Proxy Server where the document specifies different
behavior for different roles. The only requirement on providers for
RFC6655 (Events) is support for the Message Waiting Indicator (See
Section Section 8), which is optional and providers not supporting
MWI need not support RFC6665.
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.
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] at a provider it has an account with. If the configuration
contains multiple "outbound-proxies", then the RUE MUST use them as (please refer to Section 11) contains multiple "outbound-proxies",
specified in [RFC5626] to establish multiple flows. then the RUE MUST use them as specified in [RFC5626] to establish
multiple flows.
The request-URI for the REGISTER request MUST contain the "provider- The request-URI for the REGISTER request MUST contain the "provider-
domain" from the configuration. The To-URI and From-URI MUST be domain" from the configuration. The To-URI and From-URI MUST be
identical URIs, formatted as specified in Section 13, using the identical URIs, formatted as specified in Section 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 8, line 4 skipping to change at page 8, line 19
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 all outbound calls MUST be routed through an outbound proxy if A RUE device MUST routes all outbound calls through an outbound proxy
configured. if 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.
skipping to change at page 10, line 21 skipping to change at page 11, line 13
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 implementations comply with [RFC6881] for handling of emergency Implementations MUST conform to [RFC6881] for handling of emergency
calls. calls, except that if the device is unable to determine its own
location, it MAY send the emergency call without a Geolocation header
and without a Route header (since it would be unable to query the
LoST server for a route per RFC6881). If an emergency call arrives
at the provider without a Geolocation header, the provider MUST
supply location by adding the Geolocation header, and MUST supply the
route by querying the LoST server with that location.
If the emergency call is to be handled using existing country If the emergency call is to be handled using existing country
specific procedures, the Provider is responsible for modifying the specific procedures, the Provider is responsible for modifying the
INVITE to conform to the country-specific requirements. In this INVITE to conform to the country-specific requirements. In this
case, location MAY be extracted from the RFC6881 conformant INVITE case, location MAY be extracted from the RFC6881 conformant INVITE
and used to propagate it to the appropriate country-specific and used to propagate it to the appropriate country-specific
entities. Because the RUE may have a more accurate and timely entities. Because the RUE may have a more accurate and timely
location of the device than the a manual entry location for nomadic location of the device than the a manual entry location for nomadic
RUE devices, but country-specific procedures require the location to RUE devices, but country-specific procedures require the location to
be pre-loaded in some entity prior to placing an emergency call, be pre-loaded in some entity prior to placing an emergency call,
implementations MAY send a Geolocation header containing its location implementations of a RUE device MAY send a Geolocation header
in the REGISTER request if the configuration specifies it. That containing its location in the REGISTER request if the configuration
information MAY be used to populate the location to appropriate specifies it. That information MAY be used to populate the location
country-specific entities. to appropriate country-specific entities.
Implementations MUST implement Additional Data, [RFC7852]. Clients Implementations MUST implement Additional Data, [RFC7852]. RUE
MUST implement Data Provider, Device Implementation and Owner/ devices MUST implement Data Provider, Device Implementation and
Subscriber Information blocks. Servers MUST implement Data Provider Owner/Subscriber Information blocks. Providers MUST implement Data
and Service Information blocks as the call is forwarded to the PSAP. Provider and Service Information blocks as the call is forwarded to
the PSAP.
5.3. Mid Call Signaling 5.3. Mid Call Signaling
Implementations MUST support re-INVITE to renegotiate media session Implementations MUST support re-INVITE to renegotiate media session
parameters (among other uses). Per Section 6.1, implementations parameters (among other uses). Per Section 6.1, implementations
MUST, be able to support an INFO request for full frame refresh for MUST, be able to support an INFO request for full frame refresh for
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
skipping to change at page 11, line 39 skipping to change at page 12, line 28
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
Implementations MUST conform to [I-D.ietf-rtcweb-transports] with the Implementations MUST conform to [I-D.ietf-rtcweb-transports] except
understanding that this specification does not use the WebRTC data that that this specification does not use the WebRTC data channel.
channel. See Section Section 6.2 for how RUE supports real time text without
the data channel.
Implementations MUST support SIP outbound [RFC5626] (please also Implementations MUST support SIP outbound [RFC5626] (please also
refer to Section 5.1). refer to Section 5.1).
6. Media 6. Media
This specification adopts the media specifications for WebRTC This specification adopts the media specifications for WebRTC
([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
skipping to change at page 12, line 21 skipping to change at page 13, line 11
OPUS is a mandatory to implement audio codec, and all conforming OPUS is a mandatory to implement audio codec, and all conforming
implementations must support OPUS. However, implementation implementations must support OPUS. However, implementation
presenting a call across the RUE Interface where the call originates presenting a call across the RUE Interface where the call originates
in the Public Switched Telephone Network, or an older, non-RUE- in the Public Switched Telephone Network, or an older, non-RUE-
compatible device, which only offers G.711 audio, does not need to compatible device, which only offers G.711 audio, does not need to
include the OPUS codec in the offer, since it cannot be used with include the OPUS codec in the offer, since it cannot be used with
that call. that call.
6.1. SRTP and SRTCP 6.1. SRTP and SRTCP
Implementations MUST support [I-D.ietf-rtcweb-rtp-usage] with the Implementations MUST support [I-D.ietf-rtcweb-rtp-usage] except that
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
Implementations MUST support real-time text ([RFC4102] and [RFC4103]) Implementations MUST support real-time text ([RFC4102] and [RFC4103])
via T.140 media. One original and two redundant generations MUST be via T.140 media. One original and two redundant generations MUST be
transmitted and supported, with a 300 ms transmission interval. Note transmitted and supported, with a 300 ms transmission interval. Note
that this is not how real time text is transmitted in WebRTC and some that this is not how real time text is transmitted in WebRTC and some
form of transcoder would be required to interwork real time text in form of transcoder would be required to interwork real time text in
the data channel of WebRTC to RFC4103 real time text. the data channel of WebRTC to RFC4103 real time text.
6.3. Video 6.3. Video
Implementations MUST conform to [RFC7742] with the exception that, Implementations MUST conform to [RFC7742] with the exception that,
since backwards compatibility is desirable and older devices do not since backwards compatibility is desirable and older devices do not
support VP8, that only H.264, as specified in [RFC7742] is Mandatory support VP8, that only H.264, as specified in [RFC7742] is Mandatory
to Implement. to Implement and VPB support is OPTIONAL at both the device and
providers.
6.4. Audio 6.4. Audio
Implementations MUST conform to [RFC7874]. Implementations MUST conform to [RFC7874].
6.5. DTMF Digits 6.5. DTMF Digits
Implementations MUST support the "audio/telephone-event" [RFC4733] Implementations MUST support the "audio/telephone-event" [RFC4733]
media type. They MUST support conveying event codes 0 through 11 media type. They MUST support conveying event codes 0 through 11
(DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733].
Handling of other tones is OPTIONAL. Handling of other tones is OPTIONAL.
6.6. Session Description Protocol 6.6. Session Description Protocol
The SDP offers and answers MUST conform [I-D.ietf-rtcweb-jsep] with The SDP offers and answers MUST conform [I-D.ietf-rtcweb-jsep] except
the understanding that the RUE Interface uses SIP transport for SDP. 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 18, line 16 skipping to change at page 19, line 16
"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"}
], ],
"credentials": [ "credentials": [
{ {
"realm": "red.example.net", "realm": "red.example.net",
"username": "bob", "username": "bob",
"password": "reg-pw" "password": "reg-pw"
}, },
{ {
"realm": "proxies.red.example.net", "realm": "proxies.red.example.net",
"username": "bob", "username": "bob",
skipping to change at page 19, line 32 skipping to change at page 20, line 32
the user for the username and password. Unfortunately, this the user for the username and password. Unfortunately, this
authentication step might occur when the user is not present, authentication step might occur when the user is not present,
preventing SIP registration and thus incoming calls. To avoid this preventing SIP registration and thus incoming calls. To avoid this
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.
[JCR] schema notation.
Provider List JSON Schema Provider List JSON Schema
{ {
"version": 1, "$schema": "http://json-schema.org/draft-07/schema",
"providers": [ "type": "object",
1* "title": "Providers schema",
{ "description": "List of Providers",
"name": string, "required": [
"domain": fqdn, "version",
?"operator": ; "front-door" access to provider "providers"
uri, ; (sip uri) ],
* /^.*$/ : any ; (allow future extensions) "properties": {
} "version": {
] , "type": "number",
* /^.*$/ : any ; (allow future extensions) "description": "Version of this schema",
},
"providers": {
"type": "array",
"description": "provider list as an array.",
"items": {
"required": [
"name",
"domain"
],
"properties": {
"name": {
"type": "string",
"description": "Display Name",
},
"domain": {
"type": "string",
"description":
"domain name used with config file",
},
"operator": {
"type": "string",
"description":
"SIP URI for dial-around",
}
}
}
}
} }
}
Figure 4 Figure 4
RUE Configuration JSON Schema RUE Configuration JSON Schema
{ {
"version": 1, ; Interface version "$schema": "http://json-schema.org/draft-07/schema",
"lifetime": integer, ; Deadline (in seconds) for "title": "The root schema",
; refreshing this config without "description": "RUE Configuration File",
; user input. "required": [
"phone-number": /^\+[0-9]+$/ , ; E.164 phone number "version",
; for this user "lifetime",
?"display-name" : string,; display name for From: header "phone-number",
"provider-domain": fqdn, ; SHOULD match that in Provider List "provider-domain",
?"outbound-proxies": [ 1* : uri ], ; sip URIs "carddav",
?"mwi": uri , ; sip URI for MWI subscriptions ],
?"videomail": uri , ; sip URI for videomail retrieval "properties": {
"contacts": uri , ; https URI for contact list retrieval "version": {
?"carddav": /^[^@]+@[^@]+$/ , ; for contact list synch "type": "number",
?"sendLocationWithRegistration": boolean , ; send location y/n "description": "Version of this schema",
?"ice-servers": ; (Required for ICE use) },
[ 1* : uri ], ; (stun[s] & turn[s] URIs "lifetime": {
?"credentials": ; for digest authentication "type": "integer",
[ 1* { "description":
"realm": string, "how long (in seconds) the RUE MAY cache the configuration values",
"username": string, },
"password": string "display-name": {
} ], "type": "string",
* /^.*$/ : any ; (allow future extensions) "description":
} "A user-friendly name to identify the subscriber when originating calls",
},
"phone-number": {
"type": "string",
"description":
"The telephone number (in E.164 format) assigned to this subscriber",
},
"provider-domain": {
"type": "string",
"description":
"The DNS domain name of the default Provider servicing this subscriber",
},
"outbound-proxies": {
"type": "array",
"description":
"List of URIs of SIP proxies to be used when sending requests to the Provider",
"items": {
"type": "string",
"format": "uri"
}
},
"mwi": {
"type": "string",
"format": "uri",
"description":
"A URI of a SIP event server that generates message-summary events",
},
"videomail": {
"type": "string",
"format": "uri",
"description":
"A SIP URI that can be called to retrieve videomail messages",
},
"contacts": {
"$id": "#/properties/contacts",
"type": "string",
"format": "uri",
"description":
"An HTTPS URI used to manage the subscriber's contact list at the Provider.",
},
"carddav": {
"type": "string",
"description":
"A username and domain name (separated by @) identifying a CardDAV server",
},
"sendLocationWithRegistration": {
"type": "boolean",
"description":
"True if the RUE should send a Geolocation Header with REGISTER",
"default": false,
},
"ice-servers": {
"type": "array",
"description":
"An array of URLs identifying STUN and TURN servers available",
"items": {
"type": "object",
"properties": {
"servertype": {
"type": "string"
},
"url": {
"type": "string"
}
}
}
},
"credentials": {
"type": "array",
"description": "registration credentials",
"additionalItems": true,
"items": {
"type": "object",
"required": [
"realm",
"username",
"password"
],
"properties": {
"realm": {
"type": "string",
"description":
"domain of provider matching domain in provider list",
},
"username": {
"type": "string",
"description": "username for registration"
},
"password": {
"type": "string",
"description": "password for registration",
}
},
}
}
},
}
Figure 5 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 Configuration Retrieval
,-. ,-.
`-' `-'
/|\ ,---. ,---. ,------------. ,----------------. ,---. /|\ ,---. ,---. ,------------. ,----------------. ,---.
 End of changes. 27 change blocks. 
100 lines changed or deleted 241 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/