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:
|
Registrar Support Contact Param | Enable this flag to allow the Registrar to supports parameters in the Contact header:
|
Suppress Error Info Hdr | Enable this flag to suppress the Error-Info header as a response to request message with a syntax error. The options are:
|
Max Pdu Size Value | The maximum PDU size that the SBC recognizes. The options are:
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.
|
Multiple Contacts Per Aor | Enable this flag to support the multiple contacts per Address Of Record (AoR).
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.
|
Ucid Node ID | Specify 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.
|
Send503During Switchover | Enable this flag to control the sending of 503 message 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 Disabled (default) - The SBC includes the Enabled - The SBC does not include the |
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.
|
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.
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:
Additional details:
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.
|