Request for Comments: 4244 Nortel
Category: Standards Track November 2005
An Extension to the Session Initiation Protocol (SIP)
for Request History Information
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP)
request. This capability enables many enhanced services by providing
the information as to how and why a call arrives at a specific
application or user. This document defines a new optional SIP
header, History-Info, for capturing the history information in
requests.
Table of Contents
1. Introduction ....................................................2
1.1. Overview ...................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Background: Why define a Generic "Request History"
capability? ................................................3
2. "Request History" Requirements ..................................4
2.1. Security Requirements ......................................6
2.2. Privacy Requirements .......................................7
3. Request History Information Description .........................7
3.1. Optionality of History-Info ................................8
3.2. Securing History-Info ......................................8
3.3. Ensuring the Privacy of History-Info .......................9
4. Request History Information Protocol Details ....................9
4.1. Protocol Structure of History-Info ........................10
4.2. Protocol Examples .........................................11
4.3. Protocol Usage ............................................12
4.3.1. User Agent Client (UAC) Behavior ...................12
4.3.2. User Agent Server (UAS) Behavior ...................13
4.3.3. Proxy Behavior .....................................13
4.3.4. Redirect Server Behavior ...........................18
4.4. Security for History-Info .................................18
4.5. Example Applications Using History-Info ...................19
4.5.1. Example with Privacy Header for Entire
Request at Proxy2 ..................................21
4.5.2. Example with Privacy Header for Specific
URI (UA4) at Proxy2 ................................22
5. Application Considerations .....................................24
6. Security Considerations ........................................25
7. IANA Considerations ............................................25
7.1. Registration of New SIP History-Info Header ...............25
7.2. Registration of "history" for SIP Privacy Header ..........26
8. Normative References ...........................................26
9. Informative References .........................................26
10. Acknowledgements ..............................................26
11. Contributors’ Addresses .......................................27
Appendix. Example Scenarios........................................28
Appendix A. Sequentially forking (History-Info in Response).....28
Appendix B. Voicemail...........................................34
Appendix C. Automatic Call Distribution Example.................39
Appendix D. Session via Redirect and Proxy Servers..............41
1. Introduction
1.1. Overview
Many services that SIP is anticipated to support require the ability
to determine why and how the call arrived at a specific application.
Examples of such services include (but are not limited to) sessions
initiated to call centers via "click to talk" SIP Uniform Resource
Locators (URLs) on a web page, "call history/logging" style services
within intelligent "call management" software for SIP User Agents
(UAs), and calls to voicemail servers. Although SIP implicitly
provides the redirect/retarget capabilities that enable calls to be
routed to chosen applications, there is currently no standard
mechanism within SIP for communicating the history of such a request.
This "request history" information allows the receiving application
to determine hints about how and why the call arrived at the
application/user.
This document defines a new SIP header, History-Info, to provide a
standard mechanism for capturing the request history information to
enable a wide variety of services for networks and end-users. The
History-Info header provides a building block for development of new
services.
Section 1.3 provides additional background motivation for the Request
History capability. Section 2 identifies the requirements for a
solution, with Section 3 providing an overall description of the
solution.
Section 4 provides the details of the additions to the SIP protocol.
Example uses of the new header are included in Section 4.5, with
additional scenarios included in the Appendix.
Section 5 summarizes the application considerations identified in the
previous sections. Section 6 summarizes the security solution.
1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. Background: Why define a Generic "Request History" capability?
SIP implicitly provides redirect/retarget capabilities that enable
calls to be routed to specific applications as defined in [RFC3261].
The term ’retarget’ will be used henceforth in this document to refer
to the process of a Proxy Server/User Agent Client (UAC) changing a
Uniform Resource Identifier (URI) in a request and thus changing the
target of the request. This term is chosen to avoid associating this
request history only with the specific SIP Redirect Server capability
that provides for a response to be sent back to a UAC requesting that
the UAC should retarget the original request to an alternate URI.
The rules for determining request targets as described in Section
16.5 of [RFC3261] are consistent with the use of the retarget term in
this document.
The motivation for the request history is that in the process of
retargeting, old routing information can be forever lost. This lost
information may be important history that allows elements to which
the call is retargeted to process the call in a locally defined,
application-specific manner. The proposal in this document is to
provide a mechanism for transporting the request history. It is not
proposing any application-specific behavior for a Proxy or UA upon
receipt of the information. Indeed, such behavior should be a local
decision for the recipient application.
Current network applications provide the ability for elements
involved with the call to exchange additional information relating to
how and why the call was routed to a particular destination. The
following are examples of such applications:
1. Web "referral" applications, whereby an application residing
within a web server determines that a visitor to a website has
arrived at the site via an "associate" site that will receive some
"referral" commission for generating this traffic
2. Email forwarding whereby the forwarded-to user obtains a "history"
of who sent the email to whom and at what time
3. Traditional telephony services such as voicemail, call-center
"automatic call distribution", and "follow-me" style services
Several of the aforementioned applications currently define
application-specific mechanisms through which it is possible to
obtain the necessary history information.
In addition, request history information could be used to enhance
basic SIP functionality by providing the following:
o Some diagnostic information for debugging SIP requests. (Note that
the diagnostic utility of this mechanism is limited by the fact
that its use by entities that retarget is optional.)
o A stronger security solution for SIP. A side effect is that each
proxy that captures the "request history" information in a secure
manner provides an additional means (without requiring signed keys)
for the original requestor to be assured that the request was
properly retargeted.
2. "Request History" Requirements
The following list constitutes a set of requirements for a "Request
History" capability.
1) CAPABILITY-req: The "Request History" capability provides a
capability to inform proxies and UAs involved in processing a
request about the history/progress of that request. Although this
is inherently provided when the retarget is in response to a SIP
redirect, it is deemed useful for non-redirect retargeting
scenarios, as well.
2) OPTIONALITY-req: The "Request History" information is optional.
2.1) In many cases, it is anticipated that whether the history is
added to the Request would be a local policy decision
enforced by the specific application; thus, no specific
protocol element is needed.
2.2) Due to the capability being "optional" from the SIP protocol
perspective, the impact to an application of not having the
"Request History" must be described. Applicability
guidelines to be addressed by applications using this
capability must be provided as part of the solution to these
requirements.
3) GENERATION-req: "Request History" information is generated when
the request is retargeted.
3.1) In some scenarios, it might be possible for more than one
instance of retargeting to occur within the same Proxy. A
proxy should also generate Request History information for
the ’internal retargeting’.
3.2) An entity (UA or proxy) retargeting in response to a redirect
or REFER should include any Request History information from
the redirect/REFER in the new request.
4) ISSUER-req: "Request History" information can be generated by a UA
or proxy. It can be passed in both requests and responses.
5) CONTENT-req: The "Request History" information for each
occurrence of retargeting shall include the following:
5.1) The new URI or address to which the request is in the process
of being retargeted,
5.2) The URI or address from which the request was retargeted,
5.3) The reason for the Request-URI or address modification,
5.4) Chronological ordering of the Request History information.
6) REQUEST-VALIDITY-req: Request History is applicable to requests
not sent within an established dialog (e.g., INVITE, REGISTER,
MESSAGE, and OPTIONS).
7) BACKWARDS-req: Request History information may be passed from the
generating entity backwards towards the UAC. This is needed to
enable services that inform the calling party about the dialog
establishment attempts.
8) FORWARDS-req: Request History information may also be included by
the generating entity in the request, if it is forwarded onwards.
2.1. Security Requirements
The Request History information is being inserted by a network
element retargeting a Request, resulting in a slightly different
problem than the basic SIP header problem, thus requiring specific
consideration. It is recognized that these security requirements can
be generalized to a basic requirement of being able to secure
information that is inserted by proxies.
The potential security problems include the following:
1) A rogue application could insert a bogus Request History entry
either by adding an additional entry as a result of retargeting or
entering invalid information.
2) A rogue application could re-arrange the Request History
information to change the nature of the end application or to
mislead the receiver of the information.
3) A rogue application could delete some or all of the Request
History information.
Thus, a security solution for "Request History" must meet the
following requirements:
1) SEC-req-1: The entity receiving the Request History must be able
to determine whether any of the previously added Request History
content has been altered.
2) SEC-req-2: The ordering of the Request History information must be
preserved at each instance of retargeting.
3) SEC-req-3: The entity receiving the information conveyed by the
Request History must be able to authenticate the entity providing
the request.
4) SEC-req-4: To ensure the confidentiality of the Request History
information, only entities that process the request should have
visibility to the information.
It should be noted that these security requirements apply to any
entity making use of the Request History information, either by
retargeting and capturing the information, or as an application
making use of the information received in either a Request or
Response.
2.2. Privacy Requirements
Since the Request-URI that is captured could inadvertently reveal
information about the originator, there are general privacy
requirements that MUST be met:
1) PRIV-req-1: The entity retargeting the Request must ensure that it
maintains the network-provided privacy (as described in [RFC3323])
associated with the Request as it is retargeted.
2) PRIV-req-2: The entity receiving the Request History must maintain
the privacy associated with the information.
In addition, local policy at a proxy may identify privacy
requirements associated with the Request-URI being captured in the
Request History information.
3) PRIV-req-3: Request History information subject to privacy
requirements shall not be included in outgoing messages unless it
is protected as described in [RFC3323].
3. Request History Information Description
The fundamental functionality provided by the request history
information is the ability to inform proxies and UAs involved in
processing a request about the history or progress of that request
(CAPABILITY-req). The solution is to capture the Request-URIs as a
request is forwarded in a new header for SIP messages: History-Info
(CONTENT-req). This allows for the capturing of the history of a
request that would be lost with the normal SIP processing involved in
the subsequent forwarding of the request. This solution proposes no
changes in the fundamental determination of request targets or in the
request forwarding as defined in Sections 16.5 and 16.6 of the SIP
protocol specification [RFC3261].
The History-Info header can appear in any request not associated with
an established dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and
OPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY-req) and any
valid response to these requests (ISSUER-req).
The History-Info header is added to a Request when a new request is
created by a UAC or forwarded by a Proxy, or when the target of a
request is changed. The term ’retarget’ is introduced to refer to
this changing of the target of a request and the subsequent
forwarding of that request. It should be noted that retargeting only
occurs when the Request-URI indicates a domain for which the
processing entity is responsible. In terms of the SIP protocol, the
processing associated with retargeting is described in Sections 16.5
and 16.6 of [RFC3261]. As described in Section 16.5 of [RFC3261], it
is possible for the target of a request to be changed by the same
proxy multiple times (referred to as ’internal retargeting’ in
Section 2), as the proxy MAY add targets to the target set after
beginning Request Forwarding. Section 16.6 of [RFC3261] describes
Request Forwarding. It is during this process of Request Forwarding
that the History Information is captured as an optional, additional
header field. Thus, the addition of the History-Info header does not
impact fundamental SIP Request Forwarding. An entity (UA or proxy)
changing the target of a request in response to a redirect or REFER
SHOULD also propagate any History-Info header from the initial
Request in the new request (GENERATION-req, FORWARDS-req).
3.1. Optionality of History-Info
The History-Info header is optional in that neither UAs nor Proxies
are required to support it. A new Supported header, "histinfo", is
included in the Request to indicate whether the History-Info header
is returned in Responses (BACKWARDS-req). In addition to the
"histinfo" Supported header, local policy determines whether or not
the header is added to any request, or for a specific Request-URI,
being retargeted. It is possible that this could restrict the
applicability of services that make use of the Request History
Information to be limited to retargeting within domain(s) controlled
by the same local policy, or between domain(s) which negotiate
policies with other domains to ensure support of the given policy, or
services for which complete History Information isn’t required to
provide the service (OPTIONALITY-req). All applications making use
of the History-Info header MUST clearly define the impact of the
information not being available and specify the processing of such a
request.
3.2. Securing History-Info
This document defines a new header for SIP. The use of the Transport
Layer Security (TLS) protocol [RFC2246] as a mandatory mechanism to
ensure the overall confidentiality of the History-Info headers (SEC-
req-4) is strongly RECOMMENDED. This results in History-Info having
at least the same level of security as other headers in SIP that are
inserted by intermediaries. If TLS is not available for the
connection over which the request is being forwarded, then the
request MUST NOT include the History-Info header or the request MUST
be redirected to the client, including the History-Info header, so
that the request can be retargeted by the client.
With the level of security provided by TLS (SEC-req-3), the
information in the History-Info header can thus be evaluated to
determine if information has been removed by evaluating the indices
for gaps (SEC-req-1, SEC-req-2). It would be up to the application
to define whether it can make use of the information in the case of
missing entries.
Note that while using the SIPS scheme protects History-Info from
tampering by arbitrary parties outside the SIP message path, all the
intermediaries on the path are trusted implicitly. A malicious
intermediary could arbitrarily delete, rewrite, or modify History-
Info. This specification does not attempt to prevent or detect
attacks by malicious intermediaries.
3.3. Ensuring the Privacy of History-Info
Since the History-Info header can inadvertently reveal information
about the requestor as described in [RFC3323], the Privacy header
SHOULD be used to determine whether an intermediary can include the
History-Info header in a Request that it receives and forwards
(PRIV-req-2) or that it retargets (PRIV-req-1). Thus, the History-
Info header SHOULD NOT be included in Requests where the requestor
has indicated a priv-value of Session- or Header-level privacy.
In addition, the History-Info header can reveal general routing
information, which may be viewed by a specific intermediary or
network, to be subject to privacy restrictions. Thus, local policy
MAY also be used to determine whether to include the History-Info
header at all, whether to capture a specific Request-URI in the
header, or whether it be included only in the Request as it is
retargeted within a specific domain (PRIV-req-3). In the latter
case, this is accomplished by adding a new priv-value, history, to
the Privacy header [RFC3323] indicating whether any or a specific
History-Info header(s) SHOULD be forwarded.
It is recognized that satisfying the privacy requirements can impact
the functionality of this solution by overriding the request to
generate the information. As with the optionality and security
requirements, applications making use of History-Info SHOULD address
any impact this may have or MUST explain why it does not impact the
application.
4. Request History Information Protocol Details
This section contains the details and usage of the proposed new SIP
protocol elements. It also discusses the security aspects of the
solution.
4.1. Protocol Structure of History-Info
History-Info is a header field as defined by [RFC3261]. It is an
optional header field and MAY appear in any request or response not
associated with a dialog or which starts a dialog. For example,
History-Info MAY appear in INVITE, REGISTER, MESSAGE, REFER, OPTIONS,
SUBSCRIBE, and PUBLISH and any valid responses, plus NOTIFY requests
that initiate a dialog.
This document adds the following entry to Table 2 of [RFC3261]. The
additions to this table are also provided for extension methods at
the time of publication of this document. This is provided as a
courtesy to the reader and is not normative in any way.
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
History-Info amdr - - - o o o o
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
History-Info amdr o o o - - - o
The History-Info header carries the following information, with the
mandatory parameters required when the header is included in a
request or response:
o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter for
capturing the Request-URI for the specific Request as it is
forwarded.
o Index (hi-index): A mandatory parameter for History-Info
reflecting the chronological order of the information, indexed to
also reflect the forking and nesting of requests. The format for
this parameter is a string of digits, separated by dots to
indicate the number of forward hops and retargets. This results
in a tree representation of the history of the request, with the
lowest-level index reflecting a branch of the tree. By adding
the new entries in order (i.e., following existing entries per
the details in Section 4.3.3.1), including the index and securing
the header, the ordering of the History-Info headers in the
request is assured (SEC-req-2). In addition, applications may
extract a variety of metrics (total number of retargets, total
number of retargets from a specific branch, etc.) based upon the
index values.
o Reason: An optional parameter for History-Info, reflected in the
History-Info header by including the Reason Header [RFC3326]
escaped in the hi-targeted-to-uri. A reason is not included for
a hi-targeted-to-uri when it is first added in a History-Info
header, but rather is added when the retargeting actually occurs.
Note that this does appear to complicate the security problem;
however, retargeting only occurs when the hi-targeted-to-uri
indicates a domain for which the processing entity is
responsible. Thus, it would be the same processing entity that
initially added the hi-targeted-to-URI to the header that would
be updating it with the Reason.
o Privacy: An optional parameter for History-Info, reflected in the