idnits 2.17.1 draft-ietf-rum-rue-00.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 is 1 instance of too long lines in the document, the longest one being 1 character 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 (24 September 2019) is 1676 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 890 -- Looks like a reference, but probably isn't: '2' on line 893 == Missing Reference: 'JCR' is mentioned on line 833, but not defined -- Looks like a reference, but probably isn't: '3' on line 896 -- Looks like a reference, but probably isn't: '4' on line 899 -- Looks like a reference, but probably isn't: '5' on line 902 -- Looks like a reference, but probably isn't: '6' on line 905 -- Looks like a reference, but probably isn't: '7' on line 908 -- Looks like a reference, but probably isn't: '8' on line 911 -- Looks like a reference, but probably isn't: '9' on line 914 -- Looks like a reference, but probably isn't: '10' on line 918 -- Looks like a reference, but probably isn't: '11' on line 921 -- Looks like a reference, but probably isn't: '12' on line 924 -- Looks like a reference, but probably isn't: '13' on line 929 -- Looks like a reference, but probably isn't: '14' on line 932 -- Looks like a reference, but probably isn't: '15' on line 935 -- Looks like a reference, but probably isn't: '16' on line 938 -- Looks like a reference, but probably isn't: '17' on line 941 -- Possible downref: Normative reference to a draft: ref. 'I-D.yusef-sipcore-digest-scheme' ** Downref: Normative reference to an Informational RFC: RFC 3960 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 5168 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 7 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 24 September 2019 4 Intended status: Standards Track 5 Expires: 27 March 2020 7 Interoperability Profile for Relay User Equipment 8 draft-ietf-rum-rue-00 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 27 March 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 . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . 15 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 following sections specify the WebRTC documents to 522 which conformance is required. 524 6.1. SRTP and SRTCP 526 The RUE and Providers MUST support [I-D.ietf-rtcweb-rtp-usage] with 527 the understanding that RUE does not specify an API and therefore 528 MediaStreamTracks are not used. Implementations MUST conform to 529 Section 6.4 of [I-D.ietf-rtcweb-security-arch]. 531 6.2. Text-Based Communication 533 The RUE MUST and Providers MUST support real-time text ([RFC4102] and 534 [RFC4103]) via T.140 media. One original and two redundant 535 generations MUST be transmitted and supported, with a 300 ms 536 transmission interval. Note that this is not how real time text is 537 transmitted in WebRTC and some form of transcoder would be required 538 to interwork real time text in the data channel of WebRTC to RFC4103 539 real time text. 541 6.3. Video 543 The RUE and Providers MUST conform to [RFC7742] with the exception 544 that, since backwards compatibility is desirable and older devices do 545 not support VP8, that only H.264, as specified in [RFC7742] is 546 Mandatory to Implement. 548 6.4. Audio 550 The RUE and Providers MUST conform to [RFC7874]. 552 6.5. DTMF Digits 554 The RUE and Providers MUST support the "audio/telephone-event" 555 [RFC4733] media type. They MUST support conveying event codes 0 556 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of 557 [RFC4733]. Handling of other tones is OPTIONAL. 559 6.6. Session Description Protocol 561 The SDP offers and answers MUST conform [I-D.ietf-rtcweb-jsep] with 562 the understanding that the RUE uses SIP transport for SDP. 564 6.7. Privacy 566 The RUE MUST be able to control privacy of the user by implementing a 567 one-way mute of audio and or video, without signaling, locally, but 568 MUST maintain any NAT bindings by periodically sending media packets 569 on all active media sessions containing silence/comfort noise/black 570 screen/etc. per [RFC6263]. 572 6.8. Negative Acknowledgment, Packet Loss Indicator, and Full Intraframe 573 Request Features 575 NACK SHOULD be used when negotiated and conditions warrant its use. 576 Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be 577 preferred, as described in [RFC5104]. 579 FIR SHOULD be used only in situations where not sending a decoder 580 refresh point would render the video unusable for the users, as per 581 RFC5104 subsection 4.3.1.2. 583 For backwards compatibility with calling devices that do not support 584 the foregoing methods, the RUE MUST implement and use SIP INFO 585 messages to send and receive XML encoded Picture Fast Update messages 586 according to [RFC5168]. 588 7. Contacts 590 7.1. CardDAV Login and Synchronization 592 Support of CardDAV by Providers is OPTIONAL. 594 The RUE MUST and Providers MAY be able to synchronize the user's 595 contact directory between the RUE endpoint and one maintained by the 596 user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). 598 The configuration MAY supply a username and domain identifying a 599 CardDAV server and address book for this account. 601 To access the CardDAV server and address book, the RUE MUST follow 602 Section 6 of RFC6764, using the chosen username and domain in place 603 of an email address. If the request triggers a challenge for digest 604 authentication credentials, the RUE MUST attempt to continue using 605 matching "credentials" from the configuration. If no matching 606 credentials are configured, the RUE MUST use the SIP credentials from 607 the configuration. If the SIP credentials fail, the RUE MUST query 608 the user. 610 Synchronization using CardDAV MUST be a two-way synchronization 611 service, with proper handling of asynchronous adds, changes, and 612 deletes at either end of the transport channel. 614 7.2. Contacts Import/Export Service 616 Each Provider MUST supply a standard xCard import/export interface 617 and the RUE MUST be able to export/import the list of contacts in 618 xCard [RFC6351] XML format. 620 The RUE accesses this service via the "contacts" URI in the 621 configuration. The URL MUST resolve to identify a web server 622 resource that imports/exports contact lists for authorized users. 624 The RUE stores/retrieves the contact list (address book) by issuing 625 an HTTPS POST or GET request. If the request triggers a challenge 626 for digest authentication credentials, the RUE MUST attempt to 627 continue using matching "credentials" from the configuration. If no 628 credentials are configured, the RUE MUST query the user. 630 8. Mail Waiting Indicator (MWI) 632 Support of MWI by Providers is OPTIONAL 634 The RUE MUST and Providers SHOULD support subscriptions to "message- 635 summary" events [RFC3842] to the URI specified in the configuration 636 if the Provider supports message waiting indicator on any endpoint. 638 In notification bodies, videomail messages SHOULD be reported using 639 "message-context-class multimedia-message" defined in [RFC3458]. 641 9. Provisioning and Provider Selection 643 9.1. RUE Provider Selection 645 To allow the user to select a relay service, the RUE MAY obtain, on 646 startup, a list of Providers from a configured accessible URL. 648 The provider list, formatted as JSON, contains: 650 * Version: Specifies the version number of the Provider list format. 651 A new version number SHOULD only be used if the new version is not 652 backwards-compatible with the older version. A new version number 653 is not needed if new elements are optional and can be ignored by 654 older implementations. 656 * Providers: An array where each entry describes one Provider. Each 657 entry consists of the following items: 659 - name: This parameter contains the text label identifying the 660 Provider and is meant to be displayed to the human VRS user. 662 - domain: The domain parameter is used for configuration purposes 663 by the RUE (as discussed in Section 9.2) and as the domain to 664 use when targeting one-stage dial-around calls to this Provider 665 (as discussed in Section 5.2.2). 667 - operator: (OPTIONAL) The operator parameter is a SIP URL that 668 identifies the operator "front-door" that VRS users may contact 669 for manual (two-stage) dial-around calls. 671 The VRS user interacts with the RUE to select from the Provider list 672 one or more Providers with whom the user has already established an 673 account. 675 { 676 "version": 1, 677 "providers": [ 678 { 679 "name": "Red", 680 "domain": "red.example.net", 681 "operator": "sip:operator@red.example.net" 682 }, 683 { 684 "name": "Green", 685 "domain": "green.example.net", 686 "operator": "sip:+18885550123@green.example.net;user=phone" 687 }, 688 { 689 "name": "Blue", 690 "domain": "blue.example.net" 691 } 692 ] 693 } 695 Figure 2: Example of a Provider list JSON object 697 9.2. RUE Configuration Service 699 The RUE is provisioned with one or more URIs that may be queried for 700 configuration with HTTPS. 702 The data returned will include a set of key/value configuration 703 parameters to be used by the RUE, formatted as a JSON object and 704 identified by the associated [RFC7159] "application/json" MIME type, 705 to allow for other formats in the future. 707 The configuration data payload includes the following data items. 708 Items not noted as (OPTIONAL) are REQUIRED. If other unexpected 709 items are found, they MUST be ignored. 711 * version: Identifies the version of the configuration data format. 712 A new version number SHOULD only be used if the new version is not 713 backwards-compatible with the older version. A new version number 714 is not needed if new elements are optional and can be ignored by 715 older implementations. 717 * lifetime: Specifies how long (in seconds) the RUE MAY cache the 718 configuration values. Values may not be valid when lifetime 719 expires. Emergency Calls MUST continue to work. 721 * display-name: (OPTIONAL) A user-friendly name to identify the 722 subscriber when originating calls. 724 * phone-number: The telephone number (in E.164 format) assigned to 725 this subscriber. This becomes the user portion of the SIP URI 726 identifying the subscriber. 728 * provider-domain: The DNS domain name of the default Provider 729 servicing this subscriber. 731 * outbound-proxies: (OPTIONAL) A URI of a SIP proxy to be used when 732 sending requests to the Provider. 734 * mwi: (OPTIONAL) A URI identifying a SIP event server that 735 generates "message-summary" events for this subscriber. 737 * videomail: (OPTIONAL) A SIP URI that can be called to retrieve 738 videomail messages. 740 * contacts: An HTTPS URI that may be used to export (retrieve) the 741 subscriber's complete contact list managed by the Provider. 743 * carddav: (OPTIONAL) A username and domain name (separated by 744 ""@"") identifying a "CardDAV" server and user name that can be 745 used to synchronize the RUE's contact list with the contact list 746 managed by the Provider. 748 * sendLocationWithRegistration: True if the RUE should send a 749 Geolocation Header with REGISTER, false if it should not. 750 Defaults to false if not present. 752 * turn-servers: (OPTIONAL) An array of URLs identifying STUN and 753 TURN servers available for use by the RUE for establishing media 754 streams in calls via the Provider. 756 * credentials: (OPTIONAL) TBD 757 { 758 "version": 1, 759 "lifetime": 86400, 760 "display-name" : "Bob Smith", 761 "phone-number": "+18135551212", 762 "provider-domain": "red.example.net", 763 "outbound-proxies": [ 764 "sip:p1.red.example.net", 765 "sip:p2.red.example.net" 766 ], 767 "mwi": "sip:+18135551212@red.example.net", 768 "videomail": "sip:+18135551212@vm.red.example.net", 769 "contacts": "https://red.example.net:443/contacts/1dess45awd" 770 "carddav": "bob@red.example.com" , 771 "sendLocationWithRegistration": false, 772 "ice-servers": [ 773 {"stun:stun.l.google.com:19302" }, 774 {"turn:turn.red.example.net:3478"} 775 ], 776 "credentials": [ 777 { 778 "realm": "red.example.net", 779 "username": "bob", 780 "password": "reg-pw" 781 }, 782 { 783 "realm": "proxies.red.example.net", 784 "username": "bob", 785 "password": "proxy-pw" 786 }, 787 { 788 "realm": "cd.red.example.net", 789 "username": "bob", 790 "password": "cd-pw" 791 }, 792 { 793 "realm": "vm.red.example.net", 794 "username": "bob", 795 "password": "vm-pw" 796 }, 797 { 798 "realm": "stun-turn.red.example.net", 799 "username": "bob", 800 "password": "stun-turn-pw" 801 } 802 ] 803 } 804 Figure 3: Example JSON configuration payload 806 The wire format of the data is in keeping with the standard JSON 807 description in RFC7159. 809 The "lifetime" parameter in the configuration indicates how long the 810 RUE MAY cache the configuration values. If the RUE caches 811 configuration values, it MUST cryptographically protect them. The 812 RUE SHOULD retrieve a fresh copy of the configuration before the 813 lifetime expires or as soon as possible after it expires. The 814 lifetime is not guaranteed: the configuration may change before the 815 lifetime value expires. In that case, the Provider MAY indicate this 816 by generating authorization challenges to requests and/or prematurely 817 terminating a registration. 819 Note: In some cases, the RUE may successfully retrieve a fresh copy 820 of the configuration using digest credentials cached from the prior 821 retrieval. If this is not successful, then the RUE will need to ask 822 the user for the username and password. Unfortunately, this 823 authentication step might occur when the user is not present, 824 preventing SIP registration and thus incoming calls. To avoid this 825 situation, the RUE MAY retrieve a new copy of the configuration when 826 it knows the user is present, even if there is time before the 827 lifetime expires. 829 9.3. Schemas 831 The following JSON schemas are for the Provider List and the RUE 832 Configuration. These are represented using the JSON Content Rules 833 [JCR] schema notation. 835 { 836 "version": 1, 837 "providers": [ 838 1* 839 { 840 "name": string, 841 "domain": fqdn, 842 ?"operator": ; "front-door" access to provider 843 uri, ; (sip uri) 844 * /^.*$/ : any ; (allow future extensions) 845 } 846 ] , 847 * /^.*$/ : any ; (allow future extensions) 848 } 850 Figure 4: Provider List JSON Schema 852 { 853 "version": 1, ; Interface version 854 "lifetime": integer, ; Deadline (in seconds) for 855 ; refreshing this config without 856 ; user input. 857 "phone-number": /^\+[0-9]+$/ , ; E.164 phone number 858 ; for this user 859 ?"display-name" : string,; display name for From: header 860 "provider-domain": fqdn, ; SHOULD match that in Provider List 861 ?"outbound-proxies": [ 1* : uri ], ; sip URIs 862 ?"mwi": uri , ; sip URI for MWI subscriptions 863 ?"videomail": uri , ; sip URI for videomail retrieval 864 "contacts": uri , ; https URI for contact list retrieval 865 ?"carddav": /^[^@]+@[^@]+$/ , ; for contact list synch 866 ?"sendLocationWithRegistration": boolean , ; send location y/n 867 ?"ice-servers": ; (Required for ICE use) 868 [ 1* : uri ], ; (stun[s] & turn[s] URIs 869 ?"credentials": ; for digest authentication 870 [ 1* { 871 "realm": string, 872 "username": string, 873 "password": string 874 } ], 875 * /^.*$/ : any ; (allow future extensions) 876 } 878 Figure 5: RUE Configuration JSON Schema 880 The following illustrates the message flow for retrieving a RUE 881 automatic configuration using HTTPS Digest Authentication: 883 ,-. 884 `-' 885 /|\ ,---. ,---. ,------------. ,----------------. ,---. 886 | |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 887 / \ | | | | | | |Global Settings | | | 888 RUE User `-+-' `-+-' `-----+------' `--------+-------' `-+-' 889 | | | | | | 890 [1] Select a VRS Provider name | | | 891 | ------->| | | | | 892 | | | | | | 893 [2] NAPTR "SFUA.CFG" red.example.net | | 894 | |----->| | | | 895 | | | | | | 896 [3] NAPTR "!.*!https://server.red.example.net/!" | | 897 | |<-----| | | | 898 | | | | | | 899 [4] If NAPTR found, query DNS server.red.example.net | 900 | |----->| | | | 901 | | | | | | 902 [5] If NXDOMAIN, query DNS config.red.example.net | | 903 | | - - >| | | | 904 | | | | | | 905 [6] IP Address of Config Server | | | 906 | |<-----| | | | 907 | | | | | | 908 [7] Establish TLS connection | | | 909 | |<--------------->| | | 910 | | | | | | 911 [8] HTTP: https://config.red.example.net/v1 | | 912 | |---------------->| | | 913 | | | | | | 914 [9] HTTP: 401 Unauthorized | | | 915 WWW-Authenticate Digest realm="Y" qop="auth,auth-int" nonce=| 916 | |<----------------| | | 917 | | | | | | 918 [10] Query for userid/pw | | | 919 |<--------| | | | | 920 | | | | | | 921 [11] User="bob", pw="bob's global provider pw" | | 922 |-------->| | | | | 923 | | | | | | 924 [12] HTTP: https://config.red.example.net/v1 | | 925 | Authorization Digest username="bob" realm="Y" qop="auth" | 926 | nonce=... response="..." ... | | 927 | |---------------->| | | 928 | | | | | | 929 | [13] Find subscriber information for username="bob" | 930 | | | |----------------------------->| 931 | | | | | | 932 | [14] Subscriber specific configuration information | 933 | | | |<-----------------------------| 934 | | | | | | 935 | [15] Retrieve provider specific settings | 936 | | | |---------------->| | 937 | | | | | | 938 | [16] Provider configuration information | | 939 | | | |<----------------| | 940 | | | | | | 941 [17] 200 OK + JSON merge subscriber + provider configs | 942 | |<----------------| | | 943 | | | | | | 944 RUE User ,---. ,---. ,------------. ,----------------. ,---. 945 ,-. |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 946 `-' | | | | | | |Global Settings | | | 947 /|\ `-+-' `-+-' `-----+------' `--------+-------' `-+-' 948 | 949 / \ 951 Figure 6: RUE Configuration Retrieval 953 10. Acknowledgements 955 Brett Henderson and Jim Malloy provided many helpful edits to prior 956 versions of this document. 958 11. IANA Considerations 960 This memo includes no request to IANA. 962 12. Security Considerations 964 The RUE is required to communicate with servers on public IP 965 addresses and specific ports to perform its required functions. If 966 it is necessary for the RUE to function on a corporate or other 967 network that operates a default-deny firewall between the RUE and 968 these services, the user must arrange with their network manager for 969 passage of traffic through such a firewall in accordance with the 970 protocols and associated SRV records as exposed by the Provider. 971 Because VRS providers may use different ports for different services, 972 these port numbers may differ from Provider to Provider. 974 13. Normative References 976 [I-D.ietf-rtcweb-jsep] 977 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 978 Session Establishment Protocol", Internet-Draft, draft- 979 ietf-rtcweb-jsep-26, 27 February 2019, 980 . 983 [I-D.ietf-rtcweb-overview] 984 Alvestrand, H., "Overview: Real Time Protocols for 985 Browser-based Applications", Internet-Draft, draft-ietf- 986 rtcweb-overview-19, 11 November 2017, 987 . 990 [I-D.ietf-rtcweb-rtp-usage] 991 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 992 Communication (WebRTC): Media Transport and Use of RTP", 993 Internet-Draft, draft-ietf-rtcweb-rtp-usage-26, 17 March 994 2016, 995 . 998 [I-D.ietf-rtcweb-security-arch] 999 Rescorla, E., "WebRTC Security Architecture", Internet- 1000 Draft, draft-ietf-rtcweb-security-arch-20, 22 July 2019, 1001 . 1004 [I-D.ietf-rtcweb-transports] 1005 Alvestrand, H., "Transports for WebRTC", Internet-Draft, 1006 draft-ietf-rtcweb-transports-17, 26 October 2016, 1007 . 1010 [I-D.yusef-sipcore-digest-scheme] 1011 Shekh-Yusef, R., "The Session Initiation Protocol (SIP) 1012 Digest Authentication Scheme", Internet-Draft, draft- 1013 yusef-sipcore-digest-scheme-07, 1 April 2019, 1014 . 1017 [pip] SIPForum, "VRS US Providers Profile TWG-6-1.0", 2015, 1018 . 1021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1022 Requirement Levels", BCP 14, RFC 2119, 1023 DOI 10.17487/RFC2119, March 1997, 1024 . 1026 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1027 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 1028 . 1030 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1031 A., Peterson, J., Sparks, R., Handley, M., and E. 1032 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1033 DOI 10.17487/RFC3261, June 2002, 1034 . 1036 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1037 Protocol (SIP): Locating SIP Servers", RFC 3263, 1038 DOI 10.17487/RFC3263, June 2002, 1039 . 1041 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1042 with Session Description Protocol (SDP)", RFC 3264, 1043 DOI 10.17487/RFC3264, June 2002, 1044 . 1046 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1047 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1048 2002, . 1050 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1051 Initiation Protocol (SIP)", RFC 3323, 1052 DOI 10.17487/RFC3323, November 2002, 1053 . 1055 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1056 Header Field for the Session Initiation Protocol (SIP)", 1057 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1058 . 1060 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1061 (SIP) Extension Header Field for Registering Non-Adjacent 1062 Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, 1063 . 1065 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1066 Context for Internet Mail", RFC 3458, 1067 DOI 10.17487/RFC3458, January 2003, 1068 . 1070 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1071 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1072 . 1074 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1075 in Session Description Protocol (SDP)", RFC 3605, 1076 DOI 10.17487/RFC3605, October 2003, 1077 . 1079 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1080 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1081 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1082 December 2003, . 1084 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1085 "Indicating User Agent Capabilities in the Session 1086 Initiation Protocol (SIP)", RFC 3840, 1087 DOI 10.17487/RFC3840, August 2004, 1088 . 1090 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1091 Indication Event Package for the Session Initiation 1092 Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 1093 2004, . 1095 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1096 Protocol (SIP) "Replaces" Header", RFC 3891, 1097 DOI 10.17487/RFC3891, September 2004, 1098 . 1100 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 1101 Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, 1102 September 2004, . 1104 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1105 Tone Generation in the Session Initiation Protocol (SIP)", 1106 RFC 3960, DOI 10.17487/RFC3960, December 2004, 1107 . 1109 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1110 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1111 . 1113 [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", 1114 RFC 4102, DOI 10.17487/RFC4102, June 2005, 1115 . 1117 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1118 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 1119 . 1121 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 1122 (SIP) REFER Method Implicit Subscription", RFC 4488, 1123 DOI 10.17487/RFC4488, May 2006, 1124 . 1126 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1127 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1128 July 2006, . 1130 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1131 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1132 DOI 10.17487/RFC4733, December 2006, 1133 . 1135 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1136 Initiation Protocol Uniform Resource Identifier", 1137 RFC 4967, DOI 10.17487/RFC4967, July 2007, 1138 . 1140 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1141 "Codec Control Messages in the RTP Audio-Visual Profile 1142 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1143 February 2008, . 1145 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1146 Media Control", RFC 5168, DOI 10.17487/RFC5168, March 1147 2008, . 1149 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1150 (ICE): A Protocol for Network Address Translator (NAT) 1151 Traversal for Offer/Answer Protocols", RFC 5245, 1152 DOI 10.17487/RFC5245, April 2010, 1153 . 1155 [RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. 1156 Campen, "Addressing an Amplification Vulnerability in 1157 Session Initiation Protocol (SIP) Forking Proxies", 1158 RFC 5393, DOI 10.17487/RFC5393, December 2008, 1159 . 1161 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1162 "Managing Client-Initiated Connections in the Session 1163 Initiation Protocol (SIP)", RFC 5626, 1164 DOI 10.17487/RFC5626, October 2009, 1165 . 1167 [RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing 1168 Record-Route Issues in the Session Initiation Protocol 1169 (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, 1170 . 1172 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 1173 "Essential Correction for IPv6 ABNF and URI Comparison in 1174 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 1175 . 1177 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1178 Keeping Alive the NAT Mappings Associated with RTP / RTP 1179 Control Protocol (RTCP) Flows", RFC 6263, 1180 DOI 10.17487/RFC6263, June 2011, 1181 . 1183 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 1184 RFC 6351, DOI 10.17487/RFC6351, August 2011, 1185 . 1187 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 1188 Authoring and Versioning (WebDAV)", RFC 6352, 1189 DOI 10.17487/RFC6352, August 2011, 1190 . 1192 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1193 for the Session Initiation Protocol", RFC 6442, 1194 DOI 10.17487/RFC6442, December 2011, 1195 . 1197 [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, 1198 DOI 10.17487/RFC6665, July 2012, 1199 . 1201 [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions 1202 to WebDAV (CalDAV) and vCard Extensions to WebDAV 1203 (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, 1204 . 1206 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1207 Communications Services in Support of Emergency Calling", 1208 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1209 . 1211 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1212 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1213 2014, . 1215 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1216 "Recommendations for Secure Use of Transport Layer 1217 Security (TLS) and Datagram Transport Layer Security 1218 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1219 2015, . 1221 [RFC7647] Sparks, R. and A.B. Roach, "Clarifications for the Use of 1222 REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, 1223 September 2015, . 1225 [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec 1226 Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 1227 . 1229 [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing 1230 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, 1231 . 1233 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1234 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1235 . 1237 Author's Address 1239 Brian Rosen 1240 470 Conrad Dr 1241 Mars, PA 16046 1242 United States of America 1244 Phone: +1 724 382 1051 1245 Email: br@brianrosen.net