[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-rosen-rue) 00 01 02 03 04

rum                                                             B. Rosen
Internet-Draft                                           5 February 2021
Intended status: Standards Track
Expires: 9 August 2021


           Interoperability Profile for Relay User Equipment
                         draft-ietf-rum-rue-04

Abstract

   Video Relay Service (VRS) is a term used to describe a method by
   which a hearing persons can communicate with deaf/Hard of Hearing
   user using an interpreter ("Communications Assistant") connected via
   a videophone to the deaf/HoH user and an audio telephone call to the
   hearing user.  The CA interprets using sign language on the
   videophone link and voice on the telephone link.  Often the
   interpreters may be supplied by a company or agency termed a
   "provider" in this document.  The provider also provides a video
   service that allows users to connect video devices to their service,
   and subsequently to CAs and other deaf/HoH users.  It is desirable
   that the videophones used by the deaf/HoH/H-I user conform to a
   standard so that any device may be used with any provider and that
   video calls direct between deaf/HoH users work.  This document
   describes the interface between a videophone and a provider.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 August 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Rosen                     Expires 9 August 2021                 [Page 1]


Internet-Draft        Relay User Equipment Profile         February 2021


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   5
   4.  General Requirements  . . . . . . . . . . . . . . . . . . . .   6
   5.  SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Registration  . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Session Establishment . . . . . . . . . . . . . . . . . .   8
       5.2.1.  Normal Call Origination . . . . . . . . . . . . . . .   8
       5.2.2.  One-Stage Dial-Around Origination . . . . . . . . . .   9
       5.2.3.  RUE Contact Information . . . . . . . . . . . . . . .  10
       5.2.4.  Incoming Calls  . . . . . . . . . . . . . . . . . . .  10
       5.2.5.  Emergency Calls . . . . . . . . . . . . . . . . . . .  11
     5.3.  Mid Call Signaling  . . . . . . . . . . . . . . . . . . .  11
     5.4.  URI Representation of Phone Numbers . . . . . . . . . . .  12
     5.5.  Transport . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Media . . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  SRTP and SRTCP  . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Text-Based Communication  . . . . . . . . . . . . . . . .  13
     6.3.  Video . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.4.  Audio . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.5.  DTMF Digits . . . . . . . . . . . . . . . . . . . . . . .  13
     6.6.  Session Description Protocol  . . . . . . . . . . . . . .  13
     6.7.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.8.  Negative Acknowledgment, Packet Loss Indicator, and Full
           Intraframe Request Features . . . . . . . . . . . . . . .  14
   7.  Contacts  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  CardDAV Login and Synchronization . . . . . . . . . . . .  14
     7.2.  Contacts Import/Export Service  . . . . . . . . . . . . .  15
   8.  Mail Waiting Indicator (MWI)  . . . . . . . . . . . . . . . .  15
   9.  Provisioning and Provider Selection . . . . . . . . . . . . .  15
     9.1.  RUE Provider Selection  . . . . . . . . . . . . . . . . .  15
     9.2.  RUE Configuration Service . . . . . . . . . . . . . . . .  17
     9.3.  Using the Provider List and Configuration Services
           Together  . . . . . . . . . . . . . . . . . . . . . . . .  20
     9.4.  OpenAPI Interface Descriptions  . . . . . . . . . . . . .  21
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  26
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26



Rosen                     Expires 9 August 2021                 [Page 2]


Internet-Draft        Relay User Equipment Profile         February 2021


     11.1.  RUE Provider List Registry . . . . . . . . . . . . . . .  26
     11.2.  Registration of rue-owner purpose parameter  . . . . . .  26
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  27
   13. Normative References  . . . . . . . . . . . . . . . . . . . .  27
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Introduction

   Video Relay Service (VRS) is a form of Telecommunications Relay
   Service (TRS) that enables persons with hearing disabilities who use
   sign language, such as American Sign Language (ASL), to communicate
   with voice telephone users through video equipment.  These services
   also enable communication between such individuals directly in
   suitable modalities, including any combination of sign language via
   video, real-time text (RTT), and speech.

   This Interoperability Profile for Relay User Equipment (RUE) is a
   profile of the Session Initiation Protocol (SIP) and related media
   protocols that enables end-user equipment registration and calling
   for VRS calls.  It specifies the minimal set of call flows, Internet
   Engineering Task Force (IETF) and ITU-T standards that must be
   supported, provides guidance where the standards leave multiple
   implementation options, and specifies minimal and extended
   capabilities for RUE calls.

   Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/
   HoH calls are supported on this interface.  While there are some
   accommodations in this document to maximize backwards compatibility
   with devices and services that conform to this document, backwards
   compatibility is not a requirement, and some interwork may be
   required to allow direct video calls to older devices.  This document
   only describes the interface between the device and the provider, and
   not any other interface the provider may have.

2.  Terminology

   Communication Assistant (CA): A sign-language interpreter working for
   a VRS Provider, providing functionally equivalent phone service.

   Communication modality (modality): A specific form of communication
   that may be employed by two users, e.g., English voice, Spanish
   voice, American Sign Language, English lip-reading, or French real-
   time-text.  Here, one communication modality is assumed to encompass
   both the language and the way that language is exchanged.  For
   example, English voice and French voice are two different
   communication modalities.





Rosen                     Expires 9 August 2021                 [Page 3]


Internet-Draft        Relay User Equipment Profile         February 2021


   Default video relay service: The video relay service operated by a
   subscriber's default VRS provider.

   Default video relay service Provider (Default Provider): The VRS
   provider that registers, and assigns a telephone number to a specific
   subscriber, and by default provides the VRS for incoming voice calls
   to the user.  The default Provider also by default provides VRS for
   outgoing relay calls.  The user can have more than one telephone
   number and each has a default provider.

   Dial-around call: A relay call where the subscriber specifies the use
   of a VRS provider other than the default VRS provider.  This can be
   accomplished by the user dialing a "front-door" number for a VRS
   provider and signing or texting a phone number to call ("two-stage").
   Alternatively, this can be accomplished by the user's RUE software
   instructing the server of its default VRS provider to automatically
   route the call through the alternate Provider to the desired public
   switched telephone network (PSTN) directory number ("one-stage").
   Dial-around is per-call -- for any call, a user can use the default
   VRS provider or any dial-around VRS provider.

   Full Intra Request (FIR): A request to a video media sender,
   requiring that media sender to send a Decoder Refresh Point at the
   earliest opportunity.  FIR is sometimes known as "instantaneous
   decoder refresh request", "video fast update request", or "fast
   update request".  Point-to-Point Call (P2P Call): A call between two
   RUEs, without including a CA.

   Relay call: A call that allows persons with hearing or speech
   disabilities to use a RUE to talk to users of traditional voice
   services with the aid of a communication assistant (CA) to relay the
   communication.  Please refer to FCC-VRS-GUIDE.

   Relay-to-relay call: A call between two subscribers each using
   different forms of relay (video relay, IP relay, TTY), each with a
   separate CA to assist in relaying the conversation.

   Relay service (RS): A service that allow a registered subscriber to
   use a RUE to make and receive relay calls, point-to-point calls, and
   relay-to-relay calls.  The functions provided by the relay service
   include the provision of media links supporting the communication
   modalities used by the caller and callee, and user registration and
   validation, authentication, authorization, automatic call distributor
   (ACD) platform functions, routing (including emergency call routing),
   call setup, mapping, call features (such as call forwarding and video
   mail), and assignment of CAs to relay calls.





Rosen                     Expires 9 August 2021                 [Page 4]


Internet-Draft        Relay User Equipment Profile         February 2021


   Relay service Provider (Provider): An organization that operates a
   relay service.  A subscriber selects a relay service Provider to
   assign and register a telephone number for their use, to register
   with for receipt of incoming calls, and to provide the default
   service for outgoing calls.

   Relay user: Please refer to "subscriber".

   Relay user E.164 Number (user E.164): The telephone number (in ITU-T
   E.164 format) assigned to the user.

   Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra
   features to support a subscriber in requesting and using relay calls.
   A RUE may take many forms, including a stand-alone device; an
   application running on a general-purpose computing device such as a
   laptop, tablet or smart phone; or proprietary equipment connected to
   a server that provides the RUE interface.

   RUE Interface: the interfaces described in this document between a
   RUE and the VRS provider who supports it

   Sign language: A language that uses hand gestures and body language
   to convey meaning including, but not limited to, American Sign
   Language (ASL).

   Subscriber: An individual who has registered with a Provider and who
   obtains service by using relay user equipment.  This is the
   traditional telecom term for an end-user customer, which in our case
   is a relay user.  A user may be a subscriber to more than one VRS
   provider.

   Video relay service (VRS): A relay service for people with hearing or
   speech disabilities who use sign language to communicate using video
   equipment (video RUE) with other people in real time.  The video link
   allows the CA to view and interpret the subscriber's signed
   conversation and relay the conversation back and forth with the other
   party.

3.  Requirements Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119]








Rosen                     Expires 9 August 2021                 [Page 5]


Internet-Draft        Relay User Equipment Profile         February 2021


4.  General Requirements

   All HTTP/HTTPS connections specified throughout this document MUST
   use HTTPS.  Both HTTPS and all SIP connections MUST use TLS
   conforming to at least [RFC7525] and must support [RFC8446]

   All text data payloads not otherwise constrained by a specification
   in another standards document MUST be encoded as Unicode UTF/8.

   Implementations MUST support IPv4 and IPv6.

5.  SIP Signaling

   Implementations of the RUE Interface MUST conform to the following
   core SIP standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP
   Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent
   Capabilities), [RFC5626] (Outbound), [RFC8866] (Session Description
   Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP),
   [RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop-
   Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960]
   (Early Media), and [RFC6442] (Geolocation Header).

   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),
   [RFC3891] (Replaces Header), [RFC3892] (Referred-By).

   Implementations MUST include a "User-Agent" header field uniquely
   identifying the RUE application, platform, and version in all SIP
   requests, and MUST include a "Server" header field with the same
   content in SIP responses.

5.1.  Registration

   The RUE MUST register with a SIP registrar, following [RFC3261] and
   [RFC5626] at a provider it has an account with.  If the configuration
   (please refer to Section 11) contains multiple "outbound-proxies",
   then the RUE MUST use them as specified in [RFC5626] to establish
   multiple flows.





Rosen                     Expires 9 August 2021                 [Page 6]


Internet-Draft        Relay User Equipment Profile         February 2021


   The request-URI for the REGISTER request MUST contain the "provider-
   domain" from the configuration.  The To-URI and From-URI MUST be
   identical URIs, formatted as specified in Section 13, using the
   "phone-number" and "provider-domain" from the configuration.

   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.  If no outbound proxy is configured, the URI will be
   the Request-URI from the REGISTER request.  The RUE extracts the
   domain from that URI and consults the DNS record for that domain.
   The DNS entry MUST contain NAPTR records conforming to RFC3263.  One
   of those NAPTR records MUST specify TLS as the preferred transport
   for SIP.  For example, a DNS NAPTR query for "sip:
   p1.red.example.netv" could return:

         IN NAPTR 50  50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net
         IN NAPTR 90  50 "s" "SIP+D2T"  "" _sip._tcp.p1.red.example.net

   If the RUE receives a 439 (First Hop Lacks Outbound Support) response
   to a REGISTER request, it MUST re-attempt registration without using
   the outbound mechanism.

   The registrar MAY authenticate using SIP MD5 digest authentication.
   The credentials to be used (username and password) MUST be supplied
   within the credentials section of the configuration and identified by
   the realm the registrar uses in a digest challenge.  This username/
   password combination SHOULD NOT be the same as that used for other
   purposes, such as retrieving the RUE configuration or logging into
   the Provider's customer service portal.  Because MD5 is considered
   insecure, [I-D.yusef-sipcore-digest-scheme] SHOULD be implemented by
   all implementations and SHA-based digest algorithms SHOULD be used
   for digest authentication.

   If the registration request fails with an indication that credentials
   from the configuration are invalid, then the RUE SHOULD retrieve a
   fresh version of the configuration.  If credentials from a freshly
   retrieved configuration are found to be invalid, then the RUE MUST
   cease attempts to register and SHOULD inform the RUE User of the
   problem.

   Support for multiple simultaneous registrations is OPTIONAL.










Rosen                     Expires 9 August 2021                 [Page 7]


Internet-Draft        Relay User Equipment Profile         February 2021


   Multiple simultaneous RUE SIP registrations from different RUE
   devices with the same SIP URI SHOULD be permitted by the Provider.
   The Provider MAY limit the total number of simultaneous
   registrations.  When a new registration request is received that
   results in exceeding the limit on simultaneous registrations, the
   Provider MAY then prematurely terminate another registration;
   however, it SHOULD NOT do this if it would disconnect an active call.

   If a Provider prematurely terminates a registration to reduce the
   total number of concurrent registrations with the same URI, it SHOULD
   take some action to prevent the affected RUE from automatically re-
   registering and re-triggering the condition.

5.2.  Session Establishment

5.2.1.  Normal Call Origination

   After initial SIP registration, the RUE adheres to SIP [RFC3261]
   basic call flows, as documented in [RFC3665].

   A RUE device MUST route all outbound calls through an outbound proxy
   if configured.

   The SIP URIs in the To field and the Request-URI MUST be formatted as
   specified in subsection Section 5.4 using the destination phone
   number.  The domain field of the URIs SHOULD be the "provider-domain"
   from the configuration (e.g.,
   sip:+13115552368@red.example.com;user=phone).  The same exceptions
   apply, including anonymous calls.

   Anonymous calls MUST be supported by all implementations.  An
   anonymous call is signaled per [RFC3323].

   The From-URI MUST be formatted as specified in Section 5.4, using the
   phone-number and "provider-domain" from the configuration.  It SHOULD
   also contain the display-name from the configuration when present.
   (Please refer to Section 9.2.)

   Negotiated media MUST follow the guidelines specified in Section 6 of
   this document.

   To allow time to timeout an unanswered call and direct it to a
   videomail server, the User Agent Client MUST NOT impose a time limit
   less than the default SIP Invite transaction timeout of 3 minutes.







Rosen                     Expires 9 August 2021                 [Page 8]


Internet-Draft        Relay User Equipment Profile         February 2021


5.2.2.  One-Stage Dial-Around Origination

   Outbound dial-around calls allow a RUE user to select any Provider to
   provide interpreting services for any call.  "Two-stage" dial-around
   calls involve the RUE calling a telephone number that reaches the
   dial-around Provider and using signing or DTMF to provide the called
   party telephone number.  In two-stage dial-around, the To URI is the
   URI of the dial-around Provider and the domain of the URI is the
   Provider domain from the configuration.

   One-stage dial-around is a method where the called party telephone
   number is provided in the To URI and the Request-URI, using the
   domain of the dial-around Provider.

   For one-stage dial-around, the RUE MUST follow the procedures in
   Section 5.2.1 with the following exception: the domain part of the
   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 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
   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
   many header fields have been omitted:

   One Stage Dial-Around

























Rosen                     Expires 9 August 2021                 [Page 9]


Internet-Draft        Relay User Equipment Profile         February 2021


     ,-+-.        ,----+----.    ,-----+-----.
     |RUE|        |Default  |    |Dial-Around|
     |   |        |Provider |    | Provider  |
     `-+-'        `----+----'    `-----+-----'
       |               |               |
       | [1] INVITE    |               |
       |-------------->| [2] INVITE    |
       |               |-------------->|

     Message Details:

     [1] INVITE Rue -> Default Provider

     INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
     To: <sip:+15551234567@green.example.net;user=phone>
     From: "Bob Smith" <sip:+18135551212@red.example.net;user=phone>
     Route: sip:green.example.net


     [2] INVITE Default Provider -> Dial-Around Provider

     INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0
     To: <sip:+15551234567@green.example.net;user=phone>
     From: "Bob Smith" sip:+18135551212@red.example.net;user=phone
     P-Asserted-Identity: sip:+18135551212@red.example.net

                                  Figure 1

5.2.3.  RUE Contact Information

   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
   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
   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
   MIME body.  The form of the RUE ownership information is a jCard
   [RFC7095].  Please refer to [RFC6442] for an example of using
   Content-Indirect URLs in SIP messages.  Note that use of the Content-
   Indirect URL usually implies multiple message bodies ("mime/
   multipart").

5.2.4.  Incoming Calls

   The RUE MUST only accept inbound calls sent to it by the proxy
   mentioned in the configuration.





Rosen                     Expires 9 August 2021                [Page 10]


Internet-Draft        Relay User Equipment Profile         February 2021


   If Multiple simultaneous RUE SIP registrations from different RUE
   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 first RUE to reply with a 200 OK answers the call and the
   Provider MUST CANCEL other call branches.

5.2.5.  Emergency Calls

   Implementations MUST conform to [RFC6881] for handling of emergency
   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
   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 of a RUE device 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.  Re-registration SHOULD be
   used to update the location, so long as the rate of re-registration
   is limited if the device is moving.

   Implementations MUST implement Additional Data, [RFC7852].  RUE
   devices MUST implement Data Provider, Device Implementation and
   Owner/Subscriber Information blocks.

5.3.  Mid Call Signaling

   Implementations MUST support re-INVITE to renegotiate media session
   parameters (among other uses).  Per Section 6.1, implementations
   MUST, be able to support an INFO request for full frame refresh for
   devices that do not support RTCP mechanisms (please refer to
   Section 6.8).  Implementations MUST support an in-dialog REFER
   ([RFC3515] updated by [RFC7647] and including support for norefersub
   per [RFC4488]) with the Replaces header [RFC3891] to enable call
   transfer.




Rosen                     Expires 9 August 2021                [Page 11]


Internet-Draft        Relay User Equipment Profile         February 2021


5.4.  URI Representation of Phone Numbers

   SIP URIs constructed from non-URI sources (dial strings) and sent to
   SIP proxies by the RUE MUST be represented as follows, depending on
   whether they can be represented as an E.164 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
   user part of the URI MUST be in conformance with 'global-number'
   defined in [RFC3966].  The user part MUST NOT contain any 'visual-
   separator' characters.

   Dial strings that cannot be written as E.164 numbers MUST be
   represented as dialstring URIs, as specified by [RFC4967], e.g.,
   sip:411@red.example.net;user=dialstring.

   The domain part of Relay Service URIs and User Address of Records
   (AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or
   IPv6 addresses.

5.5.  Transport

   Implementations MUST conform to [RFC8835] except that that this
   specification does not use the WebRTC data 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
   refer to Section 5.1).

6.  Media

   This specification adopts the media specifications for WebRTC
   ([RFC8825]).  Where WebRTC defines how interactive media
   communications may be established using a browser as a client, this
   specification assumes a normal SIP call.  The RTP, RTCP, SDP and
   specific media requirements specified for WebRTC are adopted for this
   document.  The RUE is a WebRTC non-browser" endpoint, except as noted
   expressly below.

   The following sections specify the WebRTC documents to which
   conformance is required.  "Mandatory to Implement" means a conforming
   implementation must implement the specified capability.  It does not
   mean that the capability must be used in every session.  For example,
   OPUS is a mandatory to implement audio codec, and all conforming
   implementations must support OPUS.  However, implementation
   presenting a call across the RUE Interface where the call originates
   in the Public Switched Telephone Network, or an older, non-RUE-



Rosen                     Expires 9 August 2021                [Page 12]


Internet-Draft        Relay User Equipment Profile         February 2021


   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

   Implementations MUST support [RFC8834] except that MediaStreamTracks
   are not used.  Implementations MUST conform to Section 6.4 of
   [RFC8827].

6.2.  Text-Based Communication

   Implementations MUST support real-time text ([RFC4102] and [RFC4103])
   via T.140 media.  One original and two redundant generations MUST be
   transmitted and supported, with a 300 ms transmission interval.  Note
   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
   the data channel of WebRTC to RFC4103 real time text.

6.3.  Video

   Implementations MUST conform to [RFC7742] with the exception that,
   since backwards compatibility is desirable and older devices do not
   support VP8, that only H.264, as specified in [RFC7742] is Mandatory
   to Implement and VP8 support is OPTIONAL at both the device and
   providers.

6.4.  Audio

   Implementations MUST conform to [RFC7874].

6.5.  DTMF Digits

   Implementations MUST support the "audio/telephone-event" [RFC4733]
   media type.  They MUST support conveying event codes 0 through 11
   (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733].
   Handling of other tones is OPTIONAL.

6.6.  Session Description Protocol

   The SDP offers and answers MUST conform to [RFC8829] except that the
   RUE Interface uses SIP transport for SDP.

   note: parts of 8829 are not applicable.  Need text to handle that,
   and possibly require conformance to 8866/3264






Rosen                     Expires 9 August 2021                [Page 13]


Internet-Draft        Relay User Equipment Profile         February 2021


6.7.  Privacy

   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
   MUST maintain any NAT bindings by periodically sending media packets
   on all active media sessions containing silence/comfort noise/black
   screen/etc. per [RFC6263].

6.8.  Negative Acknowledgment, Packet Loss Indicator, and Full
      Intraframe Request Features

   NACK SHOULD be used when negotiated and conditions warrant its use.
   Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be
   preferred, as described in [RFC5104].

   FIR SHOULD be used only in situations where not sending a decoder
   refresh point would render the video unusable for the users, as per
   RFC5104 subsection 4.3.1.2.

   For backwards compatibility with calling devices that do not support
   the foregoing methods, implementations MUST implement SIP INFO
   messages to send and receive XML encoded Picture Fast Update messages
   according to [RFC5168].

7.  Contacts

7.1.  CardDAV Login and Synchronization

   Support of CardDAV by Providers is OPTIONAL.

   The RUE MUST and Providers MAY be able to synchronize the user's
   contact directory between the RUE endpoint and one maintained by the
   user's VRS provider using CardDAV ([RFC6352] and [RFC6764]).

   The configuration MAY supply a username and domain identifying a
   CardDAV server and address book for this account.

   To access the CardDAV server and address book, the RUE MUST follow
   Section 6 of RFC6764, using the chosen username and domain in place
   of an email address.  If the request triggers a challenge for digest
   authentication credentials, the RUE MUST attempt to continue using
   matching "credentials" from the configuration.  If no matching
   credentials are configured, the RUE MUST use the SIP credentials from
   the configuration.  If the SIP credentials fail, the RUE MUST query
   the user.






Rosen                     Expires 9 August 2021                [Page 14]


Internet-Draft        Relay User Equipment Profile         February 2021


   Synchronization using CardDAV MUST be a two-way synchronization
   service, with proper handling of asynchronous adds, changes, and
   deletes at either end of the transport channel.

7.2.  Contacts Import/Export Service

   Implementations MUST be able to export/import the list of contacts in
   jCard [RFC7095] json format.

   The RUE accesses this service via the "contacts" URI in the
   configuration.  The URL MUST resolve to identify a web server
   resource that imports/exports contact lists for authorized users.

   The RUE stores/retrieves the contact list (address book) by issuing
   an HTTPS POST or GET request.  If the request triggers a challenge
   for digest authentication credentials, the RUE MUST attempt to
   continue using matching "credentials" from the configuration.  If no
   credentials are configured, the RUE MUST query the user.

8.  Mail Waiting Indicator (MWI)

   Support of MWI by Providers is OPTIONAL

   Implementations MUST support subscriptions to "message-summary"
   events [RFC3842] to the URI specified in the configuration.

   In notification bodies, videomail messages SHOULD be reported using
   "message-context-class multimedia-message" defined in [RFC3458].

9.  Provisioning and Provider Selection

   To simplify how users interact with RUE devices, the RUE interface
   separates provisioning into two parts.  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
   provides configuration data for the device for each provider.

9.1.  RUE Provider Selection

   To allow the user to select a relay service, the RUE MAY obtain, on
   startup, a list of Providers that provide service in a country.  IANA
   has established a registry that contains a two letter country code
   and a URI.  The URI, when used with the following interface, returns
   a list of provider names for a country code suitable for display,
   with a corresponding a URI to obtain information about that provider.
   The provider URI is the entry point of a simple web service that
   returns contact information for that provider.




Rosen                     Expires 9 August 2021                [Page 15]


Internet-Draft        Relay User Equipment Profile         February 2021


   Each country that supports video relay service using this
   specification MAY support the provider list.  This document does not
   specify who maintains the list.  Some possibilities are a regulator
   or entity designated by a regulator, an agreement among providers to
   provide the list, or a user group.

   The web service also has a simple version mechanism that returns a
   list of versions of the web service it supports.  This document
   describes version 1.0.  Versions are described as a major version,
   the period "." and a minor version, where major and minor versions
   are integers.  A backwards compatible change within a major version
   MAY increment only the minor version number.  A non-backwards
   compatible change MUST increment the major version number.
   Implementations MUST ignore any object members they do not implement.
   This means an implementation of a specific major version and minor
   version is backwards compatible with all minor versions less than
   that minor version within the major version.  The versions mechanism
   returns an array of supported versions, one for each major version
   supported, with the minor version listed being the highest supported
   minor version.

   The provider list is a json object consisting of an array where each
   entry describes one Provider.  Each entry consists of the following
   items:

   *  name: This parameter contains the text label identifying the
      Provider and is meant to be displayed to the human VRS user.

   *  domain: The domain parameter is used for configuration purposes by
      the RUE (as discussed in Section 9.2)

   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
   account, wishes to establish an account, or wishes to use the
   provider for a one stage dial around.
















Rosen                     Expires 9 August 2021                [Page 16]


Internet-Draft        Relay User Equipment Profile         February 2021


     {
       "providers": [
         {
           "name": "Red",
           "domain": "red.example.net",
         },
         {
           "name": "Green",
           "domain": "green.example.net",
         },
         {
           "name": "Blue",
           "domain": "blue.example.net"
         }
       ]
     }

              Figure 2: Example of a Provider list JSON object

     {
       "versions": [
         {
           "major": 1,
           "minor": 6,
         },
         {
           "major": 2,
           "minor": 13,
         },
         {
           "major": 3,
           "minor": 2
         }
       ]
     }

                 Figure 3: Example of a Version JSON object

9.2.  RUE Configuration Service

   A RUE device may retrieve a provider configuration the using a simple
   HTTPs web service.  The device uses the userid/password to
   authenticate to the interface if it has credentials for that
   provider.  Without user credentials, the response includes
   configuration data for new user sign up and dial around.






Rosen                     Expires 9 August 2021                [Page 17]


Internet-Draft        Relay User Equipment Profile         February 2021


   An optional parameter may be provided to the interface which is an
   API Key.  The implementation MAY have an API Key obtained from the
   provider and specific to the implementation.  The method the API Key
   is obtained is not specified in this document.  The provider MAY
   refuse to provide service to an implementation presenting an API Key
   it does not recognize.

   The data returned is a json object consisting of an array of key/
   value configuration parameters to be used by the RUE.

   The configuration data payload includes the following data items.
   Items not noted as (OPTIONAL) are REQUIRED.  If other unexpected
   items are found, they MUST be ignored.

   *  signup: (OPTIONAL) an array of json objects consisting of:

      -  language: entry from the IANA language subtag registry

      -  uri: a URI to the website for the supported language

   *  dialAround: an array of json objects consisting of:

      -  language: entry from the IANA language subtag registry

      -  frontDoor: a URI to a queue of interpreters supporting the
         specified language for a two stage dial-around

      -  oneStage: (OPTIONAL) a URI that can be used with a one-stage
         dial-around Section 5.2.2 using an interpreter supporting the
         specified language

   *  helpDesk: (OPTIONAL) an array of json objets consisting of:

      -  language: entry from the IANA language subtag registry

      -  uri: URI that reaches a help desk for callers supporting the
         specified language.

   *  lifetime: Specifies how long (in seconds) the RUE MAY cache the
      configuration values.  Values may not be valid when lifetime
      expires.  Emergency Calls MUST continue to work.

   *  phone-number: (OPTIONAL) The telephone number (in E.164 format)
      assigned to this subscriber.  This becomes the user portion of the
      SIP URI identifying the subscriber.

   *  outbound-proxy: (OPTIONAL) A URI of a SIP proxy to be used when
      sending requests to the Provider.



Rosen                     Expires 9 August 2021                [Page 18]


Internet-Draft        Relay User Equipment Profile         February 2021


   *  mwi: (OPTIONAL) A URI identifying a SIP event server that
      generates "message-summary" events for this subscriber.

   *  videomail: (OPTIONAL) A SIP URI that can be called to retrieve
      videomail messages.

   *  contacts: (CONDITIONAL) An HTTPS URI that may be used to export
      (retrieve) the subscriber's complete contact list managed by the
      Provider.

   *  carddav: (OPTIONAL) A username and domain name (separated by
      ""@"") identifying a "CardDAV" server and user name that can be
      used to synchronize the RUE's contact list with the contact list
      managed by the Provider.

   *  sendLocationWithRegistration: (OPTIONAL) True if the RUE should
      send a Geolocation Header with REGISTER, false if it should not.
      Defaults to false if not present.

   *  ice-servers: (OPTIONAL) An array of URLs identifying STUN and TURN
      servers available for use by the RUE for establishing media
      streams in calls via the Provider.

   The configuration API also provides the same version mechanism as
   specified above in Section 9.1.  The version of the configuration
   service MAY be different than the version of the configuration
   service.

   Example JSON configuration payload






















Rosen                     Expires 9 August 2021                [Page 19]


Internet-Draft        Relay User Equipment Profile         February 2021


     {
       "signUp": [
          { "language" : "en", "uri" : "welcome-en.example.net"} ,
          { "language" : "es", "uri" : "welcome-es.example.net"} ] ,
       "dialAround": [
          { "language" : "en", "frontDoor" : "fd-en.example.net",
               "oneStage" : "1stg-eng.example.com" } ,
          { "language" : "es", "frontDoor" : "fd-es.example.net",
               "oneStage" : "1stg-spn.example.com" } ] ,
       "helpDesk": [
          { "language" : "en", "uri" : "help-en.example.net"} ,
          { "language" : "es", "uri" : "help-es.example.net"} ] ,
       "lifetime": 86400,
       "display-name" : "Bob Smith",
       "phone-number": "+18135551212",
       "provider-domain": "red.example.net",
       "outbound-proxies": [
         "sip:p1.red.example.net",
         "sip:p2.red.example.net"
         ],
       "mwi": "sip:+18135551212@red.example.net",
       "videomail": "sip:+18135551212@vm.red.example.net",
       "contacts": "https://red.example.net:443/contacts/1dess45awd",
       "carddav": "bob@red.example.com" ,
       "sendLocationWithRegistration": false,
       "ice-servers": [
          {"stun":"stun.l.google.com:19302" },
          {"turn":"turn.red.example.net:3478"}
       ],
       }

                                  Figure 4

   The "lifetime" parameter in the configuration indicates how long the
   RUE MAY cache the configuration values.  If the RUE caches
   configuration values, it MUST cryptographically protect them.  The
   RUE SHOULD retrieve a fresh copy of the configuration before the
   lifetime expires or as soon as possible after it expires.  The
   lifetime is not guaranteed: the configuration may change before the
   lifetime value expires.  In that case, the Provider MAY indicate this
   by generating authorization challenges to requests and/or prematurely
   terminating a registration.

9.3.  Using the Provider List and Configuration Services Together

   One way to use these two services is:





Rosen                     Expires 9 August 2021                [Page 20]


Internet-Draft        Relay User Equipment Profile         February 2021


   *  At startup, the RUE retrieves the provider list for the country it
      is located in.

   *  For each provider in the list:

      -  If the RUE does not have credentials for that provider, use the
         configuration service without credentials to obtain signup,
         dial around and helpdesk information.

      -  If the RUE has credentials for that provider, use the
         configuration service with credentials to obtain all
         configuration data.

9.4.  OpenAPI Interface Descriptions

   The interfaces in Sections Section 9.1 and Section 9.2 are formally
   specified with OpenAPI 3.0 descriptions in yaml form.

   openapi: 3.0.1
   info:
     title: RUM API
     version: "1.0"
   servers:
     - url: http://localhost/rum/v1
   paths:
     /Providers:
       get:
         summary: Get a list of providers to get config data from
         operationId: GetProviderList
         responses:
           '200':
             description: List of providers for a country
             content:
               application/json:
                 schema:
                   $ref: '#/components/schemas/ProviderList'
     /Versions:
       servers:
         - url: https://api.example.com/rum
           description: Override base path for Versions query
       get:
         summary: Retrieves all supported versions
         operationId: RetrieveVersions
         responses:
           '200':
             description: Versions supported
             content:
               application/json:



Rosen                     Expires 9 August 2021                [Page 21]


Internet-Draft        Relay User Equipment Profile         February 2021


                 schema:
                   $ref: '#/components/schemas/VersionsArray'
   components:
     schemas:
       ProviderList:
         type: object
         required:
           - providers
         properties:
           providers:
             type: array
             items:
               type: object
               required:
                 - name
                 - domain
               properties:
                 name:
                   type: string
                   description: Human readable provider name
                 domain:
                   type: string
                   description: provider domain for interface
       VersionsArray:
         type: object
         required:
           - versions
         properties:
           versions:
             type: array
             items:
               type: object
               required:
                 - major
                 - minor
               properties:
                 major:
                   type: integer
                   format: int32
                   description: Version major number
                 minor:
                   type: integer
                   format: int32
                   description: Version minor number

                Figure 5: Provider List OpenAPI description





Rosen                     Expires 9 August 2021                [Page 22]


Internet-Draft        Relay User Equipment Profile         February 2021


openapi: 3.0.1
info:
  title: RUM API
  version: "1.0"
servers:
  - url: http://localhost/rum/v1
paths:
  /Configuration:
    get:
      summary: Configuration data for one provider
      operationId: GetConfiguration
      responses:
        '200':
          description: configuration object
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ConfigurationData'
  /Versions:
    servers:
      - url: https://api.example.com/rum
        description: Override base path for Versions query
    get:
      summary: Retrieves all supported versions
      operationId: RetrieveVersions
      responses:
        '200':
          description: Versions supported
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/VersionsArray'
components:
  schemas:
    ConfigurationData:
      type: object
      properties:
        signup:
          type: object
          required:
            - language
            - uri
          properties:
            language:
              type: string
              description: entry from IANA language-subtag-registry
            uri:
              type: string



Rosen                     Expires 9 August 2021                [Page 23]


Internet-Draft        Relay User Equipment Profile         February 2021


              format: uri
              description: uri to signup website supporting language
        dialAround:
          type: object
          required:
            - language
            - frontDoor
          properties:
            language:
              type: string
              description: entry from IANA language-subtag-registry
            frontDoor:
              type: string
              format: uri
              description: SIP uri for 2 stage dial around
            oneStage:
              type: string
              format: uri
              description: SIP uri for 1 stage dial around
        helpDesk:
          type: object
          required:
            - language
            - uri
          properties:
            language:
              type: string
              description: entry from IANA language-subtag-registry
            uri:
              type: string
              format: uri
              description: SIP uri of helpdesk supporting language
        phone-number:
          type: string
          description: telephone number assigned this subscriber
        outbound-proxy:
          type: string
          format: uri
          description: SIP uri of proxy to be used when sending requests
             to the Provider
        mwi:
          type: string
          format: uri
          description: A URI identifying a SIP event server that
            generates "message-summary" events for this subscriber.
        videomail:
          type: string
          format: uri



Rosen                     Expires 9 August 2021                [Page 24]


Internet-Draft        Relay User Equipment Profile         February 2021


          description: A SIP URI used to retrieve videomail
             messages.
        contacts:
          type: string
          format: uri
          description: An HTTPS URI that may be used to export
            (retrieve) the subscriber's complete contact list
            managed by the Provider.
        carddav:
          type: string
          format: uri
          description: A username and domain name (separated by ""@"")
            identifying a ""CardDAV"" server and user name that can be
            used to synchronize the RUE's contact list with the
            contact list managed by the Provider.
        sendLocationWithRegistration:
          type: boolean
          description: True if the RUE should send a Geolocation Header
            with REGISTER, false if it should not. Defaults to false if
            not present.
        ice-servers:
          type: array
          items:
            type: string
            format: uri
            description: URIs identifying STUN and TURN servers
              available for use by the RUE for establishing media
              streams in calls via the Provider
    VersionsArray:
      type: object
      required:
        - versions
      properties:
        versions:
          type: array
          items:
            type: object
            required:
              - major
              - minor
            properties:
              major:
                type: integer
                format: int32
                description: Version major number
              minor:
                type: integer
                format: int32



Rosen                     Expires 9 August 2021                [Page 25]


Internet-Draft        Relay User Equipment Profile         February 2021


                description: Version minor number

             Figure 6: Configuration OpenAPI description

10.  Acknowledgements

   Brett Henderson and Jim Malloy provided many helpful edits to prior
   versions of this document.

11.  IANA Considerations

11.1.  RUE Provider List Registry

   IANA has created the "RUE Provider List" registry.  The management
   policy for this registry is "Expert Review" [RFC8126].  The expert
   should prefer a regulator operated or designated list interface
   operator.  Otherwise, evidence that the proposed list interface
   operator will provide a complete list of providers is required to add
   the entry to the registry.  Updates to the registry are permitted if
   the expert judges the new proposed uri to be better than the existing
   entry.  Each entry has two fields, values for both of which MUST be
   provided when registering or updating an entry:

   *  country code: a two letter ISO93166 country code

   *  list uri: a uri that implements the provider list interface for
      that country

11.2.  Registration of rue-owner purpose parameter

   This document defines the new predefined value "rue-owner" for the
   "purpose" header field parameter of the Call-Info header field.  This
   modifies the "Header Field Parameters and Parameter Values"
   subregistry of the "Session Initiation Protocol (SIP) Parameters"
   registry by adding this RFC as a reference to the line for the header
   field "Call-Info" and parameter name "purpose"

   *  Header Field: Call-Info

   *  Parameter Name: purpose

   *  Predefined Values: Yes









Rosen                     Expires 9 August 2021                [Page 26]


Internet-Draft        Relay User Equipment Profile         February 2021


12.  Security Considerations

   The RUE is required to communicate with servers on public IP
   addresses and specific ports to perform its required functions.  If
   it is necessary for the RUE to function on a corporate or other
   network that operates a default-deny firewall between the RUE and
   these services, the user must arrange with their network manager for
   passage of traffic through such a firewall in accordance with the
   protocols and associated SRV records as exposed by the Provider.
   Because VRS providers may use different ports for different services,
   these port numbers may differ from Provider to Provider.

13.
Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              DOI 10.17487/RFC3263, June 2002,
              <https://www.rfc-editor.org/info/rfc3263>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <https://www.rfc-editor.org/info/rfc3264>.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840,
              DOI 10.17487/RFC3840, August 2004,
              <https://www.rfc-editor.org/info/rfc3840>.






Rosen                     Expires 9 August 2021                [Page 27]


Internet-Draft        Relay User Equipment Profile         February 2021


   [RFC5626]  Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
              "Managing Client-Initiated Connections in the Session
              Initiation Protocol (SIP)", RFC 5626,
              DOI 10.17487/RFC5626, October 2009,
              <https://www.rfc-editor.org/info/rfc5626>.

   [RFC8866]  Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
              Session Description Protocol", RFC 8866,
              DOI 10.17487/RFC8866, January 2021,
              <https://www.rfc-editor.org/info/rfc8866>.

   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
              Initiation Protocol (SIP)", RFC 3323,
              DOI 10.17487/RFC3323, November 2002,
              <https://www.rfc-editor.org/info/rfc3323>.

   [RFC3605]  Huitema, C., "Real Time Control Protocol (RTCP) attribute
              in Session Description Protocol (SDP)", RFC 3605,
              DOI 10.17487/RFC3605, October 2003,
              <https://www.rfc-editor.org/info/rfc3605>.

   [RFC6665]  Roach, A.B., "SIP-Specific Event Notification", RFC 6665,
              DOI 10.17487/RFC6665, July 2012,
              <https://www.rfc-editor.org/info/rfc6665>.

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
              2002, <https://www.rfc-editor.org/info/rfc3311>.

   [RFC5393]  Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B.
              Campen, "Addressing an Amplification Vulnerability in
              Session Initiation Protocol (SIP) Forking Proxies",
              RFC 5393, DOI 10.17487/RFC5393, December 2008,
              <https://www.rfc-editor.org/info/rfc5393>.

   [RFC5658]  Froment, T., Lebel, C., and B. Bonnaerens, "Addressing
              Record-Route Issues in the Session Initiation Protocol
              (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009,
              <https://www.rfc-editor.org/info/rfc5658>.

   [RFC5954]  Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed.,
              "Essential Correction for IPv6 ABNF and URI Comparison in
              RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010,
              <https://www.rfc-editor.org/info/rfc5954>.







Rosen                     Expires 9 August 2021                [Page 28]


Internet-Draft        Relay User Equipment Profile         February 2021


   [RFC3960]  Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
              Tone Generation in the Session Initiation Protocol (SIP)",
              RFC 3960, DOI 10.17487/RFC3960, December 2004,
              <https://www.rfc-editor.org/info/rfc3960>.

   [RFC6442]  Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
              for the Session Initiation Protocol", RFC 6442,
              DOI 10.17487/RFC6442, December 2011,
              <https://www.rfc-editor.org/info/rfc6442>.

   [RFC3327]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol
              (SIP) Extension Header Field for Registering Non-Adjacent
              Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002,
              <https://www.rfc-editor.org/info/rfc3327>.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              DOI 10.17487/RFC5245, April 2010,
              <https://www.rfc-editor.org/info/rfc5245>.

   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, DOI 10.17487/RFC3326, December 2002,
              <https://www.rfc-editor.org/info/rfc3326>.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, DOI 10.17487/RFC3515, April 2003,
              <https://www.rfc-editor.org/info/rfc3515>.

   [RFC4488]  Levin, O., "Suppression of Session Initiation Protocol
              (SIP) REFER Method Implicit Subscription", RFC 4488,
              DOI 10.17487/RFC4488, May 2006,
              <https://www.rfc-editor.org/info/rfc4488>.

   [RFC7647]  Sparks, R. and A.B. Roach, "Clarifications for the Use of
              REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647,
              September 2015, <https://www.rfc-editor.org/info/rfc7647>.

   [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
              Protocol (SIP) "Replaces" Header", RFC 3891,
              DOI 10.17487/RFC3891, September 2004,
              <https://www.rfc-editor.org/info/rfc3891>.

   [RFC3892]  Sparks, R., "The Session Initiation Protocol (SIP)
              Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892,
              September 2004, <https://www.rfc-editor.org/info/rfc3892>.




Rosen                     Expires 9 August 2021                [Page 29]


Internet-Draft        Relay User Equipment Profile         February 2021


   [RFC3665]  Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
              K. Summers, "Session Initiation Protocol (SIP) Basic Call
              Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665,
              December 2003, <https://www.rfc-editor.org/info/rfc3665>.

   [RFC2392]  Levinson, E., "Content-ID and Message-ID Uniform Resource
              Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
              <https://www.rfc-editor.org/info/rfc2392>.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, DOI 10.17487/RFC3966, December 2004,
              <https://www.rfc-editor.org/info/rfc3966>.

   [RFC4967]  Rosen, B., "Dial String Parameter for the Session
              Initiation Protocol Uniform Resource Identifier",
              RFC 4967, DOI 10.17487/RFC4967, July 2007,
              <https://www.rfc-editor.org/info/rfc4967>.

   [RFC4102]  Jones, P., "Registration of the text/red MIME Sub-Type",
              RFC 4102, DOI 10.17487/RFC4102, June 2005,
              <https://www.rfc-editor.org/info/rfc4102>.

   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
              <https://www.rfc-editor.org/info/rfc4103>.

   [RFC4733]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
              Digits, Telephony Tones, and Telephony Signals", RFC 4733,
              DOI 10.17487/RFC4733, December 2006,
              <https://www.rfc-editor.org/info/rfc4733>.

   [RFC6263]  Marjou, X. and A. Sollaud, "Application Mechanism for
              Keeping Alive the NAT Mappings Associated with RTP / RTP
              Control Protocol (RTCP) Flows", RFC 6263,
              DOI 10.17487/RFC6263, June 2011,
              <https://www.rfc-editor.org/info/rfc6263>.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
              February 2008, <https://www.rfc-editor.org/info/rfc5104>.

   [RFC5168]  Levin, O., Even, R., and P. Hagendorf, "XML Schema for
              Media Control", RFC 5168, DOI 10.17487/RFC5168, March
              2008, <https://www.rfc-editor.org/info/rfc5168>.






Rosen                     Expires 9 August 2021                [Page 30]


Internet-Draft        Relay User Equipment Profile         February 2021


   [RFC6352]  Daboo, C., "CardDAV: vCard Extensions to Web Distributed
              Authoring and Versioning (WebDAV)", RFC 6352,
              DOI 10.17487/RFC6352, August 2011,
              <https://www.rfc-editor.org/info/rfc6352>.

   [RFC6764]  Daboo, C., "Locating Services for Calendaring Extensions
              to WebDAV (CalDAV) and vCard Extensions to WebDAV
              (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013,
              <https://www.rfc-editor.org/info/rfc6764>.

   [RFC7095]  Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
              DOI 10.17487/RFC7095, January 2014,
              <https://www.rfc-editor.org/info/rfc7095>.

   [RFC3842]  Mahy, R., "A Message Summary and Message Waiting
              Indication Event Package for the Session Initiation
              Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August
              2004, <https://www.rfc-editor.org/info/rfc3842>.

   [RFC3458]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
              Context for Internet Mail", RFC 3458,
              DOI 10.17487/RFC3458, January 2003,
              <https://www.rfc-editor.org/info/rfc3458>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <https://www.rfc-editor.org/info/rfc7159>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC6881]  Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in Support of Emergency Calling",
              BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
              <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>.

   [RFC7874]  Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing
              Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016,
              <https://www.rfc-editor.org/info/rfc7874>.




Rosen                     Expires 9 August 2021                [Page 31]


Internet-Draft        Relay User Equipment Profile         February 2021


   [RFC7742]  Roach, A.B., "WebRTC Video Processing and Codec
              Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016,
              <https://www.rfc-editor.org/info/rfc7742>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8825]  Alvestrand, H., "Overview: Real-Time Protocols for
              Browser-Based Applications", RFC 8825,
              DOI 10.17487/RFC8825, January 2021,
              <https://www.rfc-editor.org/info/rfc8825>.

   [RFC8827]  Rescorla, E., "WebRTC Security Architecture", RFC 8827,
              DOI 10.17487/RFC8827, January 2021,
              <https://www.rfc-editor.org/info/rfc8827>.

   [RFC8829]  Uberti, J., Jennings, C., and E. Rescorla, Ed.,
              "JavaScript Session Establishment Protocol (JSEP)",
              RFC 8829, DOI 10.17487/RFC8829, January 2021,
              <https://www.rfc-editor.org/info/rfc8829>.

   [RFC8834]  Perkins, C., Westerlund, M., and J. Ott, "Media Transport
              and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
              January 2021, <https://www.rfc-editor.org/info/rfc8834>.

   [RFC8835]  Alvestrand, H., "Transports for WebRTC", RFC 8835,
              DOI 10.17487/RFC8835, January 2021,
              <https://www.rfc-editor.org/info/rfc8835>.

   [I-D.yusef-sipcore-digest-scheme]
              Shekh-Yusef, R., "The Session Initiation Protocol (SIP)
              Digest Authentication Scheme", Work in Progress, Internet-
              Draft, draft-yusef-sipcore-digest-scheme-07, 1 April 2019,
              <http://www.ietf.org/internet-drafts/draft-yusef-sipcore-
              digest-scheme-07.txt>.

   [pip]      SIPForum, "VRS US Providers Profile TWG-6-1.0", 2015,
              <https://www.sipforum.org/download/vrs-us-providers-
              profile-twg-6-1-0-pdf/#>.

Author's Address








Rosen                     Expires 9 August 2021                [Page 32]


Internet-Draft        Relay User Equipment Profile         February 2021


   Brian Rosen
   470 Conrad Dr
   Mars, PA 16046
   United States of America

   Phone: +1 724 382 1051
   Email: br@brianrosen.net












































Rosen                     Expires 9 August 2021                [Page 33]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/