Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

SIP History-Info Header

The SIP History-Info Header defined in RFC 4244 provides a way of capturing any redirection information that may have occurred on a particular call. Without the SIP History-Info Header the redirecting information would be lost. The SIP History-Info Header is generated when a SIP request is re-targeted and can appear in any SIP request not associated with a dialog. The SIP History-Info header is generated by a User Agent or proxy and is passed from one entity to another through requests and responses. An example of the SIP History Header is shown below.

The SIP History-Info Header displays the information described below:

  • The URI or address that indicates the redirecting number

  • The reason for the Request-URI or address modification

  • Chronological ordering of the Request History information 

Example

Configuration

Initial Configuration

The procedure below explains how to configure the IMG 2020 to capture any redirection information using the History-Info Header. Before configuring, the IMG 2020 must have an initial configuration created on it. Follow the Basic Configurationsprocedure before proceeding.

Create a SIP Profile (SGP) and SIP Headers page

Configure the SIP Profile and then the SIP Headers object and then configure in the SIP History-Header functionality to the SIP Gateway profile being created.

  • Right click on the Profiles object and select New SIP Profiles. The SIP Profiles object is a parent or container object. No configuration is needed here. Refer to the SIP Profiles topic for more information on this object.

  • Right click on the SIP Profiles object and select New SIP Profile. The first profile that gets created is a Default SIP Profile and cannot be modified. Disregard this profile.

  • Right click on the SIP Profiles object and select New SIP Profile again. In the SIP Profile object that appears, either enter a name that identifies this SIP Profile or accept the default name already entered. In this example the SIP Profile was labeled HistoryInfo_Profile. Refer to the SIP Profile - SGP topic for more information on this object.

  • Right click on the SIP Profile object just created and select New SIP Headers. The Diversion Header Support feature is set to Disabled by default. To enable, select History-Info from drop down menu in the Diversion Header Support field. Refer to screen capture below.

Refer to the SIP Profile - Headers topic for more information.

 Create a Remote Gateway

An external network element must be created. Configure an external gateway that the SIP channel group will send messages to.

  • Right click on the Dialogic object and select New External Network Elements. The External Network Elements object is a parent or container object and no configuration is needed here. Refer to topic for more information.

  • Right click on External Network Elements and select New External Gateways. The External Gateways object is a parent or container object also and no configuration is needed here. Refer to for more information.

  • Right click on External Gateways and select New External Gateway. Enter a name that identifies the gateway being configured. In this example the gateway was labeled HistoryInfo_GW.

 

  • Select SIP from drop down menu in the Gateway Signaling Protocol field.

  • Enter an IP address for this gateway.

  • Select the SIP Profile (SGP) created earlier from drop down menu in the SIP Profile field.

 Configure SIP Signaling

The configuration above displays how to configure the SIP Profile and External SIP Gateway so that the SIP History-Info Header functionality is configured. The next step is to configure the SIP signaling stack and SIP Channel Groups. Refer to the Configure SIP (Single SIP IP) topic for a procedure on how to configure the SIP functionality.

 Additional Information

  • The History-Info header is to be added to an outbound SIP message if a Redirecting Number was received on the ISUP or ISDN side.

  • The History-Info header received in an inbound SIP message is sent to the ISUP or ISDN call leg to generate the Redirecting Number.

  • The History-Info header is to be added in a retargeted request such as a 3xx response.

  • The History-Info header applies to both SIP requests and responses.

  • For SIP responses received by the IMG 2020 (UAC case), the IMG 2020 supports processing of the History-Info header in 180, 183, 200 and 3xx responses only.

  • For SIP responses sent by the IMG 2020 (UAS case): If the received SIP request contained the histinfo tag in the supported header and also contained a History-Info header, the IMG 2020 will include the same History-Info header into its SIP response.

  • In SIP to SIP calls, the IMG 2020 will pass the History header received on the inbound side to the SIP message sent on the outbound side.

  • The current feature will not include the security requirements defined in RFC 4244 section 2.1, as retargeting is a behavior of proxy servers and the IMG 2020 does not have visibility over these routes.

  • The current feature is to include the privacy requirements defined in RFC 4244 section 2.2 as they apply to the History-Info header. The optional Privacy header will not be used to specify a private History-Info header.

  • The IMG 2020 will not impose the use of TLS, as described in RFC 4244 section 3.2. It is the responsibility of the network operator to ensure that the SIP target is a trusted entity.

  • The SGP profile configuration provides a Redirection option to allow the use of either the History-Info or the Diversion header. The SGP selection is to be a preference. For example, in an inbound INV request the IMG 2020 will decode either the History-Info or the Diversion header, but not both. In an outbound INV request the IMG 2020 will use the SGP selection.

  • The History-Info header will not be mapped to CDR attributes in the IMG 2020 which is in accordance with the existing implementation of Diversion header. 

 

  • No labels