IETF P. Kyzivat
Internet-Draft US VRS Providers
Intended status: Informational January 20, 2015
Expires: July 24, 2015
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.
Kyzivat Expires July 24, 2015 [Page 1]
Internet-Draft TRS Call-Info Purpose January 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Informative References . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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
Kyzivat Expires July 24, 2015 [Page 2]
Internet-Draft TRS Call-Info Purpose January 2015
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:
o in requests sent toward a peer TRS server when this server knows
the the device originating the request is an enrolled TRS device;
Kyzivat Expires July 24, 2015 [Page 3]
Internet-Draft TRS Call-Info Purpose January 2015
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.
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
[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.
Kyzivat Expires July 24, 2015 [Page 4]
Internet-Draft TRS Call-Info Purpose January 2015
[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
US VRS Providers
Hudson, MA
US
Email: pkyzivat@alum.mit.edu
Kyzivat Expires July 24, 2015 [Page 5]