Frequently Asked Questions

Link copied to clipboard

What is the difference between Zero-downtime update (ZDU) and Dual Version PortaSwitch?

Link copied to clipboard

ZDU allows to update the whole system to the new software version in a single step. Dual Version PortaSwitch solution implies the following:

  • Simultaneous operation of two independent systems in different software versions linked with each other.

  • Consistent migration of customers from a system with a lower software version to a higher version system.

Using the Dual Version PortaSwitch solution, you can gradually migrate customers from older releases to a newer release in 2-3 months (exact time depends on the database size).

The maximal update “jump” span for ZDU is 5 releases because the nearest LTS cannot be crossed in such a “jump.” Maximal “jumps” using Dual Version PortaSwitch solution are much wider but require obligatory checkpoints every 15 releases (i.e., MR55→MR70 or MR70→MR85).

Does the Dual Version architecture provide redundancy?

Link copied to clipboard

The target and source systems of the Dual Version solution operate independently and do not involve redundancy as part of the design. If a data center outage occurs for either the source or target system during a long migration, it’s going to be visible. So the Dual Version solution does not provide redundancy by itself, but instead works in conjunction with the current geo-redundancy and ZDU functionality available in PortaSwitch.

Since Dual Version PortaSwitch involves two systems running in parallel, the source and target systems can be used for geo-redundancy to ensure uninterrupted service provisioning for every system in Dual Version PortaSwitch

In most cases, the redundancy can be achieved in two ways: by deploying billing, SIP, and database clusters, or by dispersing the systems across multiple sites. The latter solution provides high-availability and geo-redundancy options.

Do I need to deploy a dispatching SBC (DSBC) if I already have the PortaSIP cluster?

Link copied to clipboard

Yes, you always need to have a separate DSBC for Dual Version PortaSwitch. Even if you have a fairly new PortaSIP, it’s still a part of your source system and is only aware of that specific system. If you want to move, for instance, from MR70 to MR85, you need a DSBC in front of your PortaSIP. DSBC decides whether to route calls to the PortaSIP cluster on the source system or the target system.

The DSBC links systems in Dual Version PortaSwitch and is required for delivering calls across systems. It “knows” where the account record is located and delivers the call accordingly. You can configure DSBC on a real or virtual server or in the PortaOne Cloud.

Does the DSBC participate in media streaming?

Link copied to clipboard

No. The DSBC only participates in the signaling path of the call by distributing incoming call initiation requests across systems for processing. When a call is established, endpoints exchange media streams directly (except for calls with RTPProxy, where the media stream goes through SIP Cluster without involving the DSBC), or it can take place via the RTPProxies of their respective PortaSIP clusters.

Where can I deploy the target system?

Link copied to clipboard

You have the choice to either:

  • Use dedicated hardware (on-premise or virtual).

  • Launch the target system fully in the PortaOne Cloud.

  • Use the PortaOne Cloud for the DSBC and the dedicated hardware (on-premise or virtual) for the rest of the target system.

The cloud can be a temporary migration tool, or you can use this as an opportunity to liberate your operations from the physical data center permanently. At PortaOne, we consider the cloud to be the way to move forward and future-proof your operations. However, to limit latency, we recommend deploying the DSBC (by default, deployed on the target system) as geographically close to the source system as possible.

Where do I need to install the dispatcher node: target or source system?

Link copied to clipboard

All dispatcher nodes need to be deployed within the context of the target system installation and configured by the target system’s Configurator.

What are the licensing terms for using Dual Version PortaSwitch?

Link copied to clipboard

An extra system requires extra licensing. The licensing depends on how you wish to deploy the target system. You can purchase a regular perpetual license and use it for your target system in the Dual Version PortaSwitch solution or as a separate system to ensure redundancy – that’s up to you. In the case of PortaOne cloud deployment, you benefit from the monthly fee calculated according to the number of your billable xDRs processed per month.

If you’re only interested in extending the system for a one-time migration, we can come up with an exclusive license to cover this situation. For detailed information about pricing, contact the PortaOne Sales team.

Can I launch Dual Version PortaSwitch if my current release is lower than MR50?

Link copied to clipboard

No. The Dual Version PortaSwitch solution is only available starting from MR55-6. If your current release is lower than MR55-6, you need to update to MR55-6 first. Contact PortaOne Support to schedule the update procedure.

Which releases are available for “long jump” via Dual Version PortaSwitch?

Link copied to clipboard

Currently, the “long jump” options are available for MR55-6 to MR70-6 and MR70-6 to MR85-3.

For detailed information about the transfer capabilities available for your current release and build, as well as for assistance in performing the transfer, contact PortaOne Support.

Can I run a pre-test to ensure that my customers are migrated successfully before I start the migration process?

Link copied to clipboard

Yes, to a certain degree, by using the “dry-run” mode of the Porter utility. In this mode, Porter emulates (there will be no new records in the database on the target system) exporting all data related to the customer and applies transformation logic for this data. Therefore, with the help of Porter, you can check the configuration of the target system before running the migration process.

Is there any downtime when a customer is moved between systems?

Link copied to clipboard

Yes. A customer can experience downtime ranging from several seconds to several minutes (for a customer with more than 100 accounts) while being migrated.

The migration of customer data related to the current configuration creates some downtime, but the migration of customer’s history of service usage (xDRs, volume discount counter history, call recordings, etc.) causes no downtime. During the customer data migration, services (LTE, SIP, xDR mediation, etc.) are affected by the downtime as the customer data might already be deleted from the source system, but not yet created on the target system.

Customer migration time strictly depends on the amount of data being migrated – for instance, the number of accounts a customer owns: it takes less time to migrate a residential customer with a basic SIP calling service than a PBX customer with dozens of accounts.

How many customers can I batch migrate at a time?

Link copied to clipboard

You can batch migrate any number of customers at a time. The number of customers in a batch is arbitrary. And the time it takes to migrate the batch depends on the number of accounts per customer and the overall capacity of the given Dual Version PortaSwitch installation. For example (based on real customer data, approximated):]

Customers

Accounts

VDCH discount history records

NAUD Internet session records

CDR_Accounts/CDR_Accounts Failed

Migration time (seconds)

1

5

15

330

255

8

1

19

236

0

1375

105

Several parallel threads deal with entities in the batch to provide maximally fast customer migration thanks to the new smart Porter utility.

Each thread processes its customer and starts transferring the data belonging to that customer. In this process, threads also branch into parallel “workers” that work in a single customer’s context, reducing the overall migration downtime.

For example, if the customer has 4 accounts and 4 workers, then each can take one account and start transferring its data to the target system. Threads allow you to port several customers at once, thus making better use of the hardware. These parameters are selected automatically (and not by an administrator). You can try and pre-define them, but the automatic way is recommended.

Can I migrate just a part of the reseller customers?

Link copied to clipboard

Yes. Partial migration allows you to migrate just a small batch, see how it behaves, test, and do a rollback in case of errors or UX problems. In this case, the reseller is not marked as Exported and thus exists in both systems. This implies reseller management in both systems.

Can I add new customers, products, etc. to the systems during data migration?

Link copied to clipboard

On the source system, you can add new customers during data migration, but you cannot add new products. On the target system, you can operate independently from the source system and create new products and service bundles, evaluate new features, etc.

Will vendors be marked Exported after migration to the target system?

Link copied to clipboard

No. The vendor configuration is duplicated in Dual Version PortaSwitch. This means that the same vendor is active in both systems and their balance is split between the systems.

What happens to the vendor’s balance on the source and target systems?

Link copied to clipboard

The same vendor is active in both systems, so the balance is split between the source and target systems. The vendor’s balance is affected by the calls and services terminated on this vendor on each system. So, while the customers use the services on different systems, the vendor’s balance on the target and source system will not match.

For example, if the vendor’s balance on the source system is $2000, initially it will also be displayed as $2000 for the target system. However, as some customers are migrated to the target system and some stay on the source system, the balance for the services used will be displayed differently on different systems: $2000 + the price of the services used on the source system and $2000 + the price of the services used on the target system. This means that until all customers are fully migrated to the target system, the vendor’s balance on source and target systems will be different.

Can I modify a product that is only used by accounts on the source system in Dual Version PortaSwitch?

Link copied to clipboard

No. Product data is dictionary data, which must be in sync on both the source and target system at all times.

If a product is modified on the source system, the service behavior of an account will change after migration to the target system, leading to undesirable results because the system doesn’t expect such behavior. If a new product is created on the source system and then assigned to some account, the migration of the customer with such an account will fail.

Everything that can