RFC 9248

Interoperability Profile for Relay User Equipment

📅 published June 2022, from ietf

📜 RFC 9248: Interoperability Profile for Relay User Equipment 🎀

Part 1 of 8 💖

Okay bestie, let's get the title block sorted first ✨

Author: B. Rosen 🧚 Date: June 2022 📅 Category: Standards Track 🦋 (it's an Internet Standards Track document) ISSN: 2070-1721 Stream: Internet Engineering Task Force (IETF) 💜 Request for Comments: 9248 👑 Obsoletes and Updates: this one doesn't list any obsoletes or updates in its title block 🙈

Abstract ✨

Okay so, Video Relay Service (VRS) is the name for a setup where a hearing person can talk to a sign language speaker who is deaf, deafblind, or hard of hearing (HoH), or who has a speech disability. The magic happens through an interpreter, aka a Communications Assistant (CA). The CA is connected to the sign language speaker by videophone and to the hearing user by an audio phone call. The CA signs on the videophone link and speaks on the telephone link 🫶

Interpreters often work for a company or agency, which this document calls a "provider" 🏢. The provider also runs a video service, so users can hook their video devices up to it and reach CAs and other sign language speakers 📹

It's honestly so desirable for the videophones used by sign language speakers to follow a standard. That way any device can work with any provider, and direct video calls between sign language speakers actually work 💅 This document describes the interface between a videophone and a provider 🌈

Status of This Memo 📝

This is an Internet Standards Track document 🦋

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Want more info on Internet Standards? Check Section 2 of RFC 7841 📚

For the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9248 🔗

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License ⚖️

Table of Contents 🗂️

   1.  Introduction
   2.  Terminology
   3.  Requirements Language
   4.  General Requirements
   5.  SIP Signaling
     5.1.  Registration
     5.2.  Session Establishment
       5.2.1.  Normal Call Origination
       5.2.2.  Dial-Around Origination
       5.2.3.  RUE Contact Information
       5.2.4.  Incoming Calls
       5.2.5.  Emergency Calls
     5.3.  Mid-Call Signaling
     5.4.  URI Representation of Phone Numbers
     5.5.  Transport
   6.  Media
     6.1.  SRTP and SRTCP
     6.2.  Text-Based Communication
     6.3.  Video
     6.4.  Audio
     6.5.  DTMF Digits
     6.6.  Session Description Protocol
     6.7.  Privacy
     6.8.  Negative Acknowledgement, Picture Loss Indicator, and Full
           Intraframe Request Features
   7.  Contacts
     7.1.  CardDAV Login and Synchronization
     7.2.  Contacts Import/Export Service
   8.  Video Mail
   9.  Provisioning and Provider Selection
     9.1.  RUE Provider Selection
     9.2.  RUE Configuration Service
       9.2.1.  Provider Configuration
       9.2.2.  RUE Configuration
       9.2.3.  Versions
       9.2.4.  Examples
       9.2.5.  Using the Provider Selection and RUE Configuration
               Services Together
     9.3.  OpenAPI Interface Descriptions
       9.3.1.  Provider List
       9.3.2.  Configuration
   10. IANA Considerations
     10.1.  RUE Provider List Registry
     10.2.  Registration of Rue-Owner Value of the Purpose Parameter
   11. Security Considerations
   12. Normative References
   13. Informative References
   Acknowledgements
   Author's Address

1. Introduction ✨

Video Relay Service (VRS) is a type of Telecommunications Relay Service (TRS). It lets people with hearing disabilities who use sign language, like American Sign Language (ASL), talk to voice telephone users through video equipment 📱 These services also let those people talk directly to each other in suitable modalities, including any mix of sign language over video, real-time text, and speech 💜

This interoperability profile for Relay User Equipment (RUE) is a profile of the Session Initiation Protocol (SIP) and the related media protocols. It handles end-user equipment registration and calling for VRS calls 📞 It lays out the minimal set of call flows and IETF and ITU-T standards that must be supported. It also gives guidance wherever the standards leave room for multiple implementation options, and it defines both minimal and extended capabilities for RUE calls 🧩

Both subscriber-to-provider (interpreted) calls and direct subscriber-to-subscriber calls are supported on this interface 🤝 There are a few accommodations in this document to keep things backwards compatible with other devices and services used to provide VRS. Backwards compatibility isn't a requirement though, so some interworking may be needed to allow direct video calls to older devices 🙈 This document only describes the interface between the device and the provider. It doesn't cover any other interface the provider might have 🎀

Here's a typical relay call. The RUE device and the communications assistant (sign language interpreter) both have videophones, and the hearing user has a telephone (mobile or fixed) 🦋

                              ||== RUE Interface (this document)
                              ||
                              \/
     +------+   +------+      -       +--------+     -      +-------+
     |User  |   |RUE   |    (   )     |Provider|    (  )    |User   |
     |who is|   |Device|<-(Internet)->|        |            |who is |
     |Deaf  |<->|      |              |        |<-( PSTN )->|Hearing|
     +------+   +------+   --------   +--------+   ------   +-------+
                                           ^
                                           |
                                   +--------------+
                                   |Communications|
                                   |Assistant     |
                                   +--------------+

2. Terminology 💅

Communications 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 two users may employ, e.g., English voice, Spanish voice, American Sign Language, English lipreading, or French real-time text. Here, one communication modality is assumed to cover both the language and the way that language is exchanged. For example, English voice and French voice are two different communication modalities 🗣️

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. By default, it provides the VRS for incoming voice calls to the user. The default provider also, by default, provides the VRS for outgoing relay calls. A user can have more than one telephone number, and each one has a default provider 📇

Outbound dial-around call: A relay call where the subscriber specifies a VRS provider other than their default VRS provider. This can be done two ways. In the "two-stage" way, the user dials a "front-door" number for a VRS provider and then signs or texts the phone number they want to call. In the "one-stage" way, the user's RUE software tells 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. Dial-around is per call, so 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 people with hearing or speech disabilities to use a RUE to talk to users of conventional voice services, with the aid of a CA to relay the communication 📞✨

Relay service (RS): A service that allows a registered subscriber to use a RUE to make and receive relay calls, point-to-point calls, and relay-to-relay calls. The functions the relay service provides include:

  • the provision of media links supporting the communication modalities used by the caller and callee
  • user registration and validation
  • authentication and authorization
  • automatic call distributor (ACD) platform functions
  • routing (including emergency call routing)
  • call setup and mapping
  • call features (such as call forwarding and video mail)
  • assignment of CAs to relay calls 🧠

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, receiving, 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 smartphone; 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 a RUE. This is the conventional telecom term for an end-user customer, which in this 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 with other people in real time using video equipment (video RUE). The video link lets the CA view and interpret the subscriber's signed conversation and relay the conversation back and forth with the other party 🎬💜

3. Requirements Language ✨

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are basically the BCP 14 power words [RFC2119] [RFC8174]. They only count when they show up in all capitals, exactly like that 💅. Lowercase or mixed-case versions are just regular words with no special meaning, so don't panic when you see "may" in a sentence 🙈

4. General Requirements 🎀

bestie, every HTTP/HTTPS [RFC9110] [RFC9112] connection in this document MUST use HTTPS 🔒 Both HTTPS and all SIP connections MUST use TLS that conforms to at least [RFC7525], and they MUST support [RFC8446]. Non-negotiable, fr fr 😤

Any text data payload that isn't already constrained by a spec in another standards document MUST be encoded as Unicode UTF-8 🌈

Implementations MUST support IPv4 and IPv6 🦋 Dual-stack support is NOT REQUIRED, though. Providers MAY support separate interfaces for IPv4 and IPv6 by having more than one server in the appropriate SRV record, as long as each server's DNS record has an A record or an AAAA record but not both. The same version of IP MUST be used for signaling and media in a call, unless Interactive Connectivity Establishment (ICE) [RFC8445] is in use. If ICE is in use, candidates may explicitly offer IPv4, IPv6, or both for any media stream. It's giving flexibility ✨

5. SIP Signaling 📞

So for the SIP stuff, implementations of the RUE interface MUST conform to these core SIP standards:

In all of the above, the RUE device follows the requirements of a SIP user agent. The provider follows the requirements of the registrar and proxy server wherever a document describes different behavior for different roles. For providers offering a video mail service, [RFC6665] (SIP Events) MUST be implemented to support the Message-Waiting Indicator (MWI) (see Section 8) 📬

Also, implementations MUST conform to:

Implementations MUST implement full ICE, although they MAY interwork with user agents that implement ICE-lite 🧚

Implementations MUST include a "User-Agent" header field that uniquely identifies the RUE application, platform, and version in all SIP requests. They MUST also include a "Server" header field with the same content in SIP responses. Identity moment 🪪

Implementations intended to support mobile platforms MUST support [RFC8599] and MUST use it as at least one way to wake the client up from the background state 📱💤

The SIP signaling for registration and for placing or receiving calls depends on various values being configured into the RUE device. Section 9.2 describes the configuration mechanism that supplies the values used in signaling. When the device starts, the configuration mechanism runs and retrieves the configuration data. Then SIP registration happens using those values. After registration, the RUE device can send or receive calls 📲

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 (see Section 9.2) contains multiple "outbound-proxies" in "RueConfigurationData", 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-domain" from the configuration. The To URI and the From URI MUST be identical URIs, formatted as follows:

  • if "user-name" is provided: "username@provider-domain"
  • if "user-name" is not provided: as specified in Section 5.4, use "phone-number" and "provider-domain" from the configuration

The RUE works out which URI to resolve by first checking whether one or more "outbound-proxies" are configured. If they are, the URI is that of one of the "outbound-proxies". If none are configured, the URI is the Request-URI from the REGISTER request. The RUE pulls the domain out of that URI and checks the DNS record for that domain. The DNS entry MUST contain NAPTR records that conform 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.net" 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 gets a 439 (First Hop Lacks Outbound Support) response to a REGISTER request, it MUST reattempt registration without using the outbound mechanism 🔁

The registrar MAY authenticate the RUE using SIP digest authentication. The credentials MUST come from the configuration in Section 9.2: "user-name" if it's provided, or "phone-number" if "user-name" isn't provided, plus "sip-password". This "user-name"/"sip-password" combo SHOULD NOT be the same as the one used for other purposes, except for the cases expressly described below, like retrieving the RUE configuration or logging into the provider's customer service portal. [RFC8760] MUST be supported by all implementations, and SHA-512 digest algorithms MUST be supported too 🧁

If registration fails with an indication that the credentials from the configuration are invalid, then the RUE MUST retrieve a fresh version of the configuration. If the credentials from the freshly retrieved configuration are also found to be invalid, then the RUE MUST stop trying to register and tell the RUE user about the problem 🚫

Supporting multiple simultaneous registrations with multiple providers is OPTIONAL for the RUE. Providers don't need any support for this option at all 🤷‍♀️

Multiple simultaneous RUE SIP registrations from different RUE devices that share 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 would push the count past that limit, the provider MAY prematurely terminate another registration. However, it SHOULD NOT do that if it would disconnect an active call ☎️

If a provider prematurely terminates a registration to reduce the total number of concurrent registrations for the same URI, it SHOULD take some action to stop the affected RUE from automatically re-registering and re-triggering the condition. Plot twist, but a very important one 🎭

5.2. Session Establishment 🌸

5.2.1. Normal Call Origination 📲

After initial SIP registration, the RUE follows SIP [RFC3261] basic call flows, as documented in [RFC3665] 💅

A RUE device MUST route all outbound calls through an outbound proxy, if one is configured 🛣️

The SIP URIs in the To field and the Request-URI MUST be formatted as specified in Section 5.4, using the destination phone number, or as SIP URIs provided in the configuration (Section 9.2). The domain field of these URIs SHOULD be the "provider-domain" from the configuration (e.g., sip:+15551234567@red.example.com;user=phone). The exception is an anonymous call, which would not use the provider domain 🕶️

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 one is present. (Please refer to Section 9.2.) ✨

Negotiated media MUST follow the requirements specified in Section 6 of this document 🎶

To give an unanswered call time to time out and get sent to a videomail server, the User Agent Client MUST NOT impose a time limit shorter than the default SIP INVITE transaction timeout of 3 minutes ⏳

5.2.2. Dial-Around Origination 🌍

Providers and RUE devices MUST support both one-stage and two-stage dial-around 🌐

Outbound dial-around calls let a RUE user pick any provider to supply interpreting services for any call. A "two-stage" dial-around call means the RUE calls a telephone number that reaches the dial-around provider, then uses signing or dual-tone multi-frequency (DTMF) to send the called party's telephone number. In two-stage dial-around, the To URI is the "front-door" URI (see Section 9.2) in "ProviderConfigurationData" of the dial-around provider. The RUE Provider Selection service (Section 9.1) can be used by the RUE to get a list of providers. After that, the provider configuration (Section 9.2.1) can be used to find the front-door URI for each of those providers 🚪

One-stage dial-around is a method where the called party's telephone number is put 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 one 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 as described in Section 9.1 💖

Here's a partial example of a one-stage dial-around call. A VRS user at +1-555-222-0001, hosted by red.example.com, calls a hearing user at +1-555-123-4567 using dial-around to green.example.com for the relay service. Only the important details of the messages are shown, and many header fields have been left out 🫶

  ,-+-.        ,----+----.    ,-----+-----.
  |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:+15552220001@red.example.net;user=phone>

  [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:+15552220001@red.example.net;user=phone
  P-Asserted-Identity: sip:+15552220001@red.example.net

                   Figure 1: One-Stage Dial-Around

5.2.3. RUE Contact Information 🎀

Okay so, to identify the owner of a RUE 💖, the initial INVITE for a call from a RUE, or the 200 OK the RUE uses to accept a call, you send a Call-Info header field with a purpose parameter of rue-owner ✨. The URI MAY be an HTTPS URI or Content-ID URL. The Content-ID kind is defined by [RFC2392] for locating message body parts 🦋. This URI type shows up in a SIP message to carry the RUE ownership info as a MIME body. The ownership info itself is an xCard [RFC6351] 💅. If you want to see content indirection URLs in SIP messages in action, go check out [RFC6442] 🌸. Heads up, using a content indirection URL usually means you've got multiple message bodies (mime/multipart) 🫶.

The RUE owner is the entity with local control over the device, and that's not necessarily the legal owner of the equipment 👑. It often is the user, but not always, so don't assume! No minimum fields are specified for the xCard, but the name, address, phone number, and email address of the RUE owner are expected to be supplied 📇.

5.2.4. Incoming Calls 📞

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

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 using a CANCEL request. Main character energy, one phone wins 🏆.

5.2.5. Emergency Calls 🚨

Implementations MUST conform to [RFC6881] for handling emergency calls. The one exception: if the device can't figure out its own location, it MAY send the emergency call without a Geolocation header field and without a Route header field. That's because it wouldn't be able to query the Location-to-Service Translation (LoST) server for a route, per [RFC6881] 🥺. If an emergency call arrives at the provider without a Geolocation header field, the provider MUST supply location by adding the Geolocation header field, and MUST supply the route by querying the LoST server with that location 🗺️.

If the emergency call is going to be handled using existing country-specific procedures, the provider is responsible for modifying the INVITE to meet the country-specific requirements 🌍. In this case, the location MAY be extracted from the [RFC6881] conformant INVITE and used to propagate it to the appropriate country-specific entities. If the configuration specifies it, an implementation of a RUE device MAY send a Geolocation header field containing its location in the REGISTER request. If implemented, users MUST be offered an opt-out 🙋‍♀️. Country-specific procedures might require the location to be preloaded in some entity before placing an emergency call. However, the RUE may have a more accurate and timely device location than that manual, preloaded entry ⏰. 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 information, device information, 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.8, implementations MUST be able to support an INFO message for full frame refresh for devices that do not support SRTCP (please refer to Section 6.1). Implementations MUST support an in-dialog REFER (as described in [RFC3515] and updated by [RFC7647], and including support for norefersub per [RFC4488]) with the Replaces header field [RFC3891] to enable call transfer 🔄.

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 🔢. In this section, "expressed as an E.164 number" includes numbers, such as toll-free numbers, that are not actually E.164 numbers but have the same format. Lowkey a very specific rule, but we respect it 💅.

A dial string that can be expressed as an E.164 phone number MUST be represented as a SIP URI with a ;user=phone tag. The user part of the URI MUST be in conformance with "global-number", as defined in [RFC3966]. The user part MUST NOT contain any "visual-separator" characters, as defined in [RFC3966] 🚫.

Dial strings that cannot be expressed 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 for its guidance on the WebRTC data channel, which this specification does not use 🙅‍♀️. See 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 📞. Various RTPs, RTCPs, SDPs, and specific media requirements specified for WebRTC are adopted for this document. Explicit requirements from the WebRTC suite of documents are described below 📚.

To use WebRTC with this document, a gateway that presents a WebRTC server interface towards a browser and a RUE client interface towards a provider is assumed 🌉. The gateway would interwork signaling and, as noted below, interwork at least any real-time text media, so that a standard browser-based WebRTC client can be a VRS client 💻. The combination of the browser client and the gateway would be a RUE user. This document does not specify the gateway 🤷‍♀️.

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, an implementation presenting a call across the RUE interface (where the call originates in the PSTN or an older, non-RUE-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 🎧. Conformance to this document allows end-to-end RTCP and media congestion control for audio and video 📶.

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] [RFC4103] via T.140 media. One original and two redundant generations MUST be transmitted and supported with a 300 ms transmission interval ⏱️. Implementations MUST support [RFC9071], especially for emergency calls 🚑. Note that [RFC4103] 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 🔁.

Transport of T.140 real-time text in WebRTC is specified in [RFC8865], using the WebRTC data channel. [RFC8865] also has some advice on how gateways between [RFC4103] and [RFC8865] should operate 🧠. It is RECOMMENDED that [RFC8865], including multiparty support, be used for communication with browser-based WebRTC implementations 🌈. Implementations MUST support [RFC9071].

6.3. Video 🎥

Implementations MUST conform to [RFC7742] with the following exceptions: only H.264, as specified in [RFC7742], is Mandatory to Implement, and VP8 support is OPTIONAL at both the device and providers. This is because backwards compatibility is desirable, and older devices do not support VP8 📼.

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 the SDP rules in [RFC8829], except that the RUE interface uses SIP transport for SDP. The SDP for real-time text MUST specify the T.140 payload type [RFC4103] ✍️.

6.7. Privacy 🙈

The RUE MUST provide for user privacy by implementing a local one-way mute, without signaling, for both audio and video. However, RUE MUST maintain any states in the network (e.g., NAT bindings) by periodically sending media packets on all active media sessions containing silence, comfort noise, blank screen, etc., per [RFC6263] 🫣. Privacy with a side of network upkeep, iconic balance 🤍.

6.8. Negative Acknowledgement, Picture Loss Indicator, and Full Intraframe Request Features 🖼️

The NACK, FIR, and Picture Loss Indicator (PLI) features, as described in [RFC4585] and [RFC5104], MUST be implemented. Availability of these features MUST be announced with the "ccm" feedback value. NACK should be used when negotiated and conditions warrant its use and the other end supports it. Signaling picture losses as a PLI should be preferred. FIR should be used only in situations where not sending a decoder refresh point would render the video unusable for the users, as per Section 4.3.1.2 of [RFC5104] 🛟.

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 vCard Extensions to WebDAV (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] [RFC6764] 👯‍♀️.

The configuration (see Section 9.2) RueConfigurationData MAY supply a carddav-username and carddav-domain identifying a CardDAV server and address book for this account, plus an optional carddav-password 🗂️.

To access the CardDAV server and address book, the RUE MUST follow Section 6 of [RFC6764], using the configured carddav-username and carddav-domain in place of an email address. If the request triggers a challenge for digest authentication credentials, the RUE MUST continue using matching carddav-username and carddav-password from the configuration. If no carddav-username and carddav-password are configured, the RUE MUST use the SIP user-name and sip-password from the configuration. If the SIP credentials fail, the RUE MUST query the user 🔑.

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 🔁✨.

The RUE MAY support other CardDAV services 🌷.

7.2. Contacts Import/Export Service 📇✨

okay so first things first 💅 Implementations MUST be able to export/import the list of contacts in xCard [RFC6351] XML format. bestie, that's the baseline, no cap 🫶

The RUE reaches this service through the contacts-uri in the configuration. The URL MUST resolve to a web server resource that imports/exports contact lists for authorized users. it's giving "the server knows who you are" 🔐

The RUE stores or retrieves the contact list (address book) by sending an HTTPS POST or GET request. If that request triggers a challenge for digest authentication credentials, the RUE MUST attempt to continue using the contacts-username and contacts-password from the configuration. If no contacts-username is configured, the SIP user-name from the configuration is used. If the SIP user-name isn't configured either, the phone-number is used. And if the user-name or phone-number is the one being used, the sip-password is used to authenticate to the contact list server. the fallback chain is so organized 🥹💜

8. Video Mail 🎬🦋

Video mail support has two parts: a retrieval mechanism and a Message-Waiting Indicator (MWI). Message storage is not specified by this document, so that's a whole other story 🙈 RUE devices MUST support message retrieval using a SIP call to a specified SIP URI, with DTMF used to manage the mailbox. They MUST also support a browser-based interface reached at a specified HTTPS URI. If a provider supports video mail, at least one of these mechanisms MUST be supported. RUE devices MUST support both. See Section 9.2 for how the URI to reach the retrieval interface is obtained, bestie 🗺️

Implementations MUST support subscriptions to "message-summary" events [RFC3842] to the URI specified in the configuration. Providers MUST support MWI if they support video mail. RUE devices MUST support MWI. the whole MWI thing is a vibe check 📬💅

The "videomail" and "mwi" properties in the configuration (see RueConfigurationData in Section 9.2.2) give the URIs for message retrieval and "message-summary" subscription. so those two properties are the map to your voicemails 🧭

In notification bodies, if detailed message summaries are available, messages with video MUST be reported using "message-context-class multimedia-message", as defined in [RFC3458] . the video messages get their own special label, periodt 🌈

9. Provisioning and Provider Selection 🌸

To make life easier for users, the RUE interface splits provisioning into two parts ✨ One part is a directory of providers, so a user interface can make provider selection super easy, either for registering or for dial-around. The other part provides configuration data for the device for each provider. two separate lanes, zero drama 🛣️

9.1. RUE Provider Selection 🗂️

To let the user pick a relay service, the RUE MAY at any time obtain a list of providers that serve a country, typically on startup. IANA has set up a registry with a two-letter country code and a list entry point string (see Section 10.1). The entry point, used with the following OpenAPI interface, returns a list of provider names for a country code that's suitable for display, along with a matching entry point to get info about each provider. No mechanism for figuring out the country where the RUE is located is specified in this document. Usually the country is the user's home country, but it could be a local country while traveling. some countries even allow support from home when you're abroad 🌍 Either way, the RUE device will need to let the user choose the country. the user is in charge of the vibe 👑

Each country that supports VRS using this specification MAY support the provider list. This document does not specify who maintains the list. Some possibilities are a regulator, an entity designated by a regulator, an agreement among providers to provide the list, or a user group. so many possible list keepers 🤷‍♀️

The interface to get the list of providers is described by an OpenAPI [OpenAPI] interface description. In that description, the "servers" component includes an occurrence of "localhost". The value from the registry, the "list entry point" string for the desired country, gets substituted for "localhost" in the "servers" component. That gives the server URI prefix of the interface used to get the list of providers for that country. The "Providers" path then specifies the rest of the URI used to get the list. For example, if the list entryPoint is "example.com/api", the provider list would be obtained from https://example.com/api/rum/v1/Providers. the swap-in-the-domain trick is so satisfying 🧩

The V1.0 "ProviderList" is a JSON object containing an array, where each entry describes one provider. Each entry has the following items:

  • name: This parameter contains the text label identifying the provider and is meant to be displayed to the human VRS user. ✍️
  • providerEntryPoint: A string used for configuration purposes by the RUE (as discussed in Section 9.2). The string MUST start with a domain but MAY include other URI path elements after the domain. 🔗

The VRS user interacts with the RUE to pick one or more providers from the provider list. They might already have an account with them, want to set one up, or just want to use the provider for a one-stage dial-around. main character decisions only 🎀

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

Figure 2: Example of a ProviderList JSON Object 🍓

9.2. RUE Configuration Service ⚙️💖

A RUE device can grab a provider configuration using a simple HTTPS web service. There are two entry points. One is used without user credentials, and its response includes configuration data for new user signup and dial-around. The other uses a locally stored username and password, the ones that come out of a new user signup, to authenticate to the interface. It returns configuration data for the RUE. one open door, one locked door, both fully iconic 🚪🔐

The interface to get configuration data is described by an OpenAPI [OpenAPI] interface description. In that description, the "servers" component string includes an occurrence of "localhost". The entry point string from the provider list (Section 9.1) gets substituted for "localhost" to get the server prefix of the interface. The path then specifies the rest of the URI used to get the list. For example, if the entryPoint from the provider list is "red.example.net", the provider configuration would be obtained from https://red.example.net/rum/V1/ProviderConfig, and the RUE configuration would be obtained from https://red.example.net/rum/V1/RueConfig. 🧁

In both queries, an optional parameter may be provided to the interface: an API Key (apiKey). The implementation MAY have an apiKey obtained from the provider, specific to the implementation. The method used to obtain the apiKey is not specified in this document. The provider MAY refuse to provide service to an implementation presenting an apiKey it does not recognize. a key that doesn't match? the door stays closed 🔑🙅‍♀️

Also in both queries, the RUE device provides a client-provided, required parameter that contains an instance identifier (instanceId). This parameter MUST be the same value each time this instance (same implementation on same device) queries the interface. This MAY be used by the provider, for example, to associate a location with the instance for emergency calls. This should be globally unique. A Universally Unique Identifier (UUID) is suggested. consistency is everything here, bestie 🆔🫶

For example, a query for the RUE configuration could be:

https://red.example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisK t8999"&instanceId="5595b5a3-0687-4b8e-9913-a7f2a04fb7bd"

The data returned is a JSON object made 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. so like, be chill about extra stuff, just skip it 🙃

9.2.1. Provider Configuration 🎁

  • signup: (OPTIONAL) an array of JSON objects consisting of:
    • language: entry from the IANA "Language Subtag Registry" (https://www.iana.org/assignments/language-subtag-registry). Normally, this would be a written language tag. 📝
    • uri: a URI to the website for creating a new account in the supported language. The new user signup URI may only initiate creation of a new account. Various vetting, approval, and other processes may be needed, which could take time, before the account is established. The result of creating a new account would be account credentials (e.g., username and password), which would be manually entered into the RUE device. Those credentials form the authentication parameters for the RUE configuration service described below in Section 9.2.2. 🪪
  • dial-around: an array of JSON objects consisting of:
    • language: entry from the IANA "Language Subtag Registry". Normally, this would be a sign language tag. 🤟
    • front-door: a URI to a queue of interpreters supporting the specified language for a two-stage dial-around. 🚶‍♀️
    • oneStage: a URI that can be used with a one-stage dial-around (Section 5.2.2) using an interpreter supporting the specified language. ⚡
  • helpDesk: (OPTIONAL) an array of JSON objects consisting of:
    • language: entry from the IANA "Language Subtag Registry". Normally, this would be a sign language tag; although, it could be a written language tag if the help desk only supports a chat interface. 💬
    • uri: a URI that reaches a help desk for callers supporting the specified language. The URI MAY be a SIP URI for help provided with a SIP call, or MAY be an HTTPS URI for help provided with a browser interface. 🆘

A list is specified so that the provider can offer users multiple choices for language and interface styles. the provider gives you a buffet of options, iykyk 🍰✨

9.2.2. RUE Configuration ✨

okay bestie, this is the big list of config knobs the RUE can grab from the provider 🧚 each one is a field in the payload, and some are optional while others are a must-have 💅

  • lifetime 🕒: (OPTIONAL) this is how long (in seconds) the RUE MAY cache the configuration values. Values may not be valid when lifetime expires. If the RUE caches config values, it MUST cryptographically protect them against unauthorized disclosure (e.g., by other applications on the platform the RUE is built on). The RUE SHOULD grab a fresh copy of the configuration before the lifetime expires or as soon as possible after it expires. The lifetime is not guaranteed, i.e., the configuration may change before the lifetime value expires. In that case, the provider MAY let the RUE know by generating authorization challenges to requests and/or prematurely terminating a registration. Emergency calls MUST continue to work. If it's not specified, the RUE MUST fetch new configuration data every time it starts. 🚨
  • sip-password 🔐: (OPTIONAL) a password used for SIP, STUN, and TURN authentication. The RUE device keeps this data, which it MUST cryptographically protect against unauthorized disclosure (e.g., by other applications on the platform the RUE is built on). If it isn't supplied but was supplied on a prior invocation of this interface, the most recently supplied password MUST be used. If it was never supplied, the password used to authenticate to the configuration service gets used for SIP, as well as for the STUN and TURN servers mentioned in this configuration. 🫶
  • phone-number 📞: (REQUIRED) the telephone number (in E.164 format) assigned to this subscriber. This becomes the user portion of the SIP URI identifying the subscriber. 💖
  • user-name 👤: (OPTIONAL) a username used for authenticating to the provider. If it's not provided, phone-number is used.
  • display-name 🎀: (OPTIONAL) a human-readable display name for the subscriber. ✨
  • provider-domain 🌐: (REQUIRED) the domain for the provider. This becomes the server portion of the SIP URI identifying the subscriber. 👑
  • outbound-proxies 🚪: (OPTIONAL) an array of URIs of SIP proxies to be used when sending requests to the provider.
  • mwi 📬: (OPTIONAL) a URI identifying a SIP event server that generates message-summary events for this subscriber.
  • videomail 🎥: (OPTIONAL) a SIP or HTTPS URI that can be used to retrieve video mail messages. 🍓
  • contacts 📇: (OPTIONAL) an HTTPS URI ("contacts-uri"), (OPTIONAL) "contacts-username", and "contacts-password" that may be used to export (retrieve) the subscriber's complete contact list managed by the provider. At least the URI MUST be provided if the subscriber has contacts. If contact-username and contacts-password aren't supplied, the sip credentials are used. If the contacts-username is provided, contacts-password MUST be provided. If contacts-password is provided, contacts-username MUST be provided. 🙈
  • carddav 🦋: (OPTIONAL) an address ("carddav-domain"), (OPTIONAL) "carddav-username", and "carddav-password" identifying a "CardDAV" server and account that can be used to synchronize the RUE's contact list with the contact list managed by the provider. If carddav-username and carddav-password aren't supplied, the sip credentials are used. If the carddav-username is provided, carddav-password MUST be provided. If carddav-password is provided, carddav-username MUST be provided. 💜
  • sendLocationWithRegistration 📍: (OPTIONAL) true if the RUE should send a Geolocation header field with REGISTER; false if it should not. Defaults to false if not present.
  • ice-servers 🧊: (OPTIONAL) an array of server types and URLs identifying STUN and TURN servers available for use by the RUE for establishing media streams in calls via the provider. If the same URL provides both STUN and TURN services, it MUST be listed twice, each with different server types. 🔥

9.2.3. Versions 🌈

okay so both web services also have a simple version mechanism that gives back a list of the versions of the web service it supports 🧠 this document describes version 1.0. Versions are shown as a major version, then a period ., then a minor version, and both the 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. Backwards compatibility applies to both the server and the client. Either one may have any higher or lower minor revision and still interoperate with its counterpart with the same major version. To achieve backwards compatibility, implementations MUST ignore any object members they do not implement. Minor version definitions SHALL only add objects, optional members of existing objects, and non-mandatory-to-use functions, and they SHALL NOT delete or change any objects, members of objects, or functions. This means an implementation of a specific major and minor version is backwards compatible with all minor versions of that major version. The version mechanism returns an array of supported versions, one for each major version supported, with the minor version listed being the highest-supported minor version. 🦋

Unless the per-country provider list service is operated by a provider at the same base URI as that provider's configuration service, the version of the configuration service MAY be different from the version of the provider list service. 🫧

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

Figure 3: Example of a Version JSON Object 💖

9.2.4. Examples 👀

here's a peek at what the payloads actually look like, bestie 🥹

{
  "signUp": [
     { "language" : "en", "uri" : "https:hello-en.example.net"},
     { "language" : "es", "uri" : "https:hello-es.example.net"} ] ,
  "dial-around": [
     { "language" : "en", "front-door" : "sip:fd-en.example.net",
          "oneStage" : "sip:1stg-eng.example.com" } ,
     { "language" : "es", "front-door" : "sip:fd-es.example.net",
          "oneStage" : "sip:1stg-spn.example.com" } ] ,
  "helpDesk": [
     { "language" : "en", "uri" : "sip:help-en.example.net"} ,
     { "language" : "es", "uri" : "sip:help-es.example.net"} ]
}

Figure 4: Example JSON Provider Configuration Payload 🌸

{
  "lifetime": 86400,
  "display-name" : "Bob Smith",
  "phone-number": "+15551234567",
  "provider-domain": "red.example.net",
  "outbound-proxies": [
    "sip:p1.red.example.net",
    "sip:p2.red.example.net" ],
  "mwi": "sip:+15551234567@red.example.net;user=phone",
  "videomail": "sip:+15551234567@vm.red.example.net;user=phone",
  "contacts": {
    "contacts-uri":
       "https://red.example.net:443/c/3617b719-2c3a-46f4-9c13",
    "contacts-username": "bob",
    "contacts-password": "XhOT4ch@ZEi&3u2xEYQNMO^5UGb"
  },
  "carddav": {
     "carddav-domain": "carddav.example.com",
     "carddav-username": "bob",
     "carddav-password": "sj887%dd*jJty%87hyys5hHT"
  },
  "sendLocationWithRegistration": false,
  "ice-servers": [
     {"stun":"stun.red.example.com:19302" },
     {"turn":"turn.red.example.com:3478"}
  ]
}

Figure 5: Example JSON RUE Configuration Payload 🎀

9.2.5. Using the Provider Selection and RUE Configuration Services Together 🧩

one way to use these two services together is like this 💅

  1. At startup, the RUE retrieves the provider list for the country it is located in. 🌍
  2. For each provider in the list:
    • If the RUE does not have credentials for that provider, if requested by the user, use the ProviderConfig path without credentials to obtain signup, dial-around, and help desk information. 📝
    • If the RUE has credentials for that provider, use the RueConfig path with the locally stored credentials to configure the RUE for that provider. 🔑

9.3. OpenAPI Interface Descriptions 🌟

the interfaces in Sections 9.1 and 9.2 are formally specified with OpenAPI 3.0 [OpenAPI] descriptions in YAML form. 📜

the OpenAPI description below is normative. If there is any conflict between the text or examples and this section, the OpenAPI description takes precedence. 👑

9.3.1. Provider List 📋

openapi: 3.0.1
info:
  title: RUM Provider List API
  version: "1.0"
servers:
  - url: https://localhost/rum/v1
paths:
  /Providers:
    get:
      summary: Get a list of providers and domains to get
               config data from
      operationId: GetProviderList
      responses:
        '200':
          description: List of providers for a country
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ProviderList'
  /Versions:
    servers:
      - url: https://localhost/rum
        description: Override base path for Versions query
    get:
      summary: Retrieves all supported versions
      operationId: RetrieveVersions
      responses:
        '200':
          description: Versions supported
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/VersionsArray'
components:
  schemas:
    ProviderList:
      type: object
      required:
        - providers
      properties:
        providers:
          type: array
          items:
            type: object
            required:
              - name
              - providerEntryPoint
            properties:
              name:
                type: string
                description: Human-readable provider name
              providerEntryPoint:
                type: string
                description: Provider entry point 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 6: Provider List OpenAPI Description (RueProviderList.yaml) ⭐

9.3.2. Configuration ✨

okay so this is where the config endpoints live, bestie 🎀 It's an OpenAPI 3.0.1 spec called RUM Configuration API, and it has three paths: /ProviderConfig, /RueConfig, and /Versions 💅

openapi: 3.0.1
info:
  title: RUM Configuration API
  version: "1.0"
servers:
  - url: https://localhost/rum/v1
paths:
  /ProviderConfig:
    get:
      summary: Configuration data for one provider
      operationId: GetProviderConfiguration
      parameters:
        - in: query
          name: apiKey
          schema:
            type: string
          description: API Key assigned to this implementation
        - in: query
          name: instanceId
          schema:
            type: string
          required: true
          description: Unique string for this implementation
                       on this device
      responses:
        '200':
          description: Configuration object
          content:
            application/json:
              schema:
                $ref:
                 '#/components/schemas/ProviderConfigurationData'
  /RueConfig:
    get:
      summary: Configuration data for one RUE
      operationId: GetRueConfiguration
      parameters:
        - in: query
          name: apiKey
          schema:
            type: string
          description: API Key assigned to this implementation
        - in: query
          name: instanceId
          schema:
            type: string
          required: true
          description: Unique string for this implementation
                       on this device
      responses:
        '200':
          description: Configuration object
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RueConfigurationData'
  /Versions:
    servers:
      - url: https://localhost/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:
    ProviderConfigurationData:
      type: object
      required:
        - dial-around
      properties:
        signup:
          type: array
          items:
            type: object
            required:
              - language
              - uri
            properties:
              language:
                type: string
                description: Entry from IANA "Language Subtag
                  Registry"
              uri:
                type: string
                format: uri
                description: URI to signup website supporting
                  this language
        dial-around:
          type: array
          items:
            type: object
            required:
              - language
              - front-door
              - oneStage
            properties:
              language:
                type: string
                description: Entry from IANA "Language Subtag
                  Registry"
              front-door:
                type: string
                format: uri
                description: SIP URI for two-stage dial-around
              oneStage:
                type: string
                format: uri
                description: SIP URI for one-stage dial-around
        helpDesk:
          type: array
          items:
            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 help desk supporting language
    RueConfigurationData:
      type: object
      required:
        - phone-number
        - provider-domain
      properties:
        lifetime:
          type: integer
          description: How long (in seconds) the RUE MAY cache the
                       configuration values
        sip-password:
          type: string
        phone-number:
          type: string
          description: Telephone number assigned this subscriber in
            E.164 format
        user-name:
          type: string
          description: A username assigned to this subscriber
        display-name:
          type: string
          description: Display name for the subscriber
        provider-domain:
          type: string
          description: Domain of the provider for this subscriber
        outbound-proxies:
          type: array
          items:
             type: string
             format: uri
             description: SIP URI of a proxy to be used when sending
                       requests to the provider
        mwi:
          type: string
          format: uri
          description: A URI identifying a SIP event server that
              generates "message-summary" events for this subscriber
        videomail:
          type: string
          format: uri
          description: An HTTPS or SIP URI that can be used to
                       retrieve video mail messages
        contacts:
          type: object
          description: Server and credentials for contact
             import/export
          required:
            - contacts-uri
          properties:
            contacts-uri:
              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
            contacts-username:
              type: string
              description: Username for authentication with the
                CardDAV server.  Use SIP user-name if not provided
            contacts-password:
              type: string
              description: Password for authentication. Use provider
                sip-password if not provided
        carddav:
          type: object
          description: CardDAV server and user information that can
               be used to synchronize the RUE's contact list with
               the contact list managed by the provider
          required:
            - carddav-domain
          properties:
            carddav-domain:
              type: string
              description: CardDAV server address
            carddav-username:
              type: string
              description: Username for authentication with the
                 CardDAV server.  Use SIP user-name if not provided
            carddav-password:
              type: string
              description: Password for authentication to the CardDAV
                 server. Use provider sip-password if not provided
        sendLocationWithRegistration:
          type: boolean
          description: True if the RUE should send a Geolocation
               header field with REGISTER; false if it should not.
               Defaults to false if not present
        ice-servers:
          type: array
          items:
            type: object
            required:
              - server-type
              - uri
            properties:
              server-type:
                type: string
                description: Server type ("stun" or "turn")
              uri:
                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
                description: Version minor number

Figure 7: Configuration OpenAPI Description (RueConfiguration.yaml)

10. IANA Considerations 🦋

10.1. RUE Provider List Registry

okay so IANA made a brand new registry called "RUE Provider List" 📋 The registration policy is "Expert Review" [RFC8126]. A regulator operated or designated list interface operator is preferred. Otherwise, you need evidence that the proposed list interface operator will provide a complete list of providers before the entry gets added to the registry. Updates are allowed if the expert decides the proposed URI gives a more accurate list than the existing entry. Each entry has two fields, and values for both MUST be provided when registering or updating an entry 🔥

  • country code: a two-letter ISO93166 country code
  • list entry point: a string is used to compose the URI to the provider list interface for that country

10.2. Registration of Rue-Owner Value of the Purpose Parameter

this one's giving paperwork energy 📝✨ This document defines the new predefined value "rue-owner" for the "purpose" header field parameter of the Call-Info header field. The use for rue-owner is defined in Section 5.2.3. IANA added a reference to this document in the "Header Field Parameters and Parameter Values" subregistry of the "Session Initiation Protocol (SIP) Parameters" for the header field "Call-Info" and parameter name "purpose".

Header Field:  Call-Info

Parameter Name:  purpose

Predefined Values:  Yes

11. Security Considerations 💀🔐

okay this part is SERIOUS bestie, read it slowly 🫶

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.

This document requires implementation and use of a number of other specifications in order to fulfill the RUE profile; the security considerations described in those documents apply accordingly to the RUE interactions.

When a CA participates in a conversation, they have access to the content of the conversation even though it is nominally a conversation between the two endpoints. There is an expectation that the CA will keep the communication contents in confidence. This is usually defined by contractual or legal requirements.

Since different providers (within a given country) may have different policies, RUE implementations MUST include a user interaction step to select from available providers before proceeding to actually register with any given provider. 🚨

12. Normative References 📚

[OpenAPI] Miller, D., Whitlock, J., Gardiner, M., Ralphson, M., Ratovsky, R., and U. Sarid, "OpenAPI Specification v3.0.1", December 2017, <https://spec.openapis.org/oas/v3.0.1>.

Okay, bestie, here's the reference list! 📚✨ Every citation is exactly as written, with its DOI and link. 💅

Okay so this is the reference home stretch 🦋 Here's the rest of the normative list, the informative ones, and the thank-you shoutouts.

   [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>.

   [RFC8839]  Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen,
              A., and R. Shpount, "Session Description Protocol (SDP)
              Offer/Answer Procedures for Interactive Connectivity
              Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839,
              January 2021, <https://www.rfc-editor.org/info/rfc8839>.

   [RFC8865]  Holmberg, C. and G. Hellström, "T.140 Real-Time Text
              Conversation over WebRTC Data Channels", RFC 8865,
              DOI 10.17487/RFC8865, January 2021,
              <https://www.rfc-editor.org/info/rfc8865>.

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

   [RFC9071]  Hellström, G., "RTP-Mixer Formatting of Multiparty Real-
              Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021,
              <https://www.rfc-editor.org/info/rfc9071>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [RFC9112]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/info/rfc9112>.

13. Informative References 📚✨

These are the "good to know" ones 💅 They help you understand the vibe but aren't strictly required reading.

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

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

Acknowledgements 🫶

Bestie, we need to give a huge shoutout to the people who made this doc so much better. Brett Henderson and Jim Malloy gave tons of super helpful edits on earlier draft versions 💖 And Paul Kyzivat did extensive reviews and comments, which is honestly iconic behaviour 👑 Thank you all, you literally carried 🙌

Author's Address 🎀

This is where you can find the author, Brian Rosen 🧚

   Brian Rosen
   470 Conrad Dr
   Mars, PA 16046
   United States of America
   Email: br@brianrosen.net
📦 where this page comes from