idnits 2.17.1 draft-rosen-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 (August 7, 2019) is 1695 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 910 -- Looks like a reference, but probably isn't: '2' on line 913 == Missing Reference: 'JCR' is mentioned on line 853, but not defined -- Looks like a reference, but probably isn't: '3' on line 916 -- Looks like a reference, but probably isn't: '4' on line 919 -- Looks like a reference, but probably isn't: '5' on line 922 -- Looks like a reference, but probably isn't: '6' on line 925 -- Looks like a reference, but probably isn't: '7' on line 928 -- Looks like a reference, but probably isn't: '8' on line 931 -- Looks like a reference, but probably isn't: '9' on line 934 -- Looks like a reference, but probably isn't: '10' on line 938 -- Looks like a reference, but probably isn't: '11' on line 941 -- Looks like a reference, but probably isn't: '12' on line 944 -- Looks like a reference, but probably isn't: '13' on line 949 -- Looks like a reference, but probably isn't: '14' on line 952 -- Looks like a reference, but probably isn't: '15' on line 955 -- Looks like a reference, but probably isn't: '16' on line 958 -- Looks like a reference, but probably isn't: '17' on line 961 == Unused Reference: 'RFC3550' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC4585' is defined on line 1140, but no explicit reference was found in the text == Unused Reference: 'RFC4961' is defined on line 1151, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 1175, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 1180, but no explicit reference was found in the text == Unused Reference: 'RFC5763' is defined on line 1202, but no explicit reference was found in the text == Unused Reference: 'RFC5764' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: 'RFC5766' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'RFC6184' is defined on line 1225, but no explicit reference was found in the text -- 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Rosen 3 Internet-Draft 4 Intended status: Standards Track J. Malloy 5 Expires: February 8, 2020 B. Henderson 6 The MITRE Corporation 7 August 7, 2019 9 Interoperability Profile for Relay User Equipment 10 draft-rosen-rue-01 12 Abstract 14 This document identifies a minimum set of standards and requirements 15 that must be supported by a Video Relay Service (VRS) Video Access 16 Technology Reference Platform (VATRP)-compliant client and United 17 States Telecommunications Relay Service providers required to be 18 VATRP compliant. This Relay User Equipment specification only 19 specifies a minimum set of requirements. It does not prohibit VRS 20 providers or endpoint developers from developing or deploying 21 additional capabilities, provided that doing so will not prevent 22 compliance with the requirements specified here. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 8, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 62 5. General Requirements . . . . . . . . . . . . . . . . . . . . 6 63 6. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 7 65 6.2. Session Establishment . . . . . . . . . . . . . . . . . . 8 66 6.2.1. Normal Call Origination . . . . . . . . . . . . . . . 8 67 6.2.2. One-Stage Dial-Around Origination . . . . . . . . . . 9 68 6.2.3. RUE Contact Information . . . . . . . . . . . . . . . 10 69 6.2.4. Incoming Calls . . . . . . . . . . . . . . . . . . . 10 70 6.2.5. Emergency Calls . . . . . . . . . . . . . . . . . . . 11 71 6.3. Mid Call Signaling . . . . . . . . . . . . . . . . . . . 11 72 6.4. URI Representation of Phone Numbers . . . . . . . . . . . 12 73 6.5. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 7.1. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . 12 76 7.2. Text-Based Communication . . . . . . . . . . . . . . . . 13 77 7.3. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.4. Audio . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.5. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 13 80 7.6. Session Description Protocol . . . . . . . . . . . . . . 13 81 7.7. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 7.8. Negative Acknowledgment, Packet Loss Indicator, and Full 83 Intraframe Request Features . . . . . . . . . . . . . . . 13 84 8. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 8.1. CardDAV Login and Synchronization . . . . . . . . . . . . 14 86 8.2. Contacts Import/Export Service . . . . . . . . . . . . . 14 87 9. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 15 88 10. Provisioning and Provider Selection . . . . . . . . . . . . . 15 89 10.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 15 90 10.2. RUE Configuration Service . . . . . . . . . . . . . . . 16 91 10.3. Schemas . . . . . . . . . . . . . . . . . . . . . . . . 19 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 93 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 95 14. Normative References . . . . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 98 1. Introduction 100 Video Relay Service (VRS) is a form of Telecommunications Relay 101 Service (TRS) that enables persons with hearing disabilities who use 102 sign language, such as American Sign Language (ASL), to communicate 103 with voice telephone users through video equipment. These services 104 also enable communication between such individuals directly in 105 suitable modalities, including any combination of sign language via 106 video, real-time text (RTT), and speech. 108 This Interoperability Profile for Relay User Equipment (RUE) is a 109 profile of the Session Initiation Protocol (SIP) and related media 110 protocols that enables end-user equipment registration and calling 111 for VRS calls. It specifies the minimal set of call flows, Internet 112 Engineering Task Force (IETF) and ITU-T standards that must be 113 supported, provides guidance where the standards leave multiple 114 implementation options, and specifies minimal and extended 115 capabilities for RUE calls. 117 This RUE profile supports the requirements of relay services in the 118 United States, as described in 47 CFR 64.601 et seq., but may be 119 applicable to similar uses elsewhere. 121 2. Scope 123 This RUE Specification documents the standards and controls 124 associated with the Video Access Technology Reference Platform 125 (VATRP). This RUE specification identifies the minimum set of 126 standards for the interface between the VATRP and Providers' networks 127 to which the VATRP adheres. This RUE Specification does not prohibit 128 the implementation of additional features or functionality by any 129 Provider. It also contains some Provider-optional features. If a 130 Provider offers the feature described by the optional specification 131 on at least one endpoint, the Provider MUST supply the standardized 132 interface described in this document for that feature. This edition 133 of the RUE specification does not address Provider-to-Provider 134 communication (covered in the US VRS Provider Interface Profile) or 135 the user interface to the RUE. 137 3. Terminology 139 Communication Assistant (CA): The ASL interpreter stationed in a TRS- 140 registered call center working for a VRS Provider, acting as part of 141 the wire of a call to provide functionally equivalent phone service. 143 Communication modality (modality): A specific form of communication 144 that may be employed by two users, e.g., English voice, Spanish 145 voice, American Sign Language, English lip-reading, or French real- 146 time-text. Here, one communication modality is assumed to encompass 147 both the language and the way that language is exchanged. For 148 example, English voice and French voice are two different 149 communication modalities. 151 Default video relay service: The video relay service operated by a 152 subscriber's default VRS provider. 154 Default video relay service Provider (default Provider): The VRS 155 provider that registers, and assigns a telephone number to, a 156 specific subscriber. A subscriber's default Provider provides the 157 VRS that handles incoming relay calls to the user. The default 158 Provider also handles outgoing relay calls by default. 160 Dial-around call: A relay call where the subscriber specifies the use 161 of a VRS provider other than one of the Providers with whom the 162 subscriber is registered. This can be accomplished by the user 163 dialing a "front-door" number for a VRS provider and signing or 164 texting a phone number to call ("two-stage"). Alternatively, this 165 can be accomplished by the user's RUE software instructing the server 166 of its default VRS provider to automatically route the call through 167 the alternate Provider to the desired public switched telephone 168 network (PSTN) directory number ("one-stage"). 170 Full Intra Request (FIR): A request to a media sender, requiring that 171 media sender to send a Decoder Refresh Point at the earliest 172 opportunity. FIR is sometimes known as "instantaneous decoder 173 refresh request", "video fast update request", or "fast update 174 request". 176 NANP: North America Numbering Plan (please refer to: 177 http://nationalnanpa.org). 179 Point-to-Point Call (P2P Call): A call between two RUEs, without 180 including a CA. 182 Relay call: A call that allows persons with hearing or speech 183 disabilities to use a RUE to talk to users of traditional voice 184 services with the aid of a communication assistant (CA) to relay the 185 communication. Please refer to FCC-VRS-GUIDE. 187 Relay number database (RND): The iTRS Relay Number Database (RND) 188 functions as a 10-digit NANP phone number lookup for SIP and H.323 189 URLs for TRS subscribers. 191 Relay-to-relay call: A call between two subscribers each using 192 different forms of relay (video relay, IP relay, TTY), each with a 193 separate CA to assist in relaying the conversation. 195 Relay service (RS): A service that allow a registered subscriber to 196 use a RUE to make and receive relay calls, point-to-point calls, and 197 relay-to-relay calls. The functions provided by the relay service 198 include the provision of media links supporting the communication 199 modalities used by the caller and callee, and user registration and 200 validation, authentication, authorization, automatic call distributor 201 (ACD) platform functions, routing (including emergency call routing), 202 call setup, mapping, call features (such as call forwarding and video 203 mail), and assignment of CAs to relay calls. 205 Relay service Provider (Provider): An organization that operates a 206 relay service. A subscriber selects a relay service Provider to 207 assign and register a telephone number for their use, to register 208 with for receipt of incoming calls, and to provide the default 209 service for outgoing calls. 211 Relay user: Please refer to "subscriber". 213 Relay user E.164 Number (user E.164): The telephone number assigned 214 to the RUE in ITU-T E.164 format. 216 Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra 217 features to support a subscriber in requesting and using relay calls. 218 A RUE may take many forms, including a stand-alone device; an 219 application running on a general-purpose computing device such as a 220 laptop, tablet or smart phone; or proprietary equipment connected to 221 a server that provides the RUE interface. 223 Sign language: A language that uses hand gestures and body language 224 to convey meaning including, but not limited to, American Sign 225 Language (ASL). 227 Subscriber: An individual who has registered with a Provider and who 228 obtains service by using relay user equipment. This is the 229 traditional telecom term for an end-user customer, which in our case 230 is a relay user. 232 Telecommunications relay services (TRS): Telephone transmission 233 services that provide the ability for an individual who has a hearing 234 impairment or speech impairment to engage in communication by wire or 235 radio with a hearing individual in a manner that is functionally 236 equivalent to the ability of an individual who does not have a 237 hearing impairment or speech impairment to communicate using voice 238 communication services by wire or radio. TRS includes services that 239 enable two-way communication between an individual who uses a 240 Telecommunications Device for the Deaf (TDD) or other non-voice 241 terminal device and an individual who does not use such a device. 243 Video relay service (VRS): A relay service for people with hearing or 244 speech disabilities who use sign language to communicate using video 245 equipment (video RUE) with other people in real time. The video link 246 allows the CA to view and interpret the subscriber's signed 247 conversation and relay the conversation back and forth with the other 248 party. 250 4. Requirements Language 252 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in [RFC2119] 256 5. General Requirements 258 All HTTP/HTTPS connections specified throughout this document MUST 259 use HTTPS. Both HTTPS and all SIP connections MUST use TLA 260 conforming to [RFC7525] 262 During the establishment of secure connections with a provider, the 263 RUE MAY be asked by the server for a client certificate. In that 264 case it SHOULD provide the provisioned client certificate (See 265 Section 10.2. Providers MAY reject requests that fail to provide a 266 recognized certificate. 268 All text data payloads not otherwise constrained by a specification 269 in another standards document MUST be encoded as Unicode UTF/8. 271 6. SIP Signaling 273 The RUE and Providers MUST conform to the following core SIP 274 standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP Servers), 275 [RFC3264] (Offer/Answer), [RFC3840] (User Agent Capabilities), 276 [RFC5626] (Outbound), [RFC4566] (Session Description Protocol), 277 [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP), [RFC6665] 278 (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop-Fix), 279 [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960] (Early 280 Media), and [RFC6442] (Geolocation Header). 282 In addition, the RUE MUST, and Providers MAY, conform to [RFC3327] 283 (Path), [RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER 284 Method), [RFC3891] (Replaces Header), [RFC3892] (Referred-By). 286 RUEs MUST include a "User-Agent" header field uniquely identifying 287 the RUE application, platform, and version in all SIP requests, and 288 MUST include a "Server" header field with the same content in SIP 289 responses. 291 6.1. Registration 293 The RUE MUST register with a SIP registrar, following [RFC3261] and 294 [RFC5626]. If the configuration (please refer to Section 11) 295 contains multiple "outbound-proxies", then the RUE MUST use them as 296 specified in [RFC5626] to establish multiple flows. 298 The request-URI for the REGISTER request MUST contain the "provider- 299 domain" from the configuration. The To-URI and From-URI MUST be 300 identical URIs, formatted as specified in Section 13, using the 301 "phone-number" and "provider-domain" from the configuration. 303 The RUE determines the URI to resolve by initially determining if an 304 outbound proxy is configured. If it is, the URI will be that of the 305 outbound proxy. If no outbound proxy is configured, the URI will be 306 the Request-URI from the REGISTER request. The RUE extracts the 307 domain from that URI and consults the DNS record for that domain. 308 The DNS entry MUST contain NAPTR records conforming to RFC3263. One 309 of those NAPTR records MUST specify TLS as the preferred transport 310 for SIP. For example, a DNS NAPTR query for "sip: 311 p1.red.example.netv" could return: 313 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net 314 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net 316 If the RUE receives a 439 (First Hop Lacks Outbound Support) response 317 to a REGISTER request, it MUST re-attempt registration without using 318 the outbound mechanism. 320 The registrar MAY authenticate using SIP MD5 digest authentication. 321 The credentials to be used (username and password) MUST be supplied 322 within the credentials section of the configuration and identified by 323 the realm the registrar uses in a digest challenge. This username/ 324 password combination SHOULD NOT be the same as that used for other 325 purposes, such as retrieving the RUE configuration or logging into 326 the Provider's customer service portal. Because MD5 is considered 327 insecure, [I-D.yusef-sipcore-digest-scheme] SHOULD be implemented by 328 both the RUE and Providers and SHA-based digest algorithms SHOULD be 329 used for digest authentication. 331 If the registration request fails with an indication that credentials 332 from the configuration are invalid, then the RUE SHOULD retrieve a 333 fresh version of the configuration. If credentials from a freshly 334 retrieved configuration are found to be invalid, then the RUE MUST 335 cease attempts to register and SHOULD inform the RUE User of the 336 problem. 338 Support for multiple simultaneous registrations by Providers is 339 OPTIONAL, as described in Section 2. 341 Multiple simultaneous RUE SIP registrations from different RUE 342 devices with the same SIP URI SHOULD be permitted by the Provider. 343 The Provider MAY limit the total number of simultaneous 344 registrations. When a new registration request is received that 345 results in exceeding the limit on simultaneous registrations, the 346 Provider MAY then prematurely terminate another registration; 347 however, it SHOULD NOT do this if it would disconnect an active call. 349 If a Provider prematurely terminates a registration to reduce the 350 total number of concurrent registrations with the same URI, it SHOULD 351 take some action to prevent the affected RUE from automatically re- 352 registering and re-triggering the condition. 354 6.2. Session Establishment 356 6.2.1. Normal Call Origination 358 After initial SIP registration, the RUE adheres to SIP [RFC3261] 359 basic call flows, as documented in [RFC3665]. 361 The RUE MUST route all calls through the outbound proxy of the 362 default Provider. 364 INVITE requests used to initiate calls SHOULD NOT contain Route 365 headers. Route headers MAY be included in one-stage dial-around 366 calls and emergency calls. The SIP URIs in the To field and the 367 Request-URI MUST be formatted as specified in subsection 6.4 using 368 the destination phone number. The domain field of the URIs SHOULD be 369 the "provider-domain" from the configuration (e.g., 370 sip:+13115552368@red.example.com;user=phone). The same exceptions 371 apply, including anonymous calls. 373 Anonymous calls MUST be supported by both the RUE and Providers. An 374 anonymous call is signaled per [RFC3323]. 376 The From-URI MUST be formatted as specified in Section 6.4, using the 377 phone-number and "provider-domain" from the configuration. It SHOULD 378 also contain the display-name from the configuration when present. 379 (Please refer to Section 10.2.) 381 Negotiated media MUST follow the guidelines specified in Section 7 of 382 this document. 384 To allow time to timeout an unanswered call and direct it to a 385 videomail server, the User Agent Client MUST NOT impose a time limit 386 less than the default SIP Invite transaction timeout of 3 minutes. 388 6.2.2. One-Stage Dial-Around Origination 390 Outbound dial-around calls allow a RUE user to select any Provider to 391 provide interpreting services for any call. "Two-stage" dial-around 392 calls involve the RUE calling a telephone number that reaches the 393 dial-around Provider and using signing or DTMF to provide the called 394 party telephone number. In two-stage dial-around, the To URI is the 395 URI of the dial-around Provider and the domain of the URI is the 396 Provider domain from the configuration. 398 One-stage dial-around is a method where the called party telephone 399 number is provided in the To URI and the Request-URI, using the 400 domain of the dial-around Provider. 402 For one-stage dial-around, the RUE MUST follow the procedures in 403 Section 6.2.1 with the following exception: the domain part of the 404 SIP URIs in the To field and the Request-URI MUST be the domain of 405 the dial-around Provider, discovered according to Section 10.1. 407 The following is a partial example of a one-stage dial-around call 408 from VRS user +1-555-222-0001 hosted by red.example.com to a hearing 409 user +1-555-123-4567 using dial-around to green.example.com for the 410 relay service. Only important details of the messages are shown and 411 many header fields have been omitted: 413 ,-+-. ,----+----. ,-----+-----. 414 |RUE| |Default | |Dial-Around| 415 | | |Provider | | Provider | 416 `-+-' `----+----' `-----+-----' 417 | | | 418 | [1] INVITE | | 419 |-------------->| [2] INVITE | 420 | |-------------->| 422 Message Details: 424 [1] INVITE Rue -> Default Provider 426 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 427 To: 428 From: "Bob Smith" 429 Route: sip:green.example.net 431 [2] INVITE Default Provider -> Dial-Around Provider 433 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 434 To: 435 From: "Bob Smith" sip:+18135551212@red.example.net;user=phone 436 P-Asserted-Identity: sip:+18135551212@red.example.net 438 One Stage Dial-Around 440 6.2.3. RUE Contact Information 442 To identify the owner of a RUE, the initial INVITE for a call from a 443 RUE, or the 200 OK accepting a call by a RUE, identifies the owner by 444 sending a Call-Info header with a purpose parameter of "rue-owner". 445 The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is 446 defined by [RFC2392] to locate message body parts. This URI type is 447 present in a SIP message to convey the RUE ownership information as a 448 MIME body. The form of the RUE ownership information is an xCard 449 [RFC6351]. Please refer to [RFC6442] for an example of using 450 Content-Indirect URLs in SIP messages. Note that use of the Content- 451 Indirect URL usually implies multiple message bodies ("mime/ 452 multipart"). 454 6.2.4. Incoming Calls 456 The RUE MUST accept inbound calls sent to it by the proxy mentioned 457 in the configuration. 459 If Multiple simultaneous RUE SIP registrations from different RUE 460 devices with the same SIP URI exist, the Provider MUST parallel fork 461 the call to all registered RUEs so that they ring at the same time. 462 The first RUE to reply with a 200 OK answers the call and the 463 Provider MUST CANCEL other call branches. 465 6.2.5. Emergency Calls 467 The RUE MUST comply with [RFC6881] for handling of emergency calls. 469 Providers MAY comply with RFC6881 for handling of emergency calls. 470 In addition, they MUST: 472 o Accept RUE emergency calls complying with the specifications in 473 this document; 475 o Recognize such calls as emergency calls and properly handle them 476 as such; 478 o Address other behavior not specified by RFC6881 as specified in 479 Section 6.2. 481 Specifically, if the emergency call is to be handled using E9-1-1 482 (VPC) procedures, the Provider is responsible for modifying the 483 INVITE to conform to the VPC requirements. In this case, location 484 MAY be extracted from the RFC6881 conformant INVITE and used to 485 propagate it to the VPC where possible with the emergency call. 486 Because the RUE may have a more accurate and timely location of the 487 device than the typical manual entry location for nomadic RUE 488 devices, the RUE MUST send a Geolocation header containing its 489 location in the REGISTER request if the configuration specifies it. 490 The Provider MAY use that information to populate the location of the 491 device in the VPC before any emergency call. 493 6.3. Mid Call Signaling 495 The RUE and Providers MUST support re-INVITE to renegotiate media 496 session parameters (among other uses). Per Section 7.1, the RUE 497 MUST, and providers SHOULD, be able to support an INFO request for 498 full frame refresh for devices in a call with the RUE that do not 499 support RTCP mechanisms (please refer to Section 7.8). The RUE MUST 500 support an in-dialog REFER ([RFC3515] updated by [RFC7647] and 501 including support for norefersub per [RFC4488]) with the Replaces 502 header [RFC3891] to enable call transfer. 504 6.4. URI Representation of Phone Numbers 506 SIP URIs constructed from non-URI sources (dial strings) and sent to 507 SIP proxies by the RUE MUST be represented as follows, depending on 508 whether they can be represented as an E.164 number. 510 A dial string that can be written as an E.164 formatted phone number 511 MUST be represented as a SIP URI with a URI ";user=phone" tag. The 512 user part of the URI MUST be in conformance with 'global-number' 513 defined in [RFC3966]. The user part MUST NOT contain any 'visual- 514 separator' characters. 516 Dial strings that cannot be written as E.164 numbers MUST be 517 represented as dialstring URIs, as specified by [RFC4967], e.g., 518 sip:411@red.example.net;user=dialstring. 520 The domain part of Relay Service URIs and User Address of Records 521 (AoR) MUST (using resolve (in accord with [RFC3263]) to globally 522 routable IPv4 addresses. The AoRs MAY also resolve to IPv6 523 addresses. 525 6.5. Transport 527 The RUE and providers MUST conform to [I-D.ietf-rtcweb-transports] 528 with the understanding that this specification does not use the 529 WebRTC data channel. 531 The RUE and providers MUST support SIP outbound [RFC5626] (please 532 also refer to Section 6.1). 534 7. Media 536 This specification adopts the media specifications for WebRTC 537 ([I-D.ietf-rtcweb-overview]). Where WebRTC defines how interactive 538 media communications may be established using a browser as a client, 539 this specification assumes a normal SIP call. The RTP, RTCP, SDP and 540 specific media requirements specified for WebRTC are adopted for this 541 document. The following sections specify the WebRTC documents to 542 which conformance is required. 544 7.1. SRTP and SRTCP 546 The RUE and Providers MUST support [I-D.ietf-rtcweb-rtp-usage] with 547 the understanding that RUE does not specify an API and therefore 548 MediaStreamTracks are not used. Implementations MUST conform to 549 Section 6.4 of [I-D.ietf-rtcweb-security-arch]. 551 7.2. Text-Based Communication 553 The RUE MUST and Providers MUST support real-time text ([RFC4102] and 554 [RFC4103]) via T.140 media. One original and two redundant 555 generations MUST be transmitted and supported, with a 300 ms 556 transmission interval. Note that this is not how real time text is 557 transmitted in WebRTC and some form of transcoder would be required 558 to interwork real time text in the data channel of WebRTC to RFC4103 559 real time text. 561 7.3. Video 563 The RUE and Providers MUST conform to [RFC7742]. 565 7.4. Audio 567 The RUE and Providers MUST conform to [RFC7874]. 569 7.5. DTMF Digits 571 The RUE and Providers MUST support the "audio/telephone-event" 572 [RFC4733] media type. They MUST support conveying event codes 0 573 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of 574 [RFC4733]. Handling of other tones is OPTIONAL. 576 7.6. Session Description Protocol 578 The SDP offers and answers MUST conform [I-D.ietf-rtcweb-jsep] with 579 the understanding that the RUE uses SIP transport for SDP. 581 7.7. Privacy 583 The RUE MUST be able to control privacy of the user by implementing a 584 one-way mute of audio and or video, without signaling, locally, but 585 MUST maintain any NAT bindings by periodically sending media packets 586 on all active media sessions containing silence/comfort noise/black 587 screen/etc. per [RFC6263]. 589 7.8. Negative Acknowledgment, Packet Loss Indicator, and Full 590 Intraframe Request Features 592 NACK SHOULD be used when negotiated and conditions warrant its use. 593 Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be 594 preferred, as described in [RFC5104]. 596 FIR SHOULD be used only in situations where not sending a decoder 597 refresh point would render the video unusable for the users, as per 598 RFC5104 subsection 4.3.1.2. 600 For backwards compatibility with calling devices that do not support 601 the foregoing methods, the RUE MUST implement and use SIP INFO 602 messages to send and receive XML encoded Picture Fast Update messages 603 according to [RFC5168]. 605 8. Contacts 607 8.1. CardDAV Login and Synchronization 609 Support of CardDAV by Providers is OPTIONAL, as described in 610 Section 2. 612 The RUE MUST and Providers MAY be able to synchronize the user's 613 contact directory between the RUE endpoint and one maintained by the 614 user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). 616 The configuration MAY supply a username and domain identifying a 617 CardDAV server and address book for this account. 619 To access the CardDAV server and address book, the RUE MUST follow 620 Section 6 of RFC6764, using the chosen username and domain in place 621 of an email address. If the request triggers a challenge for digest 622 authentication credentials, the RUE MUST attempt to continue using 623 matching "credentials" from the configuration. If no matching 624 credentials are configured, the RUE MUST use the SIP credentials from 625 the configuration. If the SIP credentials fail, the RUE MUST query 626 the user. 628 Synchronization using CardDAV MUST be a two-way synchronization 629 service, with proper handling of asynchronous adds, changes, and 630 deletes at either end of the transport channel. 632 8.2. Contacts Import/Export Service 634 Each Provider MUST supply a standard xCard import/export interface 635 and the RUE MUST be able to export/import the list of contacts in 636 xCard [RFC6351] XML format. 638 The RUE accesses this service via the "contacts" URI in the 639 configuration. The URL MUST resolve to identify a web server 640 resource that imports/exports contact lists for authorized users. 642 The RUE stores/retrieves the contact list (address book) by issuing 643 an HTTPS POST or GET request. If the request triggers a challenge 644 for digest authentication credentials, the RUE MUST attempt to 645 continue using matching "credentials" from the configuration. If no 646 credentials are configured, the RUE MUST query the user. 648 9. Mail Waiting Indicator (MWI) 650 Support of MWI by Providers is OPTIONAL, as described in Section 2 652 The RUE MUST and Providers SHOULD support subscriptions to "message- 653 summary" events [RFC3842] to the URI specified in the configuration 654 if the Provider supports message waiting indicator on any endpoint. 656 In notification bodies, videomail messages SHOULD be reported using 657 "message-context-class multimedia-message" defined in [RFC3458]. 659 10. Provisioning and Provider Selection 661 10.1. RUE Provider Selection 663 To allow the user to select a relay service, the RUE MAY obtain, on 664 startup, a list of Providers from a configured accessible URL. 666 The provider list, formatted as JSON, contains: 668 o Version: Specifies the version number of the Provider list format. 669 A new version number SHOULD only be used if the new version is not 670 backwards-compatible with the older version. A new version number 671 is not needed if new elements are optional and can be ignored by 672 older implementations. 674 o Providers: An array where each entry describes one Provider. Each 675 entry consists of the following items: 677 * name: This parameter contains the text label identifying the 678 Provider and is meant to be displayed to the human VRS user. 680 * domain: The domain parameter is used for configuration purposes 681 by the RUE (as discussed in Section 10.2) and as the domain to 682 use when targeting one-stage dial-around calls to this Provider 683 (as discussed in Section 6.2.2). 685 * operator: (OPTIONAL) The operator parameter is a SIP URL that 686 identifies the operator "front-door" that VRS users may contact 687 for manual (two-stage) dial-around calls. 689 The VRS user interacts with the RUE to select from the Provider list 690 one or more Providers with whom the user has already established an 691 account. 693 { 694 "version": 1, 695 "providers": [ 696 { 697 "name": "Red", 698 "domain": "red.example.net", 699 "operator": "sip:operator@red.example.net" 700 }, 701 { 702 "name": "Green", 703 "domain": "green.example.net", 704 "operator": "sip:+18885550123@green.example.net;user=phone" 705 }, 706 { 707 "name": "Blue", 708 "domain": "blue.example.net" 709 } 710 ] 711 } 713 Example of a Provider list JSON object 715 10.2. RUE Configuration Service 717 The RUE is provisioned with one or more URIs that may be queried for 718 configuration with HTTPS. 720 The data returned will include a set of key/value configuration 721 parameters to be used by the RUE, formatted as a JSON object and 722 identified by the associated [RFC7159] "application/json" MIME type, 723 to allow for other formats in the future. 725 The configuration data payload includes the following data items. 726 Items not noted as (OPTIONAL) are REQUIRED. If other unexpected 727 items are found, they MUST be ignored. 729 o version: Identifies the version of the configuration data format. 730 A new version number SHOULD only be used if the new version is not 731 backwards-compatible with the older version. A new version number 732 is not needed if new elements are optional and can be ignored by 733 older implementations. 735 o lifetime: Specifies how long (in seconds) the RUE MAY cache the 736 configuration values. Values may not be valid when lifetime 737 expires. Emergency Calls MUST continue to work. 739 o display-name: (OPTIONAL) A user-friendly name to identify the 740 subscriber when originating calls. 742 o phone-number: The telephone number (in E.164 format) assigned to 743 this subscriber. This becomes the user portion of the SIP URI 744 identifying the subscriber. 746 o provider-domain: The DNS domain name of the default Provider 747 servicing this subscriber. 749 o outbound-proxies: (OPTIONAL) A URI of a SIP proxy to be used when 750 sending requests to the Provider. 752 o mwi: (OPTIONAL) A URI identifying a SIP event server that 753 generates "message-summary" events for this subscriber. 755 o videomail: (OPTIONAL) A SIP URI that can be called to retrieve 756 videomail messages. 758 o contacts: An HTTPS URI that may be used to export (retrieve) the 759 subscriber's complete contact list managed by the Provider. 761 o carddav: (OPTIONAL) A username and domain name (separated by 762 ""@"") identifying a "CardDAV" server and user name that can be 763 used to synchronize the RUE's contact list with the contact list 764 managed by the Provider. 766 o sendLocationWithRegistration: True if the RUE should send a 767 Geolocation Header with REGISTER, false if it should not. 768 Defaults to false if not present. 770 o turn-servers: (OPTIONAL) An array of URLs identifying STUN and 771 TURN servers available for use by the RUE for establishing media 772 streams in calls via the Provider. 774 o credentials: (OPTIONAL) TBD 776 { 777 "version": 1, 778 "lifetime": 86400, 779 "display-name" : "Bob Smith", 780 "phone-number": "+18135551212", 781 "provider-domain": "red.example.net", 782 "outbound-proxies": [ 783 "sip:p1.red.example.net", 784 "sip:p2.red.example.net" 785 ], 786 "mwi": "sip:+18135551212@red.example.net", 787 "videomail": "sip:+18135551212@vm.red.example.net", 788 "contacts": "https://red.example.net:443/contacts/1dess45awd" 789 "carddav": "bob@red.example.com" , 790 "sendLocationWithRegistration": false, 791 "ice-servers": [ 792 {"stun:stun.l.google.com:19302" }, 793 {"turn:turn.red.example.net:3478"} 794 ], 795 "credentials": [ 796 { 797 "realm": "red.example.net", 798 "username": "bob", 799 "password": "reg-pw" 800 }, 801 { 802 "realm": "proxies.red.example.net", 803 "username": "bob", 804 "password": "proxy-pw" 805 }, 806 { 807 "realm": "cd.red.example.net", 808 "username": "bob", 809 "password": "cd-pw" 810 }, 811 { 812 "realm": "vm.red.example.net", 813 "username": "bob", 814 "password": "vm-pw" 815 }, 816 { 817 "realm": "stun-turn.red.example.net", 818 "username": "bob", 819 "password": "stun-turn-pw" 820 } 821 ] 822 } 824 Example JSON configuration payload 826 The wire format of the data is in keeping with the standard JSON 827 description in RFC7159. 829 The "lifetime" parameter in the configuration indicates how long the 830 RUE MAY cache the configuration values. If the RUE caches 831 configuration values, it MUST cryptographically protect them. The 832 RUE SHOULD retrieve a fresh copy of the configuration before the 833 lifetime expires or as soon as possible after it expires. The 834 lifetime is not guaranteed: the configuration may change before the 835 lifetime value expires. In that case, the Provider MAY indicate this 836 by generating authorization challenges to requests and/or prematurely 837 terminating a registration. 839 Note: In some cases, the RUE may successfully retrieve a fresh copy 840 of the configuration using digest credentials cached from the prior 841 retrieval. If this is not successful, then the RUE will need to ask 842 the user for the username and password. Unfortunately, this 843 authentication step might occur when the user is not present, 844 preventing SIP registration and thus incoming calls. To avoid this 845 situation, the RUE MAY retrieve a new copy of the configuration when 846 it knows the user is present, even if there is time before the 847 lifetime expires. 849 10.3. Schemas 851 The following JSON schemas are for the Provider List and the RUE 852 Configuration. These are represented using the JSON Content Rules 853 [JCR] schema notation. 855 { 856 "version": 1, 857 "providers": [ 858 1* 859 { 860 "name": string, 861 "domain": fqdn, 862 ?"operator": ; "front-door" access to provider 863 uri, ; (sip uri) 864 * /^.*$/ : any ; (allow future extensions) 865 } 866 ] , 867 * /^.*$/ : any ; (allow future extensions) 868 } 870 Provider List JSON Schema 872 { 873 "version": 1, ; Interface version 874 "lifetime": integer, ; Deadline (in seconds) for 875 ; refreshing this config without 876 ; user input. 877 "phone-number": /^\+[0-9]+$/ , ; E.164 phone number 878 ; for this user 879 ?"display-name" : string,; display name for From: header 880 "provider-domain": fqdn, ; SHOULD match that in Provider List 881 ?"outbound-proxies": [ 1* : uri ], ; sip URIs 882 ?"mwi": uri , ; sip URI for MWI subscriptions 883 ?"videomail": uri , ; sip URI for videomail retrieval 884 "contacts": uri , ; https URI for contact list retrieval 885 ?"carddav": /^[^@]+@[^@]+$/ , ; for contact list synch 886 ?"sendLocationWithRegistration": boolean , ; send location y/n 887 ?"ice-servers": ; (Required for ICE use) 888 [ 1* : uri ], ; (stun[s] & turn[s] URIs 889 ?"credentials": ; for digest authentication 890 [ 1* { 891 "realm": string, 892 "username": string, 893 "password": string 894 } ], 895 * /^.*$/ : any ; (allow future extensions) 896 } 898 RUE Configuration JSON Schema 900 The following illustrates the message flow for retrieving a RUE 901 automatic configuration using HTTPS Digest Authentication: 903 ,-. 904 `-' 905 /|\ ,---. ,---. ,------------. ,----------------. ,---. 906 | |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 907 / \ | | | | | | |Global Settings | | | 908 RUE User `-+-' `-+-' `-----+------' `--------+-------' `-+-' 909 | | | | | | 910 [1] Select a VRS Provider name | | | 911 | ------->| | | | | 912 | | | | | | 913 [2] NAPTR "SFUA.CFG" red.example.net | | 914 | |----->| | | | 915 | | | | | | 916 [3] NAPTR "!.*!https://server.red.example.net/!" | | 917 | |<-----| | | | 918 | | | | | | 919 [4] If NAPTR found, query DNS server.red.example.net | 920 | |----->| | | | 921 | | | | | | 922 [5] If NXDOMAIN, query DNS config.red.example.net | | 923 | | - - >| | | | 924 | | | | | | 925 [6] IP Address of Config Server | | | 926 | |<-----| | | | 927 | | | | | | 928 [7] Establish TLS connection | | | 929 | |<--------------->| | | 930 | | | | | | 931 [8] HTTP: https://config.red.example.net/v1 | | 932 | |---------------->| | | 933 | | | | | | 934 [9] HTTP: 401 Unauthorized | | | 935 WWW-Authenticate Digest realm="Y" qop="auth,auth-int" nonce=| 936 | |<----------------| | | 937 | | | | | | 938 [10] Query for userid/pw | | | 939 |<--------| | | | | 940 | | | | | | 941 [11] User="bob", pw="bob's global provider pw" | | 942 |-------->| | | | | 943 | | | | | | 944 [12] HTTP: https://config.red.example.net/v1 | | 945 | Authorization Digest username="bob" realm="Y" qop="auth" | 946 | nonce=... response="..." ... | | 947 | |---------------->| | | 948 | | | | | | 949 | [13] Find subscriber information for username="bob" | 950 | | | |----------------------------->| 951 | | | | | | 952 | [14] Subscriber specific configuration information | 953 | | | |<-----------------------------| 954 | | | | | | 955 | [15] Retrieve provider specific settings | 956 | | | |---------------->| | 957 | | | | | | 958 | [16] Provider configuration information | | 959 | | | |<----------------| | 960 | | | | | | 961 [17] 200 OK + JSON merge subscriber + provider configs | 962 | |<----------------| | | 963 | | | | | | 964 RUE User ,---. ,---. ,------------. ,----------------. ,---. 965 ,-. |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 966 `-' | | | | | | |Global Settings | | | 967 /|\ `-+-' `-+-' `-----+------' `--------+-------' `-+-' 968 | 969 / \ 971 RUE Configuration Retrieval 973 11. Acknowledgements 975 12. IANA Considerations 977 This memo includes no request to IANA. 979 13. Security Considerations 981 The RUE is required to communicate with servers on public IP 982 addresses and specific ports to perform its required functions. If 983 it is necessary for the RUE to function on a corporate or other 984 network that operates a default-deny firewall between the RUE and 985 these services, the user must arrange with their network manager for 986 passage of traffic through such a firewall in accordance with the 987 protocols and associated SRV records as exposed by the Provider. 988 Because VRS providers may use different ports for different services, 989 these port numbers may differ from Provider to Provider. 991 14. Normative References 993 [I-D.ietf-rtcweb-jsep] 994 Uberti, J., Jennings, C., and E. Rescorla, "JavaScript 995 Session Establishment Protocol", draft-ietf-rtcweb-jsep-26 996 (work in progress), February 2019. 998 [I-D.ietf-rtcweb-overview] 999 Alvestrand, H., "Overview: Real Time Protocols for 1000 Browser-based Applications", draft-ietf-rtcweb-overview-19 1001 (work in progress), November 2017. 1003 [I-D.ietf-rtcweb-rtp-usage] 1004 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1005 Communication (WebRTC): Media Transport and Use of RTP", 1006 draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 1007 2016. 1009 [I-D.ietf-rtcweb-security-arch] 1010 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1011 rtcweb-security-arch-20 (work in progress), July 2019. 1013 [I-D.ietf-rtcweb-transports] 1014 Alvestrand, H., "Transports for WebRTC", draft-ietf- 1015 rtcweb-transports-17 (work in progress), October 2016. 1017 [I-D.yusef-sipcore-digest-scheme] 1018 Shekh-Yusef, R., "The Session Initiation Protocol (SIP) 1019 Digest Authentication Scheme", draft-yusef-sipcore-digest- 1020 scheme-07 (work in progress), April 2019. 1022 [pip] SIPForum, "VRS US Providers Profile TWG-6-1.0", 2015, 1023 . 1026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1027 Requirement Levels", BCP 14, RFC 2119, 1028 DOI 10.17487/RFC2119, March 1997, 1029 . 1031 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1032 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 1033 . 1035 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1036 A., Peterson, J., Sparks, R., Handley, M., and E. 1037 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1038 DOI 10.17487/RFC3261, June 2002, 1039 . 1041 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1042 Protocol (SIP): Locating SIP Servers", RFC 3263, 1043 DOI 10.17487/RFC3263, June 2002, 1044 . 1046 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1047 with Session Description Protocol (SDP)", RFC 3264, 1048 DOI 10.17487/RFC3264, June 2002, 1049 . 1051 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1052 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1053 2002, . 1055 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1056 Initiation Protocol (SIP)", RFC 3323, 1057 DOI 10.17487/RFC3323, November 2002, 1058 . 1060 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1061 Header Field for the Session Initiation Protocol (SIP)", 1062 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1063 . 1065 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1066 (SIP) Extension Header Field for Registering Non-Adjacent 1067 Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, 1068 . 1070 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1071 Context for Internet Mail", RFC 3458, 1072 DOI 10.17487/RFC3458, January 2003, 1073 . 1075 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1076 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1077 . 1079 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1080 Jacobson, "RTP: A Transport Protocol for Real-Time 1081 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1082 July 2003, . 1084 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1085 in Session Description Protocol (SDP)", RFC 3605, 1086 DOI 10.17487/RFC3605, October 2003, 1087 . 1089 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1090 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1091 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1092 December 2003, . 1094 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1095 "Indicating User Agent Capabilities in the Session 1096 Initiation Protocol (SIP)", RFC 3840, 1097 DOI 10.17487/RFC3840, August 2004, 1098 . 1100 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1101 Indication Event Package for the Session Initiation 1102 Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 1103 2004, . 1105 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1106 Protocol (SIP) "Replaces" Header", RFC 3891, 1107 DOI 10.17487/RFC3891, September 2004, 1108 . 1110 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 1111 Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, 1112 September 2004, . 1114 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1115 Tone Generation in the Session Initiation Protocol (SIP)", 1116 RFC 3960, DOI 10.17487/RFC3960, December 2004, 1117 . 1119 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1120 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1121 . 1123 [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", 1124 RFC 4102, DOI 10.17487/RFC4102, June 2005, 1125 . 1127 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1128 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 1129 . 1131 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 1132 (SIP) REFER Method Implicit Subscription", RFC 4488, 1133 DOI 10.17487/RFC4488, May 2006, 1134 . 1136 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1137 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1138 July 2006, . 1140 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1141 "Extended RTP Profile for Real-time Transport Control 1142 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1143 DOI 10.17487/RFC4585, July 2006, 1144 . 1146 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1147 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1148 DOI 10.17487/RFC4733, December 2006, 1149 . 1151 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1152 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 1153 . 1155 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1156 Initiation Protocol Uniform Resource Identifier", 1157 RFC 4967, DOI 10.17487/RFC4967, July 2007, 1158 . 1160 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1161 "Codec Control Messages in the RTP Audio-Visual Profile 1162 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1163 February 2008, . 1165 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1166 Media Control", RFC 5168, DOI 10.17487/RFC5168, March 1167 2008, . 1169 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1170 (ICE): A Protocol for Network Address Translator (NAT) 1171 Traversal for Offer/Answer Protocols", RFC 5245, 1172 DOI 10.17487/RFC5245, April 2010, 1173 . 1175 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1176 (TLS) Protocol Version 1.2", RFC 5246, 1177 DOI 10.17487/RFC5246, August 2008, 1178 . 1180 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1181 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1182 DOI 10.17487/RFC5389, October 2008, 1183 . 1185 [RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. 1186 Campen, "Addressing an Amplification Vulnerability in 1187 Session Initiation Protocol (SIP) Forking Proxies", 1188 RFC 5393, DOI 10.17487/RFC5393, December 2008, 1189 . 1191 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1192 "Managing Client-Initiated Connections in the Session 1193 Initiation Protocol (SIP)", RFC 5626, 1194 DOI 10.17487/RFC5626, October 2009, 1195 . 1197 [RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing 1198 Record-Route Issues in the Session Initiation Protocol 1199 (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, 1200 . 1202 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1203 for Establishing a Secure Real-time Transport Protocol 1204 (SRTP) Security Context Using Datagram Transport Layer 1205 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1206 2010, . 1208 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1209 Security (DTLS) Extension to Establish Keys for the Secure 1210 Real-time Transport Protocol (SRTP)", RFC 5764, 1211 DOI 10.17487/RFC5764, May 2010, 1212 . 1214 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1215 Relays around NAT (TURN): Relay Extensions to Session 1216 Traversal Utilities for NAT (STUN)", RFC 5766, 1217 DOI 10.17487/RFC5766, April 2010, 1218 . 1220 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 1221 "Essential Correction for IPv6 ABNF and URI Comparison in 1222 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 1223 . 1225 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1226 Payload Format for H.264 Video", RFC 6184, 1227 DOI 10.17487/RFC6184, May 2011, 1228 . 1230 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1231 Keeping Alive the NAT Mappings Associated with RTP / RTP 1232 Control Protocol (RTCP) Flows", RFC 6263, 1233 DOI 10.17487/RFC6263, June 2011, 1234 . 1236 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 1237 RFC 6351, DOI 10.17487/RFC6351, August 2011, 1238 . 1240 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 1241 Authoring and Versioning (WebDAV)", RFC 6352, 1242 DOI 10.17487/RFC6352, August 2011, 1243 . 1245 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1246 for the Session Initiation Protocol", RFC 6442, 1247 DOI 10.17487/RFC6442, December 2011, 1248 . 1250 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1251 DOI 10.17487/RFC6665, July 2012, 1252 . 1254 [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions 1255 to WebDAV (CalDAV) and vCard Extensions to WebDAV 1256 (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, 1257 . 1259 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1260 Communications Services in Support of Emergency Calling", 1261 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1262 . 1264 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1265 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1266 2014, . 1268 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1269 "Recommendations for Secure Use of Transport Layer 1270 Security (TLS) and Datagram Transport Layer Security 1271 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1272 2015, . 1274 [RFC7647] Sparks, R. and A. Roach, "Clarifications for the Use of 1275 REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, 1276 September 2015, . 1278 [RFC7742] Roach, A., "WebRTC Video Processing and Codec 1279 Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 1280 . 1282 [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing 1283 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, 1284 . 1286 Authors' Addresses 1288 Brian Rosen 1289 Mars, PA 1290 US 1292 Phone: +1 724 382 1051 1293 Email: br@brianrosen.net 1294 Jim Malloy 1295 The MITRE Corporation 1296 McLean, VA 1297 US 1299 Phone: +1 703 983 2835 1300 Email: jmalloy@mitre.org 1302 Brett Henderson 1303 The MITRE Corporation 1304 McLean, VA 1305 US 1307 Phone: +1 619 758 6071 1308 Email: brhenderson@mitre.org