What’s new in MR125

When mobile operators offer global data plans that include roaming – for example, 10 GB in 80+ countries for 30 days – data usage in some regions, like Pacific islands, can cost them far more than average. To prevent revenue loss, operators can define usage thresholds for these high-cost roaming zones. Once a subscriber reaches the defined limit in a specific region, PortaBilling can send a notification to the subscriber and an alert to an external application, which can instruct the mobile network to reduce data speed or temporarily block internet access.

This feature allows operators to protect their profits in high-cost countries, while subscribers receive clear notifications to control their usage.

You can set a usage threshold per roaming zone for an hourly, daily, or weekly period (based on the customer’s time zone). A roaming zone is a group of mobile networks identified by MCC (Mobile Country Code) and MNC (Mobile Network Code).

When a subscriber connects to one of these networks and starts using data, PortaBilling calculates the usage for that roaming zone in real time.

You can configure either of these conditions for the threshold:

• Actual usage – PortaBilling detects when the subscriber’s data consumption reaches the defined limit. For example, if you set 100 MB per hour, PortaBilling sends a notification once the actual usage reaches 100 MB or more.
• Estimated usage – PortaBilling estimates the subscriber’s projected usage rate (based on current data consumption speed) and detects if they are likely to exceed the threshold before the period ends. For example, if the usage reaches 60 MB within the first 30 minutes (meaning that the consumption speed is 120 MB/hour), PortaBilling can warn the subscriber before the 100 MB/hour limit is actually reached. If the subscriber keeps using data and the actual usage reaches the 100 MB threshold, an additional notification is sent.

  

When the threshold condition is met, PortaBilling can trigger:

• A webhook (HTTPS request) to your preconfigured external application (middleware), which can then apply the QoS changes in the mobile network.
• A notification to the account, customer, and admin through the preconfigured channels (e.g., SMS or email).

Prevent financial losses when offering roaming bundles.

See the configuration steps and details here.

In competitive prepaid markets, such as in Africa, and in roaming scenarios, providers offer services with 1-day bundles. These bundles allow subscribers to purchase and use services only when needed, with access lasting 24 hours.

With this release, you can configure whether a prepaid bundle’s lifetime is measured by the clock (24 hours from activation) or by the calendar (until midnight). This gives you flexibility to define how long a bundle remains active and ensures that users can enjoy fair and predictable access to services.

Previously, bundles always expired at midnight, which often resulted in shorter usage periods for users who activated a bundle late in the day. Now the users with short-term bundles, such as 1-day bundles, can use the services for the full duration they paid for (e.g., 1 day = 24 hours, 2 days = 48 hours), starting from the time of bundle activation.

Admins can also configure multiple notifications to remind users of an upcoming bundle expiration not only days in advance, but also hours or even minutes, for example, 2 days and 2 hours, or 4 hours and 30 minutes before expiry. This ensures that users with short-term bundles (e.g., 1-day) receive timely reminders and can renew before their service is interrupted.

For users:

• Get full access to services for the full duration they paid for – exactly 24 hours from activation.
• Stay informed about the bundle expiration to avoid service interruptions.

For service providers:

• Stay competitive in the market.
• Inform users about the bundle expiration, which help increase sales.

See the configuration steps here.

Cloud PBX customers can now easily configure programmable phone keys on additional Polycom IP phone models:

• Polycom VVX311
• Polycom VVX400
• Polycom VVX401
• Polycom VVX500
• Polycom VVX501

Auto-provisioning for these models is available via Add-on Mart with an active subscription to the related modules. Along with programmable key configuration, PortaSwitch automatically provides core parameters such as SIP credentials, proxy settings, and codec options. Customers can apply settings to multiple devices at once via the CloudPBX Self-Care Portal (accessible through Add-on Mart) or an external portal using the PortaBilling API.

• Service providers can offer a more competitive CloudPBX service to onboard more customers.
• Customers can manage phones on their own, reducing reliance on support.

If you have an Oracle-based on-premise installation and want to move it to the cloud, there’s now a solution for that. This release introduces the possibility of migrating Oracle-based PortaSwitch systems to a MySQL-based installation in Oracle Cloud Infrastructure (OCI). In the cloud, PortaSwitch runs on a MySQL database instead of Oracle RAC. (RAC requires a very specific hardware configuration for a shared disk array, and is not compatible with virtual resources in the cloud.) The MySQL database delivers the same reliability and performance as a single-node Oracle database – and, with the PortaOne team using cloud capabilities for disaster recovery, your service will be as resilient as it was with an on-premise Oracle database cluster.

Since the new installation contains a default database, the service provider must configure the product catalog in the cloud-based PortaSwitch. After the product catalog is set up, PortaOne Support migrates customers, resellers, and representatives from the on-premise PortaSwitch to the cloud-based PortaSwitch.

• No more hardware investment: No need to purchase or maintain physical servers.
• Reduced administrative workload: The cloud infrastructure is fully maintained by PortaOne, significantly reducing the effort required from your technical staff.

• Only customer, reseller, and representative entities (together with their billing data, like xDRs of the current billing period) can be migrated from the on-premise system to the cloud-based one. All other required entities must be pre-configured by the admin manually via the web interface or API.
• You can migrate to any maintenance release in the cloud, either to the same MR as your current system or to a newer one. However, the greater the gap between releases, the more challenging the pre- and post-migration activities become.
  The minimum release of the Oracle-based PortaSwitch that supports migration is MR70.
• All customers, resellers, and representatives must be migrated in a single run.

• Only the billing data for the current billing period is migrated. Historical data, such as xDRs from previous billing periods, are not migrated.
• Transferring the migrated entities back to the on-premise system is not supported.

Admins can now access more detailed call activity reports from the custom portals (third-party or developed in-house).  Call activity reports provide the total number of calls over a selected period, along with time spent on after-call work (wrap-up time), on hold, and waiting in the call queue.

This feature is available in the PortaBilling API. To support the new functionality, update your portals to use the “total_calls”, “wrapup_duration”, and  “suspended_duration” API parameters. The CloudPBX Self-Care Portal will include this data in future versions.

Admins and supervisors can filter the data in these reports by average metrics, such as average handle time, or by extremes, such as the longest and shortest calls. This helps track agent productivity and assess service quality by highlighting unusually short or long talk times. For example, a low number of outgoing calls may suggest limited customer follow-up, while a long wrap-up time can indicate inefficiency in post-call work.

PBX admins can analyze call data to understand the agents’ effectiveness.

With this release, Cloud PBX admins, call center admins, and supervisors using custom self-care portals can view caller and recipient details in the voicemail/fax list. To support this, the PortaBilling API method has been extended with two new parameters: “from” and “to”.  Along with the basic voicemail/fax message information (such as size, duration), this method now also returns the caller’s details and the number that received the message.

The custom portal should be updated to show these details. For the CloudPBX Self-Care Portal subscribers, this information will be shown in future versions.

Cloud PBX admins, call center admins, and supervisors can handle daily tasks more efficiently by accessing voicemail and fax message information faster.

The mobile core may send the subscriber ID (the SIM card’s IMSI or phone number) in either the User-Name or Subscription-Id field of Diameter requests. If User-Name is present, PortaBilling automatically uses it for subscriber identification. Only if it is missing does PortaBilling fall back to Subscription-Id. However, some mobile networks may utilize User-Name for other purposes while placing the subscriber ID in Subscription-Id. In such cases, PortaBilling receives User-Name, assumes it contains the subscriber ID, but cannot identify the subscriber based on it.

Now, for mobile data services, you can configure PortaBilling to ignore User-Name and only use Subscription-Id for subscriber authentication – allowing integration with such networks without extra development.

For PortaBilling to ignore the User-Name field when it contains something other than the actual subscriber ID:

1. Create a service policy for internet access and specify the Origin-Host value of the MNO’s network (e.g., the packet gateway) in the Attribute pattern field. You can specify it in the format Origin-Host=%.company.domain – this pattern matches any host within the same realm (e.g., pgw1.company.domain and pgw2.company.domain).

   

2. Navigate to Attributes > Gy and turn on the Ignore User Name toggle.

   

You don’t need to assign this service policy to a product or account – PortaBilling automatically applies this service policy when it detects a match between the configured pattern and the Origin-Host value in the incoming Diameter request.  When a service policy is applied, PortaBilling ignores the User-Name field and uses Subscription-Id to identify the subscriber.

Launch mobile data service faster without the need for extra support requests and custom code changes.

This release introduces an updated look to the Trace session page.

The Search panel has been moved from the left side of the page to a single line at the top of the page. This layout provides more space for displaying sessions and eliminates the need for horizontal scrolling, even when working with a large table.

To save space at the top of the page, additional search parameters that are used less frequently are now grouped under the More menu.

This enhancement improves the user experience when troubleshooting sessions.