idnits 2.17.1 draft-kyzivat-dispatch-trs-call-info-purpose-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 160: '...ervice providers MUST act as a privacy...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 20, 2015) is 3384 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TRS-1' is mentioned on line 108, but not defined == Missing Reference: 'TRS-2' is mentioned on line 111, but not defined == Missing Reference: 'TRS-3' is mentioned on line 114, but not defined == Missing Reference: 'TRS-4' is mentioned on line 117, but not defined == Missing Reference: 'TRS-5' is mentioned on line 120, but not defined == Missing Reference: 'TRS-6' is mentioned on line 123, but not defined Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF P. Kyzivat 3 Internet-Draft US VRS Providers 4 Intended status: Informational January 20, 2015 5 Expires: July 24, 2015 7 Telecommunications Relay Service Purpose for the Call-Info Header Field 8 in the Session Initiation Protocol (SIP) 9 draft-kyzivat-dispatch-trs-call-info-purpose-01 11 Abstract 13 This document defines and registers a value of "original-identity" 14 for the "purpose" header field parameter of the Call-Info header 15 field in the Session Initiation Protocol (SIP). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 24, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. Informative References . . . . . . . . . . . . . . . . . . . 4 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1. Introduction 61 The United States Federal Communications Commission (FCC) sponsors 62 specialized Telecommunications Relay Services (TRS) for US residents 63 who are deaf, deaf-blind, and hard-of-hearing. These "relay" 64 services translate audio telephone calls to/from any user of the 65 public telephone system into other modalities (such as American Sign 66 Language) that can be used by these TRS users. These services are 67 being updated to employ SIP signaling. 69 TRS services are supplied by a number of private TRS service 70 providers. Individual TRS users enroll with one provider, and the 71 providers peer with one another and with public telecommunications 72 providers to provide connectivity equivalent with the basic telephone 73 network. Users enrolled with one provider are legally entitled to 74 request and receive relay services from any of the other providers on 75 a call-by-call basis. In that case the default provider acts as an 76 intermediary between the TRS user's device and the provider selected 77 by the user to provide the service for the call. 79 Telephone users who call a TRS user are by default routed to the 80 default provider for that user, and provided TRS relay service by the 81 default provider. However, callers are also entitled to call a TRS 82 provider of their choice and request connection to a TRS user 83 enrolled with a different provider. In that case the TRS provider 84 called by the user provides the relay service and the default 85 provider acts as an intermediary. 87 For a provider to receive reimbursement for providing relay service 88 on a call the FCC requires that the provider supply call detail 89 including the IP address of the device the TRS user is using for the 90 call. When the service provider that is rendering the service is not 91 the one enrolling the user this information may not be available 92 naturally in the SIP signaling. 94 In some simple cases the IP address of the deaf user could be present 95 in the signaling as the Contact URI of the caller or callee. However 96 this is often not case due to the presence of intermediate devices 97 acting as B2BUAs. B2BUAs often modify the Contact URI, because they 98 need the downstream entity to contact the B2BUA rather than the 99 actual contact. There are relay services that actually need the 100 "real" contact URI, and TRS is one of them. 102 This document identifies requirements for a new mechanism, not 103 currently available in SIP, for the described environment to 104 function, and defines a SIP mechanism to meet those requirements. 106 2. Requirements 108 [TRS-1] The mechanism must support carrying the IP address of the 109 source of a request in an INVITE request. 111 [TRS-2] The mechanism must support carrying the IP address of the 112 target of an INVITE request in the responses to that request. 114 [TRS-3] The mechanism must work in the presence of B2BUA 115 intermediaries in the signaling path. 117 [TRS-4] It must be possible for intermediaries to insert the IP 118 address on behalf of the source or recipient. 120 [TRS-5] It must be possible for intermediaries to remove or 121 obfuscate the IP address to enforce trust and privacy policies. 123 [TRS-6] The mechanism must support topologies where the source and/ 124 or target use a signaling protocol other than SIP (e.g. H.323) 125 and an intermediary converts the signaling to/from SIP. 127 3. Mechanism 129 To provide a mechanism that supplies the needed information in common 130 deployments, this document calls for using the SIP Call-Info header 131 field to carry a URI containing the IP address of the deaf user. To 132 distinguish this use of Call-Info from other uses, a new 'purpose' 133 parameter value ("original-identity") is used. For example: 135 Call-Info: ; purpose=original-identity 137 A Call-Info with this purpose can be inserted by a server in requests 138 and responses in the following cases: 140 o in requests sent toward a peer TRS server when this server knows 141 the the device originating the request is an enrolled TRS device; 143 o in responses sent toward a peer TRS server when this server knows 144 that the target of the corresponding request is an enrolled TRS 145 device. 147 4. Security Considerations 149 The security considerations for the extension defined herein are 150 comparable to those for the Contact-URI. The security considerations 151 of [RFC3261] apply to this extension and deal with disclosure of this 152 information to entities that are not in the signaling path for the 153 call. 155 In the case where the caller or callee wishes to withhold its 156 identity from the other UA in the call, the considerations of 157 [RFC3323] can be employed. Because 'original-identity' is used to 158 enable an intermediary to provide service, user-provided-privacy is 159 not an option, and network-provided-privacy is the only option. TRS 160 service providers MUST act as a privacy service and remove or 161 anonymize the URI in a Call-Info with purpose 'original-identity' 162 when providing 'header' privacy. 164 [NOTE: I would prefer to avoid having to define specific extensions 165 to RFC3323 for this, and complex normative requirements. But I'm not 166 sure it is possible to avoid doing so.] 168 5. IANA Considerations 170 This document defines and registers a new predefined value "original- 171 identity" for the "purpose" header field parameter of the Call-Info 172 header field (defined in [RFC3261]), following the procedures 173 specified in [RFC3968]. 175 IANA is requested to revise the existing entry for the Call-Info 176 header Field in the "Header Field Parameters and Parameter Values" 177 table of the "Session Initiation Protool (SIP) Parameters" registry, 178 by adding a reference to this document. 180 6. Informative References 182 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 183 A., Peterson, J., Sparks, R., Handley, M., and E. 184 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 185 June 2002. 187 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 188 Initiation Protocol (SIP)", RFC 3323, November 2002. 190 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 191 (IANA) Header Field Parameter Registry for the Session 192 Initiation Protocol (SIP)", BCP 98, RFC 3968, December 193 2004. 195 Author's Address 197 Paul Kyzivat 198 US VRS Providers 199 Hudson, MA 200 US 202 Email: pkyzivat@alum.mit.edu