idnits 2.17.1 draft-rosen-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 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 (February 1, 2019) is 1911 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 958 -- Looks like a reference, but probably isn't: '2' on line 961 == Missing Reference: 'JCR' is mentioned on line 901, but not defined -- Looks like a reference, but probably isn't: '3' on line 964 -- Looks like a reference, but probably isn't: '4' on line 967 -- Looks like a reference, but probably isn't: '5' on line 970 -- Looks like a reference, but probably isn't: '6' on line 973 -- Looks like a reference, but probably isn't: '7' on line 976 -- Looks like a reference, but probably isn't: '8' on line 979 -- Looks like a reference, but probably isn't: '9' on line 982 -- Looks like a reference, but probably isn't: '10' on line 986 -- Looks like a reference, but probably isn't: '11' on line 989 -- Looks like a reference, but probably isn't: '12' on line 992 -- Looks like a reference, but probably isn't: '13' on line 997 -- Looks like a reference, but probably isn't: '14' on line 1000 -- Looks like a reference, but probably isn't: '15' on line 1003 -- Looks like a reference, but probably isn't: '16' on line 1006 -- Looks like a reference, but probably isn't: '17' on line 1009 == Outdated reference: A later version (-07) exists of draft-yusef-sipcore-digest-scheme-06 -- 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) Summary: 8 errors (**), 0 flaws (~~), 5 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: August 5, 2019 B. Henderson 6 The MITRE Corporation 7 February 1, 2019 9 Interoperability Profile for Relay User Equipment 10 draft-rosen-rue-00 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 August 5, 2019. 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 . . . . . . . . . . . 11 73 6.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 12 74 7. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 7.1. Text-Based Communication . . . . . . . . . . . . . . . . 12 76 7.2. Video Codecs . . . . . . . . . . . . . . . . . . . . . . 12 77 7.3. Audio Codecs . . . . . . . . . . . . . . . . . . . . . . 13 78 7.4. DTMF Digits . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.5. Session Description Protocol . . . . . . . . . . . . . . 13 80 7.6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 8. SRTP and SRTCP . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Bandwidth Negotiation Flow Control and Media Performance 13 83 8.2. SRTP / SAVPF Profile for SRTCP Feedback . . . . . . . . . 14 84 8.3. Negative Acknowledgment, Packet Loss Indicator, and Full 85 Intraframe Request Features . . . . . . . . . . . . . . . 14 86 9. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 9.1. CardDAV Login and Synchronization . . . . . . . . . . . . 14 88 9.2. Contacts Import/Export Service . . . . . . . . . . . . . 15 89 10. Mail Waiting Indicator (MWI) . . . . . . . . . . . . . . . . 15 90 11. Provisioning and Provider Selection . . . . . . . . . . . . . 15 91 11.1. RUE Provider Selection . . . . . . . . . . . . . . . . . 15 92 11.2. RUE Configuration Service . . . . . . . . . . . . . . . 17 93 11.3. Schemas . . . . . . . . . . . . . . . . . . . . . . . . 20 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 95 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 96 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 97 15. Normative References . . . . . . . . . . . . . . . . . . . . 23 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 100 1. Introduction 102 Video Relay Service (VRS) is a form of Telecommunications Relay 103 Service (TRS) that enables persons with hearing disabilities who use 104 sign language, such as American Sign Language (ASL), to communicate 105 with voice telephone users through video equipment. These services 106 also enable communication between such individuals directly in 107 suitable modalities, including any combination of sign language via 108 video, real-time text (RTT), and speech. 110 This Interoperability Profile for Relay User Equipment (RUE) is a 111 profile of the Session Initiation Protocol (SIP) and related media 112 protocols that enables end-user equipment registration and calling 113 for VRS calls. It specifies the minimal set of call flows, Internet 114 Engineering Task Force (IETF) and ITU-T standards that must be 115 supported, provides guidance where the standards leave multiple 116 implementation options, and specifies minimal and extended 117 capabilities for RUE calls. 119 This RUE profile supports the requirements of relay services in the 120 United States, as described in 47 CFR 64.601 et seq., but may be 121 applicable to similar uses elsewhere. 123 2. Scope 125 This RUE Specification documents the standards and controls 126 associated with the Video Access Technology Reference Platform 127 (VATRP). This RUE specification identifies the minimum set of 128 standards for the interface between the VATRP and Providers' networks 129 to which the VATRP adheres. This RUE Specification does not prohibit 130 the implementation of additional features or functionality by any 131 Provider. It also contains some Provider-optional features. If a 132 Provider offers the feature described by the optional specification 133 on at least one endpoint, the Provider MUST supply the standardized 134 interface described in this document for that feature. This edition 135 of the RUE specification does not address Provider-to-Provider 136 communication (covered in the US VRS Provider Interface Profile) or 137 the user interface to the RUE. 139 3. Terminology 141 Communication Assistant (CA): The ASL interpreter stationed in a TRS- 142 registered call center working for a VRS Provider, acting as part of 143 the wire of a call to provide functionally equivalent phone service. 145 Communication modality (modality): A specific form of communication 146 that may be employed by two users, e.g., English voice, Spanish 147 voice, American Sign Language, English lip-reading, or French real- 148 time-text. Here, one communication modality is assumed to encompass 149 both the language and the way that language is exchanged. For 150 example, English voice and French voice are two different 151 communication modalities. 153 Default video relay service: The video relay service operated by a 154 subscriber's default VRS provider. 156 Default video relay service Provider (default Provider): The VRS 157 provider that registers, and assigns a telephone number to, a 158 specific subscriber. A subscriber's default Provider provides the 159 VRS that handles incoming relay calls to the user. The default 160 Provider also handles outgoing relay calls by default. 162 Dial-around call: A relay call where the subscriber specifies the use 163 of a VRS provider other than one of the Providers with whom the 164 subscriber is registered. This can be accomplished by the user 165 dialing a "front-door" number for a VRS provider and signing or 166 texting a phone number to call ("two-stage"). Alternatively, this 167 can be accomplished by the user's RUE software instructing the server 168 of its default VRS provider to automatically route the call through 169 the alternate Provider to the desired public switched telephone 170 network (PSTN) directory number ("one-stage"). 172 Full Intra Request (FIR): A request to a media sender, requiring that 173 media sender to send a Decoder Refresh Point at the earliest 174 opportunity. FIR is sometimes known as "instantaneous decoder 175 refresh request", "video fast update request", or "fast update 176 request". 178 NANP: North America Numbering Plan (please refer to: 179 http://nationalnanpa.org). 181 Point-to-Point Call (P2P Call): A call between two RUEs, without 182 including a CA. 184 Relay call: A call that allows persons with hearing or speech 185 disabilities to use a RUE to talk to users of traditional voice 186 services with the aid of a communication assistant (CA) to relay the 187 communication. Please refer to FCC-VRS-GUIDE. 189 Relay number database (RND): The iTRS Relay Number Database (RND) 190 functions as a 10-digit NANP phone number lookup for SIP and H.323 191 URLs for TRS subscribers. 193 Relay-to-relay call: A call between two subscribers each using 194 different forms of relay (video relay, IP relay, TTY), each with a 195 separate CA to assist in relaying the conversation. 197 Relay service (RS): A service that allow a registered subscriber to 198 use a RUE to make and receive relay calls, point-to-point calls, and 199 relay-to-relay calls. The functions provided by the relay service 200 include the provision of media links supporting the communication 201 modalities used by the caller and callee, and user registration and 202 validation, authentication, authorization, automatic call distributor 203 (ACD) platform functions, routing (including emergency call routing), 204 call setup, mapping, call features (such as call forwarding and video 205 mail), and assignment of CAs to relay calls. 207 Relay service Provider (Provider): An organization that operates a 208 relay service. A subscriber selects a relay service Provider to 209 assign and register a telephone number for their use, to register 210 with for receipt of incoming calls, and to provide the default 211 service for outgoing calls. 213 Relay user: Please refer to "subscriber". 215 Relay user E.164 Number (user E.164): The telephone number assigned 216 to the RUE in ITU-T E.164 format. 218 Relay user equipment (RUE): A SIP user agent (UA) enhanced with extra 219 features to support a subscriber in requesting and using relay calls. 220 A RUE may take many forms, including a stand-alone device; an 221 application running on a general-purpose computing device such as a 222 laptop, tablet or smart phone; or proprietary equipment connected to 223 a server that provides the RUE interface. 225 Sign language: A language that uses hand gestures and body language 226 to convey meaning including, but not limited to, American Sign 227 Language (ASL). 229 Subscriber: An individual who has registered with a Provider and who 230 obtains service by using relay user equipment. This is the 231 traditional telecom term for an end-user customer, which in our case 232 is a relay user. 234 Telecommunications relay services (TRS): Telephone transmission 235 services that provide the ability for an individual who has a hearing 236 impairment or speech impairment to engage in communication by wire or 237 radio with a hearing individual in a manner that is functionally 238 equivalent to the ability of an individual who does not have a 239 hearing impairment or speech impairment to communicate using voice 240 communication services by wire or radio. TRS includes services that 241 enable two-way communication between an individual who uses a 242 Telecommunications Device for the Deaf (TDD) or other non-voice 243 terminal device and an individual who does not use such a device. 245 Video relay service (VRS): A relay service for people with hearing or 246 speech disabilities who use sign language to communicate using video 247 equipment (video RUE) with other people in real time. The video link 248 allows the CA to view and interpret the subscriber's signed 249 conversation and relay the conversation back and forth with the other 250 party. 252 4. Requirements Language 254 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 256 document are to be interpreted as described in [RFC2119] 258 5. General Requirements 260 All HTTP/HTTPS connections specified throughout this document MUST 261 use HTTPS. Both HTTPS and all SIP Transactions MUST use TLS 1.2 262 [RFC5246] or later, using a server-side certificate issued by a well- 263 known Certificate Agency. The minimum cipher suite to be supported 264 is TLS_RSA_WITH_AES_256_CBC_SHA25. 265 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 support is RECOMMENDED. 267 During the establishment of secure connections with a provider, the 268 RUE MAY be asked by the server for a client certificate. In that 269 case it SHOULD provide a client certificate. Providers MAY reject 270 requests that fail to provide a recognized certificate. 272 All text data payloads not otherwise constrained by a specification 273 in another standards document MUST be encoded as Unicode UTF/8. 275 6. SIP Signaling 277 The RUE and Providers MUST conform to the following core SIP 278 standards [RFC3261] (Base SIP) [RFC3263] (Locating SIP Servers), 279 [RFC3264] (Offer/Answer), [RFC3840] (User Agent Capabilities), 280 [RFC5626] (Outbound), [RFC4566] (Session Description Protocol), 281 [RFC3323] (Privacy), [RFC3605] (RTCP Attribute in SDP), [RFC6665] 282 (SIP Events), [RFC3311] (UPDATE Method), [RFC5393] (Loop-Fix), 283 [RFC5658] (Record Route fix), [RFC5954] (ABNF fix), [RFC3960] (Early 284 Media), and [RFC6442] (Geolocation Header). 286 In addition, the RUE MUST, and Providers MAY, conform to [RFC3327] 287 (Path), [RFC5245] (ICE), [RFC3326] (Reason header), [RFC3515] (REFER 288 Method), [RFC3891] (Replaces Header), [RFC3892] (Referred-By). 290 RUEs MUST include a "User-Agent" header field uniquely identifying 291 the RUE application, platform, and version in all SIP requests, and 292 MUST include a "Server" header field with the same content in SIP 293 responses. 295 6.1. Registration 297 The RUE MUST register with a SIP registrar, following [RFC3261] and 298 [RFC5626]. If the configuration (please refer to Section 11) 299 contains multiple "outbound-proxies", then the RUE MUST use them as 300 specified in [RFC5626] to establish multiple flows. 302 The request-URI for the REGISTER request MUST contain the "provider- 303 domain" from the configuration. The To-URI and From-URI MUST be 304 identical URIs, formatted as specified in Section 13, using the 305 "phone-number" and "provider-domain" from the configuration. 307 The RUE determines the URI to resolve by initially determining if an 308 outbound proxy is configured. If it is, the URI will be that of the 309 outbound proxy. If no outbound proxy is configured, the URI will be 310 the Request-URI from the REGISTER request. The RUE extracts the 311 domain from that URI and consults the DNS record for that domain. 312 The DNS entry MUST contain NAPTR records conforming to RFC3263. One 313 of those NAPTR records MUST specify TLS as the preferred transport 314 for SIP. For example, a DNS NAPTR query for "sip: 315 p1.red.example.netv" could return: 317 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.p1.red.example.net 318 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.p1.red.example.net 320 If the RUE receives a 439 (First Hop Lacks Outbound Support) response 321 to a REGISTER request, it MUST re-attempt registration without using 322 the outbound mechanism. 324 The registrar MAY authenticate using SIP MD5 digest authentication. 325 The credentials to be used (username and password) MUST be supplied 326 within the credentials section of the configuration and identified by 327 the realm the registrar uses in a digest challenge. This username/ 328 password combination SHOULD NOT be the same as that used for other 329 purposes, such as retrieving the RUE configuration or logging into 330 the Provider's customer service portal. Because MD5 is considered 331 insecure, [I-D.yusef-sipcore-digest-scheme] SHOULD be implemented by 332 both the RUE and Providers and SHA-based digest algorithms SHOULD be 333 used for digest authentication. 335 If the registration request fails with an indication that credentials 336 from the configuration are invalid, then the RUE SHOULD retrieve a 337 fresh version of the configuration. If credentials from a freshly 338 retrieved configuration are found to be invalid, then the RUE MUST 339 cease attempts to register and SHOULD inform the RUE User of the 340 problem. 342 Support for multiple simultaneous registrations by Providers is 343 OPTIONAL, as described in Section 2. 345 Multiple simultaneous RUE SIP registrations from different RUE 346 devices with the same SIP URI SHOULD be permitted by the Provider. 347 The Provider MAY limit the total number of simultaneous 348 registrations. When a new registration request is received that 349 results in exceeding the limit on simultaneous registrations, the 350 Provider MAY then prematurely terminate another registration; 351 however, it SHOULD NOT do this if it would disconnect an active call. 353 If a Provider prematurely terminates a registration to reduce the 354 total number of concurrent registrations with the same URI, it SHOULD 355 take some action to prevent the affected RUE from automatically re- 356 registering and re-triggering the condition. 358 6.2. Session Establishment 360 6.2.1. Normal Call Origination 362 After initial SIP registration, the RUE adheres to SIP [RFC3261] 363 basic call flows, as documented in [RFC3665]. 365 The RUE MUST route all calls through the outbound proxy of the 366 default Provider. 368 INVITE requests used to initiate calls SHOULD NOT contain Route 369 headers. Route headers MAY be included in one-stage dial-around 370 calls and emergency calls. The SIP URIs in the To field and the 371 Request-URI MUST be formatted as specified in subsection 6.4 using 372 the destination phone number. The domain field of the URIs SHOULD be 373 the "provider-domain" from the configuration (e.g., 374 sip:+13115552368@red.example.com;user=phone). The same exceptions 375 apply, including anonymous calls. 377 Anonymous calls MUST be supported by both the RUE and Providers. An 378 anonymous call is signaled per [RFC3323]. 380 The From-URI MUST be formatted as specified in Section 6.4, using the 381 phone-number and "provider-domain" from the configuration. It SHOULD 382 also contain the display-name from the configuration when present. 383 (Please refer to Section 11.2.) 384 Negotiated media MUST follow the guidelines specified in Section 7 of 385 this document. 387 To allow time to timeout an unanswered call and direct it to a 388 videomail server, the User Agent Client MUST NOT impose a time limit 389 less than the default SIP Invite transaction timeout of 3 minutes. 391 6.2.2. One-Stage Dial-Around Origination 393 Outbound dial-around calls allow a RUE user to select any Provider to 394 provide interpreting services for any call. "Two-stage" dial-around 395 calls involve the RUE calling a telephone number that reaches the 396 dial-around Provider and using signing or DTMF to provide the called 397 party telephone number. In two-stage dial-around, the To URI is the 398 URI of the dial-around Provider and the domain of the URI is the 399 Provider domain from the configuration. 401 One-stage dial-around is a method where the called party telephone 402 number is provided in the To URI and the Request-URI, using the 403 domain of the dial-around Provider. 405 For one-stage dial-around, the RUE MUST follow the procedures in 406 Section 6.2.1 with the following exception: the domain part of the 407 SIP URIs in the To field and the Request-URI MUST be the domain of 408 the dial-around Provider, discovered according to Section 11.1. 410 The following is a partial example of a one-stage dial-around call 411 from VRS user +1-555-222-0001 hosted by red.example.com to a hearing 412 user +1-555-123-4567 using dial-around to green.example.com for the 413 relay service. Only important details of the messages are shown and 414 many header fields have been omitted: 416 ,-+-. ,----+----. ,-----+-----. 417 |RUE| |Default | |Dial-Around| 418 | | |Provider | | Provider | 419 `-+-' `----+----' `-----+-----' 420 | | | 421 | [1] INVITE | | 422 |-------------->| [2] INVITE | 423 | |-------------->| 425 Message Details: 427 [1] INVITE Rue -> Default Provider 429 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 430 To: 431 From: "Bob Smith" 432 Route: sip:green.example.net 434 [2] INVITE Default Provider -> Dial-Around Provider 436 INVITE sip:+15551234567@green.example.net;user=phone SIP/2.0 437 To: 438 From: "Bob Smith" sip:+18135551212@red.example.net;user=phone 439 P-Asserted-Identity: sip:+18135551212@red.example.net 441 One Stage Dial-Around 443 6.2.3. RUE Contact Information 445 To identify the owner of a RUE, the initial INVITE for a call from a 446 RUE, or the 200 OK accepting a call by a RUE, identifies the owner by 447 sending a Call-Info header with a purpose parameter of "rue-owner". 448 The URI MAY be an HTTPS URI or Content-Indirect URL. The latter is 449 defined by [RFC2392] to locate message body parts. This URI type is 450 present in a SIP message to convey the RUE ownership information as a 451 MIME body. The form of the RUE ownership information is an xCard. 452 Please refer to [RFC6442] for an example of using Content-Indirect 453 URLs in SIP messages. Note that use of the Content-Indirect URL 454 usually implies multiple message bodies ("mime/multipart"). 456 6.2.4. Incoming Calls 458 The RUE MUST accept inbound calls sent to it by the proxy mentioned 459 in the configuration. 461 If Multiple simultaneous RUE SIP registrations from different RUE 462 devices with the same SIP URI exist, the Provider MUST parallel fork 463 the call to all registered RUEs so that they ring at the same time. 464 The first RUE to reply with a 200 OK answers the call and the 465 Provider MUST CANCEL other call branches. 467 6.2.5. Emergency Calls 469 The RUE MUST comply with [RFC6881] for handling of emergency calls. 471 Providers MAY comply with RFC6881 for handling of emergency calls. 472 In addition, they MUST: 474 o Accept RUE emergency calls complying with the specifications in 475 this document; 477 o Recognize such calls as emergency calls and properly handle them 478 as such; 480 o Address other behavior not specified by RFC6881 as specified in 481 Section 6.2. 483 Specifically, if the emergency call is to be handled using E9-1-1 484 (VPC) procedures, the Provider is responsible for modifying the 485 INVITE to conform to the VPC requirements. In this case, location 486 MAY be extracted from the RFC6881 conformant INVITE and used to 487 propagate it to the VPC where possible with the emergency call. 488 Because the RUE may have a more accurate and timely location of the 489 device than the typical manual entry location for nomadic RUE 490 devices, the RUE MUST send a Geolocation header containing its 491 location in the REGISTER request if the configuration specifies it. 492 The Provider MAY use that information to populate the location of the 493 device in the VPC before any emergency call. 495 6.3. Mid Call Signaling 497 The RUE and Providers MUST support re-INVITE to renegotiate media 498 session parameters (among other uses). Per Section 8, the RUE MUST, 499 and providers SHOULD, be able to support an INFO request for full 500 frame refresh for devices in a call with the RUE that do not support 501 RTCP mechanisms (please refer to Section 8.3). The RUE MUST support 502 REFER 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 Relay Service URIs and User Address of Records (AoR) MUST resolve (in 521 accord with [RFC3263]) to globally routable IPv4 addresses. The AoRs 522 MAY also resolve to IPv6 addresses. 524 6.5. NAT Traversal 526 The RUE MUST support ICE [RFC5245] and MUST be able to use STUN 527 [RFC5389] and TURN [RFC5766] servers, when specified in the 528 configuration. If a STUN or TURN server issues a challenge for 529 digest credentials, the RUE MUST attempt to continue using matching 530 credentials from the configuration. 532 Providers MAY operate STUN and TURN servers for RUEs to use (please 533 refer to Section 11.2 for configuration). Alternatively, providers 534 MAY use Back to Back User Agents to modify media end points to 535 achieve NAT traversal. This may involve media relays. 537 The RUE and providers MUST support SIP outbound [RFC5626] (please 538 also refer to Section 6.1). 540 7. Media 542 7.1. Text-Based Communication 544 Real-time text support by Providers is OPTIONAL as described in 545 Section 2. 547 The RUE MUST and Providers SHOULD support real-time text ([RFC4102] 548 and [RFC4103]) via T.140 media. One original and two redundant 549 generations MUST be transmitted and supported, with a 300 ms 550 transmission interval. 552 7.2. Video Codecs 554 The RUE and Providers MUST implement the video/H.264 [RFC6184] 555 Constrained Baseline Profile, Level 1.3, packetization mode 1. H.265 556 Main Profile, Level 2.1 or better MAY be supported. 558 7.3. Audio Codecs 560 The RUE and Providers MUST support G.711 mu-law. Providers SHOULD, 561 and the RUE MUST, support G.722. In addition, G.722.1 and/or G.722.2 562 MAY also be supported. 564 7.4. DTMF Digits 566 The RUE and Providers MUST support the "audio/telephone-event" 567 [RFC4733] media type. They MUST support conveying event codes 0 568 through 11 (DTMF digits "0"-"9", "*","#") defined in Table 7 of 569 [RFC4733]. Handling of other tones is OPTIONAL. 571 7.5. Session Description Protocol 573 The SDP offers and answers MUST conform to the Offer/Answer 574 Section of the VRS US Provider Profile [pip] document. 576 7.6. Privacy 578 The RUE MUST be able to control privacy of the user by implementing a 579 one-way mute of audio and or video, without signaling, locally, but 580 MUST maintain any NAT bindings by periodically sending media packets 581 on all active media sessions containing silence/comfort noise/black 582 screen/etc. per [RFC6263]. 584 8. SRTP and SRTCP 586 All media streams between the RUE and another endpoint or relay 587 Provider MUST be exchanged using the secure real-time transport 588 protocol (SRTP) [RFC3550] using DTLS [RFC5763], [RFC5764], except 589 that for backwards compatibility with older video endpoints, RTP MAY 590 be negotiated if SRTP negotiation fails. All SRTP/RTP and SRTCP/RTCP 591 traffic over UDP MUST use symmetric RTP [RFC4961]. Receivers of 592 SRTP/RTP traffic MUST be capable of processing SRTP/RTP packets with 593 a different packetization rate than the rate used for sending. 595 8.1. Bandwidth Negotiation Flow Control and Media Performance 597 The RUE and Providers MUST support codec control messages as 598 described in [RFC5104]. During a call, codec control messages SHOULD 599 be used to negotiate maximum bitrate. Specifically, Temporary 600 Maximum Media Stream Bit Rate Request (TMMBR) SHOULD be used where 601 endpoints have detected the need to decrease or increase the bit 602 rate. Where either side of a session does not support CCM TMMBR, re- 603 INVITE messages MAY be used during a call to renegotiate the use of 604 bandwidth. 606 8.2. SRTP / SAVPF Profile for SRTCP Feedback 608 The RUE and Providers MUST support the SRTP/SAVPF profile per 609 [RFC4585] for SRTCP feedback support. Supporting the SRTP/SAVPF 610 profile allows implementations to use advanced RTCP mechanisms, like 611 indicating packet loss, requesting intra frame, and temporary bitrate 612 change indication, which are essential for video streams. 614 Supported SAVPF messages MUST be declared by RTCP Feedback 615 attributes. Because implementations convey media streams from RUEs 616 of varying background, there may be situations when no SAVPF 617 attributes are supported in a session. 619 For calls to devices that do not support SAVPF, it is recommended to 620 make an initial INVITE with "SAVPF". If some media are not accepted 621 with that profile, then a re-INVITE SHOULD be made with AVP 622 declaration on the non-accepted media and the other media unchanged. 623 The only combinations required are SAVPF and AVP. 625 8.3. Negative Acknowledgment, Packet Loss Indicator, and Full 626 Intraframe Request Features 628 NACK SHOULD be used when negotiated and conditions warrant its use. 629 Signaling picture losses as Packet Loss Indicator (PLI) SHOULD be 630 preferred, as described in [RFC5104]. 632 FIR SHOULD be used only in situations where not sending a decoder 633 refresh point would render the video unusable for the users, as per 634 RFC5104 subsection 4.3.1.2. 636 For backwards compatibility with calling devices that do not support 637 the foregoing methods, the RUE MUST implement and use SIP INFO 638 messages to send and receive XML encoded Picture Fast Update messages 639 according to [RFC5168]. 641 9. Contacts 643 9.1. CardDAV Login and Synchronization 645 Support of CardDAV by Providers is OPTIONAL, as described in 646 Section 2. 648 The RUE MUST and Providers MAY be able to synchronize the user's 649 contact directory between the RUE endpoint and one maintained by the 650 user's VRS provider using CardDAV ([RFC6352] and [RFC6764]). 652 The configuration MAY supply a username and domain identifying a 653 CardDAV server and address book for this account. 655 To access the CardDAV server and address book, the RUE MUST follow 656 Section 6 of RFC6764, using the chosen username and domain in place 657 of an email address. If the request triggers a challenge for digest 658 authentication credentials, the RUE MUST attempt to continue using 659 matching "credentials" from the configuration. If no matching 660 credentials are configured, the RUE MUST use the SIP credentials from 661 the configuration. If the SIP credentials fail, the RUE MUST query 662 the user. 664 Synchronization using CardDAV MUST be a two-way synchronization 665 service, with proper handling of asynchronous adds, changes, and 666 deletes at either end of the transport channel. 668 9.2. Contacts Import/Export Service 670 Each Provider MUST supply a standard xCard import/export interface 671 and the RUE MUST be able to export/import the list of contacts in 672 xCard [RFC6351] XML format. 674 The RUE accesses this service via the "contacts" URI in the 675 configuration. The URL MUST resolve to identify a web server 676 resource that imports/exports contact lists for authorized users. 678 The RUE stores/retrieves the contact list (address book) by issuing 679 an HTTPS POST or GET request. If the request triggers a challenge 680 for digest authentication credentials, the RUE MUST attempt to 681 continue using matching "credentials" from the configuration. If no 682 credentials are configured, the RUE MUST query the user. 684 10. Mail Waiting Indicator (MWI) 686 Support of MWI by Providers is OPTIONAL, as described in Section 2 688 The RUE MUST and Providers SHOULD support subscriptions to "message- 689 summary" events [RFC3842] to the URI specified in the configuration 690 if the Provider supports message waiting indicator on any endpoint. 692 In notification bodies, videomail messages SHOULD be reported using 693 "message-context-class multimedia-message" defined in [RFC3458]. 695 11. Provisioning and Provider Selection 697 11.1. RUE Provider Selection 699 To allow the user to select a relay service, the RUE MAY obtain, on 700 startup, a list of Providers from a configured accessible URL. 702 The provider list, formatted as JSON, contains: 704 o Version: Specifies the version number of the Provider list format. 705 A new version number SHOULD only be used if the new version is not 706 backwards-compatible with the older version. A new version number 707 is not needed if new elements are optional and can be ignored by 708 older implementations. 710 o Providers: An array where each entry describes one Provider. Each 711 entry consists of the following items: 713 * name: This parameter contains the text label identifying the 714 Provider and is meant to be displayed to the human VRS user. 716 * domain: The domain parameter is used for configuration purposes 717 by the RUE (as discussed in Section 11.2) and as the domain to 718 use when targeting one-stage dial-around calls to this Provider 719 (as discussed in Section 6.2.2). 721 * operator: (OPTIONAL) The operator parameter is a SIP URL that 722 identifies the operator "front-door" that VRS users may contact 723 for manual (two-stage) dial-around calls. 725 The VRS user interacts with the RUE to select from the Provider list 726 one or more Providers with whom the user has already established an 727 account. 729 { 730 "version": 1, 731 "providers": [ 732 { 733 "name": "Red", 734 "domain": "red.example.net", 735 "operator": "sip:operator@red.example.net" 736 }, 737 { 738 "name": "Green", 739 "domain": "green.example.net", 740 "operator": "sip:+18885550123@green.example.net;user=phone" 741 }, 742 { 743 "name": "Blue", 744 "domain": "blue.example.net" 745 } 746 ] 747 } 749 Example of a Provider list JSON object 751 11.2. RUE Configuration Service 753 The RUE is provisioned with one or more URIs that may be queried for 754 configuration with HTTPS. 756 The data returned will include a set of key/value configuration 757 parameters to be used by the RUE, formatted as a JSON object and 758 identified by the associated [RFC7159] "application/json" MIME type, 759 to allow for other formats in the future. 761 The configuration data payload includes the following data items. 762 Items not noted as (OPTIONAL) are REQUIRED. If other unexpected 763 items are found, they MUST be ignored. 765 o version: Identifies the version of the configuration data format. 766 A new version number SHOULD only be used if the new version is not 767 backwards-compatible with the older version. A new version number 768 is not needed if new elements are optional and can be ignored by 769 older implementations. 771 o lifetime: Specifies how long (in seconds) the RUE MAY cache the 772 configuration values. 774 o display-name: (OPTIONAL) A user-friendly name to identify the 775 subscriber when originating calls. 777 o phone-number: The telephone number (in E.164 format) assigned to 778 this subscriber. This becomes the user portion of the SIP URI 779 identifying the subscriber. 781 o provider-domain: The DNS domain name of the default Provider 782 servicing this subscriber. 784 o outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be 785 used when sending requests to the Provider. Multiple URIs 786 identify alternative (redundant) paths to the Provider. 788 o mwi: (OPTIONAL) A URI identifying a SIP event server that 789 generates "message-summary" events for this subscriber. 791 o videomail: (OPTIONAL) A SIP URI that can be called to retrieve 792 videomail messages. 794 o contacts: An HTTPS URI that may be used to export (retrieve) the 795 subscriber's complete contact list managed by the Provider. 797 o carddav: (OPTIONAL) A username and domain name (separated by 798 ""@"") identifying a "CardDAV" server and user name that can be 799 used to synchronize the RUE's contact list with the contact list 800 managed by the Provider. 802 o sendLocationWithRegistration: True if the RUE should send a 803 Geolocation Header with REGISTER, false if it should not. 804 Defaults to false if not present. 806 o ice-servers: (OPTIONAL) An array of URLs identifying STUN and TURN 807 servers available for use by the RUE for establishing media 808 streams in calls via the Provider. 810 o credentials: (OPTIONAL) An array of sets of credentials available 811 for use in responding to SIP, HTTP, contacts, cardDAV, STUN, and 812 TURN digest authentication challenges from specified realms. Each 813 set consists of the following items: 815 * realm: The realm to which this set of credentials applies. 817 * username: The username field to be used in responding to a 818 challenge. 820 * password: The password to use in generating the response to the 821 challenge. 823 { 824 "version": 1, 825 "lifetime": 86400, 826 "display-name" : "Bob Smith", 827 "phone-number": "+18135551212", 828 "provider-domain": "red.example.net", 829 "outbound-proxies": [ 830 "sip:p1.red.example.net", 831 "sip:p2.red.example.net" 832 ], 833 "mwi": "sip:+18135551212@red.example.net", 834 "videomail": "sip:+18135551212@vm.red.example.net", 835 "contacts": "https://red.example.net:443/contacts/1dess45awd" 836 "carddav": "bob@red.example.com" , 837 "sendLocationWithRegistration": false, 838 "ice-servers": [ 839 {"stun:stun.l.google.com:19302" }, 840 {"turn:turn.red.example.net:3478"} 841 ], 842 "credentials": [ 843 { 844 "realm": "red.example.net", 845 "username": "bob", 846 "password": "reg-pw" 848 }, 849 { 850 "realm": "proxies.red.example.net", 851 "username": "bob", 852 "password": "proxy-pw" 853 }, 854 { 855 "realm": "cd.red.example.net", 856 "username": "bob", 857 "password": "cd-pw" 858 }, 859 { 860 "realm": "vm.red.example.net", 861 "username": "bob", 862 "password": "vm-pw" 863 }, 864 { 865 "realm": "stun-turn.red.example.net", 866 "username": "bob", 867 "password": "stun-turn-pw" 868 } 869 ] 870 } 872 Example JSON configuration payload 874 The wire format of the data is in keeping with the standard JSON 875 description in RFC7159. 877 The "lifetime" parameter in the configuration indicates how long the 878 RUE MAY cache the configuration values. If the RUE caches 879 configuration values, it MUST cryptographically protect them. The 880 RUE SHOULD retrieve a fresh copy of the configuration before the 881 lifetime expires or as soon as possible after it expires. The 882 lifetime is not guaranteed: the configuration may change before the 883 lifetime value expires. In that case, the Provider MAY indicate this 884 by generating authorization challenges to requests and/or prematurely 885 terminating a registration. 887 Note: In some cases, the RUE may successfully retrieve a fresh copy 888 of the configuration using digest credentials cached from the prior 889 retrieval. If this is not successful, then the RUE will need to ask 890 the user for the username and password. Unfortunately, this 891 authentication step might occur when the user is not present, 892 preventing SIP registration and thus incoming calls. To avoid this 893 situation, the RUE MAY retrieve a new copy of the configuration when 894 it knows the user is present, even if there is time before the 895 lifetime expires. 897 11.3. Schemas 899 The following JSON schemas are for the Provider List and the RUE 900 Configuration. These are represented using the JSON Content Rules 901 [JCR] schema notation. 903 { 904 "version": 1, 905 "providers": [ 906 1* 907 { 908 "name": string, 909 "domain": fqdn, 910 ?"operator": ; "front-door" access to provider 911 uri, ; (sip uri) 912 * /^.*$/ : any ; (allow future extensions) 913 } 914 ] , 915 * /^.*$/ : any ; (allow future extensions) 916 } 918 Provider List JSON Schema 920 { 921 "version": 1, ; Interface version 922 "lifetime": integer, ; Deadline (in seconds) for 923 ; refreshing this config without 924 ; user input. 925 "phone-number": /^\+[0-9]+$/ , ; E.164 phone number 926 ; for this user 927 ?"display-name" : string,; display name for From: header 928 "provider-domain": fqdn, ; SHOULD match that in Provider List 929 ?"outbound-proxies": [ 1* : uri ], ; sip URIs 930 ?"mwi": uri , ; sip URI for MWI subscriptions 931 ?"videomail": uri , ; sip URI for videomail retrieval 932 "contacts": uri , ; https URI for contact list retrieval 933 ?"carddav": /^[^@]+@[^@]+$/ , ; for contact list synch 934 ?"sendLocationWithRegistration": boolean , ; send location y/n 935 ?"ice-servers": ; (Required for ICE use) 936 [ 1* : uri ], ; (stun[s] & turn[s] URIs 937 ?"credentials": ; for digest authentication 938 [ 1* { 939 "realm": string, 940 "username": string, 941 "password": string 942 } ], 943 * /^.*$/ : any ; (allow future extensions) 944 } 946 RUE Configuration JSON Schema 948 The following illustrates the message flow for retrieving a RUE 949 automatic configuration using HTTPS Digest Authentication: 951 ,-. 952 `-' 953 /|\ ,---. ,---. ,------------. ,----------------. ,---. 954 | |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 955 / \ | | | | | | |Global Settings | | | 956 RUE User `-+-' `-+-' `-----+------' `--------+-------' `-+-' 957 | | | | | | 958 [1] Select a VRS Provider name | | | 959 | ------->| | | | | 960 | | | | | | 961 [2] NAPTR "SFUA.CFG" red.example.net | | 962 | |----->| | | | 963 | | | | | | 964 [3] NAPTR "!.*!https://server.red.example.net/!" | | 965 | |<-----| | | | 966 | | | | | | 967 [4] If NAPTR found, query DNS server.red.example.net | 968 | |----->| | | | 969 | | | | | | 970 [5] If NXDOMAIN, query DNS config.red.example.net | | 971 | | - - >| | | | 972 | | | | | | 973 [6] IP Address of Config Server | | | 974 | |<-----| | | | 975 | | | | | | 976 [7] Establish TLS connection | | | 977 | |<--------------->| | | 978 | | | | | | 979 [8] HTTP: https://config.red.example.net/v1 | | 980 | |---------------->| | | 981 | | | | | | 982 [9] HTTP: 401 Unauthorized | | | 983 WWW-Authenticate Digest realm="Y" qop="auth,auth-int" nonce=| 984 | |<----------------| | | 985 | | | | | | 986 [10] Query for userid/pw | | | 987 |<--------| | | | | 988 | | | | | | 989 [11] User="bob", pw="bob's global provider pw" | | 990 |-------->| | | | | 991 | | | | | | 992 [12] HTTP: https://config.red.example.net/v1 | | 993 | Authorization Digest username="bob" realm="Y" qop="auth" | 994 | nonce=... response="..." ... | | 995 | |---------------->| | | 996 | | | | | | 997 | [13] Find subscriber information for username="bob" | 998 | | | |----------------------------->| 999 | | | | | | 1000 | [14] Subscriber specific configuration information | 1001 | | | |<-----------------------------| 1002 | | | | | | 1003 | [15] Retrieve provider specific settings | 1004 | | | |---------------->| | 1005 | | | | | | 1006 | [16] Provider configuration information | | 1007 | | | |<----------------| | 1008 | | | | | | 1009 [17] 200 OK + JSON merge subscriber + provider configs | 1010 | |<----------------| | | 1011 | | | | | | 1012 RUE User ,---. ,---. ,------------. ,----------------. ,---. 1013 ,-. |RUE| |DNS| |HTTPS Server| | Provider | |CRM| 1014 `-' | | | | | | |Global Settings | | | 1015 /|\ `-+-' `-+-' `-----+------' `--------+-------' `-+-' 1016 | 1017 / \ 1019 RUE Configuration Retrieval 1021 12. Acknowledgements 1023 13. IANA Considerations 1025 This memo includes no request to IANA. 1027 14. Security Considerations 1029 The RUE is required to communicate with servers on public IP 1030 addresses and specific ports to perform its required functions. If 1031 it is necessary for the RUE to function on a corporate or other 1032 network that operates a default-deny firewall between the RUE and 1033 these services, the user must arrange with their network manager for 1034 passage of traffic through such a firewall in accordance with the 1035 protocols and associated SRV records as exposed by the Provider. 1036 Because VRS providers may use different ports for different services, 1037 these port numbers may differ from Provider to Provider. 1039 15. Normative References 1041 [I-D.yusef-sipcore-digest-scheme] 1042 Shekh-Yusef, R., "The Session Initiation Protocol (SIP) 1043 Digest Authentication Scheme", draft-yusef-sipcore-digest- 1044 scheme-06 (work in progress), September 2017. 1046 [pip] SIPForum, "VRS US Providers Profile TWG-6-1.0", 2015, 1047 . 1050 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1051 Requirement Levels", BCP 14, RFC 2119, 1052 DOI 10.17487/RFC2119, March 1997, 1053 . 1055 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1056 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 1057 . 1059 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1060 A., Peterson, J., Sparks, R., Handley, M., and E. 1061 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1062 DOI 10.17487/RFC3261, June 2002, 1063 . 1065 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1066 Protocol (SIP): Locating SIP Servers", RFC 3263, 1067 DOI 10.17487/RFC3263, June 2002, 1068 . 1070 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1071 with Session Description Protocol (SDP)", RFC 3264, 1072 DOI 10.17487/RFC3264, June 2002, 1073 . 1075 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1076 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 1077 2002, . 1079 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1080 Initiation Protocol (SIP)", RFC 3323, 1081 DOI 10.17487/RFC3323, November 2002, 1082 . 1084 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1085 Header Field for the Session Initiation Protocol (SIP)", 1086 RFC 3326, DOI 10.17487/RFC3326, December 2002, 1087 . 1089 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 1090 (SIP) Extension Header Field for Registering Non-Adjacent 1091 Contacts", RFC 3327, DOI 10.17487/RFC3327, December 2002, 1092 . 1094 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1095 Context for Internet Mail", RFC 3458, 1096 DOI 10.17487/RFC3458, January 2003, 1097 . 1099 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1100 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1101 . 1103 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1104 Jacobson, "RTP: A Transport Protocol for Real-Time 1105 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1106 July 2003, . 1108 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1109 in Session Description Protocol (SDP)", RFC 3605, 1110 DOI 10.17487/RFC3605, October 2003, 1111 . 1113 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1114 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1115 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1116 December 2003, . 1118 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1119 "Indicating User Agent Capabilities in the Session 1120 Initiation Protocol (SIP)", RFC 3840, 1121 DOI 10.17487/RFC3840, August 2004, 1122 . 1124 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1125 Indication Event Package for the Session Initiation 1126 Protocol (SIP)", RFC 3842, DOI 10.17487/RFC3842, August 1127 2004, . 1129 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1130 Protocol (SIP) "Replaces" Header", RFC 3891, 1131 DOI 10.17487/RFC3891, September 2004, 1132 . 1134 [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) 1135 Referred-By Mechanism", RFC 3892, DOI 10.17487/RFC3892, 1136 September 2004, . 1138 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1139 Tone Generation in the Session Initiation Protocol (SIP)", 1140 RFC 3960, DOI 10.17487/RFC3960, December 2004, 1141 . 1143 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 1144 RFC 3966, DOI 10.17487/RFC3966, December 2004, 1145 . 1147 [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", 1148 RFC 4102, DOI 10.17487/RFC4102, June 2005, 1149 . 1151 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 1152 Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, 1153 . 1155 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1156 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1157 July 2006, . 1159 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1160 "Extended RTP Profile for Real-time Transport Control 1161 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1162 DOI 10.17487/RFC4585, July 2006, 1163 . 1165 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1166 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1167 DOI 10.17487/RFC4733, December 2006, 1168 . 1170 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 1171 BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, 1172 . 1174 [RFC4967] Rosen, B., "Dial String Parameter for the Session 1175 Initiation Protocol Uniform Resource Identifier", 1176 RFC 4967, DOI 10.17487/RFC4967, July 2007, 1177 . 1179 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1180 "Codec Control Messages in the RTP Audio-Visual Profile 1181 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1182 February 2008, . 1184 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1185 Media Control", RFC 5168, DOI 10.17487/RFC5168, March 1186 2008, . 1188 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1189 (ICE): A Protocol for Network Address Translator (NAT) 1190 Traversal for Offer/Answer Protocols", RFC 5245, 1191 DOI 10.17487/RFC5245, April 2010, 1192 . 1194 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1195 (TLS) Protocol Version 1.2", RFC 5246, 1196 DOI 10.17487/RFC5246, August 2008, 1197 . 1199 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1200 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1201 DOI 10.17487/RFC5389, October 2008, 1202 . 1204 [RFC5393] Sparks, R., Ed., Lawrence, S., Hawrylyshen, A., and B. 1205 Campen, "Addressing an Amplification Vulnerability in 1206 Session Initiation Protocol (SIP) Forking Proxies", 1207 RFC 5393, DOI 10.17487/RFC5393, December 2008, 1208 . 1210 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1211 "Managing Client-Initiated Connections in the Session 1212 Initiation Protocol (SIP)", RFC 5626, 1213 DOI 10.17487/RFC5626, October 2009, 1214 . 1216 [RFC5658] Froment, T., Lebel, C., and B. Bonnaerens, "Addressing 1217 Record-Route Issues in the Session Initiation Protocol 1218 (SIP)", RFC 5658, DOI 10.17487/RFC5658, October 2009, 1219 . 1221 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1222 for Establishing a Secure Real-time Transport Protocol 1223 (SRTP) Security Context Using Datagram Transport Layer 1224 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1225 2010, . 1227 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1228 Security (DTLS) Extension to Establish Keys for the Secure 1229 Real-time Transport Protocol (SRTP)", RFC 5764, 1230 DOI 10.17487/RFC5764, May 2010, 1231 . 1233 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1234 Relays around NAT (TURN): Relay Extensions to Session 1235 Traversal Utilities for NAT (STUN)", RFC 5766, 1236 DOI 10.17487/RFC5766, April 2010, 1237 . 1239 [RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., 1240 "Essential Correction for IPv6 ABNF and URI Comparison in 1241 RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, 1242 . 1244 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1245 Payload Format for H.264 Video", RFC 6184, 1246 DOI 10.17487/RFC6184, May 2011, 1247 . 1249 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 1250 Keeping Alive the NAT Mappings Associated with RTP / RTP 1251 Control Protocol (RTCP) Flows", RFC 6263, 1252 DOI 10.17487/RFC6263, June 2011, 1253 . 1255 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 1256 RFC 6351, DOI 10.17487/RFC6351, August 2011, 1257 . 1259 [RFC6352] Daboo, C., "CardDAV: vCard Extensions to Web Distributed 1260 Authoring and Versioning (WebDAV)", RFC 6352, 1261 DOI 10.17487/RFC6352, August 2011, 1262 . 1264 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1265 for the Session Initiation Protocol", RFC 6442, 1266 DOI 10.17487/RFC6442, December 2011, 1267 . 1269 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1270 DOI 10.17487/RFC6665, July 2012, 1271 . 1273 [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions 1274 to WebDAV (CalDAV) and vCard Extensions to WebDAV 1275 (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, 1276 . 1278 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1279 Communications Services in Support of Emergency Calling", 1280 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1281 . 1283 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1284 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1285 2014, . 1287 Authors' Addresses 1289 Brian Rosen 1290 Mars, PA 1291 US 1293 Phone: +1 724 382 1051 1294 Email: br@brianrosen.net 1295 Jim Malloy 1296 The MITRE Corporation 1297 McLean, VA 1298 US 1300 Phone: +1 703 983 2835 1301 Email: jmalloy@mitre.org 1303 Brett Henderson 1304 The MITRE Corporation 1305 McLean, VA 1306 US 1308 Phone: +1 619 758 6071 1309 Email: brhenderson@mitre.org