idnits 2.17.1 draft-ietf-rum-rue-09.txt: -(1598): 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 October 2021) is 926 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 467 -- Looks like a reference, but probably isn't: '2' on line 473 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 3960 ** Downref: Normative reference to an Informational RFC: RFC 5168 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 8829 (Obsoleted by RFC 9429) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rum B. Rosen 3 Internet-Draft 11 October 2021 4 Intended status: Standards Track 5 Expires: 14 April 2022 7 Interoperability Profile for Relay User Equipment 8 draft-ietf-rum-rue-09 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/HoH user and an 16 audio telephone call to the hearing user. The CA interprets using 17 sign language on the videophone link and voice on the telephone link. 18 Often the interpreters may be employed by a company or agency termed 19 a "provider" in this document. The provider also provides a video 20 service that allows users to connect video devices to their service, 21 and subsequently to CAs and other deaf/HoH users. It is desirable 22 that the videophones used by the deaf, hard of hearing or hearing 23 impaired user conform to a standard so that any device may be used 24 with any provider and that direct video calls between deaf, hard of 25 hearing or hearing impaired users work. This document describes the 26 interface between a videophone and a provider. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 14 April 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 64 4. General Requirements . . . . . . . . . . . . . . . . . . . . 6 65 5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 8 67 5.2. Session Establishment . . . . . . . . . . . . . . . . . . 9 68 5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 9 69 5.2.2. Dial-Around Origination . . . . . . . . . . . . . . . 10 70 5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 11 71 5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 11 72 5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 12 73 5.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 12 74 5.4. URI Representation of Phone Numbers . . . . . . . . . . . 13 75 5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 14 78 6.2. Text-Based Communication . . . . . . . . . . . . . . . . 14 79 6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 15 82 6.6. Session Description Protocol . . . . . . . . . . . . . . 15 83 6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 85 Intraframe Request Features . . . . . . . . . . . . . . . 15 86 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 15 88 7.2. Contacts Import/Export Service . . . . . . . . . . . . . 16 89 8. Video Mail . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 9. Provisioning and Provider Selection . . . . . . . . . . . . . 17 91 9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 17 92 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 19 93 9.2.1. Provider Configuration . . . . . . . . . . . . . . . 20 94 9.2.2. RUE Configuration . . . . . . . . . . . . . . . . . . 21 95 9.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 22 96 9.2.4. Using the Provider Selection and RUE Configuration 97 Services Together . . . . . . . . . . . . . . . . . . 23 99 9.3. OpenAPI Interface Descriptions . . . . . . . . . . . . . 23 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 101 10.1. RUE Provider List Registry . . . . . . . . . . . . . . . 29 102 10.2. Registration of rue-owner Value of the purpose 103 Parameter . . . . . . . . . . . . . . . . . . . . . . . 29 104 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 105 12. Normative References . . . . . . . . . . . . . . . . . . . . 29 106 13. Informative References . . . . . . . . . . . . . . . . . . . 35 107 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36 110 1. Introduction 112 Video Relay Service (VRS) is a form of Telecommunications Relay 113 Service (TRS) that enables persons with hearing disabilities who use 114 sign language, such as American Sign Language (ASL), to communicate 115 with voice telephone users through video equipment. These services 116 also enable communication between such individuals directly in 117 suitable modalities, including any combination of sign language via 118 video, real-time text (RTT), and speech. 120 This Interoperability Profile for Relay User Equipment (RUE) is a 121 profile of the Session Initiation Protocol (SIP) and related media 122 protocols that enables end-user equipment registration and calling 123 for VRS calls. It specifies the minimal set of call flows, Internet 124 Engineering Task Force (IETF) and ITU-T standards that must be 125 supported, provides guidance where the standards leave multiple 126 implementation options, and specifies minimal and extended 127 capabilities for RUE calls. 129 Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/ 130 HoH calls are supported on this interface. While there are some 131 accommodations in this document to maximize backwards compatibility 132 with other devices and services that are used to provide VRS service, 133 backwards compatibility is not a requirement, and some interwork may 134 be required to allow direct video calls to older devices. This 135 document only describes the interface between the device and the 136 provider, and not any other interface the provider may have. 138 2. Terminology 140 Communication Assistant (CA): A sign-language interpreter working for 141 a VRS provider, providing functionally equivalent phone service. 143 Communication modality (modality): A specific form of communication 144 that may be employed by two users, e.g., English voice, Spanish 145 voice, American Sign Language, English lip-reading, or French real- 146 time-text. Here, one communication modality is assumed to encompass 147 both the language and the way that language is exchanged. For 148 example, English voice and French voice are two different 149 communication modalities. 151 Default video relay service: The video relay service operated by a 152 subscriber's default VRS provider. 154 Default video relay service provider (default provider): The VRS 155 provider that registers, and assigns a telephone number to a specific 156 subscriber, and by default provides the VRS for incoming voice calls 157 to the user. The default provider also by default provides VRS for 158 outgoing relay calls. The user can have more than one telephone 159 number and each has a default provider. 161 Outbound Dial-around call: A relay call where the subscriber 162 specifies the use of a VRS provider other than the default VRS 163 provider. This can be accomplished by the user dialing a "front- 164 door" number for a VRS provider and signing or texting a phone number 165 to call ("two-stage"). Alternatively, this can be accomplished by 166 the user's RUE software instructing the server of its default VRS 167 provider to automatically route the call through the alternate 168 provider to the desired public switched telephone network (PSTN) 169 directory number ("one-stage"). Dial-around is per-call -- for any 170 call, a user can use the default VRS provider or any dial-around VRS 171 provider. 173 Full Intra Request (FIR): A request to a video media sender, 174 requiring that media sender to send a Decoder Refresh Point at the 175 earliest opportunity. FIR is sometimes known as "instantaneous 176 decoder refresh request", "video fast update request", or "fast 177 update request". 179 Point-to-Point Call (P2P Call): A call between two RUEs, without 180 including a CA. 182 Relay call: A call that allows persons with hearing or speech 183 disabilities to use a RUE to talk to users of traditional voice 184 services with the aid of a communication assistant (CA) to relay the 185 communication. 187 Relay service (RS): A service that allow a registered subscriber to 188 use a RUE to make and receive relay calls, point-to-point calls, and 189 relay-to-relay calls. The functions provided by the relay service 190 include the provision of media links supporting the communication 191 modalities used by the caller and callee, and user registration and 192 validation, authentication, authorization, automatic call distributor 193 (ACD) platform functions, routing (including emergency call routing), 194 call setup, mapping, call features (such as call forwarding and video 195 mail), and assignment of CAs to relay calls. 197 Relay service provider (provider): An organization that operates a 198 relay service. A subscriber selects a relay service provider to 199 assign and register a telephone number for their use, to register 200 with for receipt of incoming calls, and to provide the default 201 service for outgoing calls. 203 Relay user: Please refer to "subscriber". 205 Relay user E.164 Number (user E.164): The telephone number (in ITU-T 206 E.164 format) assigned to the user. 208 Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra 209 features to support a subscriber in requesting, receiving and using 210 relay calls. A RUE may take many forms, including a stand-alone 211 device; an application running on a general-purpose computing device 212 such as a laptop, tablet or smart phone; or proprietary equipment 213 connected to a server that provides the RUE interface. 215 RUE Interface: the interfaces described in this document between a 216 RUE and a VRS provider who supports it 218 Sign language: A language that uses hand gestures and body language 219 to convey meaning including, but not limited to, American Sign 220 Language (ASL). 222 Subscriber: An individual who has registered with a provider and who 223 obtains service by using relay user equipment. This is the 224 traditional telecom term for an end-user customer, which in our case 225 is a relay user. A user may be a subscriber to more than one VRS 226 provider. 228 Video relay service (VRS): A relay service for people with hearing or 229 speech disabilities who use sign language to communicate using video 230 equipment (video RUE) with other people in real time. The video link 231 allows the CA to view and interpret the subscriber's signed 232 conversation and relay the conversation back and forth with the other 233 party. 235 3. Requirements Language 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 239 "OPTIONAL" in this document are to be interpreted as described in BCP 240 14 [RFC2119] [RFC8174] when, and only when, they appear in all 241 capitals, as shown here. Lower- or mixed-case uses of these key 242 words are not to be interpreted as carrying special significance. 244 4. General Requirements 246 All HTTP/HTTPS [RFC7230] and [RFC2818] connections specified 247 throughout this document MUST use HTTPS. Both HTTPS and all SIP 248 connections MUST use TLS conforming to at least [RFC7525] and MUST 249 support [RFC8446]. 251 All text data payloads not otherwise constrained by a specification 252 in another standards document MUST be encoded as Unicode UTF-8. 254 Implementations MUST support IPv4 and IPv6. Dual stack support is 255 NOT required and provider implementations MAY support separate 256 interfaces for IPv4 and IPv6 by having more than one server in the 257 appropriate SRV record where there is either an A or AAAA record in 258 each server DNS record but not both. The same version of IP MUST be 259 used for both signaling and media of a call unless ICE ([RFC8445]) is 260 used, in which case candidates may explicitly offer IPv4, IPv6 or 261 both for any media stream. 263 5. SIP Signaling 265 Implementations of the RUE Interface MUST conform to the following 266 core SIP standards: 268 * [RFC3261] (Base SIP) 270 * [RFC3263] (Locating SIP Servers) 272 * [RFC3264] (Offer/Answer) 274 * [RFC3840] (User Agent Capabilities) 276 * [RFC5626] (Outbound) 278 * [RFC8866] (Session Description Protocol) 280 * [RFC3323] (Privacy) 282 * [RFC3605] (RTCP Attribute in SDP) 283 * [RFC6665] (SIP Events) 285 * [RFC3311] (UPDATE Method) 287 * [RFC5393] (Loop-Fix) 289 * [RFC5658] (Record Route fix) 291 * [RFC5954] (ABNF fix) 293 * [RFC3960] (Early Media) 295 * [RFC6442] (Geolocation header field) 297 In the above documents the RUE device conforms to the requirements of 298 a SIP user Agent, and the provider conforms to the requirements of 299 Registrar and Proxy Server where the document specifies different 300 behavior for different roles. The only requirement on providers for 301 RFC6655 (Events) is support for the Message Waiting Indicator (See 302 Section 8), which is optional and providers not supporting video mail 303 need not support RFC6665. 305 In addition, implementations MUST conform to: 307 * [RFC3327] (Path) 309 * [RFC8445] and [RFC8839] (ICE) 311 * [RFC3326] (Reason header field) 313 * [RFC3515] (REFER Method) 315 * [RFC3891] (Replaces Header field) 317 * [RFC3892] (Referred-By) 319 Implementations MUST include a "User-Agent" header field uniquely 320 identifying the RUE application, platform, and version in all SIP 321 requests, and MUST include a "Server" header field with the same 322 content in SIP responses. 324 Implementations intended to support mobile platforms MUST support 325 [RFC8599] and MUST use it as at least one way to support waking up 326 the client from background state. 328 5.1. Registration 330 The RUE MUST register with a SIP registrar, following [RFC3261] and 331 [RFC5626] at a provider it has an account with. If the configuration 332 (see Section 9.2) contains multiple "outbound-proxies", then the RUE 333 MUST use them as specified in [RFC5626] to establish multiple flows. 335 The Request-URI for the REGISTER request MUST contain the "provider- 336 domain" from the configuration. The To-URI and From-URI MUST be 337 identical URIs, formatted as specified in Section 5.4, using the 338 "phone-number" and "provider-domain" from the configuration. 340 The RUE determines the URI to resolve by initially determining if an 341 outbound proxy is configured. If it is, the URI will be that of the 342 outbound proxy. If no outbound proxy is configured, the URI will be 343 the Request-URI from the REGISTER request. The RUE extracts the 344 domain from that URI and consults the DNS record for that domain. 345 The DNS entry MUST contain NAPTR records conforming to RFC3263. One 346 of those NAPTR records MUST specify TLS as the preferred transport 347 for SIP. For example, a DNS NAPTR query for "sip: 348 p1.red.example.net" could return: 350 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net 351 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net 353 If the RUE receives a 439 (First Hop Lacks Outbound Support) response 354 to a REGISTER request, it MUST re-attempt registration without using 355 the outbound mechanism. 357 The registrar MAY authenticate using SIP digest authentication. The 358 credentials to be used (username and password) MUST be supplied 359 within the credentials section of the configuration and identified by 360 the realm the registrar uses in a digest challenge. This username/ 361 password combination SHOULD NOT be the same as that used for other 362 purposes, such as retrieving the RUE configuration or logging into 363 the Provider's customer service portal. [RFC8760] MUST be supported 364 by all implementations and SHA-512 digest algorithms MUST be 365 supported. 367 If the registration request fails with an indication that credentials 368 from the configuration are invalid, then the RUE MUST retrieve a 369 fresh version of the configuration. If credentials from a freshly 370 retrieved configuration are found to be invalid, then the RUE MUST 371 cease attempts to register and inform the RUE User of the problem. 373 Support for multiple simultaneous registrations with multiple 374 providers by the RUE is OPTIONAL for the RUE (and providers do not 375 need any support for this option). 377 Multiple simultaneous RUE SIP registrations from different RUE 378 devices with the same SIP URI SHOULD be permitted by the provider. 379 The provider MAY limit the total number of simultaneous 380 registrations. When a new registration request is received that 381 results in exceeding the limit on simultaneous registrations, the 382 provider MAY then prematurely terminate another registration; 383 however, it SHOULD NOT do this if it would disconnect an active call. 385 If a provider prematurely terminates a registration to reduce the 386 total number of concurrent registrations with the same URI, it SHOULD 387 take some action to prevent the affected RUE from automatically re- 388 registering and re-triggering the condition. 390 5.2. Session Establishment 392 5.2.1. Normal Call Origination 394 After initial SIP registration, the RUE adheres to SIP [RFC3261] 395 basic call flows, as documented in [RFC3665]. 397 A RUE device MUST route all outbound calls through an outbound proxy 398 if configured. 400 The SIP URIs in the To field and the Request-URI MUST be formatted as 401 specified in subsection Section 5.4 using the destination phone 402 number, or as SIP URIs, as provided in the configuration 403 (Section 9.2). The domain field of the URIs SHOULD be the "provider- 404 domain" from the configuration (e.g., 405 sip:+13115552368@red.example.com;user=phone) except that an anonymous 406 call would not use the provider domain. 408 Anonymous calls MUST be supported by all implementations. An 409 anonymous call is signaled per [RFC3323]. 411 The From-URI MUST be formatted as specified in Section 5.4, using the 412 phone-number and "provider-domain" from the configuration. It SHOULD 413 also contain the display-name from the configuration when present. 414 (Please refer to Section 9.2.) 416 Negotiated media MUST follow the guidelines specified in Section 6 of 417 this document. 419 To allow time to timeout an unanswered call and direct it to a 420 videomail server, the User Agent Client MUST NOT impose a time limit 421 less than the default SIP Invite transaction timeout of 3 minutes. 423 5.2.2. Dial-Around Origination 425 Providers and RUE devices MUST support both One-Stage and Two-Stage 426 dial-around 428 Outbound dial-around calls allow a RUE user to select any provider to 429 provide interpreting services for any call. "Two-stage" dial-around 430 calls involve the RUE calling a telephone number that reaches the 431 dial-around provider and using signing or DTMF to provide the called 432 party telephone number. In two-stage dial-around, the To URI is the 433 front door URI (see Section 9.2) of the dial-around provider and the 434 domain of the URI is the provider domain from the configuration. The 435 provider list service (Section 9.1) can be used by the RUE to obtain 436 a list of providers and then the configuration service 437 (Section 9.2.1) without credentials can be used to find the front 438 door URI for each of these providers. 440 One-stage dial-around is a method where the called party telephone 441 number is provided in the To URI and the Request-URI, using the 442 domain of the dial-around provider. 444 For one-stage dial-around, the RUE MUST follow the procedures in 445 Section 5.2.1 with the following exception: the domain part of the 446 SIP URIs in the To field and the Request-URI MUST be the domain of 447 the dial-around provider, discovered according to Section 9.1. 449 The following is a partial example of a one-stage dial-around call 450 from VRS user +1-555-222-0001 hosted by red.example.com to a hearing 451 user +1-555-123-4567 using dial-around to green.example.com for the 452 relay service. Only important details of the messages are shown and 453 many header fields have been omitted: 455 One-Stage Dial-Around 456 ,-+-. ,----+----. ,-----+-----. 457 |RUE| |Default | |Dial-Around| 458 | | |Provider | | Provider | 459 `-+-' `----+----' `-----+-----' 460 | | | 461 | [1] INVITE | | 462 |-------------->| [2] INVITE | 463 | |-------------->| 465 Message Details: 467 [1] INVITE Rue -> Default Provider 469 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 470 To: 471 From: "Bob Smith" 473 [2] INVITE Default Provider -> Dial-Around Provider 475 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 476 To: 477 From: "Bob Smith" sip:+18135551212@red.example.net;user=phone 478 P-Asserted-Identity: sip:+18135551212@red.example.net 480 Figure 1 482 5.2.3. RUE Contact Information 484 To identify the owner of a RUE, the initial INVITE for a call from a 485 RUE, or the 200 OK accepting a call by a RUE, identifies the owner by 486 sending a Call-Info header field with a purpose parameter of "rue- 487 owner". The URI MAY be an HTTPS URI or Content-Indirect URL. The 488 latter is defined by [RFC2392] to locate message body parts. This 489 URI type is present in a SIP message to convey the RUE ownership 490 information as a MIME body. The form of the RUE ownership 491 information is a xCard [RFC6351]. Please refer to [RFC6442] for an 492 example of using Content-Indirect URLs in SIP messages. Note that 493 use of the Content-Indirect URL usually implies multiple message 494 bodies ("mime/multipart"). 496 5.2.4. Incoming Calls 498 The RUE MUST only accept inbound calls sent to it by a proxy 499 mentioned in the configuration. 501 If Multiple simultaneous RUE SIP registrations from different RUE 502 devices with the same SIP URI exist, the provider MUST parallel fork 503 the call to all registered RUEs so that they ring at the same time. 504 The first RUE to reply with a 200 OK answers the call and the 505 provider MUST CANCEL other call branches. 507 5.2.5. Emergency Calls 509 Implementations MUST conform to [RFC6881] for handling of emergency 510 calls, except that if the device is unable to determine its own 511 location, it MAY send the emergency call without a Geolocation header 512 field and without a Route header field (since it would be unable to 513 query the LoST server for a route per RFC6881). If an emergency call 514 arrives at the provider without a Geolocation header field, the 515 provider MUST supply location by adding the Geolocation header field, 516 and MUST supply the route by querying the LoST server with that 517 location. 519 If the emergency call is to be handled using existing country 520 specific procedures, the provider is responsible for modifying the 521 INVITE to conform to the country-specific requirements. In this 522 case, location MAY be extracted from the RFC6881 conformant INVITE 523 and used to propagate it to the appropriate country-specific 524 entities. If the configuration specifies it, an implementation of a 525 RUE device MAY send a Geolocation header field containing its 526 location in the REGISTER request. If implemented, users MUST be 527 offered an opt-out. Country-specific procedures might require the 528 location to be pre-loaded in some entity prior to placing an 529 emergency call; however, the RUE may have a more accurate and timely 530 device location than the manual, pre-loaded entry. That information 531 MAY be used to populate the location to appropriate country-specific 532 entities. Re-registration SHOULD be used to update the location, so 533 long as the rate of re-registration is limited if the device is 534 moving. 536 Implementations MUST implement Additional Data, [RFC7852]. RUE 537 devices MUST implement Data Provider, Device Implementation and 538 Owner/Subscriber Information blocks. 540 5.3. Mid Call Signaling 542 Implementations MUST support re-INVITE to renegotiate media session 543 parameters (among other uses). Per Section 6.1, implementations MUST 544 be able to support an INFO request for full frame refresh for devices 545 that do not support RTCP mechanisms (please refer to Section 6.8). 546 Implementations MUST support an in-dialog REFER ([RFC3515] updated by 547 [RFC7647] and including support for norefersub per [RFC4488]) with 548 the Replaces header field [RFC3891] to enable call transfer. 550 5.4. URI Representation of Phone Numbers 552 SIP URIs constructed from non-URI sources (dial strings) and sent to 553 SIP proxies by the RUE MUST be represented as follows, depending on 554 whether they can be represented as an E.164 number. In this section 555 "expressed as an E.164 number" includes numbers such as toll free 556 numbers that are not actually E.164 numbers, but have the same 557 format. 559 A dial string that can be expressed as an E.164 phone number MUST be 560 represented as a SIP URI with a URI ";user=phone" tag. The user part 561 of the URI MUST be in conformance with 'global-number' defined in 562 [RFC3966]. The user part MUST NOT contain any 'visual-separator' 563 characters, as defined in [RFC3966]. 565 Dial strings that cannot be expressed as E.164 numbers MUST be 566 represented as dialstring URIs, as specified by [RFC4967], e.g., 567 sip:411@red.example.net;user=dialstring. 569 The domain part of Relay Service URIs and User Address of Records 570 (AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or 571 IPv6 addresses. 573 5.5. Transport 575 Implementations MUST conform to [RFC8835] except for its guidance on 576 the WebRTC data channel, which this specification does not use. See 577 Section 6.2 for how RUE supports real-time text without the data 578 channel. 580 Implementations MUST support SIP outbound [RFC5626] (please also 581 refer to Section 5.1). 583 6. Media 585 This specification adopts the media specifications for WebRTC 586 ([RFC8825]). Where WebRTC defines how interactive media 587 communications may be established using a browser as a client, this 588 specification assumes a normal SIP call. The RTP, RTCP, SDP and 589 specific media requirements specified for WebRTC are adopted for this 590 document. The RUE is a WebRTC "non-browser" endpoint, except as 591 noted expressly below. 593 The following sections specify the WebRTC documents to which 594 conformance is required. "Mandatory to Implement" means a conforming 595 implementation must implement the specified capability. It does not 596 mean that the capability must be used in every session. For example, 597 OPUS is a mandatory to implement audio codec, and all conforming 598 implementations must support OPUS. However, implementation 599 presenting a call across the RUE Interface where the call originates 600 in the Public Switched Telephone Network, or an older, non-RUE- 601 compatible device, which only offers G.711 audio, does not need to 602 include the OPUS codec in the offer, since it cannot be used with 603 that call. 605 6.1. SRTP and SRTCP 607 Implementations MUST support [RFC8834] except that MediaStreamTracks 608 are not used. Implementations MUST conform to Section 6.4 of 609 [RFC8827]. 611 6.2. Text-Based Communication 613 Implementations MUST support real-time text ([RFC4102] and [RFC4103]) 614 via T.140 media. One original and two redundant generations MUST be 615 transmitted and supported, with a 300 ms transmission interval. 616 Implementations MUST support [RFC9071] especially for emergency 617 calls. Note that RFC4103 is not how real-time text is transmitted in 618 WebRTC and some form of transcoder would be required to interwork 619 real-time text in the data channel of WebRTC to RFC4103 real-time 620 text. 622 Transport of T.140 real-time text in WebRTC is specified in 623 [RFC8865], using the WebRTC data chanel. RFC 8865 also has some 624 advice on how gateways between RFC 4103 and RFC 8865 should operate. 625 It is RECOMMENDED that RFC 8865 including multiparty support is used 626 for communication with browser-based WebRTC implementations. 627 Implementations MUST support [RFC9071]. 629 6.3. Video 631 Implementations MUST conform to [RFC7742] with following exceptions: 632 only H.264, as specified in [RFC7742], is Mandatory to Implement, and 633 VP8 support is OPTIONAL at both the device and providers. This is 634 because backwards compatibility is desirable, and older devices do 635 not support VP8. 637 6.4. Audio 639 Implementations MUST conform to [RFC7874]. 641 6.5. DTMF Digits 643 Implementations MUST support the "audio/telephone-event" [RFC4733] 644 media type. They MUST support conveying event codes 0 through 11 645 (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. 646 Handling of other tones is OPTIONAL. 648 6.6. Session Description Protocol 650 The SDP offers and answers MUST conform to the SDP rules in [RFC8829] 651 except that the RUE interface uses SIP transport for SDP. The SDP 652 for real-time text MUST specify the T.140 payload type [RFC4103]. 654 6.7. Privacy 656 The RUE MUST provide for user privacy by implementing a local one-way 657 mute, without signaling, for both audio and video. However, RUE MUST 658 maintain any NAT bindings by periodically sending media packets on 659 all active media sessions containing silence/comfort noise/black 660 screen/etc. per [RFC6263]. 662 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 663 Intraframe Request Features 665 The NACK, FIR and PLI features as described in [RFC4585] and 666 [RFC5104] MUST be implemented. Availability of these features MUST 667 be announced with the "ccm" feedback value. NACK should be used when 668 negotiated and conditions warrant its use and the other end supports 669 it. Signaling picture losses as Packet Loss Indicator (PLI) should 670 be preferred. FIR should be used only in situations where not 671 sending a decoder refresh point would render the video unusable for 672 the users, as per RFC5104 subsection 4.3.1.2. 674 For backwards compatibility with calling devices that do not support 675 the foregoing methods, implementations MUST implement SIP INFO 676 messages to send and receive XML encoded Picture Fast Update messages 677 according to [RFC5168]. 679 7. Contacts 681 7.1. CardDAV Login and Synchronization 683 Support of CardDAV by providers is OPTIONAL. 685 The RUE MUST and providers MAY be able to synchronize the user's 686 contact directory between the RUE endpoint and one maintained by the 687 user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). 689 The configuration MAY supply a username and domain identifying a 690 CardDAV server and address book for this account. 692 To access the CardDAV server and address book, the RUE MUST follow 693 Section 6 of RFC6764, using the chosen username and domain in place 694 of an email address. If the request triggers a challenge for digest 695 authentication credentials, the RUE MUST continue using matching 696 "credentials" from the configuration. If no matching credentials are 697 configured, the RUE MUST use the SIP credentials from the 698 configuration. If the SIP credentials fail, the RUE MUST query the 699 user. 701 Synchronization using CardDAV MUST be a two-way synchronization 702 service, with proper handling of asynchronous adds, changes, and 703 deletes at either end of the transport channel. 705 7.2. Contacts Import/Export Service 707 Implementations MUST be able to export/import the list of contacts in 708 xCard [RFC6351] xml format. 710 The RUE accesses this service via the "contacts" URI in the 711 configuration. The URL MUST resolve to identify a web server 712 resource that imports/exports contact lists for authorized users. 714 The RUE stores/retrieves the contact list (address book) by issuing 715 an HTTPS POST or GET request. If the request triggers a challenge 716 for digest authentication credentials, the RUE MUST attempt to 717 continue using matching "credentials" from the configuration. If no 718 credentials are configured, the RUE MUST query the user. 720 8. Video Mail 722 Support for video mail includes a retrieval mechanism and a Message 723 Waiting Indicator (MWI). Message storage is not specified by this 724 document. RUE devices MUST support message retrieval using a SIP 725 call to a specified SIP URI using DTMF to manage the mailbox, as well 726 as a browser based interface reached at a specified HTTPS URI. If a 727 provider supports video mail at least one of these mechansism MUST be 728 supported. RUE devices MUST support both. See Section 9.2 for how 729 the URI to reach the retrieval interface is obtained. 731 Implementations MUST support subscriptions to "message-summary" 732 events [RFC3842] to the URI specified in the configuration. 733 Providers MUST support MWI if they support video mail. RUE devices 734 MUST support MWI. 736 In notification bodies, if detailed message summaries are available, 737 messages with video MUST be reported using "message-context-class 738 multimedia-message" defined in [RFC3458] . 740 9. Provisioning and Provider Selection 742 To simplify how users interact with RUE devices, the RUE interface 743 separates provisioning into two parts. One provides a directory of 744 providers so that a user interface can allow easy provider selection 745 either for registering or for dial-around. The other provides 746 configuration data for the device for each provider. 748 9.1. RUE Provider Selection 750 To allow the user to select a relay service, the RUE MAY at any time 751 obtain (typically on startup) a list of Providers that provide 752 service in a country. IANA has established a registry that contains 753 a two letter country code and an entry point string. The entry 754 point, when used with the following interface, returns a list of 755 provider names for a country code suitable for display, with a 756 corresponding a entry point to obtain information about that 757 provider. 759 Each country that supports video relay service using this 760 specification MAY support the provider list. This document does not 761 specify who maintains the list. Some possibilities are a regulator 762 or entity designated by a regulator, an agreement among providers to 763 provide the list, or a user group. 765 The interface to obtain the list of providers is described by an 766 OpenApi [OpenApi] interface description. In that interface 767 description, the "servers" component is specified as "localhost". 768 The entry point in the registry is substituted for "localhost" to 769 obtain the server prefix of the interface. The "Providers" path then 770 specifies the rest of the URI used to obtain the list. For example, 771 if the entryPoint is "example.com", the provider list would be 772 obtained from https://example.com/rum/V1/Providers. 774 The web service also has a simple version mechanism that returns a 775 list of versions of the web service it supports. This document 776 describes version 1.0. Versions are described as a major version, 777 the period "." and a minor version, where major and minor versions 778 are integers. A backwards compatible change within a major version 779 MAY increment only the minor version number. A non-backwards 780 compatible change MUST increment the major version number. To 781 achieve backwards compatibility, implementations MUST ignore any 782 object members they do not implement. Minor version definitions 783 SHALL only add objects, non-required members of existing objects, and 784 non-mandatory-to use functions and SHALL NOT delete any objects, 785 members of objects or functions. This means an implementation of a 786 specific major version and minor version is backwards compatible with 787 all minor versions of the major version. The versions mechanism 788 returns an array of supported versions, one for each major version 789 supported, with the minor version listed being the highest supported 790 minor version. 792 The V1.0 provider list is a json object consisting of an array where 793 each entry describes one provider. Each entry consists of the 794 following items: 796 * name: This parameter contains the text label identifying the 797 provider and is meant to be displayed to the human VRS user. 799 * entryPoint: A string used for configuration purposes by the RUE 800 (as discussed in Section 9.2) 802 The VRS user interacts with the RUE to select from the provider list 803 one or more providers with whom the user has already established an 804 account, wishes to establish an account, or wishes to use the 805 provider for a one-stage dial around. 807 { 808 "providers": [ 809 { 810 "name": "Red", 811 "entryPoint": "red.example.net" 812 }, 813 { 814 "name": "Green", 815 "entryPoint": "green.example.net" 816 }, 817 { 818 "name": "Blue", 819 "entryPoint": "blue.example.net" 820 } 821 ] 822 } 824 Figure 2: Example of a provider list JSON object 826 { 827 "versions": [ 828 { 829 "major": 1, 830 "minor": 6 831 }, 832 { 833 "major": 2, 834 "minor": 13 835 }, 836 { 837 "major": 3, 838 "minor": 2 839 } 840 ] 841 } 843 Figure 3: Example of a Version JSON object 845 9.2. RUE Configuration Service 847 A RUE device may retrieve a provider configuration the using a simple 848 HTTPs web service. There are two entry points. One is used without 849 user credentials or parameters, the response includes configuration 850 data for new user sign up and dial around. The other uses the 851 userid/password to authenticate to the interface and returns 852 configuration data for the RUE. 854 The interface to obtain configuration data is described by an OpenApi 855 [OpenApi] interface description. In that interface description, the 856 "servers" component is specified as "localhost". The entry point 857 obtained from the provider list (Section 9.1) is substituted for 858 "localhost" to obtain the server prefix of the interface. The path 859 then specifies the rest of the URI used to obtain the list. For 860 example, if the entryPoint from the provider list is 861 "redexample.net", the provider configuration would be obtained from 862 https://red.example.net/rum/V1/ProviderConfig. 864 In both the queries, an optional parameter may be provided to the 865 interface which is an API Key. The implementation MAY have an API 866 Key obtained from the provider and specific to the implementation. 867 The method the API Key is obtained is not specified in this document. 868 The provider MAY refuse to provide service to an implementation 869 presenting an API Key it does not recognize. 871 Also in both queries, the RUE device provides a required parameter 872 which contains an instance identifier. This parameter MUST be the 873 same value each time this instance (same implementation on same 874 device) queries the interface. This MAY be used by the provider, for 875 example, to associate a location with the instance for emergency 876 calls. 878 The data returned is a json object consisting of an array of key/ 879 value configuration parameters to be used by the RUE. 881 The configuration API also provides the same version mechanism as 882 specified above in Section 9.1. The version of the configuration 883 service MAY be different than the version of the provider list 884 service. 886 The configuration data payload includes the following data items. 887 Items not noted as (OPTIONAL) are REQUIRED. If other unexpected 888 items are found, they MUST be ignored. 890 9.2.1. Provider Configuration 892 * signup: (OPTIONAL) an array of json objects consisting of: 894 - language: entry from the IANA language subtag registry. 895 Normally, this would be a written language tag. 897 - uri: a URI to the website for creating a new account in the 898 supported language. The new user signup URI may only initiate 899 creation of a new account. Various vetting, approval and other 900 processes may be needed, which could take time, before the 901 account is established. The result of creating a new account 902 would be a username and password, which would be manually 903 entered into the RUE device to allow connection to the 904 provider. 906 * dialAround: an array of json objects consisting of: 908 - language: entry from the IANA language subtag registry. 909 Normally, this would be a sign language tag. 911 - frontDoor: a URI to a queue of interpreters supporting the 912 specified language for a two-stage dial-around 914 - oneStage: a URI that can be used with a one-stage dial-around 915 Section 5.2.2 using an interpreter supporting the specified 916 language 918 * helpDesk: (OPTIONAL) an array of json objects consisting of: 920 - language: entry from the IANA language subtag registry. 921 Normally this would be a sign language tag, although it could 922 be a written language tag if the help desk only supports a chat 923 interface 925 - uri: URI that reaches a help desk for callers supporting the 926 specified language. The URI MAY be a SIP URI for help provided 927 with a SIP call, or MAY be an HTTPS URI for help provided with 928 a browser interface. 930 A list is specified so that the provider can offer multiple 931 choices to users for language and interface styles. 933 9.2.2. RUE Configuration 935 * lifetime: (optional) Specifies how long (in seconds) the RUE MAY 936 cache the configuration values. Values may not be valid when 937 lifetime expires. If the RUE caches configuration values, it MUST 938 cryptographically protect them. The RUE SHOULD retrieve a fresh 939 copy of the configuration before the lifetime expires or as soon 940 as possible after it expires. The lifetime is not guaranteed: the 941 configuration may change before the lifetime value expires. In 942 that case, the Provider MAY indicate this by generating 943 authorization challenges to requests and/or prematurely 944 terminating a registration. Emergency Calls MUST continue to 945 work. If not specified, the RUE MUST fetch new configuration data 946 every time it starts. 948 * sip-password: (optional) a password used for SIP, STUN and TURN 949 authentication. The RUE device retains this data, which must be 950 stored securely. If it is not supplied, but was supplied on a 951 prior invocation of this interface, the most recently supplied 952 password MUST be used. If it was never supplied, the password 953 used to authenticate to the configuration service is used for SIP, 954 STUN and TURN. 956 * phone-number: The telephone number (in E.164 format) assigned to 957 this subscriber. This becomes the user portion of the SIP URI 958 identifying the subscriber. 960 * outbound-proxy: (optional) A URI of a SIP proxy to be used when 961 sending requests to the provider. 963 * mwi: (optional) A URI identifying a SIP event server that 964 generates "message-summary" events for this subscriber. 966 * videomail: (optional) An SIP or HTTPS URI that can be called to 967 retrieve video mail messages. 969 * contacts: (optional) An HTTPS URI that may be used to export 970 (retrieve) the subscriber's complete contact list managed by the 971 provider. MUST be provided if the subscriber has contacts. 973 * carddav: (optional) A username, password and domain name 974 (separated by ""@"") identifying a "CardDAV" server and account 975 that can be used to synchronize the RUE's contact list with the 976 contact list managed by the provider. If username or password are 977 not supplied, the main account credentials are used. 979 * sendLocationWithRegistration: (optional) True if the RUE should 980 send a Geolocation header field with REGISTER, false if it should 981 not. Defaults to false if not present. 983 * ice-servers: (optional) An array of URLs identifying STUN and TURN 984 servers available for use by the RUE for establishing media 985 streams in calls via the provider. 987 9.2.3. Examples 989 Example JSON provider configuration payload 990 { 991 "signUp": [ 992 { "language" : "en", "uri" : "welcome-en.example.net"} , 993 { "language" : "es", "uri" : "welcome-es.example.net"} ] , 994 "dialAround": [ 995 { "language" : "en", "frontDoor" : "fd-en.example.net", 996 "oneStage" : "1stg-eng.example.com" } , 997 { "language" : "es", "frontDoor" : "fd-es.example.net", 998 "oneStage" : "1stg-spn.example.com" } ] , 999 "helpDesk": [ 1000 { "language" : "en", "uri" : "help-en.example.net"} , 1001 { "language" : "es", "uri" : "help-es.example.net"} ] 1002 } 1004 Figure 4 1006 Example JSON RUE configuration payload 1007 { 1008 "lifetime": 86400, 1009 "display-name" : "Bob Smith", 1010 "phone-number": "+18135551212", 1011 "provider-domain": "red.example.net", 1012 "outbound-proxies": [ 1013 "sip:p1.red.example.net", 1014 "sip:p2.red.example.net" ], 1015 "mwi": "sip:+18135551212@red.example.net", 1016 "videomail": "sip:+18135551212@vm.red.example.net", 1017 "contacts": "https://red.example.net:443/contacts/1dess45awd", 1018 "carddav": "bob@red.example.com" , 1019 "sendLocationWithRegistration": false, 1020 "ice-servers": [ 1021 {"stun":"stun.l.google.com:19302" }, 1022 {"turn":"turn.red.example.net:3478"} 1023 ] 1024 } 1026 Figure 5 1028 9.2.4. Using the Provider Selection and RUE Configuration Services 1029 Together 1031 One way to use these two services is: 1033 * At startup, the RUE retrieves the provider list for the country it 1034 is located in. 1036 * For each provider in the list: 1038 - If the RUE does not have credentials for that provider, use the 1039 configuration service without credentials to obtain signup, 1040 dial around and helpdesk information. 1042 - If the RUE has credentials for that provider, use the 1043 configuration service with credentials to obtain all 1044 configuration data. 1046 9.3. OpenAPI Interface Descriptions 1048 The interfaces in Section 9.1 and Section 9.2 are formally specified 1049 with OpenAPI 3.0 ([OpenApi]) descriptions in yaml form. 1051 openapi: 3.0.1 1052 info: 1053 title: RUM API 1054 version: "1.0" 1055 servers: 1056 - url: http://localhost/rum/v1 1057 paths: 1058 /Providers: 1059 get: 1060 summary: Get a list of providers and domains to get 1061 config data from 1062 operationId: GetProviderList 1063 responses: 1064 '200': 1065 description: List of providers for a country 1066 content: 1067 application/json: 1068 schema: 1069 $ref: '#/components/schemas/ProviderList' 1070 /ProviderConfig: 1071 get: 1072 summary: Configuration data for one provider 1073 operationId: GetProviderConfiguration 1074 parameters: 1075 - in: query 1076 name: apiKey 1077 schema: 1078 type: string 1079 description: API Key assigned to this implementation 1080 - in: query 1081 name: instanceId 1082 schema: 1083 type: string 1084 required: true 1085 description: Unique string for this implementation 1086 on this device 1087 responses: 1088 '200': 1089 description: configuration object 1090 content: 1091 application/json: 1092 schema: 1093 $ref: '#/components/schemas/ProviderConfigurationData' 1094 /RueConfig: 1095 get: 1096 summary: Configuration data for one RUE 1097 operationId: GetRueConfiguration 1098 parameters: 1100 - in: query 1101 name: apiKey 1102 schema: 1103 type: string 1104 description: API Key assigned to this implementation 1105 - in: query 1106 name: instanceId 1107 schema: 1108 type: string 1109 required: true 1110 description: Unique string for this implementation 1111 on this device 1112 responses: 1113 '200': 1114 description: configuration object 1115 content: 1116 application/json: 1117 schema: 1118 $ref: '#/components/schemas/RueConfigurationData' 1119 /Versions: 1120 servers: 1121 - url: https://api.example.com/rum 1122 description: Override base path for Versions query 1123 get: 1124 summary: Retrieves all supported versions 1125 operationId: RetrieveVersions 1126 responses: 1127 '200': 1128 description: Versions supported 1129 content: 1130 application/json: 1131 schema: 1132 $ref: '#/components/schemas/VersionsArray' 1133 components: 1134 schemas: 1135 ProviderList: 1136 type: object 1137 required: 1138 - providers 1139 properties: 1140 providers: 1141 type: array 1142 items: 1143 type: object 1144 required: 1145 - name 1146 - domain 1147 properties: 1149 name: 1150 type: string 1151 description: Human readable provider name 1152 entryPoint: 1153 type: string 1154 description: provider entry point for interface 1155 VersionsArray: 1156 type: object 1157 required: 1158 - versions 1159 properties: 1160 versions: 1161 type: array 1162 items: 1163 type: object 1164 required: 1165 - major 1166 - minor 1167 properties: 1168 major: 1169 type: integer 1170 format: int32 1171 description: Version major number 1172 minor: 1173 type: integer 1174 format: int32 1175 description: Version minor number 1176 ProviderConfigurationData: 1177 type: object 1178 properties: 1179 signup: 1180 type: object 1181 required: 1182 - language 1183 - uri 1184 properties: 1185 language: 1186 type: string 1187 description: entry from IANA language-subtag-registry 1188 uri: 1189 type: string 1190 format: uri 1191 description: URI to signup website supporting language 1192 dialAround: 1193 type: object 1194 required: 1195 - language 1196 - frontDoor 1197 - oneStage 1198 properties: 1199 language: 1200 type: string 1201 description: entry from IANA language-subtag-registry 1202 frontDoor: 1203 type: string 1204 format: uri 1205 description: SIP URI for two-stage dial around 1206 oneStage: 1207 type: string 1208 format: uri 1209 description: SIP URI for one-stage dial around 1210 helpDesk: 1211 type: object 1212 required: 1213 - language 1214 - uri 1215 properties: 1216 language: 1217 type: string 1218 description: entry from IANA language-subtag-registry 1219 uri: 1220 type: string 1221 format: uri 1222 description: SIP URI of helpdesk supporting language 1223 RueConfigurationData: 1224 type: object 1225 required: 1226 - phone-number 1227 properties: 1228 lifetime: 1229 type: integer 1230 description: how long (in seconds) the RUE MAY cache the 1231 configuration values 1232 sip-password: 1233 type: string 1234 phone-number: 1235 type: string 1236 description: telephone number assigned this subscriber 1237 outbound-proxy: 1238 type: string 1239 format: uri 1240 description: SIP URI of proxy to be used when sending 1241 requests to the provider 1242 mwi: 1243 type: string 1244 format: uri 1245 description: A URI identifying a SIP event server that 1246 generates "message-summary" events for this subscriber. 1247 videomail: 1248 type: string 1249 format: uri 1250 description: An HTTPS or SIP URI that can be called to 1251 retrieve video mail messages. 1252 contacts: 1253 type: string 1254 format: uri 1255 description: An HTTPS URI that may be used to export 1256 (retrieve) the subscriber's complete contact list 1257 managed by the provider. 1258 carddav: 1259 type: object 1260 description: CardDAV server and user information that can be 1261 used to synchronize the RUE's contact list with the 1262 contact list managed by the provider. 1263 properties: 1264 domain: 1265 type: string 1266 description: CardDAV server address 1267 username: 1268 type: string 1269 description: username for authentication with CardDAV 1270 server. Use provider username if not provided 1271 password: 1272 type: string 1273 description: password for authentication to the CardDAV 1274 server. Use provider password if not provided 1275 sendLocationWithRegistration: 1276 type: boolean 1277 description: True if the RUE should send a Geolocation 1278 header field with REGISTER, false if it should not. 1279 Defaults to false if not present. 1280 ice-servers: 1281 type: array 1282 items: 1283 type: string 1284 format: uri 1285 description: URIs identifying STUN and TURN servers 1286 available for use by the RUE for establishing 1287 media streams in calls via the provider. 1289 Figure 6: Provider List OpenAPI description 1291 10. IANA Considerations 1292 10.1. RUE Provider List Registry 1294 IANA has created the "RUE Provider List" registry. The management 1295 policy for this registry is "Expert Review" [RFC8126]. The expert 1296 should prefer a regulator operated or designated list interface 1297 operator. Otherwise, evidence that the proposed list interface 1298 operator will provide a complete list of providers is required to add 1299 the entry to the registry. Updates to the registry are permitted if 1300 the expert judges the new proposed URI to provide a more accurate 1301 list than the existing entry. Each entry has two fields, values for 1302 both of which MUST be provided when registering or updating an entry: 1304 * country code: a two letter ISO93166 country code 1306 * list entry point: a string is used to compose the uri to the 1307 provider list interface for that country 1309 10.2. Registration of rue-owner Value of the purpose Parameter 1311 This document defines the new predefined value "rue-owner" for the 1312 "purpose" header field parameter of the Call-Info header field. This 1313 modifies the "Header Field Parameters and Parameter Values" 1314 subregistry of the "Session Initiation Protocol (SIP) Parameters" 1315 registry by adding this RFC as a reference to the line for the header 1316 field "Call-Info" and parameter name "purpose" 1318 * Header Field: Call-Info 1320 * Parameter Name: purpose 1322 * Predefined Values: Yes 1324 11. Security Considerations 1326 The RUE is required to communicate with servers on public IP 1327 addresses and specific ports to perform its required functions. If 1328 it is necessary for the RUE to function on a corporate or other 1329 network that operates a default-deny firewall between the RUE and 1330 these services, the user must arrange with their network manager for 1331 passage of traffic through such a firewall in accordance with the 1332 protocols and associated SRV records as exposed by the provider. 1333 Because VRS providers may use different ports for different services, 1334 these port numbers may differ from provider to provider. 1336 12. 1337 Normative References 1339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1340 Requirement Levels", BCP 14, RFC 2119, 1341 DOI 10.17487/RFC2119, March 1997, 1342 . 1344 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1345 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 1346 . 1348 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1349 DOI 10.17487/RFC2818, May 2000, 1350 . 1352 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1353 A., Peterson, J., Sparks, R., Handley, M., and E. 1354 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1355 DOI 10.17487/RFC3261, June 2002, 1356 . 1358 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1359 Protocol (SIP): Locating SIP Servers", RFC 3263, 1360 DOI 10.17487/RFC3263, June 2002, 1361 . 1363 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1364 with Session Description Protocol (SDP)", RFC 3264, 1365 DOI 10.17487/RFC3264, June 2002, 1366 . 1368 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1369 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1370 2002, . 1372 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1373 Initiation Protocol (SIP)", RFC 3323, 1374 DOI 10.17487/RFC3323, November 2002, 1375 . 1377 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1378 Header Field for the Session Initiation Protocol (SIP)", 1379 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1380 . 1382 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1383 (SIP) Extension Header Field for Registering Non-Adjacent 1384 Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, 1385 . 1387 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1388 Context for Internet Mail", RFC 3458, 1389 DOI 10.17487/RFC3458, January 2003, 1390 . 1392 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1393 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1394 . 1396 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1397 in Session Description Protocol (SDP)", RFC 3605, 1398 DOI 10.17487/RFC3605, October 2003, 1399 . 1401 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1402 "Indicating User Agent Capabilities in the Session 1403 Initiation Protocol (SIP)", RFC 3840, 1404 DOI 10.17487/RFC3840, August 2004, 1405 . 1407 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1408 Indication Event Package for the Session Initiation 1409 Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 1410 2004, . 1412 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1413 Protocol (SIP) "Replaces" Header", RFC 3891, 1414 DOI 10.17487/RFC3891, September 2004, 1415 . 1417 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 1418 Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, 1419 September 2004, . 1421 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1422 Tone Generation in the Session Initiation Protocol (SIP)", 1423 RFC 3960, DOI 10.17487/RFC3960, December 2004, 1424 . 1426 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1427 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1428 . 1430 [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", 1431 RFC 4102, DOI 10.17487/RFC4102, June 2005, 1432 . 1434 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1435 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 1436 . 1438 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 1439 (SIP) REFER Method Implicit Subscription", RFC 4488, 1440 DOI 10.17487/RFC4488, May 2006, 1441 . 1443 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1444 "Extended RTP Profile for Real-time Transport Control 1445 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1446 DOI 10.17487/RFC4585, July 2006, 1447 . 1449 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1450 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1451 DOI 10.17487/RFC4733, December 2006, 1452 . 1454 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1455 Initiation Protocol Uniform Resource Identifier", 1456 RFC 4967, DOI 10.17487/RFC4967, July 2007, 1457 . 1459 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1460 "Codec Control Messages in the RTP Audio-Visual Profile 1461 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1462 February 2008, . 1464 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1465 Media Control", RFC 5168, DOI 10.17487/RFC5168, March 1466 2008, . 1468 [RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. 1469 Campen, "Addressing an Amplification Vulnerability in 1470 Session Initiation Protocol (SIP) Forking Proxies", 1471 RFC 5393, DOI 10.17487/RFC5393, December 2008, 1472 . 1474 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1475 "Managing Client-Initiated Connections in the Session 1476 Initiation Protocol (SIP)", RFC 5626, 1477 DOI 10.17487/RFC5626, October 2009, 1478 . 1480 [RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing 1481 Record-Route Issues in the Session Initiation Protocol 1482 (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, 1483 . 1485 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 1486 "Essential Correction for IPv6 ABNF and URI Comparison in 1487 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 1488 . 1490 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1491 Keeping Alive the NAT Mappings Associated with RTP / RTP 1492 Control Protocol (RTCP) Flows", RFC 6263, 1493 DOI 10.17487/RFC6263, June 2011, 1494 . 1496 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 1497 RFC 6351, DOI 10.17487/RFC6351, August 2011, 1498 . 1500 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 1501 Authoring and Versioning (WebDAV)", RFC 6352, 1502 DOI 10.17487/RFC6352, August 2011, 1503 . 1505 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1506 for the Session Initiation Protocol", RFC 6442, 1507 DOI 10.17487/RFC6442, December 2011, 1508 . 1510 [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, 1511 DOI 10.17487/RFC6665, July 2012, 1512 . 1514 [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions 1515 to WebDAV (CalDAV) and vCard Extensions to WebDAV 1516 (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, 1517 . 1519 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1520 Communications Services in Support of Emergency Calling", 1521 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1522 . 1524 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1525 Protocol (HTTP/1.1): Message Syntax and Routing", 1526 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1527 . 1529 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1530 "Recommendations for Secure Use of Transport Layer 1531 Security (TLS) and Datagram Transport Layer Security 1532 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1533 2015, . 1535 [RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of 1536 REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, 1537 September 2015, . 1539 [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec 1540 Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 1541 . 1543 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1544 J. Winterbottom, "Additional Data Related to an Emergency 1545 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 1546 . 1548 [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing 1549 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, 1550 . 1552 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1553 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1554 May 2017, . 1556 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 1557 Connectivity Establishment (ICE): A Protocol for Network 1558 Address Translator (NAT) Traversal", RFC 8445, 1559 DOI 10.17487/RFC8445, July 2018, 1560 . 1562 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1563 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1564 . 1566 [RFC8599] Holmberg, C. and M. Arnold, "Push Notification with the 1567 Session Initiation Protocol (SIP)", RFC 8599, 1568 DOI 10.17487/RFC8599, May 2019, 1569 . 1571 [RFC8760] Shekh-Yusef, R., "The Session Initiation Protocol (SIP) 1572 Digest Access Authentication Scheme", RFC 8760, 1573 DOI 10.17487/RFC8760, March 2020, 1574 . 1576 [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for 1577 Browser-Based Applications", RFC 8825, 1578 DOI 10.17487/RFC8825, January 2021, 1579 . 1581 [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, 1582 DOI 10.17487/RFC8827, January 2021, 1583 . 1585 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 1586 "JavaScript Session Establishment Protocol (JSEP)", 1587 RFC 8829, DOI 10.17487/RFC8829, January 2021, 1588 . 1590 [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport 1591 and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, 1592 January 2021, . 1594 [RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, 1595 DOI 10.17487/RFC8835, January 2021, 1596 . 1598 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, 1599 A., and R. Shpount, "Session Description Protocol (SDP) 1600 Offer/Answer Procedures for Interactive Connectivity 1601 Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, 1602 January 2021, . 1604 [RFC8865] Holmberg, C. and G. Hellström, "T.140 Real-Time Text 1605 Conversation over WebRTC Data Channels", RFC 8865, 1606 DOI 10.17487/RFC8865, January 2021, 1607 . 1609 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1610 Session Description Protocol", RFC 8866, 1611 DOI 10.17487/RFC8866, January 2021, 1612 . 1614 [RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real- 1615 Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, 1616 . 1618 13. 1619 Informative References 1621 [OpenApi] Miller, D., Whitlock, J., Gardiner, M., Ralpson, M., 1622 Ratovsky, R., and U. Sarid, "OpenAPI Specification 1623 v3.0.1", December 2017, 1624 . 1626 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1627 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1628 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1629 December 2003, . 1631 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1632 Writing an IANA Considerations Section in RFCs", BCP 26, 1633 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1634 . 1636 Acknowledgements 1638 Brett Henderson and Jim Malloy provided many helpful edits to prior 1639 versions of this document. 1641 Author's Address 1643 Brian Rosen 1644 470 Conrad Dr 1645 Mars, PA 16046 1646 United States of America 1648 Phone: +1 724 382 1051 1649 Email: br@brianrosen.net