idnits 2.17.1 draft-ietf-rum-rue-03.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 12 instances of too long lines in the document, the longest one being 25 characters in excess of 72. == 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 (25 August 2020) is 1338 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 1053 -- Looks like a reference, but probably isn't: '2' on line 1056 -- Looks like a reference, but probably isn't: '3' on line 1059 -- Looks like a reference, but probably isn't: '4' on line 1063 -- Looks like a reference, but probably isn't: '5' on line 1066 -- Looks like a reference, but probably isn't: '6' on line 1069 -- Looks like a reference, but probably isn't: '7' on line 1072 -- Looks like a reference, but probably isn't: '8' on line 1075 -- Looks like a reference, but probably isn't: '9' on line 1078 -- Looks like a reference, but probably isn't: '10' on line 1082 -- Looks like a reference, but probably isn't: '11' on line 1085 -- Looks like a reference, but probably isn't: '12' on line 1088 -- Looks like a reference, but probably isn't: '13' on line 1093 -- Looks like a reference, but probably isn't: '14' on line 1096 -- Looks like a reference, but probably isn't: '15' on line 1099 -- Looks like a reference, but probably isn't: '16' on line 1102 -- Looks like a reference, but probably isn't: '17' on line 1105 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** 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 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Possible downref: Normative reference to a draft: ref. 'I-D.yusef-sipcore-digest-scheme' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rum B. Rosen 3 Internet-Draft 25 August 2020 4 Intended status: Standards Track 5 Expires: 26 February 2021 7 Interoperability Profile for Relay User Equipment 8 draft-ietf-rum-rue-03 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 dead/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 26 February 2021. 44 Copyright Notice 46 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 16 91 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 17 92 9.3. Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 95 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 96 13. Normative References . . . . . . . . . . . . . . . . . . . . 26 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 99 1. Introduction 101 Video Relay Service (VRS) is a form of Telecommunications Relay 102 Service (TRS) that enables persons with hearing disabilities who use 103 sign language, such as American Sign Language (ASL), to communicate 104 with voice telephone users through video equipment. These services 105 also enable communication between such individuals directly in 106 suitable modalities, including any combination of sign language via 107 video, real-time text (RTT), and speech. 109 This Interoperability Profile for Relay User Equipment (RUE) is a 110 profile of the Session Initiation Protocol (SIP) and related media 111 protocols that enables end-user equipment registration and calling 112 for VRS calls. It specifies the minimal set of call flows, Internet 113 Engineering Task Force (IETF) and ITU-T standards that must be 114 supported, provides guidance where the standards leave multiple 115 implementation options, and specifies minimal and extended 116 capabilities for RUE calls. 118 Both deaf/HoH to provider (interpreted) and direct deaf/HoH to deaf/ 119 HoH calls are supported on this interface. While there are some 120 accommodations in this document to maximize backwards compatibility 121 with devices and services that conform to this document, backwards 122 compatibility is not a requirement, and some interwork may be 123 required to allow direct video calls to older devices. This document 124 only describes the interface between the device and the provider, and 125 not any other interface the provider may have. 127 2. Terminology 129 Communication Assistant (CA): The ASL interpreter stationed in a TRS- 130 registered call center working for a VRS Provider, acting as part of 131 the wire of a call to provide functionally equivalent phone service. 133 Communication modality (modality): A specific form of communication 134 that may be employed by two users, e.g., English voice, Spanish 135 voice, American Sign Language, English lip-reading, or French real- 136 time-text. Here, one communication modality is assumed to encompass 137 both the language and the way that language is exchanged. For 138 example, English voice and French voice are two different 139 communication modalities. 141 Default video relay service: The video relay service operated by a 142 subscriber's default VRS provider. 144 Default video relay service Provider (default Provider): The VRS 145 provider that registers, and assigns a telephone number to, a 146 specific subscriber. A subscriber's default Provider provides the 147 VRS that handles incoming relay calls to the user. The default 148 Provider also handles outgoing relay calls by default. 150 Dial-around call: A relay call where the subscriber specifies the use 151 of a VRS provider other than one of the Providers with whom the 152 subscriber is registered. This can be accomplished by the user 153 dialing a "front-door" number for a VRS provider and signing or 154 texting a phone number to call ("two-stage"). Alternatively, this 155 can be accomplished by the user's RUE software instructing the server 156 of its default VRS provider to automatically route the call through 157 the alternate Provider to the desired public switched telephone 158 network (PSTN) directory number ("one-stage"). 160 Full Intra Request (FIR): A request to a media sender, requiring that 161 media sender to send a Decoder Refresh Point at the earliest 162 opportunity. FIR is sometimes known as "instantaneous decoder 163 refresh request", "video fast update request", or "fast update 164 request". Point-to-Point Call (P2P Call): A call between two RUEs, 165 without including a CA. 167 Relay call: A call that allows persons with hearing or speech 168 disabilities to use a RUE to talk to users of traditional voice 169 services with the aid of a communication assistant (CA) to relay the 170 communication. Please refer to FCC-VRS-GUIDE. 172 Relay-to-relay call: A call between two subscribers each using 173 different forms of relay (video relay, IP relay, TTY), each with a 174 separate CA to assist in relaying the conversation. 176 Relay service (RS): A service that allow a registered subscriber to 177 use a RUE to make and receive relay calls, point-to-point calls, and 178 relay-to-relay calls. The functions provided by the relay service 179 include the provision of media links supporting the communication 180 modalities used by the caller and callee, and user registration and 181 validation, authentication, authorization, automatic call distributor 182 (ACD) platform functions, routing (including emergency call routing), 183 call setup, mapping, call features (such as call forwarding and video 184 mail), and assignment of CAs to relay calls. 186 Relay service Provider (Provider): An organization that operates a 187 relay service. A subscriber selects a relay service Provider to 188 assign and register a telephone number for their use, to register 189 with for receipt of incoming calls, and to provide the default 190 service for outgoing calls. 192 Relay user: Please refer to "subscriber". 194 Relay user E.164 Number (user E.164): The telephone number assigned 195 to the RUE in ITU-T E.164 format. 197 Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra 198 features to support a subscriber in requesting and using relay calls. 199 A RUE may take many forms, including a stand-alone device; an 200 application running on a general-purpose computing device such as a 201 laptop, tablet or smart phone; or proprietary equipment connected to 202 a server that provides the RUE interface. 204 RUE Interface: the SIP interface between a RUE and the provider who 205 supports it 207 Sign language: A language that uses hand gestures and body language 208 to convey meaning including, but not limited to, American Sign 209 Language (ASL). 211 Subscriber: An individual who has registered with a Provider and who 212 obtains service by using relay user equipment. This is the 213 traditional telecom term for an end-user customer, which in our case 214 is a relay user. 216 Telecommunications relay services (TRS): Telephone transmission 217 services that provide the ability for an individual who has a hearing 218 impairment or speech impairment to engage in communication by wire or 219 radio with a hearing individual in a manner that is functionally 220 equivalent to the ability of an individual who does not have a 221 hearing impairment or speech impairment to communicate using voice 222 communication services by wire or radio. TRS includes services that 223 enable two-way communication between an individual who uses a 224 Telecommunications Device for the Deaf (TDD) or other non-voice 225 terminal device and an individual who does not use such a device. 227 Video relay service (VRS): A relay service for people with hearing or 228 speech disabilities who use sign language to communicate using video 229 equipment (video RUE) with other people in real time. The video link 230 allows the CA to view and interpret the subscriber's signed 231 conversation and relay the conversation back and forth with the other 232 party. 234 3. Requirements Language 236 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in [RFC2119] 240 4. General Requirements 242 All HTTP/HTTPS connections specified throughout this document MUST 243 use HTTPS. Both HTTPS and all SIP connections MUST use TLS 244 conforming to at least [RFC7525] and must support [RFC8446] 246 All text data payloads not otherwise constrained by a specification 247 in another standards document MUST be encoded as Unicode UTF/8. 249 5. SIP Signaling 251 Implementations of the RUE Interface MUST conform to the following 252 core SIP standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP 253 Servers), [RFC3264] (Offer/Answer), [RFC3840] (User Agent 254 Capabilities), [RFC5626] (Outbound), [RFC4566] (Session Description 255 Protocol), [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP), 256 [RFC6665] (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop- 257 Fix), [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960] 258 (Early Media), and [RFC6442] (Geolocation Header). 260 In the above documents the RUE device conforms to the requirements of 261 a SIP user Agent, and the provider conforms to the requirements of 262 Registrar and Proxy Server where the document specifies different 263 behavior for different roles. The only requirement on providers for 264 RFC6655 (Events) is support for the Message Waiting Indicator (See 265 Section Section 8), which is optional and providers not supporting 266 MWI need not support RFC6665. 268 In addition, implementation MUST conform to [RFC3327] (Path), 269 [RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER Method), 270 [RFC3891] (Replaces Header), [RFC3892] (Referred-By). 272 Implementations MUST include a "User-Agent" header field uniquely 273 identifying the RUE application, platform, and version in all SIP 274 requests, and MUST include a "Server" header field with the same 275 content in SIP responses. 277 5.1. Registration 279 The RUE MUST register with a SIP registrar, following [RFC3261] and 280 [RFC5626] at a provider it has an account with. If the configuration 281 (please refer to Section 11) contains multiple "outbound-proxies", 282 then the RUE MUST use them as specified in [RFC5626] to establish 283 multiple flows. 285 The request-URI for the REGISTER request MUST contain the "provider- 286 domain" from the configuration. The To-URI and From-URI MUST be 287 identical URIs, formatted as specified in Section 13, using the 288 "phone-number" and "provider-domain" from the configuration. 290 The RUE determines the URI to resolve by initially determining if an 291 outbound proxy is configured. If it is, the URI will be that of the 292 outbound proxy. If no outbound proxy is configured, the URI will be 293 the Request-URI from the REGISTER request. The RUE extracts the 294 domain from that URI and consults the DNS record for that domain. 295 The DNS entry MUST contain NAPTR records conforming to RFC3263. One 296 of those NAPTR records MUST specify TLS as the preferred transport 297 for SIP. For example, a DNS NAPTR query for "sip: 298 p1.red.example.netv" could return: 300 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net 301 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net 303 If the RUE receives a 439 (First Hop Lacks Outbound Support) response 304 to a REGISTER request, it MUST re-attempt registration without using 305 the outbound mechanism. 307 The registrar MAY authenticate using SIP MD5 digest authentication. 308 The credentials to be used (username and password) MUST be supplied 309 within the credentials section of the configuration and identified by 310 the realm the registrar uses in a digest challenge. This username/ 311 password combination SHOULD NOT be the same as that used for other 312 purposes, such as retrieving the RUE configuration or logging into 313 the Provider's customer service portal. Because MD5 is considered 314 insecure, [I-D.yusef-sipcore-digest-scheme] SHOULD be implemented by 315 all implementations and SHA-based digest algorithms SHOULD be used 316 for digest authentication. 318 If the registration request fails with an indication that credentials 319 from the configuration are invalid, then the RUE SHOULD retrieve a 320 fresh version of the configuration. If credentials from a freshly 321 retrieved configuration are found to be invalid, then the RUE MUST 322 cease attempts to register and SHOULD inform the RUE User of the 323 problem. 325 Support for multiple simultaneous registrations is OPTIONAL. 327 Multiple simultaneous RUE SIP registrations from different RUE 328 devices with the same SIP URI SHOULD be permitted by the Provider. 329 The Provider MAY limit the total number of simultaneous 330 registrations. When a new registration request is received that 331 results in exceeding the limit on simultaneous registrations, the 332 Provider MAY then prematurely terminate another registration; 333 however, it SHOULD NOT do this if it would disconnect an active call. 335 If a Provider prematurely terminates a registration to reduce the 336 total number of concurrent registrations with the same URI, it SHOULD 337 take some action to prevent the affected RUE from automatically re- 338 registering and re-triggering the condition. 340 5.2. Session Establishment 342 5.2.1. Normal Call Origination 344 After initial SIP registration, the RUE adheres to SIP [RFC3261] 345 basic call flows, as documented in [RFC3665]. 347 A RUE device MUST routes all outbound calls through an outbound proxy 348 if configured. 350 INVITE requests used to initiate calls SHOULD NOT contain Route 351 headers. Route headers MAY be included in one-stage dial-around 352 calls and emergency calls. The SIP URIs in the To field and the 353 Request-URI MUST be formatted as specified in subsection 6.4 using 354 the destination phone number. The domain field of the URIs SHOULD be 355 the "provider-domain" from the configuration (e.g., 356 sip:+13115552368@red.example.com;user=phone). The same exceptions 357 apply, including anonymous calls. 359 Anonymous calls MUST be supported by all implementations. An 360 anonymous call is signaled per [RFC3323]. 362 The From-URI MUST be formatted as specified in Section 5.4, using the 363 phone-number and "provider-domain" from the configuration. It SHOULD 364 also contain the display-name from the configuration when present. 365 (Please refer to Section 9.2.) 367 Negotiated media MUST follow the guidelines specified in Section 6 of 368 this document. 370 To allow time to timeout an unanswered call and direct it to a 371 videomail server, the User Agent Client MUST NOT impose a time limit 372 less than the default SIP Invite transaction timeout of 3 minutes. 374 5.2.2. One-Stage Dial-Around Origination 376 Outbound dial-around calls allow a RUE user to select any Provider to 377 provide interpreting services for any call. "Two-stage" dial-around 378 calls involve the RUE calling a telephone number that reaches the 379 dial-around Provider and using signing or DTMF to provide the called 380 party telephone number. In two-stage dial-around, the To URI is the 381 URI of the dial-around Provider and the domain of the URI is the 382 Provider domain from the configuration. 384 One-stage dial-around is a method where the called party telephone 385 number is provided in the To URI and the Request-URI, using the 386 domain of the dial-around Provider. 388 For one-stage dial-around, the RUE MUST follow the procedures in 389 Section 5.2.1 with the following exception: the domain part of the 390 SIP URIs in the To field and the Request-URI MUST be the domain of 391 the dial-around Provider, discovered according to Section 9.1. 393 The following is a partial example of a one-stage dial-around call 394 from VRS user +1-555-222-0001 hosted by red.example.com to a hearing 395 user +1-555-123-4567 using dial-around to green.example.com for the 396 relay service. Only important details of the messages are shown and 397 many header fields have been omitted: 399 One Stage Dial-Around 400 ,-+-. ,----+----. ,-----+-----. 401 |RUE| |Default | |Dial-Around| 402 | | |Provider | | Provider | 403 `-+-' `----+----' `-----+-----' 404 | | | 405 | [1] INVITE | | 406 |-------------->| [2] INVITE | 407 | |-------------->| 409 Message Details: 411 [1] INVITE Rue -> Default Provider 413 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 414 To: 415 From: "Bob Smith" 416 Route: sip:green.example.net 418 [2] INVITE Default Provider -> Dial-Around Provider 420 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 421 To: 422 From: "Bob Smith" sip:+18135551212@red.example.net;user=phone 423 P-Asserted-Identity: sip:+18135551212@red.example.net 425 Figure 1 427 5.2.3. RUE Contact Information 429 To identify the owner of a RUE, the initial INVITE for a call from a 430 RUE, or the 200 OK accepting a call by a RUE, identifies the owner by 431 sending a Call-Info header with a purpose parameter of "rue-owner". 432 The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is 433 defined by [RFC2392] to locate message body parts. This URI type is 434 present in a SIP message to convey the RUE ownership information as a 435 MIME body. The form of the RUE ownership information is a jCard 436 [RFC7095]. Please refer to [RFC6442] for an example of using 437 Content-Indirect URLs in SIP messages. Note that use of the Content- 438 Indirect URL usually implies multiple message bodies ("mime/ 439 multipart"). 441 5.2.4. Incoming Calls 443 The RUE MUST accept inbound calls sent to it by the proxy mentioned 444 in the configuration. 446 If Multiple simultaneous RUE SIP registrations from different RUE 447 devices with the same SIP URI exist, the Provider MUST parallel fork 448 the call to all registered RUEs so that they ring at the same time. 449 The first RUE to reply with a 200 OK answers the call and the 450 Provider MUST CANCEL other call branches. 452 5.2.5. Emergency Calls 454 Implementations MUST conform to [RFC6881] for handling of emergency 455 calls, except that if the device is unable to determine its own 456 location, it MAY send the emergency call without a Geolocation header 457 and without a Route header (since it would be unable to query the 458 LoST server for a route per RFC6881). If an emergency call arrives 459 at the provider without a Geolocation header, the provider MUST 460 supply location by adding the Geolocation header, and MUST supply the 461 route by querying the LoST server with that location. 463 If the emergency call is to be handled using existing country 464 specific procedures, the Provider is responsible for modifying the 465 INVITE to conform to the country-specific requirements. In this 466 case, location MAY be extracted from the RFC6881 conformant INVITE 467 and used to propagate it to the appropriate country-specific 468 entities. Because the RUE may have a more accurate and timely 469 location of the device than the a manual entry location for nomadic 470 RUE devices, but country-specific procedures require the location to 471 be pre-loaded in some entity prior to placing an emergency call, 472 implementations of a RUE device MAY send a Geolocation header 473 containing its location in the REGISTER request if the configuration 474 specifies it. That information MAY be used to populate the location 475 to appropriate country-specific entities. 477 Implementations MUST implement Additional Data, [RFC7852]. RUE 478 devices MUST implement Data Provider, Device Implementation and 479 Owner/Subscriber Information blocks. Providers MUST implement Data 480 Provider and Service Information blocks as the call is forwarded to 481 the PSAP. 483 5.3. Mid Call Signaling 485 Implementations MUST support re-INVITE to renegotiate media session 486 parameters (among other uses). Per Section 6.1, implementations 487 MUST, be able to support an INFO request for full frame refresh for 488 devices that do not support RTCP mechanisms (please refer to 489 Section 6.8). Implementations MUST support an in-dialog REFER 490 ([RFC3515] updated by [RFC7647] and including support for norefersub 491 per [RFC4488]) with the Replaces header [RFC3891] to enable call 492 transfer. 494 5.4. URI Representation of Phone Numbers 496 SIP URIs constructed from non-URI sources (dial strings) and sent to 497 SIP proxies by the RUE MUST be represented as follows, depending on 498 whether they can be represented as an E.164 number. 500 A dial string that can be written as an E.164 formatted phone number 501 MUST be represented as a SIP URI with a URI ";user=phone" tag. The 502 user part of the URI MUST be in conformance with 'global-number' 503 defined in [RFC3966]. The user part MUST NOT contain any 'visual- 504 separator' characters. 506 Dial strings that cannot be written as E.164 numbers MUST be 507 represented as dialstring URIs, as specified by [RFC4967], e.g., 508 sip:411@red.example.net;user=dialstring. 510 The domain part of Relay Service URIs and User Address of Records 511 (AoR) MUST (using resolve (in accord with [RFC3263]) to globally 512 routable IPv4 addresses. The AoRs MAY also resolve to IPv6 513 addresses. 515 5.5. Transport 517 Implementations MUST conform to [I-D.ietf-rtcweb-transports] except 518 that that this specification does not use the WebRTC data channel. 519 See Section Section 6.2 for how RUE supports real time text without 520 the data channel. 522 Implementations MUST support SIP outbound [RFC5626] (please also 523 refer to Section 5.1). 525 6. Media 527 This specification adopts the media specifications for WebRTC 528 ([I-D.ietf-rtcweb-overview]). Where WebRTC defines how interactive 529 media communications may be established using a browser as a client, 530 this specification assumes a normal SIP call. The RTP, RTCP, SDP and 531 specific media requirements specified for WebRTC are adopted for this 532 document. The RUE is a WebRTC non-browser" endpoint, except as noted 533 expressly below. 535 The following sections specify the WebRTC documents to which 536 conformance is required. "Mandatory to Implement" means a conforming 537 implementation must implement the specified capability. It does not 538 mean that the capability must be used in every session. For example, 539 OPUS is a mandatory to implement audio codec, and all conforming 540 implementations must support OPUS. However, implementation 541 presenting a call across the RUE Interface where the call originates 542 in the Public Switched Telephone Network, or an older, non-RUE- 543 compatible device, which only offers G.711 audio, does not need to 544 include the OPUS codec in the offer, since it cannot be used with 545 that call. 547 6.1. SRTP and SRTCP 549 Implementations MUST support [I-D.ietf-rtcweb-rtp-usage] except that 550 MediaStreamTracks are not used. Implementations MUST conform to 551 Section 6.4 of [I-D.ietf-rtcweb-security-arch]. 553 6.2. Text-Based Communication 555 Implementations MUST support real-time text ([RFC4102] and [RFC4103]) 556 via T.140 media. One original and two redundant generations MUST be 557 transmitted and supported, with a 300 ms transmission interval. Note 558 that this is not how real time text is transmitted in WebRTC and some 559 form of transcoder would be required to interwork real time text in 560 the data channel of WebRTC to RFC4103 real time text. 562 6.3. Video 564 Implementations MUST conform to [RFC7742] with the exception that, 565 since backwards compatibility is desirable and older devices do not 566 support VP8, that only H.264, as specified in [RFC7742] is Mandatory 567 to Implement and VPB support is OPTIONAL at both the device and 568 providers. 570 6.4. Audio 572 Implementations MUST conform to [RFC7874]. 574 6.5. DTMF Digits 576 Implementations MUST support the "audio/telephone-event" [RFC4733] 577 media type. They MUST support conveying event codes 0 through 11 578 (DTMF digits "0"-"9", "*","#") defined in Table 7 of [RFC4733]. 579 Handling of other tones is OPTIONAL. 581 6.6. Session Description Protocol 583 The SDP offers and answers MUST conform [I-D.ietf-rtcweb-jsep] except 584 that the RUE Interface uses SIP transport for SDP. 586 6.7. Privacy 588 The RUE MUST be able to control privacy of the user by implementing a 589 one-way mute of audio and or video, without signaling, locally, but 590 MUST maintain any NAT bindings by periodically sending media packets 591 on all active media sessions containing silence/comfort noise/black 592 screen/etc. per [RFC6263]. 594 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 595 Intraframe Request Features 597 NACK SHOULD be used when negotiated and conditions warrant its use. 598 Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be 599 preferred, as described in [RFC5104]. 601 FIR SHOULD be used only in situations where not sending a decoder 602 refresh point would render the video unusable for the users, as per 603 RFC5104 subsection 4.3.1.2. 605 For backwards compatibility with calling devices that do not support 606 the foregoing methods, implementations MUST implement SIP INFO 607 messages to send and receive XML encoded Picture Fast Update messages 608 according to [RFC5168]. 610 7. Contacts 612 7.1. CardDAV Login and Synchronization 614 Support of CardDAV by Providers is OPTIONAL. 616 The RUE MUST and Providers MAY be able to synchronize the user's 617 contact directory between the RUE endpoint and one maintained by the 618 user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). 620 The configuration MAY supply a username and domain identifying a 621 CardDAV server and address book for this account. 623 To access the CardDAV server and address book, the RUE MUST follow 624 Section 6 of RFC6764, using the chosen username and domain in place 625 of an email address. If the request triggers a challenge for digest 626 authentication credentials, the RUE MUST attempt to continue using 627 matching "credentials" from the configuration. If no matching 628 credentials are configured, the RUE MUST use the SIP credentials from 629 the configuration. If the SIP credentials fail, the RUE MUST query 630 the user. 632 Synchronization using CardDAV MUST be a two-way synchronization 633 service, with proper handling of asynchronous adds, changes, and 634 deletes at either end of the transport channel. 636 7.2. Contacts Import/Export Service 638 Implementations MUST be able to export/import the list of contacts in 639 jCard [RFC7095] json format. 641 The RUE accesses this service via the "contacts" URI in the 642 configuration. The URL MUST resolve to identify a web server 643 resource that imports/exports contact lists for authorized users. 645 The RUE stores/retrieves the contact list (address book) by issuing 646 an HTTPS POST or GET request. If the request triggers a challenge 647 for digest authentication credentials, the RUE MUST attempt to 648 continue using matching "credentials" from the configuration. If no 649 credentials are configured, the RUE MUST query the user. 651 8. Mail Waiting Indicator (MWI) 653 Support of MWI by Providers is OPTIONAL 655 Implementations MUST support subscriptions to "message-summary" 656 events [RFC3842] to the URI specified in the configuration. 658 In notification bodies, videomail messages SHOULD be reported using 659 "message-context-class multimedia-message" defined in [RFC3458]. 661 9. Provisioning and Provider Selection 663 To simplify how users interact with RUE devices, the RUE interface 664 defines a provisioning mechanism which consist of files stored on 665 server that are retrieved by the RUE device. Two files are 666 supported: one provides a directory of providers so that a user 667 interface that allows easy provider selection either for registering 668 or for dial-around. The other file provides configuration data for 669 the device. The RUE device would retrieve these files at boot time. 670 No mechanism for creating the files are specified. Each of the files 671 contains a single json object. The retrieval mechanism is HTTPS 672 download of that object from a provisioned location. 674 9.1. RUE Provider Selection 676 To allow the user to select a relay service, the RUE MAY obtain, on 677 startup, a list of Providers from a configured accessible URL. This 678 file is MAY be a single file per country, containing all the 679 providers authorized in that country, but MAY be any collection of 680 providers. 682 The provider list, formatted as JSON, contains: 684 * Version: Specifies the version number of the Provider list format. 685 A new version number SHOULD only be used if the new version is not 686 backwards-compatible with the older version. A new version number 687 is not needed if new elements are optional and can be ignored by 688 older implementations. 690 * Providers: An array where each entry describes one Provider. Each 691 entry consists of the following items: 693 - name: This parameter contains the text label identifying the 694 Provider and is meant to be displayed to the human VRS user. 696 - domain: The domain parameter is used for configuration purposes 697 by the RUE (as discussed in Section 9.2) and as the domain to 698 use when targeting one-stage dial-around calls to this Provider 699 (as discussed in Section 5.2.2). 701 - operator: (OPTIONAL) The operator parameter is a SIP URL that 702 identifies the operator "front-door" that VRS users may contact 703 for manual (two-stage) dial-around calls. 705 The VRS user interacts with the RUE to select from the Provider list 706 one or more Providers with whom the user has already established an 707 account. 709 Example of a Provider list JSON object 710 { 711 "version": 1, 712 "providers": [ 713 { 714 "name": "Red", 715 "domain": "red.example.net", 716 "operator": "sip:operator@red.example.net" 717 }, 718 { 719 "name": "Green", 720 "domain": "green.example.net", 721 "operator": "sip:+18885550123@green.example.net;user=phone" 722 }, 723 { 724 "name": "Blue", 725 "domain": "blue.example.net" 726 } 727 ] 728 } 730 Figure 2 732 9.2. RUE Configuration Service 734 A RUE device may retrieve a configuration from a provisioned URL 735 using HTTPs. 737 The data returned will include a set of key/value configuration 738 parameters to be used by the RUE, formatted as a single JSON object 739 and identified by the associated [RFC7159] "application/json" MIME 740 type, to allow for other formats in the future. 742 The configuration data payload includes the following data items. 743 Items not noted as (OPTIONAL) are REQUIRED. If other unexpected 744 items are found, they MUST be ignored. 746 * version: Identifies the version of the configuration data format. 747 A new version number SHOULD only be used if the new version is not 748 backwards-compatible with the older version. A new version number 749 is not needed if new elements are optional and can be ignored by 750 older implementations. 752 * lifetime: Specifies how long (in seconds) the RUE MAY cache the 753 configuration values. Values may not be valid when lifetime 754 expires. Emergency Calls MUST continue to work. 756 * display-name: (OPTIONAL) A user-friendly name to identify the 757 subscriber when originating calls. 759 * phone-number: The telephone number (in E.164 format) assigned to 760 this subscriber. This becomes the user portion of the SIP URI 761 identifying the subscriber. 763 * provider-domain: The DNS domain name of the default Provider 764 servicing this subscriber. 766 * outbound-proxies: (OPTIONAL) A URI of a SIP proxy to be used when 767 sending requests to the Provider. 769 * mwi: (OPTIONAL) A URI identifying a SIP event server that 770 generates "message-summary" events for this subscriber. 772 * videomail: (OPTIONAL) A SIP URI that can be called to retrieve 773 videomail messages. 775 * contacts: An HTTPS URI that may be used to export (retrieve) the 776 subscriber's complete contact list managed by the Provider. 778 * carddav: (OPTIONAL) A username and domain name (separated by 779 ""@"") identifying a "CardDAV" server and user name that can be 780 used to synchronize the RUE's contact list with the contact list 781 managed by the Provider. 783 * sendLocationWithRegistration: True if the RUE should send a 784 Geolocation Header with REGISTER, false if it should not. 785 Defaults to false if not present. 787 * ice-servers: (OPTIONAL) An array of URLs identifying STUN and TURN 788 servers available for use by the RUE for establishing media 789 streams in calls via the Provider. 791 * credentials: (OPTIONAL) TBD 793 Example JSON configuration payload 794 { 795 "version": 1, 796 "lifetime": 86400, 797 "display-name" : "Bob Smith", 798 "phone-number": "+18135551212", 799 "provider-domain": "red.example.net", 800 "outbound-proxies": [ 801 "sip:p1.red.example.net", 802 "sip:p2.red.example.net" 803 ], 804 "mwi": "sip:+18135551212@red.example.net", 805 "videomail": "sip:+18135551212@vm.red.example.net", 806 "contacts": "https://red.example.net:443/contacts/1dess45awd", 807 "carddav": "bob@red.example.com" , 808 "sendLocationWithRegistration": false, 809 "ice-servers": [ 810 {"stun":"stun.l.google.com:19302" }, 811 {"turn":"turn.red.example.net:3478"} 812 ], 813 "credentials": [ 814 { 815 "realm": "red.example.net", 816 "username": "bob", 817 "password": "reg-pw" 818 }, 819 { 820 "realm": "proxies.red.example.net", 821 "username": "bob", 822 "password": "proxy-pw" 823 }, 824 { 825 "realm": "cd.red.example.net", 826 "username": "bob", 827 "password": "cd-pw" 828 }, 829 { 830 "realm": "vm.red.example.net", 831 "username": "bob", 832 "password": "vm-pw" 833 }, 834 { 835 "realm": "stun-turn.red.example.net", 836 "username": "bob", 837 "password": "stun-turn-pw" 838 } 839 ] 840 } 841 Figure 3 843 The wire format of the data is in keeping with the standard JSON 844 description in RFC7159. 846 The "lifetime" parameter in the configuration indicates how long the 847 RUE MAY cache the configuration values. If the RUE caches 848 configuration values, it MUST cryptographically protect them. The 849 RUE SHOULD retrieve a fresh copy of the configuration before the 850 lifetime expires or as soon as possible after it expires. The 851 lifetime is not guaranteed: the configuration may change before the 852 lifetime value expires. In that case, the Provider MAY indicate this 853 by generating authorization challenges to requests and/or prematurely 854 terminating a registration. 856 Note: In some cases, the RUE may successfully retrieve a fresh copy 857 of the configuration using digest credentials cached from the prior 858 retrieval. If this is not successful, then the RUE will need to ask 859 the user for the username and password. Unfortunately, this 860 authentication step might occur when the user is not present, 861 preventing SIP registration and thus incoming calls. To avoid this 862 situation, the RUE MAY retrieve a new copy of the configuration when 863 it knows the user is present, even if there is time before the 864 lifetime expires. 866 9.3. Schemas 868 The following JSON schemas are for the Provider List and the RUE 869 Configuration. 871 Provider List JSON Schema 872 { 873 "$schema": "http://json-schema.org/draft-07/schema", 874 "type": "object", 875 "title": "Providers schema", 876 "description": "List of Providers", 877 "required": [ 878 "version", 879 "providers" 880 ], 881 "properties": { 882 "version": { 883 "type": "number", 884 "description": "Version of this schema", 885 }, 886 "providers": { 887 "type": "array", 888 "description": "provider list as an array.", 889 "items": { 890 "required": [ 891 "name", 892 "domain" 893 ], 894 "properties": { 895 "name": { 896 "type": "string", 897 "description": "Display Name", 898 }, 899 "domain": { 900 "type": "string", 901 "description": 902 "domain name used with config file", 903 }, 904 "operator": { 905 "type": "string", 906 "description": 907 "SIP URI for dial-around", 908 } 909 } 910 } 911 } 912 } 913 } 915 Figure 4 917 RUE Configuration JSON Schema 918 { 919 "$schema": "http://json-schema.org/draft-07/schema", 920 "title": "The root schema", 921 "description": "RUE Configuration File", 922 "required": [ 923 "version", 924 "lifetime", 925 "phone-number", 926 "provider-domain", 927 "carddav", 928 ], 929 "properties": { 930 "version": { 931 "type": "number", 932 "description": "Version of this schema", 933 }, 934 "lifetime": { 935 "type": "integer", 936 "description": 937 "how long (in seconds) the RUE MAY cache the configuration values", 938 }, 939 "display-name": { 940 "type": "string", 941 "description": 942 "A user-friendly name to identify the subscriber when originating calls", 943 }, 944 "phone-number": { 945 "type": "string", 946 "description": 947 "The telephone number (in E.164 format) assigned to this subscriber", 948 }, 949 "provider-domain": { 950 "type": "string", 951 "description": 952 "The DNS domain name of the default Provider servicing this subscriber", 953 }, 954 "outbound-proxies": { 955 "type": "array", 956 "description": 957 "List of URIs of SIP proxies to be used when sending requests to the Provider", 958 "items": { 959 "type": "string", 960 "format": "uri" 961 } 962 }, 963 "mwi": { 964 "type": "string", 965 "format": "uri", 966 "description": 967 "A URI of a SIP event server that generates message-summary events", 968 }, 969 "videomail": { 970 "type": "string", 971 "format": "uri", 972 "description": 973 "A SIP URI that can be called to retrieve videomail messages", 974 }, 975 "contacts": { 976 "$id": "#/properties/contacts", 977 "type": "string", 978 "format": "uri", 979 "description": 980 "An HTTPS URI used to manage the subscriber's contact list at the Provider.", 981 }, 982 "carddav": { 983 "type": "string", 984 "description": 985 "A username and domain name (separated by @) identifying a CardDAV server", 986 }, 987 "sendLocationWithRegistration": { 988 "type": "boolean", 989 "description": 990 "True if the RUE should send a Geolocation Header with REGISTER", 991 "default": false, 992 }, 993 "ice-servers": { 994 "type": "array", 995 "description": 996 "An array of URLs identifying STUN and TURN servers available", 997 "items": { 998 "type": "object", 999 "properties": { 1000 "servertype": { 1001 "type": "string" 1002 }, 1003 "url": { 1004 "type": "string" 1005 } 1006 } 1007 } 1008 }, 1009 "credentials": { 1010 "type": "array", 1011 "description": "registration credentials", 1012 "additionalItems": true, 1013 "items": { 1014 "type": "object", 1015 "required": [ 1016 "realm", 1017 "username", 1018 "password" 1019 ], 1020 "properties": { 1021 "realm": { 1022 "type": "string", 1023 "description": 1024 "domain of provider matching domain in provider list", 1025 }, 1026 "username": { 1027 "type": "string", 1028 "description": "username for registration" 1029 }, 1030 "password": { 1031 "type": "string", 1032 "description": "password for registration", 1033 } 1034 }, 1035 } 1036 } 1037 }, 1038 } 1040 Figure 5 1042 The following illustrates the message flow for retrieving a RUE 1043 automatic configuration using HTTPS Digest Authentication: 1045 RUE Configuration Retrieval 1046 ,-. 1047 `-' 1048 /|\ ,---. ,---. ,------------. ,----------------. ,---. 1049 | |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 1050 / \ | | | | | | |Global Settings | | | 1051 RUE User `-+-' `-+-' `-----+------' `--------+-------' `-+-' 1052 | | | | | | 1053 [1] Select a VRS Provider name | | | 1054 | ------->| | | | | 1055 | | | | | | 1056 [2] NAPTR "SFUA.CFG" red.example.net | | 1057 | |----->| | | | 1058 | | | | | | 1059 [3] NAPTR "!.*!https://server.red.example.net/!" | | 1060 | |<-----| | | | 1061 | | | | | | 1063 [4] If NAPTR found, query DNS server.red.example.net | 1064 | |----->| | | | 1065 | | | | | | 1066 [5] If NXDOMAIN, query DNS config.red.example.net | | 1067 | | - - >| | | | 1068 | | | | | | 1069 [6] IP Address of Config Server | | | 1070 | |<-----| | | | 1071 | | | | | | 1072 [7] Establish TLS connection | | | 1073 | |<--------------->| | | 1074 | | | | | | 1075 [8] HTTP: https://config.red.example.net/v1 | | 1076 | |---------------->| | | 1077 | | | | | | 1078 [9] HTTP: 401 Unauthorized | | | 1079 WWW-Authenticate Digest realm="Y" qop="auth,auth-int" nonce=| 1080 | |<----------------| | | 1081 | | | | | | 1082 [10] Query for userid/pw | | | 1083 |<--------| | | | | 1084 | | | | | | 1085 [11] User="bob", pw="bob's global provider pw" | | 1086 |-------->| | | | | 1087 | | | | | | 1088 [12] HTTP: https://config.red.example.net/v1 | | 1089 | Authorization Digest username="bob" realm="Y" qop="auth" | 1090 | nonce=... response="..." ... | | 1091 | |---------------->| | | 1092 | | | | | | 1093 | [13] Find subscriber information for username="bob" | 1094 | | | |----------------------------->| 1095 | | | | | | 1096 | [14] Subscriber specific configuration information | 1097 | | | |<-----------------------------| 1098 | | | | | | 1099 | [15] Retrieve provider specific settings | 1100 | | | |---------------->| | 1101 | | | | | | 1102 | [16] Provider configuration information | | 1103 | | | |<----------------| | 1104 | | | | | | 1105 [17] 200 OK + JSON merge subscriber + provider configs | 1106 | |<----------------| | | 1107 | | | | | | 1108 RUE User ,---. ,---. ,------------. ,----------------. ,---. 1109 ,-. |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 1110 `-' | | | | | | |Global Settings | | | 1111 /|\ `-+-' `-+-' `-----+------' `--------+-------' `-+-' 1112 | 1113 / \ 1115 Figure 6 1117 10. Acknowledgements 1119 Brett Henderson and Jim Malloy provided many helpful edits to prior 1120 versions of this document. 1122 11. IANA Considerations 1124 This memo includes no request to IANA. 1126 12. Security Considerations 1128 The RUE is required to communicate with servers on public IP 1129 addresses and specific ports to perform its required functions. If 1130 it is necessary for the RUE to function on a corporate or other 1131 network that operates a default-deny firewall between the RUE and 1132 these services, the user must arrange with their network manager for 1133 passage of traffic through such a firewall in accordance with the 1134 protocols and associated SRV records as exposed by the Provider. 1135 Because VRS providers may use different ports for different services, 1136 these port numbers may differ from Provider to Provider. 1138 13. 1139 Normative References 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, 1143 DOI 10.17487/RFC2119, March 1997, 1144 . 1146 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1147 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1148 . 1150 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1151 A., Peterson, J., Sparks, R., Handley, M., and E. 1152 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1153 DOI 10.17487/RFC3261, June 2002, 1154 . 1156 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1157 Protocol (SIP): Locating SIP Servers", RFC 3263, 1158 DOI 10.17487/RFC3263, June 2002, 1159 . 1161 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1162 with Session Description Protocol (SDP)", RFC 3264, 1163 DOI 10.17487/RFC3264, June 2002, 1164 . 1166 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1167 "Indicating User Agent Capabilities in the Session 1168 Initiation Protocol (SIP)", RFC 3840, 1169 DOI 10.17487/RFC3840, August 2004, 1170 . 1172 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1173 "Managing Client-Initiated Connections in the Session 1174 Initiation Protocol (SIP)", RFC 5626, 1175 DOI 10.17487/RFC5626, October 2009, 1176 . 1178 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1179 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1180 July 2006, . 1182 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1183 Initiation Protocol (SIP)", RFC 3323, 1184 DOI 10.17487/RFC3323, November 2002, 1185 . 1187 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1188 in Session Description Protocol (SDP)", RFC 3605, 1189 DOI 10.17487/RFC3605, October 2003, 1190 . 1192 [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, 1193 DOI 10.17487/RFC6665, July 2012, 1194 . 1196 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1197 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1198 2002, . 1200 [RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. 1201 Campen, "Addressing an Amplification Vulnerability in 1202 Session Initiation Protocol (SIP) Forking Proxies", 1203 RFC 5393, DOI 10.17487/RFC5393, December 2008, 1204 . 1206 [RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing 1207 Record-Route Issues in the Session Initiation Protocol 1208 (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, 1209 . 1211 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 1212 "Essential Correction for IPv6 ABNF and URI Comparison in 1213 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 1214 . 1216 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1217 Tone Generation in the Session Initiation Protocol (SIP)", 1218 RFC 3960, DOI 10.17487/RFC3960, December 2004, 1219 . 1221 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1222 for the Session Initiation Protocol", RFC 6442, 1223 DOI 10.17487/RFC6442, December 2011, 1224 . 1226 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1227 (SIP) Extension Header Field for Registering Non-Adjacent 1228 Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, 1229 . 1231 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1232 (ICE): A Protocol for Network Address Translator (NAT) 1233 Traversal for Offer/Answer Protocols", RFC 5245, 1234 DOI 10.17487/RFC5245, April 2010, 1235 . 1237 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1238 Header Field for the Session Initiation Protocol (SIP)", 1239 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1240 . 1242 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1243 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1244 . 1246 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 1247 (SIP) REFER Method Implicit Subscription", RFC 4488, 1248 DOI 10.17487/RFC4488, May 2006, 1249 . 1251 [RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of 1252 REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, 1253 September 2015, . 1255 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1256 Protocol (SIP) "Replaces" Header", RFC 3891, 1257 DOI 10.17487/RFC3891, September 2004, 1258 . 1260 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 1261 Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, 1262 September 2004, . 1264 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1265 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1266 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1267 December 2003, . 1269 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1270 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 1271 . 1273 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1274 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1275 . 1277 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1278 Initiation Protocol Uniform Resource Identifier", 1279 RFC 4967, DOI 10.17487/RFC4967, July 2007, 1280 . 1282 [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", 1283 RFC 4102, DOI 10.17487/RFC4102, June 2005, 1284 . 1286 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1287 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 1288 . 1290 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1291 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1292 DOI 10.17487/RFC4733, December 2006, 1293 . 1295 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1296 Keeping Alive the NAT Mappings Associated with RTP / RTP 1297 Control Protocol (RTCP) Flows", RFC 6263, 1298 DOI 10.17487/RFC6263, June 2011, 1299 . 1301 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1302 "Codec Control Messages in the RTP Audio-Visual Profile 1303 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1304 February 2008, . 1306 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1307 Media Control", RFC 5168, DOI 10.17487/RFC5168, March 1308 2008, . 1310 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 1311 Authoring and Versioning (WebDAV)", RFC 6352, 1312 DOI 10.17487/RFC6352, August 2011, 1313 . 1315 [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions 1316 to WebDAV (CalDAV) and vCard Extensions to WebDAV 1317 (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, 1318 . 1320 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 1321 DOI 10.17487/RFC7095, January 2014, 1322 . 1324 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1325 Indication Event Package for the Session Initiation 1326 Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 1327 2004, . 1329 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1330 Context for Internet Mail", RFC 3458, 1331 DOI 10.17487/RFC3458, January 2003, 1332 . 1334 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1335 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1336 2014, . 1338 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1339 "Recommendations for Secure Use of Transport Layer 1340 Security (TLS) and Datagram Transport Layer Security 1341 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1342 2015, . 1344 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1345 Communications Services in Support of Emergency Calling", 1346 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1347 . 1349 [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1350 J. Winterbottom, "Additional Data Related to an Emergency 1351 Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, 1352 . 1354 [I-D.ietf-rtcweb-overview] 1355 Alvestrand, H., "Overview: Real Time Protocols for 1356 Browser-based Applications", Work in Progress, Internet- 1357 Draft, draft-ietf-rtcweb-overview-19, 11 November 2017, 1358 . 1361 [I-D.ietf-rtcweb-rtp-usage] 1362 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1363 Communication (WebRTC): Media Transport and Use of RTP", 1364 Work in Progress, Internet-Draft, draft-ietf-rtcweb-rtp- 1365 usage-26, 17 March 2016, . 1368 [I-D.ietf-rtcweb-jsep] 1369 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 1370 Session Establishment Protocol", Work in Progress, 1371 Internet-Draft, draft-ietf-rtcweb-jsep-26, 27 February 1372 2019, . 1375 [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing 1376 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, 1377 . 1379 [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec 1380 Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 1381 . 1383 [I-D.ietf-rtcweb-transports] 1384 Alvestrand, H., "Transports for WebRTC", Work in Progress, 1385 Internet-Draft, draft-ietf-rtcweb-transports-17, 26 1386 October 2016, . 1389 [I-D.ietf-rtcweb-security-arch] 1390 Rescorla, E., "WebRTC Security Architecture", Work in 1391 Progress, Internet-Draft, draft-ietf-rtcweb-security-arch- 1392 20, 22 July 2019, . 1395 [I-D.yusef-sipcore-digest-scheme] 1396 Shekh-Yusef, R., "The Session Initiation Protocol (SIP) 1397 Digest Authentication Scheme", Work in Progress, Internet- 1398 Draft, draft-yusef-sipcore-digest-scheme-07, 1 April 2019, 1399 . 1402 [pip] SIPForum, "VRS US Providers Profile TWG-6-1.0", 2015, 1403 . 1406 Author's Address 1408 Brian Rosen 1409 470 Conrad Dr 1410 Mars, PA 16046 1411 United States of America 1413 Phone: +1 724 382 1051 1414 Email: br@brianrosen.net