Use the SIP Sig Controls window to configure SIP signaling parameters at the global level.

To View and Edit SIP Sig Controls

On the SBC main screen, go to All > Global >  Signaling > SIP Sig Controls. The SIP Sig Controls window is displayed.

Figure 1: SIP Sig Controls Window

Use the following table to make any changes and then click Save.

SIP Sig Controls Parameters

Parameter Description
Loop Detection Feature

Enable this flag allow the SIP stack to perform loop detection on incoming INVITE messages.

The options are:

  • Enabled (default)
  • Disabled
Registrar Support Contact Param

Enable this flag to allow the Registrar to supports parameters in the Contact header:

  • Enabled (default): The SBC supports the parameters in the Contact header are supported. Ribbon recommends selecting the Enabled setting.
  • Disabled: The SBC supports the parameters in the Contact header are not supported. Use this flag for backward compatibility.
Suppress Error Info HdrEnable this flag to suppress the Error-Info header as a response to request message with a syntax error. The options are:
  • Enabled:
  • Disabled (default)
Max Pdu Size Value

The maximum PDU size that the SBC recognizes.

The options are:

  • pdusize2kb
  • pdusize3kb
  • pdusize6kb
  • pdusize15kb (default)
  • pdusize32kb
  • pdusize60kb

Note: The SIPSG code is enhanced to send the complete contents of data per message to the trace log. The SBC configuration allows for a max PDU of 60K.

Egress RNParam

Specify the flag to allow the SBC to sends a Redirecting Number Information Element (RNIE) in the egress leg of a call per RFC 3398 when the Request URI and the To header differ.

  • Disabled
  • Enabled (default)
Multiple Contacts Per Aor

Enable this flag to support the multiple contacts per Address Of Record (AoR).

  • Disabled – Only a single contact per AoR is supported.
  • Enabled (default) – The SBC maintains different Registration Control Blocks (RCBs) for each new registration and verifies the source IP address and port during RCB lookup.

The SBC supports validating the source IP address and the port even if Multiple Contacts Per Aor is Disabled. The SBC also supports locating the RCB using the AoR to perform additional validation on the source IP address and port if you set the option Require Registrationto "required" or "required-non-priority". This is applicable for both calls and out-of-dialog (OOD) requests that are originated from the IAD.

For refreshing registration that originates from a different IP/port, the SBC forwards the request to the registrar and moves the state to "UPDATING". Validate any calls or OOD requests that originate from the IAD while the RCB is in updating state, using the previously authenticated IP/port.

When Multiple Contacts Per Aor is Enabled, the SBC maintains different RCBs for each new registration. The SBC considers a new registration when the source IP/port of the REGISTER request is different from an earlier registration for the same AoR. Any of the registered UEs may initiate a communication on behalf of the AoR. The SBC fetches the corresponding RCB based on the source IP/port of the UE.

NOTE: Even though the default value of Multiple Contacts Per Aor is Enabled, during an upgrade, the value can be either "Enabled" or "Disabled".

Refer to Multiple Contacts per AoR for additional details.

Send De Register Contact As Star

Enable this option to allow the SBC   to send the Contact header as an asterisk (*) in de-REGISTER messages if Multiple Contacts Per Aor is Disabled.

  • Disabled
  • Enabled (default)
Ucid Node IDSpecify the UCID Node ID  to generate the UCID in the User-to-User header. The value ranges from 0 to 32676, and the default value is 0.
Offer Answer Timer

Specify the number of seconds for the SBC to wait for the Offer-Answer handshake to complete before timing out.    

Once configured, the SBC uses this value for all subsequent calls.

For backward compatibility, set the Offer Answer Timer to its default value for SIP signaling gateway.

Note:

The Offer Answer Timer goes beyond transaction timeout value only for re-INVITE  transactions. For Media Resource Function timer (MRF) calls, if the Offer Answer Timer value has a value more than MRF timer value,  which is currently hard coded to 72 seconds , the call disconnects on MRF timer timeout, irrespective of the Offer Answer Timer timer value.

Surrogate Register Pacing Time

Use this parameter to specify the time gap, in milliseconds, between a final response of surrogate register and the next surrogate register message sent across all peers. The value ranges from 0 to 10000 and the default value is 0.

If surrogate registration is active and you want to disable pacing, first disable surrogate registration for all Peers from the IP Peer - Surrogate Registration page.

NOTE: Please research the feature to fully understand pacing semantics before using it. This setting is not required in generic deployments. Pacing is applied to all surrogate REGISTER requests generated for all surrogate AoRs.

Send Surrogate Un Register After Reboot

Enable this flag to trigger de-REGISTER messages to all AORs configured to use the Surrogate Registration feature, after a reboot.

  • Disabled (default)
  • Enabled
Send503During Switchover

Enable this flag to control the sending of 503 message during a switchover.

  • Disabled  – The SBC drops the request  with no 503 message sent for INVITEs. 
  • Enabled  (default) – The SBC sends the 503 messages during a switchover.

NOTE: The Retry-After tag is set to 60 seconds in the 503 sent.

Egress Remove Enudmi

 Enable this flag to control whether the SBC removes the enumdi (ENUM dip indicator) parameter from the egress Request-URI that the SBC inserts when the PSX does an ENUM query. The options are:

Disabled (default) - The SBC includes the enumdi parameter in the egress Request-URI when the PSX does an ENUM query.

Enabled - The SBC does not include the enumdi parameter in the egress Request-URI even though the PSX does an ENUM query.

Register IP Lookup Post Switchover

Note: This feature is only applicable for TCP/TLS transports.

After an SBC switchover, the first REGISTER request sent by the UE is not matched to an existing TCP connection on the newly-active SBC. This will eventually lead the UE to become aware of the lost TCP connection, and the UE will then establish a new TCP connection and send an initial REGISTER request using the same IP address but with a different port compared to the TCP connection established before the switchover as the selection of client source port for a new TCP connection is usually ephemeral.

The SBC relays the initial REGISTER request sent by the UE to the Registrar as it creates a new AoR. Thus, the Registrar receives a high rate of REGISTER requests after an SBC switchover.

Enable this flag for the SBC to search for and validate that the initial REGISTER over the new TCP/TLS connection matches the synchronized RCB after a switchover. The SBC checks that the source IP address used for the new connection matches the old one regardless of the port value (It needs to update the port value and only for the first initial REGISTER received after the switchover for an AoR). Afterwards, the check is again based on the IP/port. 

Note: You must enable Multiple Contacts Per Aor to use this flag.

  • Disabled (default)
  • Enabled
SIP Bulk Status For Subscribers

(For S-SBC / I-SBC in 1:1 deployments only)

Enable this flag to use the SIP Bulk Status For Subscribers feature. 

  • Disabled (default)
  • Enabled

Enabling SIP Bulk Status For Subscribers gives you the ability to collect status files for the following after performing three dump requests over CLI or RESTCONF API:

    • Status of all Active registered endpoints. 
    • The Deleted Registers table, which includes the last deleted (or expired) registered endpoints.
    • All subscriptions generated by the SBC – specifically, SIP Generated Subscription Status – and the status for SIP endpoints.

Additional details: 


Feature Limitations
  • On a switchover, this feature is available on the newly-active SBC. Any rollover of the dump commands started on the earlier Active SBC is not supported.

  • If the feature is enabled at runtime, the required status lists start capturing the status of the subscribers who have seen a Register/Refresh Register at least once. Additionally, the status lists will dump the complete set of registered subscribers on the system over a period of time. However, if the system experiences a restart while the feature is enabled, the complete set of registered subscribers are available in the status lists once the SBC application comes up.
  • A dumped status file remains in the system until the SBC receives the next dump request for a similar status. No history of the files are maintained in the SBC.