1. ACLI Configuration Guide
  2. SIP Signaling Services
  3. Diversion Info and History-Info Header Mapping
  4. History-Info and Diversion Header Interworking Operations

History-Info and Diversion Header Interworking Operations

The Oracle® Enterprise Session Border Controller (ESBC) performs this interworking on the information provided in the initial INVITE. History-Info and Diversion header entries may arrive in any order and can be mixed. The ESBC supports interworking for interleaved entries and mixed input. History-Info has a much broader scope than Diversion header (not limited to call forwarding) so not all information can be interworked. The ESBC manages History-Info headers with or without cause parameter per RFC 7544.

At a high level, the ESBC performs the following tasks:

  • When interworking History-Info to Diversion headers:
    • Supports the mp parameters in History-Info received and generated to the hi-targeted-to-URI to change the user. Examples include forwarding to a different call center technician.
    • If received in the INVITE, the ESBC stores the rc and np parameters:
      • rc—Changes Request-URI, while the target user does not. Examples include forwarding to a user's voice mail.
      • np—No change in the Request-URI. Examples include a proxy forwarding a request to a next-hop proxy when you are using loose routing.
    • Interworks the History-Info 380 cause parameter to the Diversion header (cause=unknown), as described below.
  • When interworking Diversion headers to History-Info:
    • Creates placeholder History-Info headers when the Diversion counter is greater than 1.
    • Converts TEL-URIs to SIP-URIs.
    • Forwards History-Info not related to call forwarding without change.

For both directions:

  • Preserves unknown elements of History-Info and Diversion headers, such as display name, parameters, and enclosed headers adhering to the HI or DIV syntax. Specifically:
    • If there are any unknown parameters/elements present in the URI part (in between "<" and ">") of HI/Diversion headers, the ESBC preserves those values in the converted entries.
    • If there is any extra/unknown supplementary information outside the URI of an HI entry, the ESBC maps that HI entry, including the EXTRA info.
    • If there is any extra/unknown supplementary information outside the URI of the Diversion entry, the ESBC maps that Diversion entry, but ignores the EXTRA information.
  • Based on sip-config configuration, makes the Diversion and History-Info headers anonymous if the egress peer is untrusted.

Note:

If there is any information outside of the HI/DIV header syntax, the ESBC treats that information as unknown or supplementary information.

You configure the ESBC for this interworking support at the egress interface. The applicable parameter, diversion-info-mapping-mode, assumes traffic egressing the interface supports either History-Info or Diversion. There are three modes of operation:

  • History-Info to Diversion Header Interworking (hist2div)
    • If Diversion headers are already present, the ESBC considers them when building the egress request.
    • The ESBC adds the unknown elements of History-Info headers to the generated Diversion headers (display-name, SIP parameters, SIP headers). See the specific functions presented above.
    • The ESBC optionally converts History-Info with a "380" cause to a Diversion header (cause=unknown). By default, it forwards the History-Info cause=380 transparently.
    • Existing Diversion headers received in the input appear at the end of the Diversion list.
    • Converted History-Info entry with cause = 380, shall be at the top of newly created div headers. The ESBC adds other HI entries with different cause (other than 380) per the conversion.
    • The ESBC retains HI entries if they don't have a cause parameter, and if that entry is not a target entry to any diverting entry.
    • When configured, the ESBC inserts the cause 380 History-Info as the topmost Diversion header, because it assumes the applicable events happened before the call forwarding History-Info.
      • When converting hist2div, the ESBC removes the last History-Info with a cause parameter if used to build a diversion header.
      • If this cause parameter is 380 and option hist380todiv (hist-to-div-for-cause-380) is not present, then this History-Info header is not taken into account to build a Diversion because it is not recognized as a call forward. This results in the ESBC keeping the last History-Info header.
      • If this cause parameter is 380 and option hist380todiv (hist-to-div-for-cause-380) is present, then this History-Info header is taken into account to build a Diversion because it is recognized as a call forward. In that case, the History-Info header removes the last History-Info header.
  • Diversion Header to History-Info Interworking (div2hist)
    • The ESBC generates the mp-param parameter for History-Info headers.
    • If the ESBC is adding converted History-Info headers to existing History-Info headers it manages both index and mp-param continuation.
    • The ESBC integrates any existing History-Info headers to the top of the list in the resulting request.
    • The ESBC adds the unknown R-URI elements of Diversion headers to the generated History-Info headers (display-name, SIP parameters, SIP headers). If there is any other extra info that cannot be mapped to History-Info header, the ESBC ignores it.
    • If a Diversion header contains a TEL-URI, the ESBC converts it into a SIP-URI and inserts it into the resulting History-Info header.
    • Tel-URI with additional parameters to SIP-URI. If a Diversion header contains a TEL-URI, the ESBC converts it into a SIP-URI and inserts it into the resulting History-Info header along with any additional Tel-URI parameters.
    • The ESBC adds newly converted History-Info headers to the existing History-Info headers. If the last old/existing HI entry has cause 380, the ESBC removes the mp-param from the first HI entry in the list of converted HI entries that it is going to add.
    • All Diversion headers are always converted to HI headers because information in diversion headers can always be converted.
  • Forced Mode (force)
    • This mode is similar to div2hist, but invokes additional actions by the ESBC.
    • If History-Info headers are already present, the ESBC adds new History-Info header(s) to the existing set.
    • The ESBC retargeting feature adds a History-Info entry as well as the expected Index and mp to an outgoing INVITE when certain conditions are met:
      • When force mode is set on the realm from which the 3xx or ENUM response came.
      • When the ESBC gets a redirect response (3xx) or an ENUM response.
      • When this response also contains the new URI and cause-param.
      • When it receives a cause parameter in a SIP redirect reply.
    • The ESBC extracts parameters for creating a History-Info header from the Contact header of the incoming SIP redirect reply. This Contact header must contain the URI and cause. The ESBC copies all this information for use in the History-Info it generates.
    • Adds History-Info headers to a SIP INVITE if it has been re-targeted.
    • For repeated re-targeting the ESBC keeps adding History-Info headers to each INVITE it sends out.
    • The ESBC extracts information from a received Contact header from incoming re-direct replies. For this feature ESBC only uses the URI and cause.
    • The ESBC ignores a hi-target-param if it is received as the Contact of a 3xx or via an ENUM response. The ESBC can not rely on that information.

The ESBC retains any added History-Info entry it adds to an outgoing retargeting request for ensuing retargeting requests.