Telecommunications Relay Service Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)
draft-kyzivat-dispatch-trs-call-info-purpose-01

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 24, 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.

Table of Contents

• 1. Introduction
• 2. Requirements
• 3. Mechanism
• 4. Security Considerations
• 5. IANA Considerations
• 6. Informative References
• Author's Address

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 to/from any user of the public telephone system into other modalities (such as American Sign Language) that can be used by these TRS users. These services are being updated to employ SIP signaling.

TRS services are supplied by a number of private TRS service providers. Individual TRS users enroll with one provider, and the providers peer with one another and with public telecommunications providers to provide connectivity equivalent with the basic telephone network. Users enrolled with one provider are legally entitled to request and receive relay services from any of the other providers on a call-by-call basis. In that case the default provider acts as an intermediary between the TRS user's device and the provider selected by the user to provide the service for the call.

Telephone users who call a TRS user are by default routed to the default provider for that user, and provided TRS relay service by the default provider. However, callers are also entitled to call a TRS provider of their choice and request connection to a TRS user enrolled with a different provider. In that case the TRS provider called by the user provides the relay service and the default provider acts as an intermediary.

For a provider to receive reimbursement for providing relay service on a call the FCC requires that the provider supply call detail including the IP address of the device the TRS user is using for the call. When the service provider that is rendering the service is not the one enrolling the user this information may not be available naturally in the SIP signaling.

In some simple cases the IP address of the deaf 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.

This document identifies requirements for a new mechanism, not currently available in SIP, for the described environment to function, and defines a SIP mechanism to meet those requirements.

2. Requirements

[TRS-1]

The mechanism must support carrying the IP address of the source of a request in an INVITE request.

[TRS-2]

The mechanism must support carrying the IP address of the target of an INVITE request in the responses to that request.

[TRS-3]

The mechanism must work in the presence of B2BUA intermediaries in the signaling path.

[TRS-4]

It must be possible for intermediaries to insert the IP address on behalf of the source or recipient.

[TRS-5]

It must be possible for intermediaries to remove or obfuscate the IP address to enforce trust and privacy policies.

[TRS-6]

The mechanism must support topologies where the source and/or target use a signaling protocol other than SIP (e.g. H.323) and an intermediary converts the signaling to/from SIP.

3. Mechanism

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 a URI containing the IP address of the deaf user. To distinguish this 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:

• in requests sent toward a peer TRS server when this server knows the the device originating the request is an enrolled TRS device;
• in responses sent toward a peer TRS server when this server knows that the target of the corresponding request is an enrolled TRS device.

4. 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.]

5. 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.

6. Informative References

Author's Address