News

contact@portaone.com

Toll-free calls (phone & Skype)
+1 866 747 8647
Calls & faxes from abroad:
+1 604 628 2508

PortaOne, Inc.
Suite 408, 2963 Glen Drive
Coquitlam, BC, V3B 2P7
Canada

8 December 2017

MR63-65 Webinar Summary and Recording

webinar_image

For those of you who missed the recent PortaOne webinar on the new features in MR63-65 PortaSwitch, we have made available the recorded version.


Here is a list of the most important new features discussed during the webinar:

  • PortaSwitch Cloud SaaS
  • Dispatching SBC in PortaSIP for zero-downtime updates, easy end-point configuration and smooth operation
  • Performing gradual software upgrades via "dual-version" PortaSwitch — now available for customers with older releases (MR50 and MR55)
  • Provisioning of core mobile network components (HLR/HSS, PCRF) for MVNO and MNO service
  • Enhanced IP Centrex
  • Completing Phase 1 of new web GUI
  • and many others

Please find below a digest of the most frequently asked questions:

Q: In order to deploy a dual-version PortaSwitch system, do we need an extra set of servers?

A: We want to ensure your existing customers / operations are in no way affected by any changes related to launching a “new” release. To do that, the “alter-ego” site (the one running the newer release) must be physically separate from the “old” system. So, yes, the alter-ego system must reside on a different set of hardware. Or, alternatively, run it in the cloud.

Q: I would like to move from MR50 (or MR55) to a recent release via a dual-version gradual upgrade. What are the next steps? How long will it take?

A: To discuss your requirements and create a custom-tailored migration plan, please contact our support team (support@portaone.com).

A pilot set of several hundred customers can be migrated in one maintenance window. Each customer might experience a brief service disruption of only a couple of minutes while his / her record is being transferred from one system to another. This means that for customers as a group, the service is continuous. Typically most of the time required is for you to observe and verify that everything runs smoothly and customers can use the service on the new system. Ideally customer accounts should reside on the alter-ego site for at least one full billing cycle. After the recommended minimum of one full billing cycle, you can then migrate more customers (potentially increasing the “batch” size) or make an “educated decision” to upgrade the remaining “old” system as a whole.

Q: Does dual-version PortaSwitch allow zero-downtime upgrades?

A: When you add a secondary site to your installation, it can be used for two distinct and mutually exclusive purposes:

  1. Increased availability. The site then becomes fully synchronized with the main one (runs the same maintenance release, has a full replica of customer data, etc.) and can take over from the main site when the latter is unavailable due to some hardware issue or connectivity problem. The same site configuration is used to execute zero-downtime updates
  2. Gradual migration to a new software release. The site becomes independent: it runs the desired maintenance release (different from the one of the main site) and has its own set of customers. Customers are migrated from the main system using the Porter tool (that allows automatically transferring balances, service configuration, xDRs, etc.). All customers connect via Dispatching SBC (DSBC), so the migration is seamless for the customer: DSBC transparently redirects the requests (SIP, Diameter, API, etc.) to the system where customer is currently hosted.

A single site cannot provide both high availability for the existing software version and migration to a new release. So, a “gradual upgrade with high availability” requires one site to provide a redundancy and another site to be used for hosting a pilot set of customers on the new version.

Q: In order to deploy a dual-version PortaSwitch system, do we need an extra set of servers?

A: We want to ensure your existing customers / operations are in no way affected by any changes related to launching a “new” release. To do that, the “alter-ego” site (the one running the newer release) must be physically separate from the “old” system. So, yes, the alter-ego system must reside on a different set of hardware. Or, alternatively, run it in the cloud.

Q: What is DSBC?

A: Dispatching Session Border Controller (DSBC) is a new component of PortaSwitch responsible for providing a single entry-point for end-users. It processes incoming SIP requests, Diameter / RADIUS messages, API requests, etc., then dispatches them to the correct sub-system to ensure correct operations. Use-cases for using DSBC include:

  • Providing a seamless user experience in case of a zero-downtime upgrade. If only two redundant sites (with separate IP addresses) are used (without DSBC), when site A is down (hardware issue or scheduled software upgrade) then phones registered to this site cannot receive incoming calls until they re-register to site B. Using DSBC allows using a single IP address for NAT traversal. Any active site can then deliver an incoming call
  • Running a dual-version PortaSwitch (two sites operating different software releases and customer set). DSBC delivers requests to the site on which a customer currently resides.

DSBC should be installed on a separate set of hardware—minimum of two servers required (three recommended) to create a proper high-availability cluster. The alternative is to run DSBC in the cloud.

Q: What is the oldest version of PortaSwitch that can run in the cloud?

A: MR60. But we strongly encourage our customers to use the cloud as a tool to get upgraded to a more recent release such as MR65. It contains many important improvements such as a new Web UI. Running a dual-version PortaSwitch with the “new” (alter-ego) part in the cloud allows easy and virtually risk-free migration—even if you currently are on an older release such as MR50 or MR55.

Q: What are your plans for full IPv6 migration?

A: We believe that most CSP will have to live with IPv4 support for the foreseeable future. Hence IPv4 is still required. – and the current approach is to allow both IPv4 and IPv6 addresses on network interfaces. This allows transparent access via IPv6 for “network-agnostic” applications, such as Web UI. For network-aware applications, such as PortaSIP, the current approach is to use a single IP entry point accessible via IPv4 or IPv6 via NAT64+DNS64. This has already been proven to work (for instance when SIP dialer applications pass certification in the Apple app store).

So, for all practical purposes, you can provide service for customers on either IPv4 or IPv6 networks. If additional tuning or network configuration for a very specific case is required, please contact our support team to discuss the details.

Q: Does PortaSwitch provide API for creating call applications (Twilio-style)?

A: The new PortaSIP media server contains all the call processing logic within Python scripts that access media-server API for things such as establishing a call, playing a voice prompt, collecting DTMF input, etc. PortaSwitch users can write their own call-control scripts.

Additionally, recent versions of PortaSwitch include Websockets API that can be used by external applications for establishing new calls, call control, etc. We do want to extend this light-weight API with extra options such as IVR control functionality.

Please contact us if you have a specific project where this is required, so we can discuss the implementation scope and priority.

Q: New Web GUI – when will it be available?

A: As of MR65-1 and MR66-1, the new Web GUI becomes the default option on the admin interface, that is, you will see the new-style navigation menu that opens the redesigned pages, etc. Currently, the new GUI covers a large portion of the functionality, responsible for pretty much all daily operations of regular users — including (but not limited to):

  • service catalog (currencies & exchange rates, services, destinations, destination groups)
  • management of tariffs, volume discounts, quotas and bundle promotions
  • set up of recurring fees (subscriptions)
  • configuration of products
  • inventories (DIDs, SIM cards, IP phones)
  • sales agents (resellers / distributors / representatives)
  • management of customers / accounts
  • viewing logs / troubleshooting

There are quite a few remaining components, mostly in the "advanced administration" realm (e.g., management of service policies or taxation methods), which are seldom used. Nevertheless, we will keep migrating all of them to the new GUI. These changes will appear in upcoming leap-forward maintenance releases (MR67, MR68, etc.) as well as subsequent builds of MR65 (MR65-2, MR65-3, etc.)

Superb Reliability and Scalability with
24/7 Professional Technical Support

icon1.png

Open architecture

PortaOne provides both APIs and source code for PortaSwitch to allow an easy integration
 
icon2.png

Scalability for growth

Our platforms can easily scale up by adding more servers to match your project success
 
icon3.png

Reliability and redundancy

Clustering and geo-redundant site configuration allow to address the most rigorous requirements
 
icon4.png

24/7 technical support

Over 60% of our 300 engineers are in the technical support services, praised as the best in industry
 
icon5.png

Constant improvement

The dedicated highly skilled development team delivers more than 20 software builds per year