idnits 2.17.1 draft-ietf-rum-rue-01.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 (4 November 2019) is 1636 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 900 -- Looks like a reference, but probably isn't: '2' on line 903 == Missing Reference: 'JCR' is mentioned on line 843, but not defined -- Looks like a reference, but probably isn't: '3' on line 906 -- Looks like a reference, but probably isn't: '4' on line 909 -- Looks like a reference, but probably isn't: '5' on line 912 -- Looks like a reference, but probably isn't: '6' on line 915 -- Looks like a reference, but probably isn't: '7' on line 918 -- Looks like a reference, but probably isn't: '8' on line 921 -- Looks like a reference, but probably isn't: '9' on line 924 -- Looks like a reference, but probably isn't: '10' on line 928 -- Looks like a reference, but probably isn't: '11' on line 931 -- Looks like a reference, but probably isn't: '12' on line 934 -- Looks like a reference, but probably isn't: '13' on line 939 -- Looks like a reference, but probably isn't: '14' on line 942 -- Looks like a reference, but probably isn't: '15' on line 945 -- Looks like a reference, but probably isn't: '16' on line 948 -- Looks like a reference, but probably isn't: '17' on line 951 ** 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: 6 errors (**), 0 flaws (~~), 4 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rum B. Rosen 3 Internet-Draft 4 November 2019 4 Intended status: Standards Track 5 Expires: 7 May 2020 7 Interoperability Profile for Relay User Equipment 8 draft-ietf-rum-rue-01 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 7 May 2020. 44 Copyright Notice 46 Copyright (c) 2019 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 . . . . . . . . . . 8 69 5.2.3. RUE Contact Information . . . . . . . . . . . . . . . 10 70 5.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10 71 5.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 10 72 5.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 11 73 5.4. URI Representation of Phone Numbers . . . . . . . . . . . 11 74 5.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 12 77 6.2. Text-Based Communication . . . . . . . . . . . . . . . . 12 78 6.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.6. Session Description Protocol . . . . . . . . . . . . . . 13 82 6.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6.8. Negative Acknowledgment, Packet Loss Indicator, and 84 Full Intraframe Request Features . . . . . . . . . . . . 13 85 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 7.1. CardDAV Login and Synchronization . . . . . . . . . . . . 13 87 7.2. Contacts Import/Export Service . . . . . . . . . . . . . 14 88 8. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 14 89 9. Provisioning and Provider Selection . . . . . . . . . . . . . 14 90 9.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 14 91 9.2. RUE Configuration Service . . . . . . . . . . . . . . . . 16 92 9.3. Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 95 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 13. Normative References . . . . . . . . . . . . . . . . . . . . 22 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 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 Sign language: A language that uses hand gestures and body language 205 to convey meaning including, but not limited to, American Sign 206 Language (ASL). 208 Subscriber: An individual who has registered with a Provider and who 209 obtains service by using relay user equipment. This is the 210 traditional telecom term for an end-user customer, which in our case 211 is a relay user. 213 Telecommunications relay services (TRS): Telephone transmission 214 services that provide the ability for an individual who has a hearing 215 impairment or speech impairment to engage in communication by wire or 216 radio with a hearing individual in a manner that is functionally 217 equivalent to the ability of an individual who does not have a 218 hearing impairment or speech impairment to communicate using voice 219 communication services by wire or radio. TRS includes services that 220 enable two-way communication between an individual who uses a 221 Telecommunications Device for the Deaf (TDD) or other non-voice 222 terminal device and an individual who does not use such a device. 224 Video relay service (VRS): A relay service for people with hearing or 225 speech disabilities who use sign language to communicate using video 226 equipment (video RUE) with other people in real time. The video link 227 allows the CA to view and interpret the subscriber's signed 228 conversation and relay the conversation back and forth with the other 229 party. 231 3. Requirements Language 233 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in [RFC2119] 237 4. General Requirements 239 All HTTP/HTTPS connections specified throughout this document MUST 240 use HTTPS. Both HTTPS and all SIP connections MUST use TLS 241 conforming to at least [RFC7525] and must support [RFC8446] 243 During the establishment of secure connections with a provider, the 244 RUE MAY be asked by the server for a client certificate. In that 245 case it SHOULD provide the provisioned client certificate (See 246 Section 9.2. Providers MAY reject requests that fail to provide a 247 recognized certificate. 249 All text data payloads not otherwise constrained by a specification 250 in another standards document MUST be encoded as Unicode UTF/8. 252 5. SIP Signaling 254 The RUE and Providers MUST conform to the following core SIP 255 standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP Servers), 256 [RFC3264] (Offer/Answer), [RFC3840] (User Agent Capabilities), 257 [RFC5626] (Outbound), [RFC4566] (Session Description Protocol), 258 [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP), [RFC6665] 259 (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop-Fix), 260 [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960] (Early 261 Media), and [RFC6442] (Geolocation Header). 263 In addition, the RUE MUST, and Providers MAY, conform to [RFC3327] 264 (Path), [RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER 265 Method), [RFC3891] (Replaces Header), [RFC3892] (Referred-By). 267 RUEs MUST include a "User-Agent" header field uniquely identifying 268 the RUE application, platform, and version in all SIP requests, and 269 MUST include a "Server" header field with the same content in SIP 270 responses. 272 5.1. Registration 274 The RUE MUST register with a SIP registrar, following [RFC3261] and 275 [RFC5626]. If the configuration (please refer to Section 11) 276 contains multiple "outbound-proxies", then the RUE MUST use them as 277 specified in [RFC5626] to establish multiple flows. 279 The request-URI for the REGISTER request MUST contain the "provider- 280 domain" from the configuration. The To-URI and From-URI MUST be 281 identical URIs, formatted as specified in Section 13, using the 282 "phone-number" and "provider-domain" from the configuration. 284 The RUE determines the URI to resolve by initially determining if an 285 outbound proxy is configured. If it is, the URI will be that of the 286 outbound proxy. If no outbound proxy is configured, the URI will be 287 the Request-URI from the REGISTER request. The RUE extracts the 288 domain from that URI and consults the DNS record for that domain. 289 The DNS entry MUST contain NAPTR records conforming to RFC3263. One 290 of those NAPTR records MUST specify TLS as the preferred transport 291 for SIP. For example, a DNS NAPTR query for "sip: 292 p1.red.example.netv" could return: 294 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net 295 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net 297 If the RUE receives a 439 (First Hop Lacks Outbound Support) response 298 to a REGISTER request, it MUST re-attempt registration without using 299 the outbound mechanism. 301 The registrar MAY authenticate using SIP MD5 digest authentication. 302 The credentials to be used (username and password) MUST be supplied 303 within the credentials section of the configuration and identified by 304 the realm the registrar uses in a digest challenge. This username/ 305 password combination SHOULD NOT be the same as that used for other 306 purposes, such as retrieving the RUE configuration or logging into 307 the Provider's customer service portal. Because MD5 is considered 308 insecure, [I-D.yusef-sipcore-digest-scheme] SHOULD be implemented by 309 both the RUE and Providers and SHA-based digest algorithms SHOULD be 310 used for digest authentication. 312 If the registration request fails with an indication that credentials 313 from the configuration are invalid, then the RUE SHOULD retrieve a 314 fresh version of the configuration. If credentials from a freshly 315 retrieved configuration are found to be invalid, then the RUE MUST 316 cease attempts to register and SHOULD inform the RUE User of the 317 problem. 319 Support for multiple simultaneous registrations by Providers is 320 OPTIONAL. 322 Multiple simultaneous RUE SIP registrations from different RUE 323 devices with the same SIP URI SHOULD be permitted by the Provider. 324 The Provider MAY limit the total number of simultaneous 325 registrations. When a new registration request is received that 326 results in exceeding the limit on simultaneous registrations, the 327 Provider MAY then prematurely terminate another registration; 328 however, it SHOULD NOT do this if it would disconnect an active call. 330 If a Provider prematurely terminates a registration to reduce the 331 total number of concurrent registrations with the same URI, it SHOULD 332 take some action to prevent the affected RUE from automatically re- 333 registering and re-triggering the condition. 335 5.2. Session Establishment 337 5.2.1. Normal Call Origination 339 After initial SIP registration, the RUE adheres to SIP [RFC3261] 340 basic call flows, as documented in [RFC3665]. 342 The RUE MUST route all calls through the outbound proxy of the 343 default Provider. 345 INVITE requests used to initiate calls SHOULD NOT contain Route 346 headers. Route headers MAY be included in one-stage dial-around 347 calls and emergency calls. The SIP URIs in the To field and the 348 Request-URI MUST be formatted as specified in subsection 6.4 using 349 the destination phone number. The domain field of the URIs SHOULD be 350 the "provider-domain" from the configuration (e.g., 351 sip:+13115552368@red.example.com;user=phone). The same exceptions 352 apply, including anonymous calls. 354 Anonymous calls MUST be supported by both the RUE and Providers. An 355 anonymous call is signaled per [RFC3323]. 357 The From-URI MUST be formatted as specified in Section 5.4, using the 358 phone-number and "provider-domain" from the configuration. It SHOULD 359 also contain the display-name from the configuration when present. 360 (Please refer to Section 9.2.) 362 Negotiated media MUST follow the guidelines specified in Section 6 of 363 this document. 365 To allow time to timeout an unanswered call and direct it to a 366 videomail server, the User Agent Client MUST NOT impose a time limit 367 less than the default SIP Invite transaction timeout of 3 minutes. 369 5.2.2. One-Stage Dial-Around Origination 371 Outbound dial-around calls allow a RUE user to select any Provider to 372 provide interpreting services for any call. "Two-stage" dial-around 373 calls involve the RUE calling a telephone number that reaches the 374 dial-around Provider and using signing or DTMF to provide the called 375 party telephone number. In two-stage dial-around, the To URI is the 376 URI of the dial-around Provider and the domain of the URI is the 377 Provider domain from the configuration. 379 One-stage dial-around is a method where the called party telephone 380 number is provided in the To URI and the Request-URI, using the 381 domain of the dial-around Provider. 383 For one-stage dial-around, the RUE MUST follow the procedures in 384 Section 5.2.1 with the following exception: the domain part of the 385 SIP URIs in the To field and the Request-URI MUST be the domain of 386 the dial-around Provider, discovered according to Section 9.1. 388 The following is a partial example of a one-stage dial-around call 389 from VRS user +1-555-222-0001 hosted by red.example.com to a hearing 390 user +1-555-123-4567 using dial-around to green.example.com for the 391 relay service. Only important details of the messages are shown and 392 many header fields have been omitted: 394 ,-+-. ,----+----. ,-----+-----. 395 |RUE| |Default | |Dial-Around| 396 | | |Provider | | Provider | 397 `-+-' `----+----' `-----+-----' 398 | | | 399 | [1] INVITE | | 400 |-------------->| [2] INVITE | 401 | |-------------->| 403 Message Details: 405 [1] INVITE Rue -> Default Provider 407 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 408 To: 409 From: "Bob Smith" 410 Route: sip:green.example.net 412 [2] INVITE Default Provider -> Dial-Around Provider 414 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 415 To: 416 From: "Bob Smith" sip:+18135551212@red.example.net;user=phone 417 P-Asserted-Identity: sip:+18135551212@red.example.net 419 Figure 1: One Stage Dial-Around 421 5.2.3. RUE Contact Information 423 To identify the owner of a RUE, the initial INVITE for a call from a 424 RUE, or the 200 OK accepting a call by a RUE, identifies the owner by 425 sending a Call-Info header with a purpose parameter of "rue-owner". 426 The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is 427 defined by [RFC2392] to locate message body parts. This URI type is 428 present in a SIP message to convey the RUE ownership information as a 429 MIME body. The form of the RUE ownership information is an xCard 430 [RFC6351]. Please refer to [RFC6442] for an example of using 431 Content-Indirect URLs in SIP messages. Note that use of the Content- 432 Indirect URL usually implies multiple message bodies ("mime/ 433 multipart"). 435 5.2.4. Incoming Calls 437 The RUE MUST accept inbound calls sent to it by the proxy mentioned 438 in the configuration. 440 If Multiple simultaneous RUE SIP registrations from different RUE 441 devices with the same SIP URI exist, the Provider MUST parallel fork 442 the call to all registered RUEs so that they ring at the same time. 443 The first RUE to reply with a 200 OK answers the call and the 444 Provider MUST CANCEL other call branches. 446 5.2.5. Emergency Calls 448 The RUE MUST comply with [RFC6881] for handling of emergency calls. 450 Providers MUST: 452 * Accept RUE emergency calls complying with the specifications in 453 this document; 455 * Recognize such calls as emergency calls and properly handle them 456 as such; 458 * Address other behavior not specified by RFC6881 as specified in 459 Section 5.2. 461 Specifically, if the emergency call is to be handled using existing 462 country specific procedures, the Provider is responsible for 463 modifying the INVITE to conform to the country-specific requirements. 464 In this case, location MAY be extracted from the RFC6881 conformant 465 INVITE and used to propagate it to the VPC where possible with the 466 emergency call. Because the RUE may have a more accurate and timely 467 location of the device than the typical manual entry location for 468 nomadic RUE devices, the RUE MAY send a Geolocation header containing 469 its location in the REGISTER request if the configuration specifies 470 it. The Provider MAY use that information to populate the location 471 of the device in the VPC before any emergency call. 473 5.3. Mid Call Signaling 475 The RUE and Providers MUST support re-INVITE to renegotiate media 476 session parameters (among other uses). Per Section 6.1, the RUE 477 MUST, and providers SHOULD, be able to support an INFO request for 478 full frame refresh for devices in a call with the RUE that do not 479 support RTCP mechanisms (please refer to Section 6.8). The RUE MUST 480 support an in-dialog REFER ([RFC3515] updated by [RFC7647] and 481 including support for norefersub per [RFC4488]) with the Replaces 482 header [RFC3891] to enable call transfer. 484 5.4. URI Representation of Phone Numbers 486 SIP URIs constructed from non-URI sources (dial strings) and sent to 487 SIP proxies by the RUE MUST be represented as follows, depending on 488 whether they can be represented as an E.164 number. 490 A dial string that can be written as an E.164 formatted phone number 491 MUST be represented as a SIP URI with a URI ";user=phone" tag. The 492 user part of the URI MUST be in conformance with 'global-number' 493 defined in [RFC3966]. The user part MUST NOT contain any 'visual- 494 separator' characters. 496 Dial strings that cannot be written as E.164 numbers MUST be 497 represented as dialstring URIs, as specified by [RFC4967], e.g., 498 sip:411@red.example.net;user=dialstring. 500 The domain part of Relay Service URIs and User Address of Records 501 (AoR) MUST (using resolve (in accord with [RFC3263]) to globally 502 routable IPv4 addresses. The AoRs MAY also resolve to IPv6 503 addresses. 505 5.5. Transport 507 The RUE and providers MUST conform to [I-D.ietf-rtcweb-transports] 508 with the understanding that this specification does not use the 509 WebRTC data channel. 511 The RUE and providers MUST support SIP outbound [RFC5626] (please 512 also refer to Section 5.1). 514 6. Media 516 This specification adopts the media specifications for WebRTC 517 ([I-D.ietf-rtcweb-overview]). Where WebRTC defines how interactive 518 media communications may be established using a browser as a client, 519 this specification assumes a normal SIP call. The RTP, RTCP, SDP and 520 specific media requirements specified for WebRTC are adopted for this 521 document. The RUE is a WebRTC non-browser" endpoint, except as noted 522 expressly below. 524 The following sections specify the WebRTC documents to which 525 conformance is required. "Mandatory to Implement" means a conforming 526 implementation must implement the specified capability. It does not 527 mean that the capabity must be used in every session. For example, 528 OPUS is a mandatory to implement audio codec, and all conforming 529 implementations must support OPUS. However, a call that originates 530 in the Public Switched Telephone Network, which only offers G.711 531 audio does not need to include the OPUS codec in the offer, since it 532 cannot be used with that call. 534 6.1. SRTP and SRTCP 536 The RUE and Providers MUST support [I-D.ietf-rtcweb-rtp-usage] with 537 the understanding that RUE does not specify an API and therefore 538 MediaStreamTracks are not used. Implementations MUST conform to 539 Section 6.4 of [I-D.ietf-rtcweb-security-arch]. 541 6.2. Text-Based Communication 543 The RUE MUST and Providers MUST support real-time text ([RFC4102] and 544 [RFC4103]) via T.140 media. One original and two redundant 545 generations MUST be transmitted and supported, with a 300 ms 546 transmission interval. Note that this is not how real time text is 547 transmitted in WebRTC and some form of transcoder would be required 548 to interwork real time text in the data channel of WebRTC to RFC4103 549 real time text. 551 6.3. Video 553 The RUE and Providers MUST conform to [RFC7742] with the exception 554 that, since backwards compatibility is desirable and older devices do 555 not support VP8, that only H.264, as specified in [RFC7742] is 556 Mandatory to Implement. 558 6.4. Audio 560 The RUE and Providers MUST conform to [RFC7874]. 562 6.5. DTMF Digits 564 The RUE and Providers MUST support the "audio/telephone-event" 565 [RFC4733] media type. They MUST support conveying event codes 0 566 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of 567 [RFC4733]. Handling of other tones is OPTIONAL. 569 6.6. Session Description Protocol 571 The SDP offers and answers MUST conform [I-D.ietf-rtcweb-jsep] with 572 the understanding that the RUE uses SIP transport for SDP. 574 6.7. Privacy 576 The RUE MUST be able to control privacy of the user by implementing a 577 one-way mute of audio and or video, without signaling, locally, but 578 MUST maintain any NAT bindings by periodically sending media packets 579 on all active media sessions containing silence/comfort noise/black 580 screen/etc. per [RFC6263]. 582 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full 583 Intraframe Request Features 585 NACK SHOULD be used when negotiated and conditions warrant its use. 586 Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be 587 preferred, as described in [RFC5104]. 589 FIR SHOULD be used only in situations where not sending a decoder 590 refresh point would render the video unusable for the users, as per 591 RFC5104 subsection 4.3.1.2. 593 For backwards compatibility with calling devices that do not support 594 the foregoing methods, the RUE MUST implement and use SIP INFO 595 messages to send and receive XML encoded Picture Fast Update messages 596 according to [RFC5168]. 598 7. Contacts 600 7.1. CardDAV Login and Synchronization 602 Support of CardDAV by Providers is OPTIONAL. 604 The RUE MUST and Providers MAY be able to synchronize the user's 605 contact directory between the RUE endpoint and one maintained by the 606 user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). 608 The configuration MAY supply a username and domain identifying a 609 CardDAV server and address book for this account. 611 To access the CardDAV server and address book, the RUE MUST follow 612 Section 6 of RFC6764, using the chosen username and domain in place 613 of an email address. If the request triggers a challenge for digest 614 authentication credentials, the RUE MUST attempt to continue using 615 matching "credentials" from the configuration. If no matching 616 credentials are configured, the RUE MUST use the SIP credentials from 617 the configuration. If the SIP credentials fail, the RUE MUST query 618 the user. 620 Synchronization using CardDAV MUST be a two-way synchronization 621 service, with proper handling of asynchronous adds, changes, and 622 deletes at either end of the transport channel. 624 7.2. Contacts Import/Export Service 626 Each Provider MUST supply a standard xCard import/export interface 627 and the RUE MUST be able to export/import the list of contacts in 628 xCard [RFC6351] XML format. 630 The RUE accesses this service via the "contacts" URI in the 631 configuration. The URL MUST resolve to identify a web server 632 resource that imports/exports contact lists for authorized users. 634 The RUE stores/retrieves the contact list (address book) by issuing 635 an HTTPS POST or GET request. If the request triggers a challenge 636 for digest authentication credentials, the RUE MUST attempt to 637 continue using matching "credentials" from the configuration. If no 638 credentials are configured, the RUE MUST query the user. 640 8. Mail Waiting Indicator (MWI) 642 Support of MWI by Providers is OPTIONAL 644 The RUE MUST and Providers SHOULD support subscriptions to "message- 645 summary" events [RFC3842] to the URI specified in the configuration 646 if the Provider supports message waiting indicator on any endpoint. 648 In notification bodies, videomail messages SHOULD be reported using 649 "message-context-class multimedia-message" defined in [RFC3458]. 651 9. Provisioning and Provider Selection 653 9.1. RUE Provider Selection 655 To allow the user to select a relay service, the RUE MAY obtain, on 656 startup, a list of Providers from a configured accessible URL. 658 The provider list, formatted as JSON, contains: 660 * Version: Specifies the version number of the Provider list format. 661 A new version number SHOULD only be used if the new version is not 662 backwards-compatible with the older version. A new version number 663 is not needed if new elements are optional and can be ignored by 664 older implementations. 666 * Providers: An array where each entry describes one Provider. Each 667 entry consists of the following items: 669 - name: This parameter contains the text label identifying the 670 Provider and is meant to be displayed to the human VRS user. 672 - domain: The domain parameter is used for configuration purposes 673 by the RUE (as discussed in Section 9.2) and as the domain to 674 use when targeting one-stage dial-around calls to this Provider 675 (as discussed in Section 5.2.2). 677 - operator: (OPTIONAL) The operator parameter is a SIP URL that 678 identifies the operator "front-door" that VRS users may contact 679 for manual (two-stage) dial-around calls. 681 The VRS user interacts with the RUE to select from the Provider list 682 one or more Providers with whom the user has already established an 683 account. 685 { 686 "version": 1, 687 "providers": [ 688 { 689 "name": "Red", 690 "domain": "red.example.net", 691 "operator": "sip:operator@red.example.net" 692 }, 693 { 694 "name": "Green", 695 "domain": "green.example.net", 696 "operator": "sip:+18885550123@green.example.net;user=phone" 697 }, 698 { 699 "name": "Blue", 700 "domain": "blue.example.net" 701 } 702 ] 703 } 705 Figure 2: Example of a Provider list JSON object 707 9.2. RUE Configuration Service 709 The RUE is provisioned with one or more URIs that may be queried for 710 configuration with HTTPS. 712 The data returned will include a set of key/value configuration 713 parameters to be used by the RUE, formatted as a JSON object and 714 identified by the associated [RFC7159] "application/json" MIME type, 715 to allow for other formats in the future. 717 The configuration data payload includes the following data items. 718 Items not noted as (OPTIONAL) are REQUIRED. If other unexpected 719 items are found, they MUST be ignored. 721 * version: Identifies the version of the configuration data format. 722 A new version number SHOULD only be used if the new version is not 723 backwards-compatible with the older version. A new version number 724 is not needed if new elements are optional and can be ignored by 725 older implementations. 727 * lifetime: Specifies how long (in seconds) the RUE MAY cache the 728 configuration values. Values may not be valid when lifetime 729 expires. Emergency Calls MUST continue to work. 731 * display-name: (OPTIONAL) A user-friendly name to identify the 732 subscriber when originating calls. 734 * phone-number: The telephone number (in E.164 format) assigned to 735 this subscriber. This becomes the user portion of the SIP URI 736 identifying the subscriber. 738 * provider-domain: The DNS domain name of the default Provider 739 servicing this subscriber. 741 * outbound-proxies: (OPTIONAL) A URI of a SIP proxy to be used when 742 sending requests to the Provider. 744 * mwi: (OPTIONAL) A URI identifying a SIP event server that 745 generates "message-summary" events for this subscriber. 747 * videomail: (OPTIONAL) A SIP URI that can be called to retrieve 748 videomail messages. 750 * contacts: An HTTPS URI that may be used to export (retrieve) the 751 subscriber's complete contact list managed by the Provider. 753 * carddav: (OPTIONAL) A username and domain name (separated by 754 ""@"") identifying a "CardDAV" server and user name that can be 755 used to synchronize the RUE's contact list with the contact list 756 managed by the Provider. 758 * sendLocationWithRegistration: True if the RUE should send a 759 Geolocation Header with REGISTER, false if it should not. 760 Defaults to false if not present. 762 * turn-servers: (OPTIONAL) An array of URLs identifying STUN and 763 TURN servers available for use by the RUE for establishing media 764 streams in calls via the Provider. 766 * credentials: (OPTIONAL) TBD 767 { 768 "version": 1, 769 "lifetime": 86400, 770 "display-name" : "Bob Smith", 771 "phone-number": "+18135551212", 772 "provider-domain": "red.example.net", 773 "outbound-proxies": [ 774 "sip:p1.red.example.net", 775 "sip:p2.red.example.net" 776 ], 777 "mwi": "sip:+18135551212@red.example.net", 778 "videomail": "sip:+18135551212@vm.red.example.net", 779 "contacts": "https://red.example.net:443/contacts/1dess45awd" 780 "carddav": "bob@red.example.com" , 781 "sendLocationWithRegistration": false, 782 "ice-servers": [ 783 {"stun:stun.l.google.com:19302" }, 784 {"turn:turn.red.example.net:3478"} 785 ], 786 "credentials": [ 787 { 788 "realm": "red.example.net", 789 "username": "bob", 790 "password": "reg-pw" 791 }, 792 { 793 "realm": "proxies.red.example.net", 794 "username": "bob", 795 "password": "proxy-pw" 796 }, 797 { 798 "realm": "cd.red.example.net", 799 "username": "bob", 800 "password": "cd-pw" 801 }, 802 { 803 "realm": "vm.red.example.net", 804 "username": "bob", 805 "password": "vm-pw" 806 }, 807 { 808 "realm": "stun-turn.red.example.net", 809 "username": "bob", 810 "password": "stun-turn-pw" 811 } 812 ] 813 } 814 Figure 3: Example JSON configuration payload 816 The wire format of the data is in keeping with the standard JSON 817 description in RFC7159. 819 The "lifetime" parameter in the configuration indicates how long the 820 RUE MAY cache the configuration values. If the RUE caches 821 configuration values, it MUST cryptographically protect them. The 822 RUE SHOULD retrieve a fresh copy of the configuration before the 823 lifetime expires or as soon as possible after it expires. The 824 lifetime is not guaranteed: the configuration may change before the 825 lifetime value expires. In that case, the Provider MAY indicate this 826 by generating authorization challenges to requests and/or prematurely 827 terminating a registration. 829 Note: In some cases, the RUE may successfully retrieve a fresh copy 830 of the configuration using digest credentials cached from the prior 831 retrieval. If this is not successful, then the RUE will need to ask 832 the user for the username and password. Unfortunately, this 833 authentication step might occur when the user is not present, 834 preventing SIP registration and thus incoming calls. To avoid this 835 situation, the RUE MAY retrieve a new copy of the configuration when 836 it knows the user is present, even if there is time before the 837 lifetime expires. 839 9.3. Schemas 841 The following JSON schemas are for the Provider List and the RUE 842 Configuration. These are represented using the JSON Content Rules 843 [JCR] schema notation. 845 { 846 "version": 1, 847 "providers": [ 848 1* 849 { 850 "name": string, 851 "domain": fqdn, 852 ?"operator": ; "front-door" access to provider 853 uri, ; (sip uri) 854 * /^.*$/ : any ; (allow future extensions) 855 } 856 ] , 857 * /^.*$/ : any ; (allow future extensions) 858 } 860 Figure 4: Provider List JSON Schema 862 { 863 "version": 1, ; Interface version 864 "lifetime": integer, ; Deadline (in seconds) for 865 ; refreshing this config without 866 ; user input. 867 "phone-number": /^\+[0-9]+$/ , ; E.164 phone number 868 ; for this user 869 ?"display-name" : string,; display name for From: header 870 "provider-domain": fqdn, ; SHOULD match that in Provider List 871 ?"outbound-proxies": [ 1* : uri ], ; sip URIs 872 ?"mwi": uri , ; sip URI for MWI subscriptions 873 ?"videomail": uri , ; sip URI for videomail retrieval 874 "contacts": uri , ; https URI for contact list retrieval 875 ?"carddav": /^[^@]+@[^@]+$/ , ; for contact list synch 876 ?"sendLocationWithRegistration": boolean , ; send location y/n 877 ?"ice-servers": ; (Required for ICE use) 878 [ 1* : uri ], ; (stun[s] & turn[s] URIs 879 ?"credentials": ; for digest authentication 880 [ 1* { 881 "realm": string, 882 "username": string, 883 "password": string 884 } ], 885 * /^.*$/ : any ; (allow future extensions) 886 } 888 Figure 5: RUE Configuration JSON Schema 890 The following illustrates the message flow for retrieving a RUE 891 automatic configuration using HTTPS Digest Authentication: 893 ,-. 894 `-' 895 /|\ ,---. ,---. ,------------. ,----------------. ,---. 896 | |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 897 / \ | | | | | | |Global Settings | | | 898 RUE User `-+-' `-+-' `-----+------' `--------+-------' `-+-' 899 | | | | | | 900 [1] Select a VRS Provider name | | | 901 | ------->| | | | | 902 | | | | | | 903 [2] NAPTR "SFUA.CFG" red.example.net | | 904 | |----->| | | | 905 | | | | | | 906 [3] NAPTR "!.*!https://server.red.example.net/!" | | 907 | |<-----| | | | 908 | | | | | | 909 [4] If NAPTR found, query DNS server.red.example.net | 910 | |----->| | | | 911 | | | | | | 912 [5] If NXDOMAIN, query DNS config.red.example.net | | 913 | | - - >| | | | 914 | | | | | | 915 [6] IP Address of Config Server | | | 916 | |<-----| | | | 917 | | | | | | 918 [7] Establish TLS connection | | | 919 | |<--------------->| | | 920 | | | | | | 921 [8] HTTP: https://config.red.example.net/v1 | | 922 | |---------------->| | | 923 | | | | | | 924 [9] HTTP: 401 Unauthorized | | | 925 WWW-Authenticate Digest realm="Y" qop="auth,auth-int" nonce=| 926 | |<----------------| | | 927 | | | | | | 928 [10] Query for userid/pw | | | 929 |<--------| | | | | 930 | | | | | | 931 [11] User="bob", pw="bob's global provider pw" | | 932 |-------->| | | | | 933 | | | | | | 934 [12] HTTP: https://config.red.example.net/v1 | | 935 | Authorization Digest username="bob" realm="Y" qop="auth" | 936 | nonce=... response="..." ... | | 937 | |---------------->| | | 938 | | | | | | 939 | [13] Find subscriber information for username="bob" | 940 | | | |----------------------------->| 941 | | | | | | 942 | [14] Subscriber specific configuration information | 943 | | | |<-----------------------------| 944 | | | | | | 945 | [15] Retrieve provider specific settings | 946 | | | |---------------->| | 947 | | | | | | 948 | [16] Provider configuration information | | 949 | | | |<----------------| | 950 | | | | | | 951 [17] 200 OK + JSON merge subscriber + provider configs | 952 | |<----------------| | | 953 | | | | | | 954 RUE User ,---. ,---. ,------------. ,----------------. ,---. 955 ,-. |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 956 `-' | | | | | | |Global Settings | | | 957 /|\ `-+-' `-+-' `-----+------' `--------+-------' `-+-' 958 | 959 / \ 961 Figure 6: RUE Configuration Retrieval 963 10. Acknowledgements 965 Brett Henderson and Jim Malloy provided many helpful edits to prior 966 versions of this document. 968 11. IANA Considerations 970 This memo includes no request to IANA. 972 12. Security Considerations 974 The RUE is required to communicate with servers on public IP 975 addresses and specific ports to perform its required functions. If 976 it is necessary for the RUE to function on a corporate or other 977 network that operates a default-deny firewall between the RUE and 978 these services, the user must arrange with their network manager for 979 passage of traffic through such a firewall in accordance with the 980 protocols and associated SRV records as exposed by the Provider. 981 Because VRS providers may use different ports for different services, 982 these port numbers may differ from Provider to Provider. 984 13. Normative References 986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 987 Requirement Levels", BCP 14, RFC 2119, 988 DOI 10.17487/RFC2119, March 1997, 989 . 991 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 992 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 993 . 995 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 996 A., Peterson, J., Sparks, R., Handley, M., and E. 997 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 998 DOI 10.17487/RFC3261, June 2002, 999 . 1001 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1002 Protocol (SIP): Locating SIP Servers", RFC 3263, 1003 DOI 10.17487/RFC3263, June 2002, 1004 . 1006 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1007 with Session Description Protocol (SDP)", RFC 3264, 1008 DOI 10.17487/RFC3264, June 2002, 1009 . 1011 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1012 "Indicating User Agent Capabilities in the Session 1013 Initiation Protocol (SIP)", RFC 3840, 1014 DOI 10.17487/RFC3840, August 2004, 1015 . 1017 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1018 "Managing Client-Initiated Connections in the Session 1019 Initiation Protocol (SIP)", RFC 5626, 1020 DOI 10.17487/RFC5626, October 2009, 1021 . 1023 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1024 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1025 July 2006, . 1027 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1028 Initiation Protocol (SIP)", RFC 3323, 1029 DOI 10.17487/RFC3323, November 2002, 1030 . 1032 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1033 in Session Description Protocol (SDP)", RFC 3605, 1034 DOI 10.17487/RFC3605, October 2003, 1035 . 1037 [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, 1038 DOI 10.17487/RFC6665, July 2012, 1039 . 1041 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1042 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1043 2002, . 1045 [RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. 1046 Campen, "Addressing an Amplification Vulnerability in 1047 Session Initiation Protocol (SIP) Forking Proxies", 1048 RFC 5393, DOI 10.17487/RFC5393, December 2008, 1049 . 1051 [RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing 1052 Record-Route Issues in the Session Initiation Protocol 1053 (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, 1054 . 1056 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 1057 "Essential Correction for IPv6 ABNF and URI Comparison in 1058 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 1059 . 1061 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1062 Tone Generation in the Session Initiation Protocol (SIP)", 1063 RFC 3960, DOI 10.17487/RFC3960, December 2004, 1064 . 1066 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1067 for the Session Initiation Protocol", RFC 6442, 1068 DOI 10.17487/RFC6442, December 2011, 1069 . 1071 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1072 (SIP) Extension Header Field for Registering Non-Adjacent 1073 Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, 1074 . 1076 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1077 (ICE): A Protocol for Network Address Translator (NAT) 1078 Traversal for Offer/Answer Protocols", RFC 5245, 1079 DOI 10.17487/RFC5245, April 2010, 1080 . 1082 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1083 Header Field for the Session Initiation Protocol (SIP)", 1084 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1085 . 1087 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1088 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1089 . 1091 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 1092 (SIP) REFER Method Implicit Subscription", RFC 4488, 1093 DOI 10.17487/RFC4488, May 2006, 1094 . 1096 [RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of 1097 REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, 1098 September 2015, . 1100 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1101 Protocol (SIP) "Replaces" Header", RFC 3891, 1102 DOI 10.17487/RFC3891, September 2004, 1103 . 1105 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 1106 Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, 1107 September 2004, . 1109 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1110 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1111 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1112 December 2003, . 1114 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1115 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 1116 . 1118 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1119 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1120 . 1122 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1123 Initiation Protocol Uniform Resource Identifier", 1124 RFC 4967, DOI 10.17487/RFC4967, July 2007, 1125 . 1127 [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", 1128 RFC 4102, DOI 10.17487/RFC4102, June 2005, 1129 . 1131 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1132 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 1133 . 1135 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1136 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1137 DOI 10.17487/RFC4733, December 2006, 1138 . 1140 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1141 Keeping Alive the NAT Mappings Associated with RTP / RTP 1142 Control Protocol (RTCP) Flows", RFC 6263, 1143 DOI 10.17487/RFC6263, June 2011, 1144 . 1146 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1147 "Codec Control Messages in the RTP Audio-Visual Profile 1148 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1149 February 2008, . 1151 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1152 Media Control", RFC 5168, DOI 10.17487/RFC5168, March 1153 2008, . 1155 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 1156 Authoring and Versioning (WebDAV)", RFC 6352, 1157 DOI 10.17487/RFC6352, August 2011, 1158 . 1160 [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions 1161 to WebDAV (CalDAV) and vCard Extensions to WebDAV 1162 (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, 1163 . 1165 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 1166 RFC 6351, DOI 10.17487/RFC6351, August 2011, 1167 . 1169 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1170 Indication Event Package for the Session Initiation 1171 Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 1172 2004, . 1174 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1175 Context for Internet Mail", RFC 3458, 1176 DOI 10.17487/RFC3458, January 2003, 1177 . 1179 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1180 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1181 2014, . 1183 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1184 "Recommendations for Secure Use of Transport Layer 1185 Security (TLS) and Datagram Transport Layer Security 1186 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1187 2015, . 1189 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1190 Communications Services in Support of Emergency Calling", 1191 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1192 . 1194 [I-D.ietf-rtcweb-overview] 1195 Alvestrand, H., "Overview: Real Time Protocols for 1196 Browser-based Applications", Work in Progress, Internet- 1197 Draft, draft-ietf-rtcweb-overview-19, 11 November 2017, 1198 . 1201 [I-D.ietf-rtcweb-rtp-usage] 1202 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1203 Communication (WebRTC): Media Transport and Use of RTP", 1204 Work in Progress, Internet-Draft, draft-ietf-rtcweb-rtp- 1205 usage-26, 17 March 2016, . 1208 [I-D.ietf-rtcweb-jsep] 1209 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 1210 Session Establishment Protocol", Work in Progress, 1211 Internet-Draft, draft-ietf-rtcweb-jsep-26, 27 February 1212 2019, . 1215 [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing 1216 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, 1217 . 1219 [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec 1220 Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 1221 . 1223 [I-D.ietf-rtcweb-transports] 1224 Alvestrand, H., "Transports for WebRTC", Work in Progress, 1225 Internet-Draft, draft-ietf-rtcweb-transports-17, 26 1226 October 2016, . 1229 [I-D.ietf-rtcweb-security-arch] 1230 Rescorla, E., "WebRTC Security Architecture", Work in 1231 Progress, Internet-Draft, draft-ietf-rtcweb-security-arch- 1232 20, 22 July 2019, . 1235 [I-D.yusef-sipcore-digest-scheme] 1236 Shekh-Yusef, R., "The Session Initiation Protocol (SIP) 1237 Digest Authentication Scheme", Work in Progress, Internet- 1238 Draft, draft-yusef-sipcore-digest-scheme-07, 1 April 2019, 1239 . 1242 [pip] SIPForum, "VRS US Providers Profile TWG-6-1.0", 2015, 1243 . 1246 Author's Address 1248 Brian Rosen 1249 470 Conrad Dr 1250 Mars, PA 16046 1251 United States of America 1253 Phone: +1 724 382 1051 1254 Email: br@brianrosen.net