Technical Summary
This document defines a standard mechanism for capturing the history
information associated with a 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.
WG Summary
There was extended working group review, including a requirements
document, which was absorbed eventually into this specification,
and a lengthy debate to obtain methods for provision of privacy.
The working group reached a good consensus to advance this
solution.
Protocol Quality
Some implementation and testing have been discussed.
The WG Chair shepherd for this document was Rohan Mahy.
Notes to the RFC Editor
Section 1, 2nd to last paragraph
OLD:
o Some diagnostic information for debugging SIP requests.
NEW:
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 which retarget is optional.)
Section 2.1, insert after 3rd para
NEW:
3) A rogue application could delete some or all of the Request History
information.
Section 2.1, 3rd para from the end
OLD:
3) SEC-req-3: The entity receiving the information conveyed by the
Request History must be able to authenticate the source of the
information.
NEW:
3) SEC-req-3: The entity receiving the information conveyed by the
Request History must be able to authenticate the entity providing
the request.
Section 3.2: Insert immediately after last paragraph
NEW:
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.
Section 4.1: Please delete the blank line indicated below with -->
OLD:
History-Info = "History-Info" HCOLON
-->
hi-entry *(COMMA hi-entry)
NEW:
History-Info = "History-Info" HCOLON
hi-entry *(COMMA hi-entry)
Section 4.3.1, 1st paragraph
OLD:
The UAC SHOULD include the "histinfo" option tag in the Supported
header in any request not associated with an established dialog for
which the UAC would like the History-Info header in the Response. In
addition, the UAC SHOULD initiate the capturing of the History
Information by adding a History-Info header, using the Request-URI of
the request as the hi-targeted-to-uri and initializing the index to
the RECOMMENDED value of 1 in the hi-entry.
NEW:
The UAC SHOULD include the "histinfo" option tag in the Supported
header in any request not associated with an established dialog for
which the UAC would like the History-Info header in the response. In
addition, the UAC MAY improve the diagnostic utility of its request by
adding a History-Info header, using the Request-URI of the request as
the hi-target-to-uri and initializing the index to the RECOMMENDED
value of 1 in the hi-entry. As a result, intermediaries and the UAS
will know at least the original Request-URI, and if the Request-URI was
modified by a previous hop.
Appendix A
OLD:
UA 1sends
NEW:
UA1 sends