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