idnits 2.17.00 (12 Aug 2021) /tmp/idnits44080/draft-ietf-rum-rue-11.txt: -(1848): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (17 February 2022) is 86 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 504 -- Looks like a reference, but probably isn't: '2' on line 510 -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenApi' ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Downref: Normative reference to an Informational RFC: RFC 3960 ** Downref: Normative reference to an Informational RFC: RFC 5168 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rum B. Rosen 3 Internet-Draft 17 February 2022 4 Intended status: Standards Track 5 Expires: 21 August 2022 7 Interoperability Profile for Relay User Equipment 8 draft-ietf-rum-rue-11 10 Abstract 12 Video Relay Service (VRS) is a term used to describe a method by 13 which a hearing person can communicate with a deaf, hard of hearing 14 or hearing impaired user using an interpreter ("Communications 15 Assistant") connected via a videophone to the deaf/hard of hearing/ 16 hearing impaired user and an audio telephone call to the hearing 17 user. The CA interprets using sign language on the videophone link 18 and voice on the telephone link. Often the interpreters may be 19 employed by a company or agency termed a "provider" in this document. 20 The provider also provides a video service that allows users to 21 connect video devices to their service, and subsequently to CAs and 22 other deaf/hard of hearing/hearing impaired users. It is desirable 23 that the videophones used by the deaf, hard of hearing or hearing 24 impaired user conform to a standard so that any device may be used 25 with any provider and that direct video calls between deaf, hard of 26 hearing or hearing impaired users work. This document describes the 27 interface between a videophone and a provider. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 21 August 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 65 4. General Requirements . . . . . . . . . . . . . . . . . . . . 6 66 5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 8 68 5.2. Session Establishment . . . . . . . . . . . . . . . . . . 10 69 5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 10 70 5.2.2. Dial-Around Origination . . . . . . . . . . . . . . . 10 71 5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 12 72 5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 12 73 5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 12 74 5.3. Mid-Call Signaling . . . . . . . . . . . . . . . . . . . 13 75 5.4. URI Representation of Phone Numbers . . . . . . . . . . . 13 76 5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 14 79 6.2. Text-Based Communication . . . . . . . . . . . . . . . . 15 80 6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 15 83 6.6. Session Description Protocol . . . . . . . . . . . . . . 15 84 6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 86 Intraframe Request Features . . . . . . . . . . . . . . . 16 87 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 16 89 7.2. Contacts Import/Export Service . . . . . . . . . . . . . 17 90 8. Video Mail . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 9. Provisioning and Provider Selection . . . . . . . . . . . . . 18 92 9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 18 93 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 20 94 9.2.1. Provider Configuration . . . . . . . . . . . . . . . 21 95 9.2.2. RUE Configuration . . . . . . . . . . . . . . . . . . 21 96 9.2.3. Versions . . . . . . . . . . . . . . . . . . . . . . 23 97 9.2.4. Examples . . . . . . . . . . . . . . . . . . . . . . 24 98 9.2.5. Using the Provider Selection and RUE Configuration 99 Services Together . . . . . . . . . . . . . . . . . . 25 100 9.3. OpenAPI Interface Descriptions . . . . . . . . . . . . . 26 101 9.3.1. Provider List . . . . . . . . . . . . . . . . . . . . 26 102 9.3.2. Configuration . . . . . . . . . . . . . . . . . . . . 27 103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 104 10.1. RUE Provider List Registry . . . . . . . . . . . . . . . 33 105 10.2. Registration of rue-owner Value of the purpose 106 Parameter . . . . . . . . . . . . . . . . . . . . . . . 33 107 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 108 12. Normative References . . . . . . . . . . . . . . . . . . . . 34 109 13. Informative References . . . . . . . . . . . . . . . . . . . 40 110 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 113 1. Introduction 115 Video Relay Service (VRS) is a form of Telecommunications Relay 116 Service (TRS) that enables persons with hearing disabilities who use 117 sign language, such as American Sign Language (ASL), to communicate 118 with voice telephone users through video equipment. These services 119 also enable communication between such individuals directly in 120 suitable modalities, including any combination of sign language via 121 video, real-time text (RTT), and speech. 123 This Interoperability Profile for Relay User Equipment (RUE) is a 124 profile of the Session Initiation Protocol (SIP) and related media 125 protocols that enables end-user equipment registration and calling 126 for VRS calls. It specifies the minimal set of call flows, Internet 127 Engineering Task Force (IETF) and ITU-T standards that must be 128 supported, provides guidance where the standards leave multiple 129 implementation options, and specifies minimal and extended 130 capabilities for RUE calls. 132 Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/ 133 HoH calls are supported on this interface. While there are some 134 accommodations in this document to maximize backwards compatibility 135 with other devices and services that are used to provide VRS service, 136 backwards compatibility is not a requirement, and some interwork may 137 be required to allow direct video calls to older devices. This 138 document only describes the interface between the device and the 139 provider, and not any other interface the provider may have. 141 The following illustrates a typical relay call. The RUE device and 142 the Commincations Assistant (sign language interpretter) have 143 videophones. The Hearing User has a telephone (mobile or fixed). 145 ||== RUE Interface (this document) 146 || 147 \/ 148 +----+ +------+ - +--------+ - +-------+ 149 |Deaf| |RUE | ( ) |Provider| ( ) |Hearing| 150 |User|<->|Device|<-(Internet)->| |<-( PSTN )->|User | 151 +----+ +------+ -------- +--------+ ------ +-------+ 152 ^ 153 | 154 +--------------+ 155 |Communications| 156 |Assistant | 157 +--------------+ 159 2. Terminology 161 Communication Assistant (CA): A sign-language interpreter working for 162 a VRS provider, providing functionally equivalent phone service. 164 Communication modality (modality): A specific form of communication 165 that may be employed by two users, e.g., English voice, Spanish 166 voice, American Sign Language, English lip-reading, or French real- 167 time-text. Here, one communication modality is assumed to encompass 168 both the language and the way that language is exchanged. For 169 example, English voice and French voice are two different 170 communication modalities. 172 Default video relay service: The video relay service operated by a 173 subscriber's default VRS provider. 175 Default video relay service provider (default provider): The VRS 176 provider that registers, and assigns a telephone number to a specific 177 subscriber, and by default provides the VRS for incoming voice calls 178 to the user. The default provider also by default provides VRS for 179 outgoing relay calls. The user can have more than one telephone 180 number and each has a default provider. 182 Outbound Dial-around call: A relay call where the subscriber 183 specifies the use of a VRS provider other than the default VRS 184 provider. This can be accomplished by the user dialing a "front- 185 door" number for a VRS provider and signing or texting a phone number 186 to call ("two-stage"). Alternatively, this can be accomplished by 187 the user's RUE software instructing the server of its default VRS 188 provider to automatically route the call through the alternate 189 provider to the desired public switched telephone network (PSTN) 190 directory number ("one-stage"). Dial-around is per-call -- for any 191 call, a user can use the default VRS provider or any dial-around VRS 192 provider. 194 Full Intra Request (FIR): A request to a video media sender, 195 requiring that media sender to send a Decoder Refresh Point at the 196 earliest opportunity. FIR is sometimes known as "instantaneous 197 decoder refresh request", "video fast update request", or "fast 198 update request". 200 Point-to-Point Call (P2P Call): A call between two RUEs, without 201 including a CA. 203 Relay call: A call that allows persons with hearing or speech 204 disabilities to use a RUE to talk to users of conventional voice 205 services with the aid of a communication assistant (CA) to relay the 206 communication. 208 Relay service (RS): A service that allow a registered subscriber to 209 use a RUE to make and receive relay calls, point-to-point calls, and 210 relay-to-relay calls. The functions provided by the relay service 211 include the provision of media links supporting the communication 212 modalities used by the caller and callee, and user registration and 213 validation, authentication, authorization, automatic call distributor 214 (ACD) platform functions, routing (including emergency call routing), 215 call setup, mapping, call features (such as call forwarding and video 216 mail), and assignment of CAs to relay calls. 218 Relay service provider (provider): An organization that operates a 219 relay service. A subscriber selects a relay service provider to 220 assign and register a telephone number for their use, to register 221 with for receipt of incoming calls, and to provide the default 222 service for outgoing calls. 224 Relay user: Please refer to "subscriber". 226 Relay user E.164 Number (user E.164): The telephone number (in ITU-T 227 E.164 format) assigned to the user. 229 Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra 230 features to support a subscriber in requesting, receiving and using 231 relay calls. A RUE may take many forms, including a stand-alone 232 device; an application running on a general-purpose computing device 233 such as a laptop, tablet or smartphone; or proprietary equipment 234 connected to a server that provides the RUE interface. 236 RUE Interface: the interfaces described in this document between a 237 RUE and a VRS provider who supports it 239 Sign language: A language that uses hand gestures and body language 240 to convey meaning including, but not limited to, American Sign 241 Language (ASL). 243 Subscriber: An individual who has registered with a provider and who 244 obtains service by using relay user equipment. This is the 245 conventional telecom term for an end-user customer, which in our case 246 is a relay user. A user may be a subscriber to more than one VRS 247 provider. 249 Video relay service (VRS): A relay service for people with hearing or 250 speech disabilities who use sign language to communicate using video 251 equipment (video RUE) with other people in real time. The video link 252 allows the CA to view and interpret the subscriber's signed 253 conversation and relay the conversation back and forth with the other 254 party. 256 3. Requirements Language 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 260 "OPTIONAL" in this document are to be interpreted as described in BCP 261 14 [RFC2119] [RFC8174] when, and only when, they appear in all 262 capitals, as shown here. Lower- or mixed-case uses of these key 263 words are not to be interpreted as carrying special significance. 265 4. General Requirements 267 All HTTP/HTTPS [RFC7230] and [RFC2818] connections specified 268 throughout this document MUST use HTTPS. Both HTTPS and all SIP 269 connections MUST use TLS conforming to at least [RFC7525] and MUST 270 support [RFC8446]. 272 All text data payloads not otherwise constrained by a specification 273 in another standards document MUST be encoded as Unicode UTF-8. 275 Implementations MUST support IPv4 and IPv6. Dual stack support is 276 NOT required and provider implementations MAY support separate 277 interfaces for IPv4 and IPv6 by having more than one server in the 278 appropriate SRV record where there is either an A or AAAA record in 279 each server DNS record but not both. The same version of IP MUST be 280 used for both signaling and media of a call unless ICE ([RFC8445]) is 281 used, in which case candidates may explicitly offer IPv4, IPv6 or 282 both for any media stream. 284 5. SIP Signaling 286 Implementations of the RUE Interface MUST conform to the following 287 core SIP standards: 289 * [RFC3261] (Base SIP) 291 * [RFC3263] (Locating SIP Servers) 293 * [RFC3264] (Offer/Answer) 295 * [RFC3840] (User Agent Capabilities) 297 * [RFC5626] (Outbound) 299 * [RFC8866] (Session Description Protocol) 301 * [RFC3323] (Privacy) 303 * [RFC3605] (RTCP Attribute in SDP) 305 * [RFC6665] (SIP Events) 307 * [RFC3311] (UPDATE Method) 309 * [RFC5393] (Loop-Fix) 311 * [RFC5658] (Record Route fix) 313 * [RFC5954] (ABNF fix) 315 * [RFC3960] (Early Media) 317 * [RFC6442] (Geolocation header field) 319 In the above documents the RUE device conforms to the requirements of 320 a SIP user Agent, and the provider conforms to the requirements of 321 Registrar and Proxy Server where the document specifies different 322 behavior for different roles. The only requirement on providers for 323 RFC6665 (Events) is support for the Message Waiting Indicator (See 324 Section 8), which is optional and providers not supporting video mail 325 need not support RFC6665. 327 In addition, implementations MUST conform to: 329 * [RFC3327] (Path) 331 * [RFC8445] and [RFC8839] (ICE) 332 * [RFC3326] (Reason header field) 334 * [RFC3515] (REFER Method) 336 * [RFC3891] (Replaces Header field) 338 * [RFC3892] (Referred-By) 340 Implementations MUST implement full ICE, although they MAY interwork 341 with User Agents that implement ICE-lite. 343 Implementations MUST include a "User-Agent" header field uniquely 344 identifying the RUE application, platform, and version in all SIP 345 requests, and MUST include a "Server" header field with the same 346 content in SIP responses. 348 Implementations intended to support mobile platforms MUST support 349 [RFC8599] and MUST use it as at least one way to support waking up 350 the client from background state. 352 The SIP signaling for registration and placing/receiving calls 353 depends on configuration of various values into the RUE device. 354 Section 9.2 describes the configuration mechanism which provides 355 values that are used in the signaling. When the device starts, the 356 configuration mechanism is run which retrieves the configuration 357 data, and then SIP registration occurs using the values from the 358 configuration. After registration, calls may be sent or received by 359 the RUE device. 361 5.1. Registration 363 The RUE MUST register with a SIP registrar, following [RFC3261] and 364 [RFC5626] at a provider it has an account with. If the configuration 365 (see Section 9.2) contains multiple "outbound-proxies" in 366 "RueConfigurationData", then the RUE MUST use them as specified in 367 [RFC5626] to establish multiple flows. 369 The Request-URI for the REGISTER request MUST contain the "provider- 370 domain" from the configuration. The To-URI and From-URI MUST be 371 identical URIs, formatted as follows: 373 * if "user-name" is provided:"username@provider-domain"; 375 * if "user-name" is not provided: as specified in Section 5.4, using 376 "phone-number" and "provider-domain" from the configuration. 378 The RUE determines the URI to resolve by initially determining if one 379 or more outbound proxies are+ configured. If there are, the URI will 380 be that of one of the "outbound-proxies". If no "outbound-proxies" 381 are configured, the URI will be the Request-URI from the REGISTER 382 request. The RUE extracts the domain from that URI and consults the 383 DNS record for that domain. The DNS entry MUST contain NAPTR records 384 conforming to RFC3263. One of those NAPTR records MUST specify TLS 385 as the preferred transport for SIP. For example, a DNS NAPTR query 386 for "sip: p1.red.example.net" could return: 388 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net 389 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net 391 If the RUE receives a 439 (First Hop Lacks Outbound Support) response 392 to a REGISTER request, it MUST re-attempt registration without using 393 the outbound mechanism. 395 The registrar MAY authenticate the RUE using SIP digest 396 authentication. The credentials to be used MUST come from the 397 configuration Section 9.2: "user-name" if provided or "phone-number" 398 if user-name is not provided, and "sip-password". This "user- 399 name"/"sip-password" combination SHOULD NOT be the same as that used 400 for other purposes, except as expressly described below, such as 401 retrieving the RUE configuration or logging into the Provider's 402 customer service portal. [RFC8760] MUST be supported by all 403 implementations and SHA-512 digest algorithms MUST be supported. 405 If the registration request fails with an indication that credentials 406 from the configuration are invalid, then the RUE MUST retrieve a 407 fresh version of the configuration. If credentials from a freshly 408 retrieved configuration are found to be invalid, then the RUE MUST 409 cease attempts to register and inform the RUE User of the problem. 411 Support for multiple simultaneous registrations with multiple 412 providers by the RUE is OPTIONAL for the RUE (and providers do not 413 need any support for this option). 415 Multiple simultaneous RUE SIP registrations from different RUE 416 devices with the same SIP URI SHOULD be permitted by the provider. 417 The provider MAY limit the total number of simultaneous 418 registrations. When a new registration request is received that 419 results in exceeding the limit on simultaneous registrations, the 420 provider MAY then prematurely terminate another registration; 421 however, it SHOULD NOT do this if it would disconnect an active call. 423 If a provider prematurely terminates a registration to reduce the 424 total number of concurrent registrations with the same URI, it SHOULD 425 take some action to prevent the affected RUE from automatically re- 426 registering and re-triggering the condition. 428 5.2. Session Establishment 430 5.2.1. Normal Call Origination 432 After initial SIP registration, the RUE adheres to SIP [RFC3261] 433 basic call flows, as documented in [RFC3665]. 435 A RUE device MUST route all outbound calls through an outbound proxy 436 if configured. 438 The SIP URIs in the To field and the Request-URI MUST be formatted as 439 specified in subsection Section 5.4 using the destination phone 440 number, or as SIP URIs, as provided in the configuration 441 (Section 9.2). The domain field of the URIs SHOULD be the "provider- 442 domain" from the configuration (e.g., 443 sip:+15551234567@red.example.com;user=phone) except that an anonymous 444 call would not use the provider domain. 446 Anonymous calls MUST be supported by all implementations. An 447 anonymous call is signaled per [RFC3323]. 449 The From-URI MUST be formatted as specified in Section 5.4, using the 450 phone-number and "provider-domain" from the configuration. It SHOULD 451 also contain the display-name from the configuration when present. 452 (Please refer to Section 9.2.) 454 Negotiated media MUST follow the requirements specified in Section 6 455 of this document. 457 To allow time to time out an unanswered call and direct it to a 458 videomail server, the User Agent Client MUST NOT impose a time limit 459 less than the default SIP Invite transaction timeout of 3 minutes. 461 5.2.2. Dial-Around Origination 463 Providers and RUE devices MUST support both One-Stage and Two-Stage 464 dial-around 466 Outbound dial-around calls allow a RUE user to select any provider to 467 provide interpreting services for any call. "Two-stage" dial-around 468 calls involve the RUE calling a telephone number that reaches the 469 dial-around provider and using signing or DTMF to provide the called 470 party telephone number. In two-stage dial-around, the To URI is the 471 "frontDoor" URI (see Section 9.2) in "ProviderConfigurationData" of 472 the dial-around provider. The RUE Provider Selection service 473 (Section 9.1) can be used by the RUE to obtain a list of providers 474 and then the Provider Configuration (Section 9.2.1) can be used to 475 find the front door URI for each of these providers. 477 One-stage dial-around is a method where the called party telephone 478 number is provided in the To URI and the Request-URI, using the 479 domain of the dial-around provider. 481 For one-stage dial-around, the RUE MUST follow the procedures in 482 Section 5.2.1 with the following exception: the domain part of the 483 SIP URIs in the To field and the Request-URI MUST be the domain of 484 the dial-around provider, discovered according to Section 9.1. 486 The following is a partial example of a one-stage dial-around call 487 from VRS user +1-555-222-0001 hosted by red.example.com to a hearing 488 user +1-555-123-4567 using dial-around to green.example.com for the 489 relay service. Only important details of the messages are shown and 490 many header fields have been omitted: 492 One-Stage Dial-Around 493 ,-+-. ,----+----. ,-----+-----. 494 |RUE| |Default | |Dial-Around| 495 | | |Provider | | Provider | 496 `-+-' `----+----' `-----+-----' 497 | | | 498 | [1] INVITE | | 499 |-------------->| [2] INVITE | 500 | |-------------->| 502 Message Details: 504 [1] INVITE Rue -> Default Provider 506 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 507 To: 508 From: "Bob Smith" 510 [2] INVITE Default Provider -> Dial-Around Provider 512 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 513 To: 514 From: "Bob Smith" sip:+15552220001@red.example.net;user=phone 515 P-Asserted-Identity: sip:+15552220001@red.example.net 517 Figure 1 519 5.2.3. RUE Contact Information 521 To identify the owner of a RUE, the initial INVITE for a call from a 522 RUE, or the 200 OK the RUE uses to accept a call, identifies the 523 owner by sending a Call-Info header field with a purpose parameter of 524 "rue-owner". The URI MAY be an HTTPS URI or Content-ID URL. The 525 latter is defined by [RFC2392] to locate message body parts. This 526 URI type is present in a SIP message to convey the RUE ownership 527 information as a MIME body. The form of the RUE ownership 528 information is a xCard [RFC6351]. Please refer to [RFC6442] for an 529 example of using Content-Indirect URLs in SIP messages. Note that 530 use of the Content-Indirect URL usually implies multiple message 531 bodies ("mime/multipart"). The RUE owner is the entity that has 532 local control over the device which is not necessarily the legal 533 owner of the equipment. It often is the user, but that is not 534 necessarily true. While no minimum fields in the xCard are 535 specified, the name, address, phone number and email address of the 536 RUE owner are expected to be supplied. 538 5.2.4. Incoming Calls 540 The RUE MUST only accept inbound calls sent to it by a proxy 541 mentioned in the configuration. 543 If Multiple simultaneous RUE SIP registrations from different RUE 544 devices with the same SIP URI exist, the provider MUST parallel fork 545 the call to all registered RUEs so that they ring at the same time. 546 The first RUE to reply with a 200 OK answers the call and the 547 provider MUST CANCEL other call branches. 549 5.2.5. Emergency Calls 551 Implementations MUST conform to [RFC6881] for handling of emergency 552 calls, except that if the device is unable to determine its own 553 location, it MAY send the emergency call without a Geolocation header 554 field and without a Route header field (since it would be unable to 555 query the LoST server for a route per RFC6881). If an emergency call 556 arrives at the provider without a Geolocation header field, the 557 provider MUST supply location by adding the Geolocation header field, 558 and MUST supply the route by querying the LoST server with that 559 location. 561 If the emergency call is to be handled using existing country 562 specific procedures, the provider is responsible for modifying the 563 INVITE to conform to the country-specific requirements. In this 564 case, location MAY be extracted from the RFC6881 conformant INVITE 565 and used to propagate it to the appropriate country-specific 566 entities. If the configuration specifies it, an implementation of a 567 RUE device MAY send a Geolocation header field containing its 568 location in the REGISTER request. If implemented, users MUST be 569 offered an opt-out. Country-specific procedures might require the 570 location to be pre-loaded in some entity prior to placing an 571 emergency call; however, the RUE may have a more accurate and timely 572 device location than the manual, pre-loaded entry. That information 573 MAY be used to populate the location to appropriate country-specific 574 entities. Re-registration SHOULD be used to update the location, so 575 long as the rate of re-registration is limited if the device is 576 moving. 578 Implementations MUST implement Additional Data, [RFC7852]. RUE 579 devices MUST implement Data Provider, Device Information and Owner/ 580 Subscriber Information blocks. 582 5.3. Mid-Call Signaling 584 Implementations MUST support re-INVITE to renegotiate media session 585 parameters (among other uses). Per Section 6.1, implementations MUST 586 be able to support an INFO request for full frame refresh for devices 587 that do not support RTCP mechanisms (please refer to Section 6.8). 588 Implementations MUST support an in-dialog REFER ([RFC3515] updated by 589 [RFC7647] and including support for norefersub per [RFC4488]) with 590 the Replaces header field [RFC3891] to enable call transfer. 592 5.4. URI Representation of Phone Numbers 594 SIP URIs constructed from non-URI sources (dial strings) and sent to 595 SIP proxies by the RUE MUST be represented as follows, depending on 596 whether they can be represented as an E.164 number. In this section 597 "expressed as an E.164 number" includes numbers such as toll-free 598 numbers that are not actually E.164 numbers, but have the same 599 format. 601 A dial string that can be expressed as an E.164 phone number MUST be 602 represented as a SIP URI with a URI ";user=phone" tag. The user part 603 of the URI MUST be in conformance with 'global-number' defined in 604 [RFC3966]. The user part MUST NOT contain any 'visual-separator' 605 characters, as defined in [RFC3966]. 607 Dial strings that cannot be expressed as E.164 numbers MUST be 608 represented as dialstring URIs, as specified by [RFC4967], e.g., 609 sip:411@red.example.net;user=dialstring. 611 The domain part of Relay Service URIs and User Address of Records 612 (AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or 613 IPv6 addresses. 615 5.5. Transport 617 Implementations MUST conform to [RFC8835] except for its guidance on 618 the WebRTC data channel, which this specification does not use. See 619 Section 6.2 for how RUE supports real-time text without the data 620 channel. 622 Implementations MUST support SIP outbound [RFC5626] (please also 623 refer to Section 5.1). 625 6. Media 627 This specification adopts the media specifications for WebRTC 628 ([RFC8825]). Where WebRTC defines how interactive media 629 communications may be established using a browser as a client, this 630 specification assumes a normal SIP call. Various RTP, RTCP, SDP and 631 specific media requirements specified for WebRTC are adopted for this 632 document. Explicit requirements from the WebRTC suite of documents 633 are described below . 635 To use WebRTC with this document, a gateway that presents a WebRTC 636 server interface towards a browser, and a RUE client interface 637 towards a provider is assumed. The gateway would interwork 638 signaling, and as noted below, interwork at least any real time text 639 media, in order to allow a standard browser based WebRTC client to be 640 a VRS client. The combination of the browser client and the gateway 641 would be a RUE user. This document does not specify the gateway. 643 The following sections specify the WebRTC documents to which 644 conformance is required. "Mandatory to Implement" means a conforming 645 implementation MUST implement the specified capability. It does not 646 mean that the capability must be used in every session. For example, 647 OPUS is a mandatory to implement audio codec, and all conforming 648 implementations must support OPUS. However, implementation 649 presenting a call across the RUE Interface where the call originates 650 in the Public Switched Telephone Network, or an older, non-RUE- 651 compatible device, which only offers G.711 audio, does not need to 652 include the OPUS codec in the offer, since it cannot be used with 653 that call. Conformance to this document allows end-to-end RTCP and 654 media congestion control for audio and video. 656 6.1. SRTP and SRTCP 658 Implementations MUST support [RFC8834] except that MediaStreamTracks 659 are not used. Implementations MUST conform to Section 6.4 of 660 [RFC8827]. 662 6.2. Text-Based Communication 664 Implementations MUST support real-time text ([RFC4102] and [RFC4103]) 665 via T.140 media. One original and two redundant generations MUST be 666 transmitted and supported, with a 300 ms transmission interval. 667 Implementations MUST support [RFC9071] especially for emergency 668 calls. Note that RFC4103 is not how real-time text is transmitted in 669 WebRTC and some form of transcoder would be required to interwork 670 real-time text in the data channel of WebRTC to RFC4103 real-time 671 text. 673 Transport of T.140 real-time text in WebRTC is specified in 674 [RFC8865], using the WebRTC data channel. RFC 8865 also has some 675 advice on how gateways between RFC 4103 and RFC 8865 should operate. 676 It is RECOMMENDED that RFC 8865 including multiparty support is used 677 for communication with browser-based WebRTC implementations. 678 Implementations MUST support [RFC9071]. 680 6.3. Video 682 Implementations MUST conform to [RFC7742] with following exceptions: 683 only H.264, as specified in [RFC7742], is Mandatory to Implement, and 684 VP8 support is OPTIONAL at both the device and providers. This is 685 because backwards compatibility is desirable, and older devices do 686 not support VP8. 688 6.4. Audio 690 Implementations MUST conform to [RFC7874]. 692 6.5. DTMF Digits 694 Implementations MUST support the "audio/telephone-event" [RFC4733] 695 media type. They MUST support conveying event codes 0 through 11 696 (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. 697 Handling of other tones is OPTIONAL. 699 6.6. Session Description Protocol 701 The SDP offers and answers MUST conform to the SDP rules in [RFC8829] 702 except that the RUE interface uses SIP transport for SDP. The SDP 703 for real-time text MUST specify the T.140 payload type [RFC4103]. 705 6.7. Privacy 707 The RUE MUST provide for user privacy by implementing a local one-way 708 mute, without signaling, for both audio and video. However, RUE MUST 709 maintain any states in the network (e.g. NAT bindings) by 710 periodically sending media packets on all active media sessions 711 containing silence/comfort noise/black screen/etc. per [RFC6263]. 713 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 714 Intraframe Request Features 716 The NACK, FIR and PLI features as described in [RFC4585] and 717 [RFC5104] MUST be implemented. Availability of these features MUST 718 be announced with the "ccm" feedback value. NACK should be used when 719 negotiated and conditions warrant its use and the other end supports 720 it. Signaling picture losses as Packet Loss Indicator (PLI) should 721 be preferred. FIR should be used only in situations where not 722 sending a decoder refresh point would render the video unusable for 723 the users, as per RFC5104 subsection 4.3.1.2. 725 For backwards compatibility with calling devices that do not support 726 the foregoing methods, implementations MUST implement SIP INFO 727 messages to send and receive XML encoded Picture Fast Update messages 728 according to [RFC5168]. 730 7. Contacts 732 7.1. CardDAV Login and Synchronization 734 Support of CardDAV by providers is OPTIONAL. 736 The RUE MUST and providers MAY be able to synchronize the user's 737 contact directory between the RUE endpoint and one maintained by the 738 user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). 740 The configuration (see Section Section 9.2) RueConfigurationData MAY 741 supply a "carddav-username" and "carddav-domain" identifying a 742 CardDAV server and address book for this account, plus an optional 743 "carddav-password". 745 To access the CardDAV server and address book, the RUE MUST follow 746 Section 6 of RFC6764, using the configured carddav-username and 747 carddav-domain in place of an email address. If the request triggers 748 a challenge for digest authentication credentials, the RUE MUST 749 continue using matching carddav-username and carddav-password from 750 the configuration. If no carddav-username and carddav-password are 751 configured, the RUE MUST use the SIP user-name and sip-password from 752 the configuration. If the SIP credentials fail, the RUE MUST query 753 the user. 755 Synchronization using CardDAV MUST be a two-way synchronization 756 service, with proper handling of asynchronous adds, changes, and 757 deletes at either end of the transport channel. 759 The RUE MAY support other CardDAV services. 761 7.2. Contacts Import/Export Service 763 Implementations MUST be able to export/import the list of contacts in 764 xCard [RFC6351] XML format. 766 The RUE accesses this service via the "contacts-uri" in the 767 configuration. The URL MUST resolve to identify a web server 768 resource that imports/exports contact lists for authorized users. 770 The RUE stores/retrieves the contact list (address book) by issuing 771 an HTTPS POST or GET request. If the request triggers a challenge 772 for digest authentication credentials, the RUE MUST attempt to 773 continue using the "contacts-username" and "contacts-password" from 774 the configuration. If no contacts-username is configured, the sip 775 user-name from the configuration is used, and if the sip user-name is 776 not configured, the phone-number is used. If user-name or phone- 777 number is used, the sip-password is used to authenticate to the 778 contact list server. 780 8. Video Mail 782 Support for video mail includes a retrieval mechanism and a Message 783 Waiting Indicator (MWI). Message storage is not specified by this 784 document. RUE devices MUST support message retrieval using a SIP 785 call to a specified SIP URI using DTMF to manage the mailbox, as well 786 as a browser based interface reached at a specified HTTPS URI. If a 787 provider supports video mail at least one of these mechanisms MUST be 788 supported. RUE devices MUST support both. See Section 9.2 for how 789 the URI to reach the retrieval interface is obtained. 791 Implementations MUST support subscriptions to "message-summary" 792 events [RFC3842] to the URI specified in the configuration. 793 Providers MUST support MWI if they support video mail. RUE devices 794 MUST support MWI. 796 The "videomail" and "mwi" properties in the configuration (see 797 RueConfigurationData in Section 9.2.2) gives the URIs for message 798 retrieval and "message-summary" subscription. 800 In notification bodies, if detailed message summaries are available, 801 messages with video MUST be reported using "message-context-class 802 multimedia-message" defined in [RFC3458] . 804 9. Provisioning and Provider Selection 806 To simplify how users interact with RUE devices, the RUE interface 807 separates provisioning into two parts. One provides a directory of 808 providers so that a user interface can allow easy provider selection 809 either for registering or for dial-around. The other provides 810 configuration data for the device for each provider. 812 9.1. RUE Provider Selection 814 To allow the user to select a relay service, the RUE MAY at any time 815 obtain (typically on startup) a list of Providers that provide 816 service in a country. IANA has established a registry that contains 817 a two-letter country code and an entry point string (See 818 Section 10.1). The entry point, when used with the following OpenAPI 819 interface, returns a list of provider names for a country code 820 suitable for display, with a corresponding entry point to obtain 821 information about that provider. No mechanism to determine the 822 country the RUE is located is specified in this document. Typically 823 the country is the home country of the user, but may be a local 824 country while traveling. Some countries allow support from their 825 home country when traveling abroad. Regardless, the RUE device will 826 need to allow the user to choose the country. 828 Each country that supports video relay service using this 829 specification MAY support the provider list. This document does not 830 specify who maintains the list. Some possibilities are a regulator 831 or entity designated by a regulator, an agreement among providers to 832 provide the list, or a user group. 834 The interface to obtain the list of providers is described by an 835 OpenApi [OpenApi] interface description. In that interface 836 description, the "servers" component includes an occurance of 837 "localhost". The value from the registry of the "list entry point" 838 string for the desired country is substituted for "localhost" in the 839 "servers" component to obtain the server URI prefix of the interface 840 to be used to obtain the list of providers for that country. The 841 "Providers" path then specifies the rest of the URI used to obtain 842 the list. For example, if the list entryPoint is "example.com/api", 843 the provider list would be obtained from 844 https://example.com/api/rum/v1/Providers. 846 The V1.0 "ProviderList" is a JSON object consisting of an array where 847 each entry describes one provider. Each entry consists of the 848 following items: 850 * name: This parameter contains the text label identifying the 851 provider and is meant to be displayed to the human VRS user. 853 * providerEntryPoint: A string used for configuration purposes by 854 the RUE (as discussed in Section 9.2). The string MUST start with 855 a domain, but MAY include other URI path elements after the 856 domain. 858 The VRS user interacts with the RUE to select from the provider list 859 one or more providers with whom the user has already established an 860 account, wishes to establish an account, or wishes to use the 861 provider for a one-stage dial around. 863 { 864 "providers": [ 865 { 866 "name": "Red", 867 "entryPoint": "red.example.net" 868 }, 869 { 870 "name": "Green", 871 "entryPoint": "green.example.net" 872 }, 873 { 874 "name": "Blue", 875 "entryPoint": "blue.example.net" 876 } 877 ] 878 } 880 Figure 2: Example of a ProviderList JSON object 882 9.2. RUE Configuration Service 884 A RUE device may retrieve a provider configuration using a simple 885 HTTPs web service. There are two entry points. One is used without 886 user credentials, and the response includes configuration data for 887 new user sign up and dial around. The other uses locally stored 888 username and password that results from a new user sign up to 889 authenticate to the interface and returns configuration data for the 890 RUE. 892 The interface to obtain configuration data is described by an OpenApi 893 [OpenApi] interface description. In that interface description, the 894 "servers" component string includes an occurence of "localhost". The 895 entry point string obtained from the provider list (Section 9.1) is 896 substituted for "localhost" to obtain the server prefix of the 897 interface. The path then specifies the rest of the URI used to 898 obtain the list. For example, if the entryPoint from the provider 899 list is "red.example.net", the provider configuration would be 900 obtained from https://red.example.net/rum/V1/ProviderConfig and the 901 RUE configuration would be obtained from 902 https://red.example.net/rum/V1/RueConfig. 904 In both the queries, an optional parameter may be provided to the 905 interface which is an API Key (apiKey). The implementation MAY have 906 an apiKey obtained from the provider and specific to the 907 implementation. The method used to obtain the apiKey is not 908 specified in this document. The provider MAY refuse to provide 909 service to an implementation presenting an apiKey it does not 910 recognize. 912 Also in both queries, the RUE device provides a client provided, 913 required parameter, which contains an instance identifier 914 (instanceId). This parameter MUST be the same value each time this 915 instance (same implementation on same device) queries the interface. 916 This MAY be used by the provider, for example, to associate a 917 location with the instance for emergency calls. This should be 918 globally unique. A UUID is suggested. 920 For example, a query for the RUE configuration could be 921 https://red.example.net/rum/V1/RueConfig?apiKey="t65667Ajjss90uuuDisK 922 t8999"&instanceId="5595b5a3-0687-4b8e-9913-a7f2a04fb7bd" 924 The data returned is a JSON object consisting of key/value 925 configuration parameters to be used by the RUE. 927 The configuration data payload includes the following data items. 928 Items not noted as (OPTIONAL) are REQUIRED. If other unexpected 929 items are found, they MUST be ignored. 931 9.2.1. Provider Configuration 933 * signup: (OPTIONAL) an array of JSON objects consisting of: 935 - language: entry from the IANA language subtag registry 936 (https://www.iana.org/assignments/language-subtag-registry/ 937 language-subtag-registry). Normally, this would be a written 938 language tag. 940 - uri: a URI to the website for creating a new account in the 941 supported language. The new user signup URI may only initiate 942 creation of a new account. Various vetting, approval and other 943 processes may be needed, which could take time, before the 944 account is established. The result of creating a new account 945 would be account credentials (e.g. username and password), 946 which would be manually entered into the RUE device which form 947 the authentication parameters for the RUE configuration service 948 described below in Section 9.2.2. 950 * dialAround: an array of JSON objects consisting of: 952 - language: entry from the IANA language subtag registry. 953 Normally, this would be a sign language tag. 955 - frontDoor: a URI to a queue of interpreters supporting the 956 specified language for a two-stage dial-around 958 - oneStage: a URI that can be used with a one-stage dial-around 959 Section 5.2.2 using an interpreter supporting the specified 960 language 962 * helpDesk: (OPTIONAL) an array of JSON objects consisting of: 964 - language: entry from the IANA language subtag registry. 965 Normally this would be a sign language tag, although it could 966 be a written language tag if the help desk only supports a chat 967 interface 969 - uri: URI that reaches a help desk for callers supporting the 970 specified language. The URI MAY be a SIP URI for help provided 971 with a SIP call, or MAY be an HTTPS URI for help provided with 972 a browser interface. 974 A list is specified so that the provider can offer multiple 975 choices to users for language and interface styles. 977 9.2.2. RUE Configuration 978 * lifetime: (optional) Specifies how long (in seconds) the RUE MAY 979 cache the configuration values. Values may not be valid when 980 lifetime expires. If the RUE caches configuration values, it MUST 981 cryptographically protect them against unauthorized disclosure 982 (e.g. by other applications on the platform the RUE is built on). 983 The RUE SHOULD retrieve a fresh copy of the configuration before 984 the lifetime expires or as soon as possible after it expires. The 985 lifetime is not guaranteed: the configuration may change before 986 the lifetime value expires. In that case, the Provider MAY 987 indicate this by generating authorization challenges to requests 988 and/or prematurely terminating a registration. Emergency Calls 989 MUST continue to work. If not specified, the RUE MUST fetch new 990 configuration data every time it starts. 992 * sip-password: (optional) a password used for SIP, STUN and TURN 993 authentication. The RUE device retains this data, which it MUST 994 cryptographically protect against unauthorized disclosure (e.g. by 995 other applications on the platform the RUE is built on). If it is 996 not supplied, but was supplied on a prior invocation of this 997 interface, the most recently supplied password MUST be used. If 998 it was never supplied, the password used to authenticate to the 999 configuration service is used for SIP, as well as STUN and TURN 1000 servers mentioned in this configuration. 1002 * phone-number: The telephone number (in E.164 format) assigned to 1003 this subscriber. This becomes the user portion of the SIP URI 1004 identifying the subscriber. 1006 * user-name: (optional) a username used for authenticating to the 1007 provider. If not provided, the phone-number is used. 1009 * display-name: (optional) a human readable display name for the 1010 subscriber 1012 * provider-domain: the domain for the provider. This becomes the 1013 server portion of the SIP URI identifying the subscriber. 1015 * outbound-proxies: (optional) An array of URIs of SIP proxies to be 1016 used when sending requests to the provider. 1018 * mwi: (optional) A URI identifying a SIP event server that 1019 generates "message-summary" events for this subscriber. 1021 * videomail: (optional) An SIP or HTTPS URI that can be used to 1022 retrieve video mail messages. 1024 * contacts: (optional) An HTTPS URI ("contacts-uri"), (optional) 1025 "contacts-username" and "contacts-password" that may be used to 1026 export (retrieve) the subscriber's complete contact list managed 1027 by the provider. At least the URI MUST be provided if the 1028 subscriber has contacts. If contact-username and contacts- 1029 password are not supplied, the sip credentials are used. If the 1030 contacts-username is provided, contacts-password MUST be provided. 1031 If contacts-password is provided, contacts-username MUST be 1032 provided. 1034 * carddav: (optional) An address ("carddav-domain"), (optional) 1035 "carddav-username" and "carddav-password" identifying a "CardDAV" 1036 server and account that can be used to synchronize the RUE's 1037 contact list with the contact list managed by the provider. If 1038 carddav-username and carddav-password are not supplied, the sip 1039 credentials are used. If the carddav-username is provided, 1040 carddav-password MUST be provided. If carddav-password is 1041 provided, carddav-username MUST be provided. 1043 * sendLocationWithRegistration: (optional) True if the RUE should 1044 send a Geolocation header field with REGISTER, false if it should 1045 not. Defaults to false if not present. 1047 * ice-servers: (optional) An array of server types and URLs 1048 identifying STUN and TURN servers available for use by the RUE for 1049 establishing media streams in calls via the provider. If the same 1050 URL provides both STUN and TURN services, it MUST be listed twice, 1051 each with different server types. 1053 9.2.3. Versions 1055 Both web services also have a simple version mechanism that returns a 1056 list of versions of the web service it supports. This document 1057 describes version 1.0. Versions are described as a major version, 1058 the period "." and a minor version, where major and minor versions 1059 are integers. A backwards compatible change within a major version 1060 MAY increment only the minor version number. A non-backwards 1061 compatible change MUST increment the major version number. Backwards 1062 compatibility applies to both the server and the client. Either may 1063 have any higher or lower minor revision and interoperate with its 1064 counterpart with the same major version. To achieve backwards 1065 compatibility, implementations MUST ignore any object members they do 1066 not implement. Minor version definitions SHALL only add objects, 1067 non-required members of existing objects, and non-mandatory-to use 1068 functions and SHALL NOT delete or change any objects, members of 1069 objects or functions. This means an implementation of a specific 1070 major version and minor version is backwards compatible with all 1071 minor versions of the major version. The version mechanism returns 1072 an array of supported versions, one for each major version supported, 1073 with the minor version listed being the highest supported minor 1074 version. 1076 Unless the per-country provider list service is operated by a 1077 provider at the same base URI as that provider's configuration 1078 service, the version of the configuration service MAY be different 1079 from the version of the provider list service. 1081 { 1082 "versions": [ 1083 { 1084 "major": 1, 1085 "minor": 6 1086 }, 1087 { 1088 "major": 2, 1089 "minor": 13 1090 }, 1091 { 1092 "major": 3, 1093 "minor": 2 1094 } 1095 ] 1096 } 1098 Figure 3: Example of a Version JSON object 1100 9.2.4. Examples 1102 Example JSON provider configuration payload 1103 { 1104 "signUp": [ 1105 { "language" : "en", "uri" : "https:hello-en.example.net"}, 1106 { "language" : "es", "uri" : "https:hello-es.example.net"} ] , 1107 "dialAround": [ 1108 { "language" : "en", "frontDoor" : "sip:fd-en.example.net", 1109 "oneStage" : "sip:1stg-eng.example.com" } , 1110 { "language" : "es", "frontDoor" : "sip:fd-es.example.net", 1111 "oneStage" : "sip:1stg-spn.example.com" } ] , 1112 "helpDesk": [ 1113 { "language" : "en", "uri" : "sip:help-en.example.net"} , 1114 { "language" : "es", "uri" : "sip:help-es.example.net"} ] 1115 } 1117 Figure 4 1119 Example JSON RUE configuration payload 1120 { 1121 "lifetime": 86400, 1122 "display-name" : "Bob Smith", 1123 "phone-number": "+15551234567", 1124 "provider-domain": "red.example.net", 1125 "outbound-proxies": [ 1126 "sip:p1.red.example.net", 1127 "sip:p2.red.example.net" ], 1128 "mwi": "sip:+15551234567@red.example.net;user=phone", 1129 "videomail": "sip:+15551234567@vm.red.example.net;user=phone", 1130 "contacts": { 1131 "contacts-uri": 1132 "https://red.example.net:443/c/3617b719-2c3a-46f4-9c13", 1133 "contacts-username": "bob", 1134 "contacts-password": "XhOT4ch@ZEi&3u2xEYQNMO^5UGb" 1135 }, 1136 "carddav": { 1137 "carddav-domain": "carddav.example.com", 1138 "carddav-username": "bob", 1139 "carddav-password": "sj887%dd*jJty%87hyys5hHT" 1140 }, 1141 "sendLocationWithRegistration": false, 1142 "ice-servers": [ 1143 {"stun":"stun.red.example.com:19302" }, 1144 {"turn":"turn.red.example.com:3478"} 1145 ] 1146 } 1148 Figure 5 1150 9.2.5. Using the Provider Selection and RUE Configuration Services 1151 Together 1153 One way to use these two services is: 1155 * At startup, the RUE retrieves the provider list for the country it 1156 is located in. 1158 * For each provider in the list: 1160 - If the RUE does not have credentials for that provider, if 1161 requested by the user, use the ProviderConfig path without 1162 credentials to obtain signup, dial around and helpdesk 1163 information. 1165 - If the RUE has credentials for that provider, use the RueConfig 1166 path with the locally stored credentials to configure the RUE 1167 for that provider. 1169 9.3. OpenAPI Interface Descriptions 1171 The interfaces in Section 9.1 and Section 9.2 are formally specified 1172 with OpenAPI 3.0 ([OpenApi]) descriptions in YAML form. 1174 The OpenAPI description below is normative. If there is any conflict 1175 between the text or examples and this section, the OpenAPI 1176 description takes precedence. 1178 9.3.1. Provider List 1180 openapi: 3.0.1 1181 info: 1182 title: RUM Provider List API 1183 version: "1.0" 1184 servers: 1185 - url: https://localhost/rum/v1 1186 paths: 1187 /Providers: 1188 get: 1189 summary: Get a list of providers and domains to get 1190 config data from 1191 operationId: GetProviderList 1192 responses: 1193 '200': 1194 description: List of providers for a country 1195 content: 1196 application/json: 1197 schema: 1198 $ref: '#/components/schemas/ProviderList' 1199 /Versions: 1200 servers: 1201 - url: https://localhost/rum 1202 description: Override base path for Versions query 1203 get: 1204 summary: Retrieves all supported versions 1205 operationId: RetrieveVersions 1206 responses: 1207 '200': 1208 description: Versions supported 1209 content: 1210 application/json: 1211 schema: 1212 $ref: '#/components/schemas/VersionsArray' 1213 components: 1214 schemas: 1215 ProviderList: 1216 type: object 1217 required: 1218 - providers 1219 properties: 1220 providers: 1221 type: array 1222 items: 1223 type: object 1224 required: 1225 - name 1226 - providerEntryPoint 1227 properties: 1228 name: 1229 type: string 1230 description: Human readable provider name 1231 providerEntryPoint: 1232 type: string 1233 description: provider entry point for interface 1234 VersionsArray: 1235 type: object 1236 required: 1237 - versions 1238 properties: 1239 versions: 1240 type: array 1241 items: 1242 type: object 1243 required: 1244 - major 1245 - minor 1246 properties: 1247 major: 1248 type: integer 1249 format: int32 1250 description: Version major number 1251 minor: 1252 type: integer 1253 format: int32 1254 description: Version minor number 1256 Figure 6: Provider List OpenAPI description (RueProviderList.yaml) 1258 9.3.2. Configuration 1259 openapi: 3.0.1 1260 info: 1261 title: RUM Configuration API 1262 version: "1.0" 1263 servers: 1264 - url: https://localhost/rum/v1 1265 paths: 1266 /ProviderConfig: 1267 get: 1268 summary: Configuration data for one provider 1269 operationId: GetProviderConfiguration 1270 parameters: 1271 - in: query 1272 name: apiKey 1273 schema: 1274 type: string 1275 description: API Key assigned to this implementation 1276 - in: query 1277 name: instanceId 1278 schema: 1279 type: string 1280 required: true 1281 description: Unique string for this implementation 1282 on this device 1283 responses: 1284 '200': 1285 description: configuration object 1286 content: 1287 application/json: 1288 schema: 1289 $ref: 1290 '#/components/schemas/ProviderConfigurationData' 1291 /RueConfig: 1292 get: 1293 summary: Configuration data for one RUE 1294 operationId: GetRueConfiguration 1295 parameters: 1296 - in: query 1297 name: apiKey 1298 schema: 1299 type: string 1300 description: API Key assigned to this implementation 1301 - in: query 1302 name: instanceId 1303 schema: 1304 type: string 1305 required: true 1306 description: Unique string for this implementation 1307 on this device 1308 responses: 1309 '200': 1310 description: configuration object 1311 content: 1312 application/json: 1313 schema: 1314 $ref: '#/components/schemas/RueConfigurationData' 1315 /Versions: 1316 servers: 1317 - url: https://localhost/rum 1318 description: Override base path for Versions query 1319 get: 1320 summary: Retrieves all supported versions 1321 operationId: RetrieveVersions 1322 responses: 1323 '200': 1324 description: Versions supported 1325 content: 1326 application/json: 1327 schema: 1328 $ref: '#/components/schemas/VersionsArray' 1329 components: 1330 schemas: 1331 ProviderConfigurationData: 1332 type: object 1333 required: 1334 - dialAround 1335 properties: 1336 signup: 1337 type: array 1338 items: 1339 type: object 1340 required: 1341 - language 1342 - uri 1343 properties: 1344 language: 1345 type: string 1346 description: entry from IANA language-subtag-registry 1347 uri: 1348 type: string 1349 format: uri 1350 description: URI to signup website supporting 1351 this language 1352 dialAround: 1353 type: array 1354 items: 1356 type: object 1357 required: 1358 - language 1359 - frontDoor 1360 - oneStage 1361 properties: 1362 language: 1363 type: string 1364 description: entry from IANA language-subtag-registry 1365 frontDoor: 1366 type: string 1367 format: uri 1368 description: SIP URI for two-stage dial around 1369 oneStage: 1370 type: string 1371 format: uri 1372 description: SIP URI for one-stage dial around 1373 helpDesk: 1374 type: array 1375 items: 1376 type: object 1377 required: 1378 - language 1379 - uri 1380 properties: 1381 language: 1382 type: string 1383 description: entry from IANA language-subtag-registry 1384 uri: 1385 type: string 1386 format: uri 1387 description: SIP URI of helpdesk supporting language 1388 RueConfigurationData: 1389 type: object 1390 required: 1391 - phone-number 1392 - provider-domain 1393 properties: 1394 lifetime: 1395 type: integer 1396 description: how long (in seconds) the RUE MAY cache the 1397 configuration values 1398 sip-password: 1399 type: string 1400 phone-number: 1401 type: string 1402 description: telephone number assigned this subscriber in 1403 E.164 format 1405 user-name: 1406 type: string 1407 description: a username assigned this subscriber. 1408 display-name: 1409 type: string 1410 description: display name for the subscriber 1411 provider-domain: 1412 type: string 1413 description: domain of the provider for this subscriber 1414 outbound-proxies: 1415 type: array 1416 items: 1417 type: string 1418 format: uri 1419 description: SIP URI of a proxy to be used when sending 1420 requests to the provider 1421 mwi: 1422 type: string 1423 format: uri 1424 description: A URI identifying a SIP event server that 1425 generates "message-summary" events for this subscriber. 1426 videomail: 1427 type: string 1428 format: uri 1429 description: An HTTPS or SIP URI that can be used to 1430 retrieve video mail messages. 1431 contacts: 1432 type: object 1433 description: server and credentials for contact 1434 import/export 1435 required: 1436 - contacts-uri 1437 properties: 1438 contacts-uri: 1439 type: string 1440 format: uri 1441 description: An HTTPS URI that may be used to export 1442 (retrieve) the subscriber's complete contact list 1443 managed by the provider. 1444 contacts-username: 1445 type: string 1446 description: username for authentication with CardDAV 1447 server. Use sip user-name if not provided 1448 contacts-password: 1449 type: string 1450 description: password for authentication. Use provider 1451 sip-password if not provided 1452 carddav: 1454 type: object 1455 description: CardDAV server and user information that can 1456 be used to synchronize the RUE's contact list with 1457 the contact list managed by the provider. 1458 required: 1459 - carddav-domain 1460 properties: 1461 carddav-domain: 1462 type: string 1463 description: CardDAV server address 1464 carddav-username: 1465 type: string 1466 description: username for authentication with CardDAV 1467 server. Use sip user-name if not provided 1468 carddav-password: 1469 type: string 1470 description: password for authentication to the CardDAV 1471 server. Use provider sip-password if not provided 1472 sendLocationWithRegistration: 1473 type: boolean 1474 description: True if the RUE should send a Geolocation 1475 header field with REGISTER, false if it should not. 1476 Defaults to false if not present. 1477 ice-servers: 1478 type: array 1479 items: 1480 type: object 1481 required: 1482 - server-type 1483 - uri 1484 properties: 1485 server-type: 1486 type: string 1487 description: server type ("stun" or "turn") 1488 uri: 1489 type: string 1490 format: uri 1491 description: URIs identifying STUN and TURN servers 1492 available for use by the RUE for establishing 1493 media streams in calls via the provider. 1494 VersionsArray: 1495 type: object 1496 required: 1497 - versions 1498 properties: 1499 versions: 1500 type: array 1501 items: 1503 type: object 1504 required: 1505 - major 1506 - minor 1507 properties: 1508 major: 1509 type: integer 1510 format: int32 1511 description: Version major number 1512 minor: 1513 type: integer 1514 format: int32 1515 description: Version minor number 1517 Figure 7: Configuration OpenAPI description (RueConfiguration.yaml) 1519 10. IANA Considerations 1521 10.1. RUE Provider List Registry 1523 IANA has created the "RUE Provider List" registry. The management 1524 policy for this registry is "Expert Review" [RFC8126]. The expert 1525 should prefer a regulator operated or designated list interface 1526 operator. Otherwise, evidence that the proposed list interface 1527 operator will provide a complete list of providers is required to add 1528 the entry to the registry. Updates to the registry are permitted if 1529 the expert judges the new proposed URI to provide a more accurate 1530 list than the existing entry. Each entry has two fields, values for 1531 both of which MUST be provided when registering or updating an entry: 1533 * country code: a two-letter ISO93166 country code 1535 * list entry point: a string is used to compose the URI to the 1536 provider list interface for that country 1538 10.2. Registration of rue-owner Value of the purpose Parameter 1540 This document defines the new predefined value "rue-owner" for the 1541 "purpose" header field parameter of the Call-Info header field. The 1542 use for rue-owner is defined in Section 5.2.3. This modifies the 1543 "Header Field Parameters and Parameter Values" subregistry of the 1544 "Session Initiation Protocol (SIP) Parameters" registry by adding 1545 this RFC as a reference to the line for the header field "Call-Info" 1546 and parameter name "purpose" 1548 * Header Field: Call-Info 1550 * Parameter Name: purpose 1551 * Predefined Values: Yes 1553 11. Security Considerations 1555 The RUE is required to communicate with servers on public IP 1556 addresses and specific ports to perform its required functions. If 1557 it is necessary for the RUE to function on a corporate or other 1558 network that operates a default-deny firewall between the RUE and 1559 these services, the user must arrange with their network manager for 1560 passage of traffic through such a firewall in accordance with the 1561 protocols and associated SRV records as exposed by the provider. 1562 Because VRS providers may use different ports for different services, 1563 these port numbers may differ from provider to provider. 1565 This document requires implementation and use of a number of other 1566 specifications in order to fulfill the RUE profile; the security 1567 considerations described in those documents apply accordingly to the 1568 RUE interactions. 1570 When a CA participates in a conversation they have access to the 1571 content of the conversation even though it is nominally a 1572 conversation between the two endpoints. There is an expectation that 1573 the CA will keep the communication contents in confidence. This is 1574 usually defined by contractual or legal requirements. 1576 Since different providers (within a given country) may have different 1577 policies, RUE implementations MUST include a user interaction step to 1578 select from available providers before proceeding to actually 1579 register with any given provider. 1581 12. 1582 Normative References 1584 [OpenApi] Miller, D., Whitlock, J., Gardiner, M., Ralpson, M., 1585 Ratovsky, R., and U. Sarid, "OpenAPI Specification 1586 v3.0.1", December 2017, 1587 . 1589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1590 Requirement Levels", BCP 14, RFC 2119, 1591 DOI 10.17487/RFC2119, March 1997, 1592 . 1594 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1595 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 1596 . 1598 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1599 DOI 10.17487/RFC2818, May 2000, 1600 . 1602 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1603 A., Peterson, J., Sparks, R., Handley, M., and E. 1604 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1605 DOI 10.17487/RFC3261, June 2002, 1606 . 1608 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1609 Protocol (SIP): Locating SIP Servers", RFC 3263, 1610 DOI 10.17487/RFC3263, June 2002, 1611 . 1613 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1614 with Session Description Protocol (SDP)", RFC 3264, 1615 DOI 10.17487/RFC3264, June 2002, 1616 . 1618 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1619 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1620 2002, . 1622 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1623 Initiation Protocol (SIP)", RFC 3323, 1624 DOI 10.17487/RFC3323, November 2002, 1625 . 1627 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1628 Header Field for the Session Initiation Protocol (SIP)", 1629 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1630 . 1632 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1633 (SIP) Extension Header Field for Registering Non-Adjacent 1634 Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, 1635 . 1637 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1638 Context for Internet Mail", RFC 3458, 1639 DOI 10.17487/RFC3458, January 2003, 1640 . 1642 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1643 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1644 . 1646 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1647 in Session Description Protocol (SDP)", RFC 3605, 1648 DOI 10.17487/RFC3605, October 2003, 1649 . 1651 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1652 "Indicating User Agent Capabilities in the Session 1653 Initiation Protocol (SIP)", RFC 3840, 1654 DOI 10.17487/RFC3840, August 2004, 1655 . 1657 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1658 Indication Event Package for the Session Initiation 1659 Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 1660 2004, . 1662 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1663 Protocol (SIP) "Replaces" Header", RFC 3891, 1664 DOI 10.17487/RFC3891, September 2004, 1665 . 1667 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 1668 Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, 1669 September 2004, . 1671 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1672 Tone Generation in the Session Initiation Protocol (SIP)", 1673 RFC 3960, DOI 10.17487/RFC3960, December 2004, 1674 . 1676 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1677 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1678 . 1680 [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", 1681 RFC 4102, DOI 10.17487/RFC4102, June 2005, 1682 . 1684 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1685 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 1686 . 1688 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 1689 (SIP) REFER Method Implicit Subscription", RFC 4488, 1690 DOI 10.17487/RFC4488, May 2006, 1691 . 1693 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1694 "Extended RTP Profile for Real-time Transport Control 1695 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1696 DOI 10.17487/RFC4585, July 2006, 1697 . 1699 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1700 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1701 DOI 10.17487/RFC4733, December 2006, 1702 . 1704 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1705 Initiation Protocol Uniform Resource Identifier", 1706 RFC 4967, DOI 10.17487/RFC4967, July 2007, 1707 . 1709 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1710 "Codec Control Messages in the RTP Audio-Visual Profile 1711 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1712 February 2008, . 1714 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1715 Media Control", RFC 5168, DOI 10.17487/RFC5168, March 1716 2008, . 1718 [RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. 1719 Campen, "Addressing an Amplification Vulnerability in 1720 Session Initiation Protocol (SIP) Forking Proxies", 1721 RFC 5393, DOI 10.17487/RFC5393, December 2008, 1722 . 1724 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1725 "Managing Client-Initiated Connections in the Session 1726 Initiation Protocol (SIP)", RFC 5626, 1727 DOI 10.17487/RFC5626, October 2009, 1728 . 1730 [RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing 1731 Record-Route Issues in the Session Initiation Protocol 1732 (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, 1733 . 1735 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 1736 "Essential Correction for IPv6 ABNF and URI Comparison in 1737 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 1738 . 1740 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1741 Keeping Alive the NAT Mappings Associated with RTP / RTP 1742 Control Protocol (RTCP) Flows", RFC 6263, 1743 DOI 10.17487/RFC6263, June 2011, 1744 . 1746 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 1747 RFC 6351, DOI 10.17487/RFC6351, August 2011, 1748 . 1750 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 1751 Authoring and Versioning (WebDAV)", RFC 6352, 1752 DOI 10.17487/RFC6352, August 2011, 1753 . 1755 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1756 for the Session Initiation Protocol", RFC 6442, 1757 DOI 10.17487/RFC6442, December 2011, 1758 . 1760 [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, 1761 DOI 10.17487/RFC6665, July 2012, 1762 . 1764 [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions 1765 to WebDAV (CalDAV) and vCard Extensions to WebDAV 1766 (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, 1767 . 1769 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1770 Communications Services in Support of Emergency Calling", 1771 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1772 . 1774 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1775 Protocol (HTTP/1.1): Message Syntax and Routing", 1776 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1777 . 1779 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1780 "Recommendations for Secure Use of Transport Layer 1781 Security (TLS) and Datagram Transport Layer Security 1782 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1783 2015, . 1785 [RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of 1786 REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, 1787 September 2015, . 1789 [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec 1790 Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 1791 . 1793 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1794 J. Winterbottom, "Additional Data Related to an Emergency 1795 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 1796 . 1798 [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing 1799 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, 1800 . 1802 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1803 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1804 May 2017, . 1806 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1807 Connectivity Establishment (ICE): A Protocol for Network 1808 Address Translator (NAT) Traversal", RFC 8445, 1809 DOI 10.17487/RFC8445, July 2018, 1810 . 1812 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1813 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1814 . 1816 [RFC8599] Holmberg, C. and M. Arnold, "Push Notification with the 1817 Session Initiation Protocol (SIP)", RFC 8599, 1818 DOI 10.17487/RFC8599, May 2019, 1819 . 1821 [RFC8760] Shekh-Yusef, R., "The Session Initiation Protocol (SIP) 1822 Digest Access Authentication Scheme", RFC 8760, 1823 DOI 10.17487/RFC8760, March 2020, 1824 . 1826 [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for 1827 Browser-Based Applications", RFC 8825, 1828 DOI 10.17487/RFC8825, January 2021, 1829 . 1831 [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, 1832 DOI 10.17487/RFC8827, January 2021, 1833 . 1835 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 1836 "JavaScript Session Establishment Protocol (JSEP)", 1837 RFC 8829, DOI 10.17487/RFC8829, January 2021, 1838 . 1840 [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport 1841 and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, 1842 January 2021, . 1844 [RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, 1845 DOI 10.17487/RFC8835, January 2021, 1846 . 1848 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, 1849 A., and R. Shpount, "Session Description Protocol (SDP) 1850 Offer/Answer Procedures for Interactive Connectivity 1851 Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, 1852 January 2021, . 1854 [RFC8865] Holmberg, C. and G. Hellström, "T.140 Real-Time Text 1855 Conversation over WebRTC Data Channels", RFC 8865, 1856 DOI 10.17487/RFC8865, January 2021, 1857 . 1859 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1860 Session Description Protocol", RFC 8866, 1861 DOI 10.17487/RFC8866, January 2021, 1862 . 1864 [RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real- 1865 Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, 1866 . 1868 13. 1869 Informative References 1871 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1872 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1873 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1874 December 2003, . 1876 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1877 Writing an IANA Considerations Section in RFCs", BCP 26, 1878 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1879 . 1881 Acknowledgements 1883 Brett Henderson and Jim Malloy provided many helpful edits to prior 1884 versions of this document. Paul Kyzivat provided extensive reviews 1885 and comments. 1887 Author's Address 1889 Brian Rosen 1890 470 Conrad Dr 1891 Mars, PA 16046 1892 United States of America 1893 Email: br@brianrosen.net