1. Configuration Guide
  2. SIP Signaling Services
  3. SIP SIP-I Interworking
  4. SIP-SIPI IWF Operational Overview

SIP-SIPI IWF Operational Overview

The SBC uses the ITU Q.1912.5 specification for guidance on this IWF. The following sections describe key SBC behavior that is not defined by any external specification.

Function Processing Order

There are three configurable objects that you can use to perform SIP-SIPI IWF. When designing your IWF, ensure you configure each object using the understanding of which functions the SBC has already performed. Doing this ensures that your configuration performs each step on the data based on which functions are already completed.

For ingress, the SBC acts on these objects in the following order:

  1. HMR rules
  2. in-translationid rule(s)
  3. sip-isup-profile

For egress, the SBC acts on these objects in the following order:

  1. sip-isup-profile
  2. out-translationid rule(s)
  3. HMR rules

The sip-isup-profile is applicable only on the SIP-I side of the call.

IAM Message Interworking

The SBC performs IAM message insertion and deletion, using the version specified in that applicable sip-profile, without requiring HMR when your configuration invokes a valid sip-isup-profile. This includes diversion information. The SBC also interworks the IAM parameters documented herein. Extended IAM support, including number portability interworking support requires that you configure the native inter-working method.

Additional Message Interworking

When enabled, Native interworking mode interworks additional ISUP messages:

  • ACM
  • CPG
  • ANM
  • CON
  • REL
  • RLC

Applicable parameter interworking is documented below.

BYE and REL

The SBC inserts an REL as an application/isup “content-type” with the header parameters based on the applicable sip-isup-profile, and formats the message according to the ISUP version configured in the sip-isup-profile.

In addition, if a Reason header, as described in IETF RFC 6432, is included in a 4xx, 5xx, 6xx response, the SBC maps the Cause Value of the Reason header to the ISUP Cause Value field in the REL message.

200OK and RLC

The SBC inserts an RLC as an application/isup content-type, with the header parameters based on the applicable sip-isup-profile. It does not include any ISUP parameters in this message.

CON Message Workaround

It is possible for an SIP-I node to receive a CONNECT (CON) without receiving any Address Complete Message (ACM) or Call Progress (CPG) message, such as when the call is answered automatically. In these cases, the SIP user does not receive a 18x provisional response, and does not hear ringtone before the callee answers. To support these cases, the SBC inserts a CON message into the outgoing 200 OK response.

High Availability

By design, the SBC replicates session level data to the standby after the 200 OK message. Because the SBC processes ISUP signaling prior to the 200 OK, there is no HA replication of these messages. Specifically, the ACM and CPG get processed with provisional (18x ) responses and the ANM or CON ISUP get processed with the 200 OK response. If an HA pair fails over between the IAM and ANM messages, the SBC cannot maintain state for these sessions.

State Machine

The SBC maintains state for SIP to SIP-I sessions only when configured for native ISUP message interworking; not for the HMR method.