Page History

set addressContext <addressContext name> zone <zone name> sipTrunkGroup <TG name> signaling honorMaddrParam <disabled | enabled> 

New Features

New Features in 07.02.00R000 Release

SBX-50672 STIR-SHAKEN: Support for signing via 3rd party Signature Server 3rd party Verification Server and Tagging

The proliferation of identity spoofing (potentially combined with robocalling) often leads to unsuspecting consumers falling victim to scams, such as IRS impersonation, offers of free travel, loan support and software technical support.  Identity spoofing and robocalls also devalue the real-time communications process and annoy customers.  Well-intentioned, but flawed “blacklists” for anti-robocalling tools and applications are easily thwarted by spoofing techniques.  SBC provides the solution is based on industry-standards activities related to securing VoIP call identity.

STIR (Secure Telephone Identify Revisited) defines core protocols and technologies for SIP and certificate usage for applying digital signatures to validate the telephone identity of the calling party.STIR (Secure Telephony Identity Revisited) provides an anti-spoofing SIP protocol specification to authenticate a SIP origination using a cryptographic signature called an IDENTITY header that is verified by a terminating SIP element.  This IDENTITY header provides an attribution to the signing carrier, and assurance that it is authorized to sign over the originating telephone number.

SHAKEN (Signature-based Handling of Asserted Information Using Tokens) defines the industry framework for using STIR technologies and how service providers will interwork VoIP based calls. 

For more information, refer to:

• CAM Changes in this Release
• CDR Field Descriptions
• Show Table Profiles - Services - Retry Profile
• Services - Sti Profile
• Services - Retry Profile
• Trigger Action Rule - Action
• Retry Profile - Trigger Action Rule
• SIP Trunk Group - Services
• STIR/SHAKEN Support

SBX-51418 Increase in the Number of Rules in SMM Profile  

An SMM profile is currently limited up to 64 rules. This limit can be reached if a carrier requires a lot of adaptations so the customer requires an increase in this limit to 256. 

For more information, refer to:

• SIP Adaptor Profile - CLI
  
• System Provisioning - SIP Adaptor (SMM) Profile
• SMM Rules

SBX-52861 Add a Dynamic SIP Signaling Port

The SBC uses port 5060 as the default signaling port. The default system-wide port range is 1024 - 65148. When the sigport is modified and falls outside the media port range, the NP layer is able to process as control packet and same is forwarded to application and call established successfully.

If the default signalling port is configured to other than 5060 or 5061 and falls inside the system-level media port range, then the packets received on the port will be part of the rogue media list because NP will not find any XRes activated for the port and the call will fail.

To complete the calls, you must reconfigure the system-level media port range or sipsig port so that the configured sigport falls outside the media port range.

This feature allows the admin to configure the sipsigport inside the media port range as well. 

For more information, refer to:

•  Media System - CLI

SBX-54420 Create Different Triggers Based on TLD (Top Level Domain)

The SBC now allows users to create multiple ENUM services for same service type (sipAor, CNAM, or LNP), and to create different triggers based on TLD (Top level Domain).

For example:

Service1 -> SIPAoR type -> Trigger1 as TG1 -> ENUM TLD example1.net

Service2 -> SIPAOR type -> Trigger2 as TG2 -> ENUM TLD example2.net

For more information, refer to:

• Servers - CLI
  
• Servers - ENUM - CLI
• Show Table Global
• Servers - ENUM Service
• ENUM Service - Flags

SBX-56399 DSCP Marking for T.140 Text Media

In previous releases, the SBC supported Differentiated Services Code Point (DSCP) marking for non-audio streams (video and T.140 text) for both High Priority Calls (HPC) and non-HPC calls. The SBC Core is enhanced to support alternative DSCP marking for T.140 text media stream types from what is used for video and audio media stream types irrespective if the request has an RPH header.

For Government Emergency Telecommunications Service (GETS) / Wireless Priority Service (WPS) calls ( high priority calls), DSCP markings are associated with the provisioned ETS value and in the outgoing message includes an RPH containing the provisioned ETS.x. When the message is destined for the internal network,  there is a single DSCP associated with that ETS value and assigned to all associated signaling and media packets. When it is destined for an external network, there is a single DSCP associated for every peer. In other words, there is a set of DSCP values rather than a single DSCP value in each case, one each for signaling, audio, video and text.

To support this feature, a new parameter "T140 DSCP" is added to QosValues for DSCP marking of T.140 text .The  DSCP value for T.140 packets is configured on Packet Service Profile (PSP) basis.

For more information, refer to:

• SBC Support of GETS and WPS
• QoS-Based Routing Support
• Media - Packet Service Profile - QOS Values
• SBC Support of GETS and WPS

SBX-57592 Need Trap to Notify Users of a DB out of Sync Condition

An entity, dbSyncCheckProfile, is added. A parameter, syncCheckInterval is added to dbSyncCheckProfile to configure the time interval for verifying the database integrity. It will raise an existing TRAP "sonusDatabaseConfigPolicyDataOutOfSyncNotification" when a DB Out of Sync condition arises. If a subsequent DB out of sync condition arises then it should increment the TRAP counter unless it is cleared by the clear trap. Also, the application shall raise a clear state TRAP, the existing "sonusDatabaseConfigPolicyDataInSyncNotification" when CDB and Oracle are back in sync state. A DB Out of Sync condition is a state when there is a mismatch between the count of trunkgroups, ippeer and relayPort between CDB and oracle DB.

The value range for this parameter is either 0, or between 5-30 minutes. The default value is 5. If the user wishes to not receive the automated db sync state traps, they can disable it by configuring the syncCheckInterval parameter to 0. If it is configured to 0, then no traps will be generated. However, integrity is still checked in 1 minute intervals and is logged into the .SYS file at /var/log/sonus/sbx/evlog path. Since there should only be one sync interval timer, there is only one entity of this profile, which is "DEFAULT", and it cannot be deleted. 

For more information, refer to:

• Show Table Profiles
• Db Sync Check Profile - CLI
• Show Table Profiles - Db Sync Check Profile
• Profiles - Db Sync Check Profile

SBX-62287 EVS Pass-Through Support

The SBC supports use of the Enhanced Voice Services (EVS) codec in pass-through mode. Pass-through of the EVS codec from one call leg to another can occur when EVS is configured in both the ingress and egress PSPs, based on the outcome of SDP offer-answer procedures.

In pass-through mode, all EVS codec parameters in Primary mode as well as AMRWB-IO mode are relayed to the egress peer. 

The SBC drops any unknown parameters received in the a=fmtp: line in the SDP offer or answer, as well as any known EVS codec parameters that have values other than the range defined in the TS 26.114 standard. 

To enable support of EVS, you can configure codec entries that specify EVS as the codec type. The codec entry configuration allows the SBC to restrict certain parameters, like bit-rate, according to the operator's requirements. The configurable options for an EVS-based codec entry include:

• Packet size 20-100ms supported - default 20 ms
• Dynamic Preferred RTP Payload Type 0-127 supported - default 96
• Min Bit Rate - Supported rates are: 5.9, 7.2,8, 9.6, 13.2, 16.4, 24.4, 32, 48, 64, 96, and 128, but must be less than or equal to Max Bit Rate - default 5.9
• Max Bit Rate - Supported rates are: 5.9, 7.2,8, 9.6, 13.2, 16.4, 24.4, 32, 48, 64, 96, and 128, but must be greater than or equal to Min Bit Rate - default 128
  The configured minimum and maximum for bit rate defines the range the SBC uses in its offer/answers during SDP negotiation.
• DTMF Relay - Supported values are: None (default), Out Of Band, Rfc2833, Either Oob Or Rfc2833, Both Oob And2833.
• DTMF Remove Digits - Supported values are Disable and Enable (default).

The configured Codec Entries are then incorporated in Packet Service Profiles (PSP) and assigned to enable EVS support.

For more information, refer to:

• Audio Codecs
• Routing Mechanisms
• Tones and Announcements
• Tone Codec Entry - CLI
• Codec Entry - CLI 
• Codec Routing Priority - CLI 
• Show Status System
• Show Table System 
• Media - Tone Codec Entry
• Media Profiles - Codec Entry
• Media Profiles - Codec Routing Priority 
• Codec Type Descriptions
• Supported Standards
• SBC Node-Locked Licenses for HW and SWe SBCs

SBX-62919 SILK Transcoding Support

The SBC currently provides pass-through support for the SILK codec in narrowband (NB), mediumband (MB), wideband (WB), and super-wideband (SWB) formats. It will now also support transcoding for the NB and WB SILK codec variants. SILK transcoding support applies to the SBC 5110, 5210, 5400 and 7000 platforms only.

SILK is a patented codec and its use is controlled by a countable license when transcoding is involved. A "DSP-SILK" license is required, per call leg, when SILK transcoding is required. If a SILK codec transcoding session is rejected because a SILK license is not available, the disconnect reason field in CDRs will contain a value of 206.

When configuring codec entries for the SILK codecs, options are now offered for enabling/disabling discontinuous transmission (DTX) (disabled by default), and for configuring Max Average Bit Rate. Each supported SILK variant has its own allowed range and default value for bit rate (see New Command Parameters).

To support SILK transcoding, SILK can now be selected in either the "This Leg" or "Other Leg" options within the "Codecs Allowed For Transcoding" in the Packet Service Profile. Adding SILK to the allowed codecs enables transcoding of both SILK NB (SILK8) and SILK WB (SILK16).

The following DSP-related statistics tables now include entries for SILK8 and SILK16:

• DSP Usage
• DSP Call Current Statistics
• DSP Call Interval Statistics
• DSP Usage Current Statistics
• DSP Usage Interval Statistics 

The following counted-license usage tables now include entries for SILK usage:

• Call Count Current Statistics
• Call Count Interval Statistics
• Service Authorised Cur Stats

• Service Authorised Int Stats

For more information, refer to:

• SBC Node-Locked Licenses for HW and SWe SBCs
  
• Show Status System
• Show Status Global
• Codec Entry - CLI
• Packet Service Profile - CLI
• DSP Status - DSP Usage
• DSP Res - DSP Call Current Statistics
• DSP Res - DSP Call Interval Statistics
• DSP Res - DSP Usage Current Statistics
• Global - Call Count Current Statistics
• Global - Call Count Interval Statistics
• Global - Service Authorised Cur Stats
• Global - Service Authorised Int Stats
• Call Routing: System Provisioning - Codec Entry
• Packet To Packet Control - Codecs Allowed For Transcoding
• Audio Codecs
• SBC 5400 Performance Metrics
• SBC 7000 Performance Metrics
• Supported Standards
• Call Termination Reason Codes
• Codec Type Descriptions

SBX-64225 SBC SWe - Count Out of Dialog Messages for Reporting and Billing

Networks with a Caller ID Name (CNAM) gateway use an out of dialog Subscribe/Notify and there aren't any "sessions" as part of the transaction. The SBC now reports peak transactions for all Out of Dialog (OOD) in order to facilitate reporting of OOD SIP transactions.  

This capability can be used with CNAM gateways, Rich Communication Services (RCS)-based services and any SBC that uses OOD messages.

The SBX reports interval statistics for the peak-rate of OOD SIP Messages in the SBC to the EMS:

• The rate counting is done at global level (system-wide) at each SBC.
• Only the incoming OOD messages are used for counting the rate. 
• The SIP requests counted are all OOD requests except INVITE AND REGISTER.
• The rate is counted before any rejections at application level such as CAC and traffic control.
  
  

In order to help monitor usage, a new configuration is added to help configure a limit for OOD usage:

• A new CLI to configure an licensedMaxRateLimit at global level.
• You can set this value based the rate allowed from the paper license.
• When the calculated OOD rate exceeds this maximum limit, the application (TRM) will generate a trap.
• The trap will be cleared when the usage rate falls below 10 percentage of the configured limit.

For more information, refer to:

• SIP OOD Limit - CLI
  
• Show Status Global
• Global - SIP Ood
• Global - Ood Message Current Statistics
• Global - Ood Message Interval Statistics
• sonusSbxLicensedOodRateLimitReachedNotification - MAJOR
• sonusSbxLicensedOodRateLimitClearNotification - MAJ

SBX-65402 RTCP Relay Feature With RTCP Generation

The RTP Control Protocol (RTCP) in conjunction with RTP, provides the report of PDUs exchanged between the source and the destination. It provides feedback on the quality of the data distribution. The RTCP monitors the transmission statistics and Quality of Service (QoS) status of the media streams and aids synchronization of multiple streams.

When the SBC generates an RTCP packet toward the outgoing direction, it relays the received RTCP packets from one leg to another leg. The SBC supports  RTCP monitoring and generates RTCP for pass through calls regardless of the leg where the RTCP is received. The SBC generates RTCP on one leg, even if other leg sends RTCP, without any dependency on the RTCP-related configuration on the other leg.

For more information, refer to:

• Packet Service Profile - RTCP Options
  
• Packet Service Profile - CLI

SBX-65508 Domain-based Licensing on SBC SWe Cloud

Network-wide domain licensing (NWDL) is supported in OpenStack cloud environments. NWDL ties a license to a Ribbon EMS administrative domain rather than the hardware ID for a specific host server or the UUID for a specific node instance. This feature is available only in specific OpenStack cloud environments. Contact your Ribbon representative for applicability and licensing information.

SBX-66050 Individual RTP Inactivity Timer for Audio and Video Stream

In sessions with video and audio streams, the SBC now distinguishes between “audio” and “video” so that calls will not be discontinued due to call-hold RTP inactivity. This solution allows enabling/disabling of the RTP inactivity timer on audio and video individually. This means that sessions with an audio stream, but no video stream, the session will stay live.

 For more information, refer to:

• AMR and RTCP Enhancements

SBX-67358 Copy All Direct Media SDP Information on Incoming INVITE to Outgoing INVITE

In a direct media call, the SBC changes the SDP parameters (such as packet size) while sending out direct media SDP which results in a call failure. To overcome this limitation, the SBC is enhanced to remove any default value SDP parameters (if it is not correct) added by the SBC in direct media basic DM, DM Anti trombone and DM Xdmi calls.

The SBC identified the SDP parameters (such as packet size) values that the SBC is modifying to default or based on configured value, while sending Direct Media Sdp parameters in outgoing INVITE.

In the direct media call, the SBC adds the default/configured parameters in outgoing SDP and does not pass the exact incoming SDP as direct media, in an outgoing SDP. Neither the ingress and nor the egress leg have the same protocol (one leg is SIPS protocol and other leg is H323 protocol).

This features identifies and removes the default/configured media parameters added by the SBC in direct media when sending the direct media SDP parameters in outgoing INVITE.

The SDP parameters whose default value is added in the direct media SDP include, but not limited to:

• rtcp (port)
• codec parameters minptime.
• codec parameters maxavaragebitrate

The SBC SDP functions include:

• Storing the appropriate SDP content (c-line, m-line, a-line) on the incoming INVITE
• Adding the stored SDP content on the outgoing INVITE
• Supporting this function on both, direct media and antiTrombone
• Supporting for SRTP
  
  

For more information, refer to:

• Direct Media

SBX-67789 Disable/OOS per Peer with DNS Query

The SBC is enhanced to disable/set Out of Service the server at the IP peer level. In order to do so, your network must know the server IP address of the peer.

The SBC uses a Domain Name Server (DNS) server to resolve the Fully Qualified Domain Name (FQDN), and obtains multiple IP peer addresses. After a carrier notifies your network that a particular server has an issue and is out of service, your network server's peer mode is set to Out Of Service.

This feature provides the flexibility to block peers individually within a trunk group. The can be set to out of service, rejecting both incoming and outgoing calls.

For more information, refer to:

• Zone - CLI
• Zone - IP Peer - CLI
• Show Table Address Context - Zone
• System Provisioning - Zone
• System Provisioning - IP Peer

SBX-67797 Multiple Bindings per SIP Line (several phones share same number)

When a subscriber registers from multiple devices with the same username, there is an inherent issue on the private side of the SBC. In Access mode, the SBC traditionally does not manipulate the username for the AOR, but does manipulate the host portion. The host portion is changed to the private side IP of the SBC when sending to the Registrar. If a subscriber registers from multiple devices it causes the same AOR to be created from the SBC to the registrar. 

To make this unique, the SBC inserts a parameter called reg-info and inserts a unique value in this parameter. Some registrars do not cache the parameters inserted by the SBC which causes this use case to fail.

To remediate this type of failure, the SBC privately assigns a unique new value to the username. The SBC maintains a mapping from this unique username value on the private side, and the original username on the public side.

For more information, refer to:

• CLI Changes in This Release
• SIP Trunk Group - Signaling - CLI
• Show Table Address Context - Zone
• SIP Trunk Group - Signaling
• SIP TG - Signaling - Embedded Reg Info in User Part - CLI

SBX-67830 Remove enumdi Parameter Inserted in Egress R-URI after ENUM Query from PSX

In its default behavior, the SBC adds an enumdi (ENUM dip indicator) parameter to the outgoing Request URI when the PSX performs an ENUM query. Some peering carriers do not support this parameter and want the option to not have the SBC insert the parameter the egress Request URI.  A global flag, egressRemoveEnudmi, controls whether the parameter is present. By default the flag is disabled to maintain the SBC default behavior. When the egressRemoveEnudmi flag is enabled the SBC does not add an enumdi parameter even if the PSX performs an ENUM query.  

For more information, refer to:

• Signaling - SIP Sig Controls
  
• Signaling - Global - CLI
  
  

SBX-68156 Enhancements to SBC Orchestration and Life Cycle Management using VNFM

The 7.2 SBC SWe Cloud aligns with the 18.3 Ribbon Virtual Network Function Manager (VNFM) to support additional deployment models and options. For example, VNFM now supports deploying and upgrading I-SBC and N:1 HA M-SBC configurations. Options such as provider networks, IPv6 networks and use of bootable cinder volumes are also supported.

For more information, refer to:

• Lifecycle Management using VNFM
• sonusVnfmConnectionFailed - MINOR
• Steps for SBC SWe Instantiation on OpenStack using VNFM
• For OpenStack
• VNF Performance Tuning
• Creating Flavors
• Creating a Glance Image
• Creating Tenant Networks
• Creating Security Group Rules
• Configuring SBC SWe on OpenStack using SBC Configuration Manager
• Upgrading SBC SWe Cloud Instances using VNFM
• Instantiating SBC SWe on OpenStack using VNFM
• Microservices SBC on OpenStack: Performance Metrics
• Configuring an SBC SWe Cluster using the EMS

SBX-69299 Support OpenStack Queens 

OpenStack Queens is supported.

Pagebreak

SBX-69807 503 Response Behavior on ARS

The SBC uses the SIP ARS (Address Reachability Service) profile to define criteria for temporarily blacklisting a peer endpoint when the endpoint appears to be unreachable.The SIP ARS profile now includes an option to blacklist a peer endpoint when the number of SIP 503 responses which do not contain a Retry After header that the peer sends within a configured period of time exceeds a configured threshold. Blacklisting due to 503 responses without Retry headers can be configured alone, or in combination with the two existing options for blacklisting due to 503 responses with Retry After headers or the rate at which INVITE timeouts occur. The mechanisms offered to recover a peer endpoint that was blacklisted due to the rate of 503 responses without Retry After headers is the same as those used to recover from the existing blacklisting methods: a configured time limit for the blacklisting or when the SBC receives a configured number of responses to a SIP OPTIONS ping probe messages sent to the peer within a specified duration. SIP ARS profiles can be assigned to SIP trunk groups.

For more information, refer to:

• Address Reachability Service
  
• SIP ARS Profile - CLI
• Show Table Profiles - Services - SIP ARS Profile
• Service Profiles - SIP ARS Profile
• sonusSbxArsEndPointBlacklistedNotification - MINOR
• sonusSbxArsEndPointBlacklistedNotificationV6 - MINOR
• sonusSbxArsEndPointRecoveredNotification - MINOR
• sonusSbxArsEndPointRecoveredNotificationV6 - MINOR
• sonusSbxArsEndPointsRecoveredNotification - MINOR

SBX-69821 Update MetaVariables Table to Add New SIP Signaling Port

In  the SBC SWe Cloud deployments, metadata configures values related to the SBC interfaces such as IP addresses and gateways. This information initially comes during instantiation from the metadata found in Heat templates or configuration drives.

The SBC SWe Cloud provides a system table that you can populate with additional metavariables to add to the metadata in an existing SBC deployment. The metavariable values in the table become available to the SBC instance without having to rebuild it. For example, you can add the metavariable values needed to configure an additional SIP signaling port in a deployed SBC instance.

The table is not intended to make changes to existing configuration.  You cannot add metavariables to the table to override values that were already defined during instantiation.

For more information, refer to:

•  Show Table System

Pagebreak

SBX-70226 Early Media Interworking between

Customer Networks

with Direct Indirect Peering Networks

The Ribbon SBC is enhanced to provide:

• Interworking towards ATT/TMO networks to provide explicit early media authorization
• Enhanced Monitoring Logic (monitoring for configured number of RTP packets – instead of one RTP packet)
• Flexible Tone-Generation criterion (primarily to cater to different criteria for interworking for different types of networks) and Delayed RBT (i.e. playing tone only if monitoring fails)
• Enhancements related to P-Early-Media to Alert-Info interworking

The tone-criteria-profile and rtp-monitoring profile are configured in the PSX and provided to the SBC as part of policy response. This will cause Diameter+ interface to be enhanced to take these parameters. The SBC is backward compatible with these additions in the Diameter+ interface.

 For more information, refer to:

• Tones and Announcements

Resolved Issues

Resolved Issues in 07.02.00R000 Release 

The following issues are resolved in this release:

Known Issues

Known Issues in 07.02.00R000 Release

The following issues exist in this release:

Known Limitations

The following limitations exist in this release:

• Due to a known EMA GUI issue, it can take up to 10 minutes to process each SMM rule when provisioning SMM on the SBC using the EMA. This will be fixed in a future release.

• The Access Control List (ACL) is not installed to configure SNMP traps for accepting traffic. A dynamic ACL is added to configure SNMP traps. An ACL must be installed for SNMP traps for accepting traffic.
• The physical NIC connectivity must be in active state at the hypervisor level before starting the SWe instance on the SBC SWe platforms. In case of SWe instance with SR-IOV interfaces, manual restart of the SWe instance is required if physical NIC connectivity goes down while the instance is in progress.The HA interface must not be configured with link localaddress or subnet.  
• The Antitrombone feature is not supported on the D-SBC.
• EMS identifies the nodes based on the VNFC-ID. While instantiating SBC/PSX cloud nodes, ensure that you use a unique VNFC-ID only. If you reuse an existing VNFC-ID, EMS treats this as a re-registration request and overwrites the existing data on the cloud node.
• While configuring the SBC SWe Cloud instances, the CLIs commits successfully even if any metaVariable provided is incorrect. The SBC SWe Cloud instance cannot validate the CLIs, as the CDB configuration file is stored in the SBC Configurator and is shared among all the other SBC SWe Cloud instances in the cluster.
• Editing IP Interface is not reflected in the if configuration (ifConfig). This behavior is observed only on the S-SBC when action is set to "dryup" mode on the IP Interface. The IP address changes are not updated in the kernel and will not be displayed when ifconfig linux command is executed. In case of S-SBC, if the ipInterface configuration needs to be modified and if the action is set to "dryup" in ipInterface configuration, it must be set to "force" before disabling the ipInterface and making any changes.
• A LSWU on an SBC 7000 should only be performed when the total number of active calls on the system is below 18,000. If the criteria is not met, a double failure during the upgrade may occur thereby losing all active calls. If such a failure occurs, both active and standby SBC services will go down.  Contact Ribbon Support immediately.
  
  

Performing Heat Stack Update when userdata is Updated with SSH Keys

When upgrading SBC SWe cloud instances to release 7.2, you must update your Heat template userdata section to include mandatory SSH key information. An issue in OpenStack requires that you use the stack-update process rather than re-launch after updating the template, which leads to a new UUID for the instance. As a result, you must regenerate and apply new license bundles to the upgraded instances during the upgrade.

Refer to Upgrading M-SBCs in an N:1 Redundancy Group for the relevant procedure. 

Restricted Functionality with SBC

The following functionalities are not supported with SBC Microservices:

• SRTP
• Far end NAT traversal
• DTMF inter-working
• RTCP termination for pass-through calls
• Direct Media and Antitrombone
  
• NICE, SIP-REC
• Rx, Rf interfaces
• Multimedia - MSRP, BFCP  
• Fax detection
• ICE/STUN
• SIP REFER
• SIP REPLACE

• Two stage calls

• H323 support
• GW signaling support

Restricted Functionality with SBC for AWS

The following functionalities are not supported with SBC for AWS:

• The EC2 does not support VM console. The SSH must be used to access the VM.
• The smarctl disk status is not supported on Amazon instance.
• All the networking ports must be in different subnets.
• The instance creation and reboot process take approximately 4 to 6 minutes to complete.
• IP spoofing or L2 learning is not supported.
• It is required to associate an EIP on MGT0 for an HA, and the CFN template automatically assigns the EIP. This is required for communicating with AWS servers while instance switchover. The EIP switchover takes 15-20 seconds.

Network Licensing Limitations

After switchover during grace period, when the new standby SBC comes up and establishes itself as standby, there is a short period (a few minutes) when the standby is synchronized for normal operation, but the new standby has not yet completed establishing its licensing state using the grace license information. If there is a second SBC switchover during that window, the new active SBC (which became active before completing license state synchronization) will lose calls until it re-acquires the grace licenses.