IETF P. Kyzivat Internet-Draft Sorenson Communications Intended status: Informational January 13, 2015 Expires: July 17, 2015 Telecommunications Relay Service Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) draft-kyzivat-dispatch-trs-call-info-purpose-00 Abstract This document defines and registers a value of "original-identity" for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 17, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Kyzivat Expires July 17, 2015 [Page 1] Internet-Draft TRS Call-Info Purpose January 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5. Informative References . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction The United States Federal Communications Commission (FCC) sponsors specialized Telecommunications Relay Services (TRS) for US residents who are deaf, deaf-blind, and hard-of-hearing. These "relay" services translate audio telephone calls into other modalities that can be used by these TRS users. These services are being updated to employ SIP signaling. TRS services are provided by a number of private service providers. Individual users enroll with a provider, and the providers peer with one another and with public telecommunications providers to provide connectivity equivalent with basic telephone network. Users enrolled with one provider may receive relay services from another provider. For providers to receive reimbursement for handling a call the FCC requires that the provider supply call detail including the URI of the device the hearing impaired user is using for the call. When the service provider that is rendering the service is not the one enrolling the user this information is not necessarily available naturally in the SIP signaling. To meet the requirement, this document defines a SIP extension to carry the URI of the user's device from the server enrolling the user to the server providing the service. 2. Mechanism In some simple cases the URI of the hearing impaired user could be present in the signaling as the Contact URI of the caller or callee. However this is often not case due to the presence of intermediate devices acting as B2BUAs. B2BUAs often modify the Contact URI, because they need the downstream entity to contact the B2BUA rather than the actual contact. There are relay services that actually need the "real" contact URI, and TRS is one of them. To provide a mechanism that supplies the needed information in common deployments, this document calls for using the SIP Call-Info header field to carry the hearing impaired user's URI. To distinguish this Kyzivat Expires July 17, 2015 [Page 2] Internet-Draft TRS Call-Info Purpose January 2015 use of Call-Info from other uses, a new 'purpose' parameter value ("original-identity") is used. For example: Call-Info: sip:10.1.1.1; purpose="original-identity" A Call-Info with this purpose can be inserted by a server in requests and responses in the following cases: o in requests sent toward a peer TRS server when this server knows the the device originating the request is an enrolled TRS device; o in responses sent toward a peer TRS server when this server knows that the target of the corresponding request is an enrolled TRS device. 3. Security Considerations The security considerations for the extension defined herein are comparable to those for the Contact-URI. The security considerations of [RFC3261] apply to this extension and deal with disclosure of this information to entities that are not in the signaling path for the call. In the case where the caller or callee wishes to withhold its identity from the other UA in the call, the considerations of [RFC3323] can be employed. Because 'original-identity' is used to enable an intermediary to provide service, user-provided-privacy is not an option, and network-provided-privacy is the only option. TRS service providers MUST act as a privacy service and remove or anonymize the URI in a Call-Info with purpose 'original-identity' when providing 'header' privacy. [NOTE: I would prefer to avoid having to define specific extensions to RFC3323 for this, and complex normative requirements. But I'm not sure it is possible to avoid doing so.] 4. IANA Considerations This document defines and registers a new predefined value "original- identity" for the "purpose" header field parameter of the Call-Info header field (defined in [RFC3261]), following the procedures specified in [RFC3968]. IANA is requested to revise the existing entry for the Call-Info header Field in the "Header Field Parameters and Parameter Values" table of the "Session Initiation Protool (SIP) Parameters" registry, by adding a reference to this document. Kyzivat Expires July 17, 2015 [Page 3] Internet-Draft TRS Call-Info Purpose January 2015 5. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004. Author's Address Paul Kyzivat Sorenson Communications Hudson, MA US Email: pkyzivat@alum.mit.edu Kyzivat Expires July 17, 2015 [Page 4]