Mapping of Diversion Information Between Diversion and History-Info Headers

History-Info and Diversion are two headers commonly used in SIP signaling used to convey information related to call transfer and call diversion. The Oracle® Enterprise Session Border Controller (E-SBC) supports mapping and interworking between networks that support the History-Info versus the Diversion header. You implement this interworking on the E-SBC using the diversion-info-mapping-mode parameter on egress sip-interface configuration elements. This interworking, and the subsequent header behaviors comply with RFC 6044. When configured, the E-SBC monitors signaling for the presence of History-info headers that comply with RFC 6044 and Diversion headers that comply with RFC 5806 to trigger the interworking.

The History-Info header is the standard solution adopted by the Internet Engineering Task Force (IETF) for storing re-targeting information. The non-standard Diversion header is also used in many existing network implementations. Individual networks typically use one or the other. As both headers address call forwarding needs but have different syntaxes, having both present in a signaling request can cause diverting information to be misinterpreted, thereby making an interworking solution necessary. In addition to using different syntaxes, these methods also use different reason codes for the diversions, different security flags, and list events using opposite chronology. The diversion header lists the last diversion first; the History-Info header lists the first diversion last.

You enable this interworking using the diversion-info-mapping-mode parameter on sip-interface elements. The E-SBC applies the configuration at the egress interface. You can configure the following header interworking modes:

• Diversion to History-Info,
• History-info to Diversion, or
• A combination of Diversion to History-Info interworking and a forced insertion of the History-info header if the INVITE contains neither.

When interworking from a History-Info header to a Diversion header for each, the E-SBC initializes the new Diversion header with the value of the History-Info header. The presence of re-direction headers and the absence of a to-tag in the To header of an initial INVITE triggers the E-SBC to perform the interworking.

Note:

This feature supports only SIP-URIs in the diversion header. There is no supported conversion from TEL-URI to SIP-URI.

History-Info to Diversion Header Interworking

When configured for this interworking, the E-SBC takes the following steps for all History-Info headers except the last in the incoming initial INVITE:

1. Create a new diversion header.
2. Extract the cause parameter from the subsequent History-Info header if any, and add a reason parameter to the Diversion header, using the following conversion table.

   History-Info Cause	Diversion Reason
   404	Unknown (default value)
   302	unconditional
   486	user-busy
   408	no-answer
   480	deflection
   487	deflection
   503	unavailable

3. If a cause is not present, use the default value Unknown for the reason parameter.
4. If the History-Info header contains a privacy parameter, add a Privacy parameter to the Diversion header, using the following conversion table.

   History-Info Privacy	Diversion Privacy
   history	full
   Field absent or none	Off (default value)

5. If there is no privacy parameter, use the default value Off in the Diversion header.
6. Add a counter parameter with the value 1.
7. Delete the History-Info header.

The diagram below provides an example flow and the header text used for this example.

In addition, the E-SBC removes any Diversion headers already present in the incoming initial INVITE before the steps above.

Diversion to History-Info Header Interworking

When configured for this interworking, the E-SBC takes the following steps for all Diversion headers in the incoming initial INVITE:

1. Create a new History-Info header.
2. Add the index header parameter.
3. Set the value for the first header to 1. Append .1 to the value of the last_index_value for the subsequent headers.
4. If the Diversion header contains a privacy parameter, add the Privacy header parameter to the History-Info header using the following conversion table.

   Diversion Privacy	History-Info Privacy
   full	history
   name	history
   uri	history
   off	none

5. If the previous Diversion header contains a reason parameter, add the cause header parameter to the History-Info header using the following conversion table. The E-SBC does not add a cause parameter to the first History-info entry.

   Diversion Reason	History-Info Cause
   unknown	404 (default value)
   unconditional	302
   user-busy	486
   no-answer	408
   deflection	480
   unavailable	404
   time-of-day	404
   do-not-disturb	404
   follow-me	404
   out-of-service	404
   away	404

6. If there is no reason parameter for any History-info headers, set the parameter to the default value of 404.
7. Remove the diversion header from the outgoing INVITE.

The diagram below provides an example flow and the header text used for this example.

Diversion and History-Info Headers Interworking Configuration

You can configure Oracle® Enterprise Session Border Controllers to map call transfer and call diversion information between Diversion and History-Info headers.

To configure interworking between the Diversion and History-Info headers:

1. Access the sip-interface configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# session-router
   ORACLE(session-router)# sip-interface
   ORACLE(sip-interface)# 
   

2. Select the sip-interface object to edit.

   ORACLE(sip-interface)# select
   <RealmID>:
   1: realm01 172.172.30.31:5060
   
   selection: 1
   ORACLE(sip-interface)#

3. diversion-info-mapping-mode— Configure this parameter to specify how the Diversion and History-Info headers map to and work with each other on the interface. The default value is none.
   • div2hist — any Diversion headers in the initial INVITEs going out of this sip-interface will be converted to History-Info headers before sending
   • force — behavior is the same as div2hist when a Diversion header is present in the incoming INVITE. If there are no Diversion headers, a History-Info header for the current URI is added in the outgoing INVITE.
   • hist2div — any History-Info headers in the initial INVITEs going out of this sip-interface will be converted to Diversion headers before sending
   • none — no conversion applied (default)
4. Type done to save your configuration.