SIP Diversion Header vs. History-Info (RFC 4244/7544) in Call Forwarding Scenarios

Overview

Key takeaways

• The Diversion header (draft-levy-sip-diversion) is a non-standardized mechanism that conveys simple redirection history using a flat stack of headers.
• History-Info (RFC 4244/7544) is the IETF standard that captures a complete hierarchical audit trail of Request-URIs via explicit index parameters.
• Voicemail systems and auto-attendants use these headers to determine the original intended recipient and deposit messages into the correct mailbox.
• Session Border Controllers frequently perform bi-directional header translation between legacy enterprise PBXs using Diversion and modern IMS/carriers requiring History-Info.
• History-Info provides superior privacy controls and support for standardized SIP/Q.850 cause codes.

Prerequisites

• Fundamental understanding of SIP request routing, Request-URI manipulation, and the INVITE transaction flow.
• Familiarity with call forwarding concepts such as Call Forward Unconditional (CFU), Busy (CFB), and No Answer (CFNR).

Guide

1. section #1

   The Need for Call Forwarding Context in SIP When a SIP call is forwarded, the Request-URI (R-URI) of the incoming INVITE is rewritten to the new destination target. Without explicit tracking headers, downstream elements—such as voicemail servers, auto-attendants, and billing systems—lose the context of who the call was originally intended for and why the redirection occurred. To solve this, two primary header mechanisms evolved in SIP networks: the draft-based Diversion header and the IETF-standardized History-Info header field.

2. section #2

   The Legacy Diversion Header (draft-levy-sip-diversion) The Diversion header was defined in an expired IETF draft (draft-levy-sip-diversion-08) and became the de facto industry standard for PSTN gateways and legacy IP-PBXs. Each forwarding hop prepends a new Diversion header to the top of the SIP request. It typically contains the URI of the diverting party, a reason parameter (such as 'user-busy', 'no-answer', or 'unconditional'), and optional parameters like counter, screen, and privacy flags.

   sipcopy

   INVITE sip:user-c@example.com SIP/2.0
   From: Alice <sip:alice@carrier.com>;tag=12345
   To: User C <sip:user-c@example.com>
   Diversion: <sip:user-b@example.com>;reason=user-busy;counter=1;privacy=off
   Diversion: <sip:user-a@example.com>;reason=unconditional;counter=2;privacy=off

3. section #3

   The History-Info Header Field (RFC 4244 and RFC 7544) History-Info (originally RFC 4244, updated by RFC 7544) standardizes a mechanism for capturing the history of request targets as a call is retargeted or forwarded. Rather than just recording who diverted the call, History-Info logs every target URI in chronological order using a hierarchical dot-delimited index parameter (e.g., index=1, index=1.1, index=1.2). RFC 7544 defines modern extensions for representing specific redirection reasons, mapping Q.850 cause codes directly inside the URI parameters.

   sipcopy

   INVITE sip:user-c@example.com SIP/2.0
   From: Alice <sip:alice@carrier.com>;tag=12345
   To: User C <sip:user-c@example.com>
   History-Info: <sip:user-a@example.com>;index=1
   History-Info: <sip:user-b@example.com?Reason=sip%3Bcause%3D302>;index=1.1;rc=1.1
   History-Info: <sip:user-c@example.com?Reason=sip%3Bcause%3D486>;index=1.1.1;mp=1.1

4. section #4

   Structural and Semantic Comparison While Diversion relies on a simple list ordered top-to-bottom where the topmost header represents the most recent diverting entity, History-Info uses an append-only structure with explicit indexing. History-Info index notation allows reconstruction of parallel fork trees and recursive redirects. Furthermore, History-Info leverages standard SIP RFC 3326 Reason headers embedded as URI parameters (e.g., Reason=sip;cause=302 or cause=486), whereas Diversion uses proprietary or draft-defined string tokens (e.g., reason=user-busy).

5. section #5

   Header Interworking and SBC Translation Session Border Controllers (SBCs) regularly translate between Diversion and History-Info when bridging legacy enterprise systems with modern carrier IMS networks or cloud services like Microsoft Teams. Translation rules must map the target URI, convert reason strings to standard Q.850/SIP cause codes (e.g., 'unconditional' maps to SIP cause 302 / Q.850 cause 16 or 31), and correctly construct or strip the dot-annotated index values.

   sipcopy

   ; Example Mapping Logic (Diversion to History-Info):
   ; Diversion: <sip:bob@example.com>;reason=unconditional
   ;
   ; Becomes:
   ; History-Info: <sip:bob@example.com?Reason=sip%3Bcause%3D302>;index=1;rc=1
   ; History-Info: <sip:charlie@example.com>;index=1.1

6. section #6

   Best Practices for Implementation and Privacy When deploying call forwarding in production networks, prefer History-Info (RFC 7544) for all new implementations to ensure compliance with modern carrier specifications and 3GPP/IMS standards. Ensure that privacy settings (RFC 3323) are properly evaluated; if a diverting user requests privacy, SBCs and proxies must mask or strip the diverting entity's URI in public networks while preserving the underlying forwarding logic for authorized internal nodes.

Further reading

• RFC 4244: An Extension to the Session Initiation Protocol (SIP) for Request History Information
• RFC 7544: Timely History-Info Header Field Extension for Request History Information
• RFC 5806: Diversion Indication in SIP (Informational Draft Status)
• RFC 4458: Session Initiation Protocol (SIP) URIs for Applications Involved in Support of Service Requests