An Extension to the Session Initiation Protocol (SIP) for Request History Information
obsoleted by
- rfc-7044 — An Extension to the Session Initiation Protocol (SIP) for Request History Information
Extracted elements (28)
Adding History-Info between Steps 8 and 9 of RFC 3261 proxy forwarding (rather than Step 5) is recommended because strict routing can change the Request-URI during Step 6, which would cause an incorrect URI to be captured if the header were added earlier.
History-Info is defined as a generic building block rather than as application-specific mechanism because existing services (voicemail, ACD, follow-me) each had their own proprietary history mechanisms, and a standard mechanism avoids fragmentation while leaving application-specific behavior as a local decision for recipients.
The hi-index uses a dot-delimited tree structure rather than a flat sequence number so that forking and nesting of requests can be accurately represented, enabling applications to extract metrics such as total retargets, retargets per branch, and forking depth from the index values alone.
History-Info does not alter the fundamental processing of proxies for determining request targets as defined in RFC 3261 Sections 16.5 and 16.6. Its addition is purely an optional, additional header field and does not impact SIP request forwarding or retargeting mechanics.
A proxy SHOULD add a hi-entry as it forwards a request. Adding the History-Info header between Steps 8 (adding Via header) and 9 (adding Content-Length) of RFC 3261 Section 16.6 is RECOMMENDED to avoid issues with strict routing changing the Request-URI.
A redirect server SHOULD NOT add any new History-Info, as that would be done by the entity receiving the 3xx response; however, it MAY include History-Info from the received request in subsequent responses.
An entity retargeting a request in response to a redirect or REFER SHOULD propagate any History-Info header from the initial request in the new request.
Applications using History-Info MUST clearly define the impact of the information not being available and specify the processing of such a request, because the History-Info header is optional and neither UAs nor Proxies are required to support it.
For parallel forking, the hi-index MUST be captured for each forked request with a unique index per the indexing rules; proxy aggregates History-Info entries from all forked requests ordered by index when building the subsequent response.
For retargets resulting from an explicit SIP response, a Reason MUST be associated with the retargeted hi-targeted-to-uri. If the SIP response lacks a Reason header, the SIP response code MUST be included; non-SIP Reason headers (e.g., Q.850) MUST be captured as additional Reasons along with the SIP response code.
If the 'histinfo' option tag is received in a request, the UAS SHOULD include any History-Info received in that request in the subsequent response.
If the response is being forwarded outside the proxy's domain and there is a Privacy header with priv-value 'session', 'header', or 'history' in the original request, the proxy MUST remove the History-Info header (all hi-entries) prior to forwarding the response.
If TLS is not available for the connection over which a request containing History-Info is being forwarded, 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 client can securely retarget.
Proxies SHOULD maintain History-Info headers received in messages being forwarded, independent of whether local policy supports History-Info, consistent with basic SIP processing of optional headers.
The hi-entry MUST be added following any hi-entry already present in the request being forwarded, ensuring chronological ordering is maintained.
The History-Info header SHOULD NOT be included in requests where the requestor has indicated a priv-value of Session- or Header-level privacy, since the header can inadvertently reveal information about the requestor.
The UAC SHOULD include the 'histinfo' option tag in the Supported header in any request not associated with an established dialog for which it desires History-Info returned in responses.
The History-Info header can inadvertently reveal routing information about the requestor. The Privacy header with priv-values 'session', 'header', or 'history' controls whether intermediaries include or strip History-Info. Local policy may further restrict which Request-URIs are captured or forwarded.
A new priv-value 'history' is added to the SIP Privacy header. It can be applied to the entire request or to a specific hi-targeted-to-uri to indicate that the associated History-Info entry (or all entries) should not be forwarded beyond the current domain.
The 'histinfo' option tag is included in the Supported header of requests to indicate that the UAC desires History-Info to be returned in responses. It is not used in Proxy-Require or Require because support is optional.
The History-Info header is a new optional SIP header field that captures the sequence of Request-URIs as a SIP request is retargeted and forwarded. It may appear in any request or response not associated with an established dialog, including INVITE, REGISTER, MESSAGE, REFER, OPTIONS, SUBSCRIBE, PUBLISH, and NOTIFY.
IANA registers 'history' as a new priv-value for the SIP Privacy header, indicating that privacy is requested for the History-Info header(s), referencing RFC 4244.
IANA registers 'History-Info' as a new SIP header field name (compact form: none) and 'histinfo' as a new SIP option tag, both referencing RFC 4244.
Gaps in hi-index values can indicate that an entry has been maliciously removed or removed for privacy reasons. Applications SHOULD evaluate indices for gaps and MAY choose not to process History-Info when entries appear to be missing.
TLS is mandated for hop-by-hop security of History-Info between all entities (UAC-to-Proxy, Proxy-to-Proxy, Proxy-to-UAS). If TLS is unavailable, the History-Info header MUST be removed prior to forwarding, or the request MUST be redirected to the UAC so it can securely retarget. TLS provides authentication and confidentiality but does not prevent malicious intermediaries from deleting, rewriting, or modifying History-Info.
Proxy indexing state machine for History-Info: (1) Basic forwarding appends a new dot-level to the last index (e.g., 1.1 → 1.1.1); (2) first retarget within a proxy follows basic forwarding; (3) each subsequent retarget by the same proxy increments the last digit (e.g., 1.1.1 → 1.1.2); (4) retarget due to a response also increments the last digit; (5) parallel forking assigns a unique index per branch.
Each History-Info entry (hi-entry) contains a mandatory hi-targeted-to-uri (name-addr format capturing the Request-URI) and mandatory hi-index (dot-delimited digits reflecting chronological order and forking depth). Optional parameters include a Reason header escaped in the URI, a Privacy header with priv-value 'history', and hi-extension for future use.
The hi-index parameter uses the syntax '1*DIGIT *(DOT 1*DIGIT)', forming a dot-delimited tree representation where each dot reflects a hop or level of nesting and each integer reflects the number of peer entities at that level.