availability*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;\
cause=603;text="Decline">; index=1.1.3
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;cause=603;\
text="Decline">; index=1.1.3
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
4.5.1. Example with Privacy Header for Entire Request at Proxy2
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1
| | | | | | |
| | |-INVITE>| | | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com>;index=1.1.3
/* All Responses from the INVITEs indicate non-success/non-
availability and only the initial, received History-Info entries
are NOT returned to P1 due to the Privacy header value.*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, including UA3, which was attempted by P2, but due to
Privacy P1 is not aware of this, so UA3 is re-attempted prior to
forwarding the INVITE to UA5, where the session is successfully
established */
| | | | | | |
| |--------------INVITE ----->| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |<-- 486 -------------------| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=486;\
text="Busy Here">;index=1.2,
<sip:User5@UA5.example.com>;index=1.3
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
4.5.2. Example with Privacy Header for Specific URI (UA4) at Proxy2
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
| | |-INVITE>| | | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com?\
Privacy=history>; index=1.1.3
/* All Responses from the INVITEs indicate non-success/non-
availability. The History-Info associated with UA4 is not returned
in the response due to the privacy header associated with that URI */
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
text="Request Terminated">; index=1.1.2,
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
5. Application Considerations
As seen by the example scenarios in the appendix, History-Info
provides a very flexible building block that can be used by
intermediaries and UAs for a variety of services. As such, any
services making use of History-Info must be designed with the
following considerations:
1) History-Info is optional; thus, a service MUST define default
behavior for requests and responses not containing History-Info
headers.
2) History-Info may be impacted by privacy considerations.
Applications requiring History-Info need to be aware that if
Header-, Session-, or History-level privacy is requested by a UA
(or imposed by an intermediary) that History-Info may not be
available in a request or response. This would be addressed by an
application in the same manner as the previous consideration by
ensuring there is reasonable default behavior should the
information not be available.
3) History-Info may be impacted by local policy. Each application
making use of the History-Info header SHOULD address the impacts
of the local policies on the specific application (e.g., what
specification of local policy is optimally required for a specific
application and any potential limitations imposed by local policy
decisions). Note that this is related to the optionality and
privacy considerations identified in 1 and 2 above, but goes
beyond that. For example, due to the optionality and privacy
considerations, an entity may receive only partial History-Info
entries; will this suffice? Note that this would be a limitation
for debugging purposes, but might be perfectly satisfactory for
some models whereby only the information from a specific
intermediary is required.
4) The security associated with the History-Info header requires the
use of TLS. In the case of TLS not being available for a
connection over which a request is being forwarded, the History-
Info header may be removed from a request. The impact of lack of
having the information depends upon the nature of the specific
application (e.g., Is the information something that appears on a
display or is it processed by automata which could have negative
impacts on the subsequent processing of a request?). It is
suggested that the impact of an intermediary not supporting the
security recommendations should be evaluated by the application to
ensure that the impacts have been sufficiently addressed by the
application.
6. Security Considerations
The threat model and related security and privacy requirements for
the History-Info header are described in Sections 2.1 and 2.2 of this
document. Sections 3.2, 3.3, and 4.4 provide normative
recommendations related to security and privacy fulfilling these
requirements. The use of TLS is mandated between the entities (i.e.,
UAC to Proxy, Proxy to Proxy, and Proxy to UAS) that use the
History-Info header. The appropriate handling of a request in the
case that TLS is not available for a specific connection is described
in Section 5.
With TLS, History-Info headers are no less, nor no more, secure than
other SIP headers, which generally have even more impact on the
subsequent processing of SIP sessions than the History-Info header.
7. IANA Considerations
7.1. Registration of New SIP History-Info Header
This document defines a new SIP header field name: History-Info and a
new option tag: histinfo.
The following changes have been made to
http:///www.iana.org/assignments/sip-parameters
The following row has been added to the header field section:
Header Name Compact Form Reference
----------- ------------ ---------
History-Info none [RFC4244]
The following has been added to the Options Tags section:
Name Description Reference
---- ----------- ---------
histinfo When used with the Supported header, [RFC4244]
this option tag indicates support
for the History Information to be
captured for requests and returned in
subsequent responses. This tag is not
used in a Proxy-Require or Require
header field since support of
History-Info is optional.
7.2. Registration of "history" for SIP Privacy Header
This document defines a new priv-value for the SIP Privacy header:
history
The following changes have been made to
http://www.iana.org/assignments/sip-priv-values
The following has been added to the registration for the SIP Privacy
header:
Name Description Registrant Reference
---- ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC4244]
History-Info header(s) mary.barnes@nortel.com
8. Normative 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.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
9. Informative References
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
K. Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, December 2003.
10. Acknowledgements
The editor would like to acknowledge the constructive feedback
provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell,
Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng,
Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger,
Martin Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and
Sebastien Garcin.
The editor would like to acknowledge the significant input from Rohan
Mahy on some of the normative aspects of the ABNF, particularly
around the need for and format of the index and around the security
aspects.
11. Contributors’ Addresses
Cullen, Mark, and Jon contributed to the development of the initial
requirements.
Cullen and Mark provided substantial input in the form of email
discussion in the development of the initial version of the
individual solution document.
Cullen Jennings
Cisco Systems
170 West Tasman Dr
MS: SJC-21/3
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
Jon Peterson
NeuStar, Inc.
1800 Sutter Street, Suite 570
Concord, CA 94520
USA
Phone: +1 925-363-8720
EMail: Jon.Peterson@NeuStar.biz
Mark Watson
Digital Fountain
39141 Civic Center Drive Suite 300
Fremont, CA 94538
U.S.A.
EMail: mark@digitalfountain.com
Appendix. Example Scenarios
The scenarios in Appendices A-D provide sample use cases for the
History-Info header for informational purposes only. They are not
intended to be normative and the formatting is for visual purposes;
thus, the headers in the URI are not shown properly formatted for
escaping. Refer to Section 4.2 examples with the proper formatting.
Appendix A. Sequentially Forking (History-Info in Response)
This scenario highlights an example where the History-Info in the
response is useful to an application or user that originated the
request.
Alice at UA1 sends a call to Bob via Proxy1. Proxy1 sequentially
tries several places (UA2, UA3 and UA4) unsuccessfully before sending
a response to Alice.
This scenario is provided to show that by providing the History-Info
to UA1, the end-user or an application at UA1 could make a decision
on how best to attempt finding Bob. Without this mechanism, UA1
might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a
third manual attempt at reaching Bob. With this mechanism, either
the end-user or application could know that Bob is busy on his home
phone and is physically not in the office. If there were an
alternative address for Bob known to this end-user or application,
that hasn’t been attempted, then either the application or the end-
user could attempt that. The intent here is to highlight an example