idnits 2.17.1 draft-ietf-rum-rue-05.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (14 June 2021) is 1019 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 413 -- Looks like a reference, but probably isn't: '2' on line 420 ** Downref: Normative reference to an Informational RFC: RFC 3960 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Downref: Normative reference to an Informational RFC: RFC 5168 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rum B. Rosen 3 Internet-Draft 14 June 2021 4 Intended status: Standards Track 5 Expires: 16 December 2021 7 Interoperability Profile for Relay User Equipment 8 draft-ietf-rum-rue-05 10 Abstract 12 Video Relay Service (VRS) is a term used to describe a method by 13 which a hearing persons can communicate with deaf/Hard of Hearing 14 user using an interpreter ("Communications Assistant") connected via 15 a videophone to the deaf/HoH user and an audio telephone call to the 16 hearing user. The CA interprets using sign language on the 17 videophone link and voice on the telephone link. Often the 18 interpreters may be supplied by a company or agency termed a 19 "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/HoH/H-I user conform to a 23 standard so that any device may be used with any provider and that 24 video calls direct between deaf/HoH users work. This document 25 describes the interface between a videophone and a provider. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 16 December 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 63 4. General Requirements . . . . . . . . . . . . . . . . . . . . 6 64 5. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 7 66 5.2. Session Establishment . . . . . . . . . . . . . . . . . . 8 67 5.2.1. Normal Call Origination . . . . . . . . . . . . . . . 8 68 5.2.2. One-Stage Dial-Around Origination . . . . . . . . . . 9 69 5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 10 70 5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10 71 5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 11 72 5.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 11 73 5.4. URI Representation of Phone Numbers . . . . . . . . . . . 12 74 5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 13 77 6.2. Text-Based Communication . . . . . . . . . . . . . . . . 13 78 6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.6. Session Description Protocol . . . . . . . . . . . . . . 13 82 6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 84 Intraframe Request Features . . . . . . . . . . . . . . . 14 85 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 14 87 7.2. Contacts Import/Export Service . . . . . . . . . . . . . 15 88 8. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 15 89 9. Provisioning and Provider Selection . . . . . . . . . . . . . 15 90 9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 15 91 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 17 92 9.3. Using the Provider List and Configuration Services 93 Together . . . . . . . . . . . . . . . . . . . . . . . . 21 94 9.4. OpenAPI Interface Descriptions . . . . . . . . . . . . . 21 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 96 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 97 11.1. RUE Provider List Registry . . . . . . . . . . . . . . . 27 98 11.2. Registration of rue-owner purpose parameter . . . . . . 27 99 12. Security Considerations . . . . . . . . . . . . . . . . . . . 27 100 13. Normative References . . . . . . . . . . . . . . . . . . . . 27 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 103 1. Introduction 105 Video Relay Service (VRS) is a form of Telecommunications Relay 106 Service (TRS) that enables persons with hearing disabilities who use 107 sign language, such as American Sign Language (ASL), to communicate 108 with voice telephone users through video equipment. These services 109 also enable communication between such individuals directly in 110 suitable modalities, including any combination of sign language via 111 video, real-time text (RTT), and speech. 113 This Interoperability Profile for Relay User Equipment (RUE) is a 114 profile of the Session Initiation Protocol (SIP) and related media 115 protocols that enables end-user equipment registration and calling 116 for VRS calls. It specifies the minimal set of call flows, Internet 117 Engineering Task Force (IETF) and ITU-T standards that must be 118 supported, provides guidance where the standards leave multiple 119 implementation options, and specifies minimal and extended 120 capabilities for RUE calls. 122 Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/ 123 HoH calls are supported on this interface. While there are some 124 accommodations in this document to maximize backwards compatibility 125 with devices and services that conform to this document, backwards 126 compatibility is not a requirement, and some interwork may be 127 required to allow direct video calls to older devices. This document 128 only describes the interface between the device and the provider, and 129 not any other interface the provider may have. 131 2. Terminology 133 Communication Assistant (CA): A sign-language interpreter working for 134 a VRS Provider, providing functionally equivalent phone service. 136 Communication modality (modality): A specific form of communication 137 that may be employed by two users, e.g., English voice, Spanish 138 voice, American Sign Language, English lip-reading, or French real- 139 time-text. Here, one communication modality is assumed to encompass 140 both the language and the way that language is exchanged. For 141 example, English voice and French voice are two different 142 communication modalities. 144 Default video relay service: The video relay service operated by a 145 subscriber's default VRS provider. 147 Default video relay service Provider (Default Provider): The VRS 148 provider that registers, and assigns a telephone number to a specific 149 subscriber, and by default provides the VRS for incoming voice calls 150 to the user. The default Provider also by default provides VRS for 151 outgoing relay calls. The user can have more than one telephone 152 number and each has a default provider. 154 Dial-around call: A relay call where the subscriber specifies the use 155 of a VRS provider other than the default VRS provider. This can be 156 accomplished by the user dialing a "front-door" number for a VRS 157 provider and signing or texting a phone number to call ("two-stage"). 158 Alternatively, this can be accomplished by the user's RUE software 159 instructing the server of its default VRS provider to automatically 160 route the call through the alternate Provider to the desired public 161 switched telephone network (PSTN) directory number ("one-stage"). 162 Dial-around is per-call -- for any call, a user can use the default 163 VRS provider or any dial-around VRS provider. 165 Full Intra Request (FIR): A request to a video media sender, 166 requiring that media sender to send a Decoder Refresh Point at the 167 earliest opportunity. FIR is sometimes known as "instantaneous 168 decoder refresh request", "video fast update request", or "fast 169 update request". Point-to-Point Call (P2P Call): A call between two 170 RUEs, without including a CA. 172 Relay call: A call that allows persons with hearing or speech 173 disabilities to use a RUE to talk to users of traditional voice 174 services with the aid of a communication assistant (CA) to relay the 175 communication. Please refer to FCC-VRS-GUIDE. 177 Relay-to-relay call: A call between two subscribers each using 178 different forms of relay (video relay, IP relay, TTY), each with a 179 separate CA to assist in relaying the conversation. 181 Relay service (RS): A service that allow a registered subscriber to 182 use a RUE to make and receive relay calls, point-to-point calls, and 183 relay-to-relay calls. The functions provided by the relay service 184 include the provision of media links supporting the communication 185 modalities used by the caller and callee, and user registration and 186 validation, authentication, authorization, automatic call distributor 187 (ACD) platform functions, routing (including emergency call routing), 188 call setup, mapping, call features (such as call forwarding and video 189 mail), and assignment of CAs to relay calls. 191 Relay service Provider (Provider): An organization that operates a 192 relay service. A subscriber selects a relay service Provider to 193 assign and register a telephone number for their use, to register 194 with for receipt of incoming calls, and to provide the default 195 service for outgoing calls. 197 Relay user: Please refer to "subscriber". 199 Relay user E.164 Number (user E.164): The telephone number (in ITU-T 200 E.164 format) assigned to the user. 202 Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra 203 features to support a subscriber in requesting and using relay calls. 204 A RUE may take many forms, including a stand-alone device; an 205 application running on a general-purpose computing device such as a 206 laptop, tablet or smart phone; or proprietary equipment connected to 207 a server that provides the RUE interface. 209 RUE Interface: the interfaces described in this document between a 210 RUE and a VRS provider who supports it 212 Sign language: A language that uses hand gestures and body language 213 to convey meaning including, but not limited to, American Sign 214 Language (ASL). 216 Subscriber: An individual who has registered with a Provider and who 217 obtains service by using relay user equipment. This is the 218 traditional telecom term for an end-user customer, which in our case 219 is a relay user. A user may be a subscriber to more than one VRS 220 provider. 222 Video relay service (VRS): A relay service for people with hearing or 223 speech disabilities who use sign language to communicate using video 224 equipment (video RUE) with other people in real time. The video link 225 allows the CA to view and interpret the subscriber's signed 226 conversation and relay the conversation back and forth with the other 227 party. 229 3. Requirements Language 231 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in [RFC2119] 235 4. General Requirements 237 All HTTP/HTTPS connections specified throughout this document MUST 238 use HTTPS. Both HTTPS and all SIP connections MUST use TLS 239 conforming to at least [RFC7525] and must support [RFC8446] 241 All text data payloads not otherwise constrained by a specification 242 in another standards document MUST be encoded as Unicode UTF/8. 244 Implementations MUST support IPv4 and IPv6. Dual stack support is 245 NOT required and provider implementations MAY support separate 246 interfaces for IPv4 and IPv6 by having more than one server in the 247 appropriate SRV record where there is either an A or AAAA record in 248 each server DNS record but not both. 250 5. SIP Signaling 252 Implementations of the RUE Interface MUST conform to the following 253 core SIP standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP 254 Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent 255 Capabilities), [RFC5626] (Outbound), [RFC8866] (Session Description 256 Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP), 257 [RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop- 258 Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960] 259 (Early Media), and [RFC6442] (Geolocation Header). 261 In the above documents the RUE device conforms to the requirements of 262 a SIP user Agent, and the provider conforms to the requirements of 263 Registrar and Proxy Server where the document specifies different 264 behavior for different roles. The only requirement on providers for 265 RFC6655 (Events) is support for the Message Waiting Indicator (See 266 Section Section 8), which is optional and providers not supporting 267 MWI need not support RFC6665. 269 In addition, implementation MUST conform to [RFC3327] (Path), 270 [RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER Method), 271 [RFC3891] (Replaces Header), [RFC3892] (Referred-By). 273 Implementations MUST include a "User-Agent" header field uniquely 274 identifying the RUE application, platform, and version in all SIP 275 requests, and MUST include a "Server" header field with the same 276 content in SIP responses. 278 Implementations intended to support mobile platforms MUST support 279 [RFC8599] and MUST use it as at least one way to support waking up 280 the client from background state. 282 5.1. Registration 284 The RUE MUST register with a SIP registrar, following [RFC3261] and 285 [RFC5626] at a provider it has an account with. If the configuration 286 (please refer to Section 11) contains multiple "outbound-proxies", 287 then the RUE MUST use them as specified in [RFC5626] to establish 288 multiple flows. 290 The request-URI for the REGISTER request MUST contain the "provider- 291 domain" from the configuration. The To-URI and From-URI MUST be 292 identical URIs, formatted as specified in Section 13, using the 293 "phone-number" and "provider-domain" from the configuration. 295 The RUE determines the URI to resolve by initially determining if an 296 outbound proxy is configured. If it is, the URI will be that of the 297 outbound proxy. If no outbound proxy is configured, the URI will be 298 the Request-URI from the REGISTER request. The RUE extracts the 299 domain from that URI and consults the DNS record for that domain. 300 The DNS entry MUST contain NAPTR records conforming to RFC3263. One 301 of those NAPTR records MUST specify TLS as the preferred transport 302 for SIP. For example, a DNS NAPTR query for "sip: 303 p1.red.example.netv" could return: 305 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net 306 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net 308 If the RUE receives a 439 (First Hop Lacks Outbound Support) response 309 to a REGISTER request, it MUST re-attempt registration without using 310 the outbound mechanism. 312 The registrar MAY authenticate using SIP digest authentication. The 313 credentials to be used (username and password) MUST be supplied 314 within the credentials section of the configuration and identified by 315 the realm the registrar uses in a digest challenge. This username/ 316 password combination SHOULD NOT be the same as that used for other 317 purposes, such as retrieving the RUE configuration or logging into 318 the Provider's customer service portal. [RFC8760] MUST be supported 319 by all implementations and SHA-512 digest algorithms MUST be 320 supported. 322 If the registration request fails with an indication that credentials 323 from the configuration are invalid, then the RUE SHOULD retrieve a 324 fresh version of the configuration. If credentials from a freshly 325 retrieved configuration are found to be invalid, then the RUE MUST 326 cease attempts to register and SHOULD inform the RUE User of the 327 problem. 329 Support for multiple simultaneous registrations is OPTIONAL. 331 Multiple simultaneous RUE SIP registrations from different RUE 332 devices with the same SIP URI SHOULD be permitted by the Provider. 333 The Provider MAY limit the total number of simultaneous 334 registrations. When a new registration request is received that 335 results in exceeding the limit on simultaneous registrations, the 336 Provider MAY then prematurely terminate another registration; 337 however, it SHOULD NOT do this if it would disconnect an active call. 339 If a Provider prematurely terminates a registration to reduce the 340 total number of concurrent registrations with the same URI, it SHOULD 341 take some action to prevent the affected RUE from automatically re- 342 registering and re-triggering the condition. 344 5.2. Session Establishment 346 5.2.1. Normal Call Origination 348 After initial SIP registration, the RUE adheres to SIP [RFC3261] 349 basic call flows, as documented in [RFC3665]. 351 A RUE device MUST route all outbound calls through an outbound proxy 352 if configured. 354 The SIP URIs in the To field and the Request-URI MUST be formatted as 355 specified in subsection Section 5.4 using the destination phone 356 number. The domain field of the URIs SHOULD be the "provider-domain" 357 from the configuration (e.g., 358 sip:+13115552368@red.example.com;user=phone). The same exceptions 359 apply, including anonymous calls. 361 Anonymous calls MUST be supported by all implementations. An 362 anonymous call is signaled per [RFC3323]. 364 The From-URI MUST be formatted as specified in Section 5.4, using the 365 phone-number and "provider-domain" from the configuration. It SHOULD 366 also contain the display-name from the configuration when present. 367 (Please refer to Section 9.2.) 369 Negotiated media MUST follow the guidelines specified in Section 6 of 370 this document. 372 To allow time to timeout an unanswered call and direct it to a 373 videomail server, the User Agent Client MUST NOT impose a time limit 374 less than the default SIP Invite transaction timeout of 3 minutes. 376 5.2.2. One-Stage Dial-Around Origination 378 Outbound dial-around calls allow a RUE user to select any Provider to 379 provide interpreting services for any call. "Two-stage" dial-around 380 calls involve the RUE calling a telephone number that reaches the 381 dial-around Provider and using signing or DTMF to provide the called 382 party telephone number. In two-stage dial-around, the To URI is the 383 URI of the dial-around Provider and the domain of the URI is the 384 Provider domain from the configuration. 386 One-stage dial-around is a method where the called party telephone 387 number is provided in the To URI and the Request-URI, using the 388 domain of the dial-around Provider. 390 For one-stage dial-around, the RUE MUST follow the procedures in 391 Section 5.2.1 with the following exception: the domain part of the 392 SIP URIs in the To field and the Request-URI MUST be the domain of 393 the dial-around Provider, discovered according to Section 9.1. 395 The following is a partial example of a one-stage dial-around call 396 from VRS user +1-555-222-0001 hosted by red.example.com to a hearing 397 user +1-555-123-4567 using dial-around to green.example.com for the 398 relay service. Only important details of the messages are shown and 399 many header fields have been omitted: 401 One Stage Dial-Around 402 ,-+-. ,----+----. ,-----+-----. 403 |RUE| |Default | |Dial-Around| 404 | | |Provider | | Provider | 405 `-+-' `----+----' `-----+-----' 406 | | | 407 | [1] INVITE | | 408 |-------------->| [2] INVITE | 409 | |-------------->| 411 Message Details: 413 [1] INVITE Rue -> Default Provider 415 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 416 To: 417 From: "Bob Smith" 418 Route: sip:green.example.net 420 [2] INVITE Default Provider -> Dial-Around Provider 422 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 423 To: 424 From: "Bob Smith" sip:+18135551212@red.example.net;user=phone 425 P-Asserted-Identity: sip:+18135551212@red.example.net 427 Figure 1 429 5.2.3. RUE Contact Information 431 To identify the owner of a RUE, the initial INVITE for a call from a 432 RUE, or the 200 OK accepting a call by a RUE, identifies the owner by 433 sending a Call-Info header with a purpose parameter of "rue-owner". 434 The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is 435 defined by [RFC2392] to locate message body parts. This URI type is 436 present in a SIP message to convey the RUE ownership information as a 437 MIME body. The form of the RUE ownership information is a jCard 438 [RFC7095]. Please refer to [RFC6442] for an example of using 439 Content-Indirect URLs in SIP messages. Note that use of the Content- 440 Indirect URL usually implies multiple message bodies ("mime/ 441 multipart"). 443 5.2.4. Incoming Calls 445 The RUE MUST only accept inbound calls sent to it by a proxy 446 mentioned in the configuration. 448 If Multiple simultaneous RUE SIP registrations from different RUE 449 devices with the same SIP URI exist, the Provider MUST parallel fork 450 the call to all registered RUEs so that they ring at the same time. 451 The first RUE to reply with a 200 OK answers the call and the 452 Provider MUST CANCEL other call branches. 454 5.2.5. Emergency Calls 456 Implementations MUST conform to [RFC6881] for handling of emergency 457 calls, except that if the device is unable to determine its own 458 location, it MAY send the emergency call without a Geolocation header 459 and without a Route header (since it would be unable to query the 460 LoST server for a route per RFC6881). If an emergency call arrives 461 at the provider without a Geolocation header, the provider MUST 462 supply location by adding the Geolocation header, and MUST supply the 463 route by querying the LoST server with that location. 465 If the emergency call is to be handled using existing country 466 specific procedures, the Provider is responsible for modifying the 467 INVITE to conform to the country-specific requirements. In this 468 case, location MAY be extracted from the RFC6881 conformant INVITE 469 and used to propagate it to the appropriate country-specific 470 entities. Because the RUE may have a more accurate and timely 471 location of the device than the a manual entry location for nomadic 472 RUE devices, but country-specific procedures require the location to 473 be pre-loaded in some entity prior to placing an emergency call, 474 implementations of a RUE device MAY send a Geolocation header 475 containing its location in the REGISTER request if the configuration 476 specifies it. That information MAY be used to populate the location 477 to appropriate country-specific entities. Re-registration SHOULD be 478 used to update the location, so long as the rate of re-registration 479 is limited if the device is moving. 481 Implementations MUST implement Additional Data, [RFC7852]. RUE 482 devices MUST implement Data Provider, Device Implementation and 483 Owner/Subscriber Information blocks. 485 5.3. Mid Call Signaling 487 Implementations MUST support re-INVITE to renegotiate media session 488 parameters (among other uses). Per Section 6.1, implementations 489 MUST, be able to support an INFO request for full frame refresh for 490 devices that do not support RTCP mechanisms (please refer to 491 Section 6.8). Implementations MUST support an in-dialog REFER 492 ([RFC3515] updated by [RFC7647] and including support for norefersub 493 per [RFC4488]) with the Replaces header [RFC3891] to enable call 494 transfer. 496 5.4. URI Representation of Phone Numbers 498 SIP URIs constructed from non-URI sources (dial strings) and sent to 499 SIP proxies by the RUE MUST be represented as follows, depending on 500 whether they can be represented as an E.164 number. 502 A dial string that can be written as an E.164 formatted phone number 503 MUST be represented as a SIP URI with a URI ";user=phone" tag. The 504 user part of the URI MUST be in conformance with 'global-number' 505 defined in [RFC3966]. The user part MUST NOT contain any 'visual- 506 separator' characters. 508 Dial strings that cannot be written as E.164 numbers MUST be 509 represented as dialstring URIs, as specified by [RFC4967], e.g., 510 sip:411@red.example.net;user=dialstring. 512 The domain part of Relay Service URIs and User Address of Records 513 (AoR) MUST resolve (per [RFC3263]) to globally routable IPv4 and/or 514 IPv6 addresses. 516 5.5. Transport 518 Implementations MUST conform to [RFC8835] except that that this 519 specification does not use the WebRTC data channel. See 520 Section Section 6.2 for how RUE supports real time text without the 521 data channel. 523 Implementations MUST support SIP outbound [RFC5626] (please also 524 refer to Section 5.1). 526 6. Media 528 This specification adopts the media specifications for WebRTC 529 ([RFC8825]). Where WebRTC defines how interactive media 530 communications may be established using a browser as a client, this 531 specification assumes a normal SIP call. The RTP, RTCP, SDP and 532 specific media requirements specified for WebRTC are adopted for this 533 document. The RUE is a WebRTC non-browser" endpoint, except as noted 534 expressly below. 536 The following sections specify the WebRTC documents to which 537 conformance is required. "Mandatory to Implement" means a conforming 538 implementation must implement the specified capability. It does not 539 mean that the capability must be used in every session. For example, 540 OPUS is a mandatory to implement audio codec, and all conforming 541 implementations must support OPUS. However, implementation 542 presenting a call across the RUE Interface where the call originates 543 in the Public Switched Telephone Network, or an older, non-RUE- 544 compatible device, which only offers G.711 audio, does not need to 545 include the OPUS codec in the offer, since it cannot be used with 546 that call. 548 6.1. SRTP and SRTCP 550 Implementations MUST support [RFC8834] except that MediaStreamTracks 551 are not used. Implementations MUST conform to Section 6.4 of 552 [RFC8827]. 554 6.2. Text-Based Communication 556 Implementations MUST support real-time text ([RFC4102] and [RFC4103]) 557 via T.140 media. One original and two redundant generations MUST be 558 transmitted and supported, with a 300 ms transmission interval. Note 559 that this is not how real time text is transmitted in WebRTC and some 560 form of transcoder would be required to interwork real time text in 561 the data channel of WebRTC to RFC4103 real time text. 563 6.3. Video 565 Implementations MUST conform to [RFC7742] with the exception that, 566 since backwards compatibility is desirable and older devices do not 567 support VP8, that only H.264, as specified in [RFC7742] is Mandatory 568 to Implement and VP8 support is OPTIONAL at both the device and 569 providers. 571 6.4. Audio 573 Implementations MUST conform to [RFC7874]. 575 6.5. DTMF Digits 577 Implementations MUST support the "audio/telephone-event" [RFC4733] 578 media type. They MUST support conveying event codes 0 through 11 579 (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. 580 Handling of other tones is OPTIONAL. 582 6.6. Session Description Protocol 584 The SDP offers and answers MUST conform to [RFC8829] except that the 585 RUE Interface uses SIP transport for SDP. 587 note: parts of 8829 are not applicable. Need text to handle that, 588 and possibly require conformance to 8866/3264 590 6.7. Privacy 592 The RUE MUST be able to control privacy of the user by implementing a 593 one-way mute of audio and or video, without signaling, locally, but 594 MUST maintain any NAT bindings by periodically sending media packets 595 on all active media sessions containing silence/comfort noise/black 596 screen/etc. per [RFC6263]. 598 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 599 Intraframe Request Features 601 NACK SHOULD be used when negotiated and conditions warrant its use. 602 Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be 603 preferred, as described in [RFC5104]. 605 FIR SHOULD be used only in situations where not sending a decoder 606 refresh point would render the video unusable for the users, as per 607 RFC5104 subsection 4.3.1.2. 609 For backwards compatibility with calling devices that do not support 610 the foregoing methods, implementations MUST implement SIP INFO 611 messages to send and receive XML encoded Picture Fast Update messages 612 according to [RFC5168]. 614 7. Contacts 616 7.1. CardDAV Login and Synchronization 618 Support of CardDAV by Providers is OPTIONAL. 620 The RUE MUST and Providers MAY be able to synchronize the user's 621 contact directory between the RUE endpoint and one maintained by the 622 user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). 624 The configuration MAY supply a username and domain identifying a 625 CardDAV server and address book for this account. 627 To access the CardDAV server and address book, the RUE MUST follow 628 Section 6 of RFC6764, using the chosen username and domain in place 629 of an email address. If the request triggers a challenge for digest 630 authentication credentials, the RUE MUST attempt to continue using 631 matching "credentials" from the configuration. If no matching 632 credentials are configured, the RUE MUST use the SIP credentials from 633 the configuration. If the SIP credentials fail, the RUE MUST query 634 the user. 636 Synchronization using CardDAV MUST be a two-way synchronization 637 service, with proper handling of asynchronous adds, changes, and 638 deletes at either end of the transport channel. 640 7.2. Contacts Import/Export Service 642 Implementations MUST be able to export/import the list of contacts in 643 jCard [RFC7095] json format. 645 The RUE accesses this service via the "contacts" URI in the 646 configuration. The URL MUST resolve to identify a web server 647 resource that imports/exports contact lists for authorized users. 649 The RUE stores/retrieves the contact list (address book) by issuing 650 an HTTPS POST or GET request. If the request triggers a challenge 651 for digest authentication credentials, the RUE MUST attempt to 652 continue using matching "credentials" from the configuration. If no 653 credentials are configured, the RUE MUST query the user. 655 8. Mail Waiting Indicator (MWI) 657 Support of MWI by Providers is OPTIONAL 659 Implementations MUST support subscriptions to "message-summary" 660 events [RFC3842] to the URI specified in the configuration. 662 In notification bodies, videomail messages SHOULD be reported using 663 "message-context-class multimedia-message" defined in [RFC3458]. 665 9. Provisioning and Provider Selection 667 To simplify how users interact with RUE devices, the RUE interface 668 separates provisioning into two parts. One provides a directory of 669 providers so that a user interface that allows easy provider 670 selection either for registering or for dial-around. The other 671 provides configuration data for the device for each provider. 673 9.1. RUE Provider Selection 675 To allow the user to select a relay service, the RUE MAY obtain, on 676 startup, a list of Providers that provide service in a country. IANA 677 has established a registry that contains a two letter country code 678 and a URI. The URI, when used with the following interface, returns 679 a list of provider names for a country code suitable for display, 680 with a corresponding a URI to obtain information about that provider. 681 The provider URI is the entry point of a simple web service that 682 returns contact information for that provider. 684 Each country that supports video relay service using this 685 specification MAY support the provider list. This document does not 686 specify who maintains the list. Some possibilities are a regulator 687 or entity designated by a regulator, an agreement among providers to 688 provide the list, or a user group. 690 The web service also has a simple version mechanism that returns a 691 list of versions of the web service it supports. This document 692 describes version 1.0. Versions are described as a major version, 693 the period "." and a minor version, where major and minor versions 694 are integers. A backwards compatible change within a major version 695 MAY increment only the minor version number. A non-backwards 696 compatible change MUST increment the major version number. To 697 achieve backwards compatibility, implementations MUST ignore any 698 object members they do not implement and minor version definitions 699 SHALL only add objects, non-required members of existing objects, and 700 non-mandatory-to use functions and SHALL NOT delete any objects, 701 members of objects or functions. This means an implementation of a 702 specific major version and minor version is backwards compatible with 703 all minor versions of the major version. The versions mechanism 704 returns an array of supported versions, one for each major version 705 supported, with the minor version listed being the highest supported 706 minor version. 708 The V1 provider list is a json object consisting of an array where 709 each entry describes one Provider. Each entry consists of the 710 following items: 712 * name: This parameter contains the text label identifying the 713 Provider and is meant to be displayed to the human VRS user. 715 * domain: The domain parameter is used for configuration purposes by 716 the RUE (as discussed in Section 9.2) 718 The VRS user interacts with the RUE to select from the Provider list 719 one or more Providers with whom the user has already established an 720 account, wishes to establish an account, or wishes to use the 721 provider for a one stage dial around. 723 { 724 "providers": [ 725 { 726 "name": "Red", 727 "domain": "red.example.net", 728 }, 729 { 730 "name": "Green", 731 "domain": "green.example.net", 732 }, 733 { 734 "name": "Blue", 735 "domain": "blue.example.net" 736 } 737 ] 738 } 740 Figure 2: Example of a Provider list JSON object 742 { 743 "versions": [ 744 { 745 "major": 1, 746 "minor": 6, 747 }, 748 { 749 "major": 2, 750 "minor": 13, 751 }, 752 { 753 "major": 3, 754 "minor": 2 755 } 756 ] 757 } 759 Figure 3: Example of a Version JSON object 761 9.2. RUE Configuration Service 763 A RUE device may retrieve a provider configuration the using a simple 764 HTTPs web service. The device uses the userid/password to 765 authenticate to the interface if it has credentials for that 766 provider. Without user credentials, the response includes 767 configuration data for new user sign up and dial around. 769 An optional parameter may be provided to the interface which is an 770 API Key. The implementation MAY have an API Key obtained from the 771 provider and specific to the implementation. The method the API Key 772 is obtained is not specified in this document. The provider MAY 773 refuse to provide service to an implementation presenting an API Key 774 it does not recognize. 776 A required parameter which contains an instance identifier. This 777 parameter MUST be the same value each time this instance (same 778 implementation on same device) queries the interface. This may be 779 used by the provider, for example, to associate a location with the 780 instance for emergency calls. 782 The data returned is a json object consisting of an array of key/ 783 value configuration parameters to be used by the RUE. 785 The configuration data payload includes the following data items. 786 Items not noted as (OPTIONAL) are REQUIRED. If other unexpected 787 items are found, they MUST be ignored. 789 * signup: (OPTIONAL) an array of json objects consisting of: 791 - language: entry from the IANA language subtag registry 793 - uri: a URI to the website for creating a new account in the 794 supported language. The new user signup URI may only initiate 795 creation of a new account. Various vetting, approval and other 796 processes may be needed, which could take time, before the 797 account is established. The result of creating a new account 798 would be a username and password, which would be manually 799 entered into the RUE device to allow connection to the 800 Provider. 802 * dialAround: an array of json objects consisting of: 804 - language: entry from the IANA language subtag registry 806 - frontDoor: a URI to a queue of interpreters supporting the 807 specified language for a two stage dial-around 809 - oneStage: (OPTIONAL) a URI that can be used with a one-stage 810 dial-around Section 5.2.2 using an interpreter supporting the 811 specified language 813 * helpDesk: (OPTIONAL) an array of json objets consisting of: 815 - language: entry from the IANA language subtag registry 816 - uri: URI that reaches a help desk for callers supporting the 817 specified language. 819 * lifetime: Specifies how long (in seconds) the RUE MAY cache the 820 configuration values. Values may not be valid when lifetime 821 expires. Emergency Calls MUST continue to work. 823 * sip-password: (OPTIONAL) a password used for SIP, STUN and TURN 824 authentication. The RUE device retains this data, which must be 825 stored securely. If it is not supplied, but was supplied on a 826 prior invocation of this interface, the most recently supplied 827 password MUST be used. If it was never supplied, the password 828 used to authenticate to the configuration service is used for SIP, 829 STUN and TURN. 831 * phone-number: (OPTIONAL) The telephone number (in E.164 format) 832 assigned to this subscriber. This becomes the user portion of the 833 SIP URI identifying the subscriber. 835 * outbound-proxy: (OPTIONAL) A URI of a SIP proxy to be used when 836 sending requests to the Provider. 838 * mwi: (OPTIONAL) A URI identifying a SIP event server that 839 generates "message-summary" events for this subscriber. 841 * videomail: (OPTIONAL) A SIP URI that can be called to retrieve 842 videomail messages. 844 * contacts: (CONDITIONAL) An HTTPS URI that may be used to export 845 (retrieve) the subscriber's complete contact list managed by the 846 Provider. 848 * carddav: (OPTIONAL) A username, password and domain name 849 (separated by ""@"") identifying a "CardDAV" server that can be 850 used to synchronize the RUE's contact list with the contact list 851 managed by the Provider. Optionally contains a user name and/or 852 password that may be used with the server. If username or 853 password are not supplied, the main account credentials are used. 855 * sendLocationWithRegistration: (OPTIONAL) True if the RUE should 856 send a Geolocation Header with REGISTER, false if it should not. 857 Defaults to false if not present. 859 * ice-servers: (OPTIONAL) An array of URLs identifying STUN and TURN 860 servers available for use by the RUE for establishing media 861 streams in calls via the Provider. 863 The configuration API also provides the same version mechanism as 864 specified above in Section 9.1. The version of the configuration 865 service MAY be different than the version of the provider list 866 service. 868 Example JSON configuration payload 869 { 870 "signUp": [ 871 { "language" : "en", "uri" : "welcome-en.example.net"} , 872 { "language" : "es", "uri" : "welcome-es.example.net"} ] , 873 "dialAround": [ 874 { "language" : "en", "frontDoor" : "fd-en.example.net", 875 "oneStage" : "1stg-eng.example.com" } , 876 { "language" : "es", "frontDoor" : "fd-es.example.net", 877 "oneStage" : "1stg-spn.example.com" } ] , 878 "helpDesk": [ 879 { "language" : "en", "uri" : "help-en.example.net"} , 880 { "language" : "es", "uri" : "help-es.example.net"} ] , 881 "lifetime": 86400, 882 "display-name" : "Bob Smith", 883 "phone-number": "+18135551212", 884 "provider-domain": "red.example.net", 885 "outbound-proxies": [ 886 "sip:p1.red.example.net", 887 "sip:p2.red.example.net" 888 ], 889 "mwi": "sip:+18135551212@red.example.net", 890 "videomail": "sip:+18135551212@vm.red.example.net", 891 "contacts": "https://red.example.net:443/contacts/1dess45awd", 892 "carddav": "bob@red.example.com" , 893 "sendLocationWithRegistration": false, 894 "ice-servers": [ 895 {"stun":"stun.l.google.com:19302" }, 896 {"turn":"turn.red.example.net:3478"} 897 ], 898 } 900 Figure 4 902 The "lifetime" parameter in the configuration indicates how long the 903 RUE MAY cache the configuration values. If the RUE caches 904 configuration values, it MUST cryptographically protect them. The 905 RUE SHOULD retrieve a fresh copy of the configuration before the 906 lifetime expires or as soon as possible after it expires. The 907 lifetime is not guaranteed: the configuration may change before the 908 lifetime value expires. In that case, the Provider MAY indicate this 909 by generating authorization challenges to requests and/or prematurely 910 terminating a registration. 912 9.3. Using the Provider List and Configuration Services Together 914 One way to use these two services is: 916 * At startup, the RUE retrieves the provider list for the country it 917 is located in. 919 * For each provider in the list: 921 - If the RUE does not have credentials for that provider, use the 922 configuration service without credentials to obtain signup, 923 dial around and helpdesk information. 925 - If the RUE has credentials for that provider, use the 926 configuration service with credentials to obtain all 927 configuration data. 929 9.4. OpenAPI Interface Descriptions 931 The interfaces in Sections Section 9.1 and Section 9.2 are formally 932 specified with OpenAPI 3.0 descriptions in yaml form. 934 openapi: 3.0.1 935 info: 936 title: RUM API 937 version: "1.0" 938 servers: 939 - url: http://localhost/rum/v1 940 paths: 941 /Providers: 942 get: 943 summary: Get a list of providers to get config data from 944 operationId: GetProviderList 945 responses: 946 '200': 947 description: List of providers for a country 948 content: 949 application/json: 950 schema: 951 $ref: '#/components/schemas/ProviderList' 952 /Versions: 953 servers: 954 - url: https://api.example.com/rum 955 description: Override base path for Versions query 956 get: 957 summary: Retrieves all supported versions 958 operationId: RetrieveVersions 959 responses: 961 '200': 962 description: Versions supported 963 content: 964 application/json: 965 schema: 966 $ref: '#/components/schemas/VersionsArray' 967 components: 968 schemas: 969 ProviderList: 970 type: object 971 required: 972 - providers 973 properties: 974 providers: 975 type: array 976 items: 977 type: object 978 required: 979 - name 980 - domain 981 properties: 982 name: 983 type: string 984 description: Human readable provider name 985 domain: 986 type: string 987 description: provider domain for interface 988 VersionsArray: 989 type: object 990 required: 991 - versions 992 properties: 993 versions: 994 type: array 995 items: 996 type: object 997 required: 998 - major 999 - minor 1000 properties: 1001 major: 1002 type: integer 1003 format: int32 1004 description: Version major number 1005 minor: 1006 type: integer 1007 format: int32 1008 description: Version minor number 1010 Figure 5: Provider List OpenAPI description 1012 openapi: 3.0.1 1013 info: 1014 title: RUM API 1015 version: "1.0" 1016 servers: 1017 - url: http://localhost/rum/v1 1018 paths: 1019 /Configuration: 1020 get: 1021 summary: Configuration data for one provider 1022 operationId: GetConfiguration 1023 parameters: 1024 - in: query 1025 name: apiKey 1026 schema: 1027 type: string 1028 description: API Key assigned to this implementation 1029 - in: query 1030 name: instanceId 1031 schema: 1032 type: string 1033 required: true 1034 description: Unique string for this implementation on this 1035 device 1036 responses: 1037 '200': 1038 description: configuration object 1039 content: 1040 application/json: 1041 schema: 1042 $ref: '#/components/schemas/ConfigurationData' 1043 /Versions: 1044 servers: 1045 - url: https://api.example.com/rum 1046 description: Override base path for Versions query 1047 get: 1048 summary: Retrieves all supported versions 1049 operationId: RetrieveVersions 1050 responses: 1051 '200': 1052 description: Versions supported 1053 content: 1054 application/json: 1055 schema: 1056 $ref: '#/components/schemas/VersionsArray' 1057 components: 1059 schemas: 1060 ConfigurationData: 1061 type: object 1062 properties: 1063 signup: 1064 type: object 1065 required: 1066 - language 1067 - uri 1068 properties: 1069 language: 1070 type: string 1071 description: entry from IANA language-subtag-registry 1072 uri: 1073 type: string 1074 format: uri 1075 description: uri to signup website supporting language 1076 dialAround: 1077 type: object 1078 required: 1079 - language 1080 - frontDoor 1081 properties: 1082 language: 1083 type: string 1084 description: entry from IANA language-subtag-registry 1085 frontDoor: 1086 type: string 1087 format: uri 1088 description: SIP uri for 2 stage dial around 1089 oneStage: 1090 type: string 1091 format: uri 1092 description: SIP uri for 1 stage dial around 1093 helpDesk: 1094 type: object 1095 required: 1096 - language 1097 - uri 1098 properties: 1099 language: 1100 type: string 1101 description: entry from IANA language-subtag-registry 1102 uri: 1103 type: string 1104 format: uri 1105 description: SIP uri of helpdesk supporting language 1106 sip-password: 1108 type: string 1109 phone-number: 1110 type: string 1111 description: telephone number assigned this subscriber 1112 outbound-proxy: 1113 type: string 1114 format: uri 1115 description: SIP uri of proxy to be used when sending requests 1116 to the Provider 1117 mwi: 1118 type: string 1119 format: uri 1120 description: A URI identifying a SIP event server that 1121 generates "message-summary" events for this subscriber. 1122 videomail: 1123 type: string 1124 format: uri 1125 description: A SIP URI that can be called to retrieve 1126 videomail messages. 1127 contacts: 1128 type: string 1129 format: uri 1130 description: An HTTPS URI that may be used to export 1131 (retrieve) the subscriber's complete contact list 1132 managed by the Provider. 1133 carddav: 1134 type: object 1135 description: CardDAV server and user information that can be 1136 used to synchronize the RUE's contact list with the 1137 contact list managed by the Provider. 1138 properties: 1139 domain: 1140 type: string 1141 description: CardDAV server address 1142 username: 1143 type: string 1144 description: username for authentication with CardDAV 1145 server. Use provider username if not provided 1146 password: 1147 type: string 1148 description: password for authentication to the CardDAV 1149 server. Use provider password if not provided 1150 sendLocationWithRegistration: 1151 type: boolean 1152 description: True if the RUE should send a Geolocation Header 1153 with REGISTER, false if it should not. Defaults to false 1154 if not present. 1155 ice-servers: 1157 type: array 1158 items: 1159 type: string 1160 format: uri 1161 description: URIs identifying STUN and TURN servers 1162 available for use by the RUE for establishing media 1163 streams in calls via the Provider. 1164 VersionsArray: 1165 type: object 1166 required: 1167 - versions 1168 properties: 1169 versions: 1170 type: array 1171 items: 1172 type: object 1173 required: 1174 - major 1175 - minor 1176 properties: 1177 major: 1178 type: integer 1179 format: int32 1180 description: Version major number 1181 minor: 1182 type: integer 1183 format: int32 1184 description: Version minor number 1186 Figure 6: Configuration OpenAPI description 1188 10. Acknowledgements 1190 Brett Henderson and Jim Malloy provided many helpful edits to prior 1191 versions of this document. 1193 11. IANA Considerations 1194 11.1. RUE Provider List Registry 1196 IANA has created the "RUE Provider List" registry. The management 1197 policy for this registry is "Expert Review" [RFC8126]. The expert 1198 should prefer a regulator operated or designated list interface 1199 operator. Otherwise, evidence that the proposed list interface 1200 operator will provide a complete list of providers is required to add 1201 the entry to the registry. Updates to the registry are permitted if 1202 the expert judges the new proposed uri to be better than the existing 1203 entry. Each entry has two fields, values for both of which MUST be 1204 provided when registering or updating an entry: 1206 * country code: a two letter ISO93166 country code 1208 * list uri: a uri that implements the provider list interface for 1209 that country 1211 11.2. Registration of rue-owner purpose parameter 1213 This document defines the new predefined value "rue-owner" for the 1214 "purpose" header field parameter of the Call-Info header field. This 1215 modifies the "Header Field Parameters and Parameter Values" 1216 subregistry of the "Session Initiation Protocol (SIP) Parameters" 1217 registry by adding this RFC as a reference to the line for the header 1218 field "Call-Info" and parameter name "purpose" 1220 * Header Field: Call-Info 1222 * Parameter Name: purpose 1224 * Predefined Values: Yes 1226 12. Security Considerations 1228 The RUE is required to communicate with servers on public IP 1229 addresses and specific ports to perform its required functions. If 1230 it is necessary for the RUE to function on a corporate or other 1231 network that operates a default-deny firewall between the RUE and 1232 these services, the user must arrange with their network manager for 1233 passage of traffic through such a firewall in accordance with the 1234 protocols and associated SRV records as exposed by the Provider. 1235 Because VRS providers may use different ports for different services, 1236 these port numbers may differ from Provider to Provider. 1238 13. 1239 Normative References 1241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1242 Requirement Levels", BCP 14, RFC 2119, 1243 DOI 10.17487/RFC2119, March 1997, 1244 . 1246 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1247 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1248 . 1250 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1251 A., Peterson, J., Sparks, R., Handley, M., and E. 1252 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1253 DOI 10.17487/RFC3261, June 2002, 1254 . 1256 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1257 Protocol (SIP): Locating SIP Servers", RFC 3263, 1258 DOI 10.17487/RFC3263, June 2002, 1259 . 1261 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1262 with Session Description Protocol (SDP)", RFC 3264, 1263 DOI 10.17487/RFC3264, June 2002, 1264 . 1266 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1267 "Indicating User Agent Capabilities in the Session 1268 Initiation Protocol (SIP)", RFC 3840, 1269 DOI 10.17487/RFC3840, August 2004, 1270 . 1272 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1273 "Managing Client-Initiated Connections in the Session 1274 Initiation Protocol (SIP)", RFC 5626, 1275 DOI 10.17487/RFC5626, October 2009, 1276 . 1278 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1279 Session Description Protocol", RFC 8866, 1280 DOI 10.17487/RFC8866, January 2021, 1281 . 1283 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1284 Initiation Protocol (SIP)", RFC 3323, 1285 DOI 10.17487/RFC3323, November 2002, 1286 . 1288 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1289 in Session Description Protocol (SDP)", RFC 3605, 1290 DOI 10.17487/RFC3605, October 2003, 1291 . 1293 [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, 1294 DOI 10.17487/RFC6665, July 2012, 1295 . 1297 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1298 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1299 2002, . 1301 [RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. 1302 Campen, "Addressing an Amplification Vulnerability in 1303 Session Initiation Protocol (SIP) Forking Proxies", 1304 RFC 5393, DOI 10.17487/RFC5393, December 2008, 1305 . 1307 [RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing 1308 Record-Route Issues in the Session Initiation Protocol 1309 (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, 1310 . 1312 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 1313 "Essential Correction for IPv6 ABNF and URI Comparison in 1314 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 1315 . 1317 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1318 Tone Generation in the Session Initiation Protocol (SIP)", 1319 RFC 3960, DOI 10.17487/RFC3960, December 2004, 1320 . 1322 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1323 for the Session Initiation Protocol", RFC 6442, 1324 DOI 10.17487/RFC6442, December 2011, 1325 . 1327 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1328 (SIP) Extension Header Field for Registering Non-Adjacent 1329 Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, 1330 . 1332 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1333 (ICE): A Protocol for Network Address Translator (NAT) 1334 Traversal for Offer/Answer Protocols", RFC 5245, 1335 DOI 10.17487/RFC5245, April 2010, 1336 . 1338 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1339 Header Field for the Session Initiation Protocol (SIP)", 1340 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1341 . 1343 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1344 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1345 . 1347 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 1348 (SIP) REFER Method Implicit Subscription", RFC 4488, 1349 DOI 10.17487/RFC4488, May 2006, 1350 . 1352 [RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of 1353 REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, 1354 September 2015, . 1356 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1357 Protocol (SIP) "Replaces" Header", RFC 3891, 1358 DOI 10.17487/RFC3891, September 2004, 1359 . 1361 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 1362 Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, 1363 September 2004, . 1365 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1366 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1367 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1368 December 2003, . 1370 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1371 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 1372 . 1374 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1375 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1376 . 1378 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1379 Initiation Protocol Uniform Resource Identifier", 1380 RFC 4967, DOI 10.17487/RFC4967, July 2007, 1381 . 1383 [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", 1384 RFC 4102, DOI 10.17487/RFC4102, June 2005, 1385 . 1387 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1388 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 1389 . 1391 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1392 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1393 DOI 10.17487/RFC4733, December 2006, 1394 . 1396 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1397 Keeping Alive the NAT Mappings Associated with RTP / RTP 1398 Control Protocol (RTCP) Flows", RFC 6263, 1399 DOI 10.17487/RFC6263, June 2011, 1400 . 1402 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1403 "Codec Control Messages in the RTP Audio-Visual Profile 1404 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1405 February 2008, . 1407 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1408 Media Control", RFC 5168, DOI 10.17487/RFC5168, March 1409 2008, . 1411 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 1412 Authoring and Versioning (WebDAV)", RFC 6352, 1413 DOI 10.17487/RFC6352, August 2011, 1414 . 1416 [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions 1417 to WebDAV (CalDAV) and vCard Extensions to WebDAV 1418 (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, 1419 . 1421 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 1422 DOI 10.17487/RFC7095, January 2014, 1423 . 1425 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1426 Indication Event Package for the Session Initiation 1427 Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 1428 2004, . 1430 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1431 Context for Internet Mail", RFC 3458, 1432 DOI 10.17487/RFC3458, January 2003, 1433 . 1435 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1436 "Recommendations for Secure Use of Transport Layer 1437 Security (TLS) and Datagram Transport Layer Security 1438 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1439 2015, . 1441 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1442 Communications Services in Support of Emergency Calling", 1443 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1444 . 1446 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1447 J. Winterbottom, "Additional Data Related to an Emergency 1448 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 1449 . 1451 [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing 1452 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, 1453 . 1455 [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec 1456 Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 1457 . 1459 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1460 Writing an IANA Considerations Section in RFCs", BCP 26, 1461 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1462 . 1464 [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for 1465 Browser-Based Applications", RFC 8825, 1466 DOI 10.17487/RFC8825, January 2021, 1467 . 1469 [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, 1470 DOI 10.17487/RFC8827, January 2021, 1471 . 1473 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 1474 "JavaScript Session Establishment Protocol (JSEP)", 1475 RFC 8829, DOI 10.17487/RFC8829, January 2021, 1476 . 1478 [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport 1479 and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, 1480 January 2021, . 1482 [RFC8835] Alvestrand, H., "Transports for WebRTC", RFC 8835, 1483 DOI 10.17487/RFC8835, January 2021, 1484 . 1486 [RFC8760] Shekh-Yusef, R., "The Session Initiation Protocol (SIP) 1487 Digest Access Authentication Scheme", RFC 8760, 1488 DOI 10.17487/RFC8760, March 2020, 1489 . 1491 [RFC8599] Holmberg, C. and M. Arnold, "Push Notification with the 1492 Session Initiation Protocol (SIP)", RFC 8599, 1493 DOI 10.17487/RFC8599, May 2019, 1494 . 1496 [pip] SIPForum, "VRS US Providers Profile TWG-6-1.0", 2015, 1497 . 1500 Author's Address 1502 Brian Rosen 1503 470 Conrad Dr 1504 Mars, PA 16046 1505 United States of America 1507 Phone: +1 724 382 1051 1508 Email: br@brianrosen.net