New set of SIM card events sent to an external web application
MVNOs pass SIM card information to their host MNO’s network to activate SIM cards for their subscribers. Now, SIM card provisioning becomes easier to implement with a new set of simplified SIM-related provisioning events and variables relevant to mobile subscriber provisioning.
This set has been introduced in PortaBilling for the webhook-based provisioning used by the universal EventSender handler, including:
- SIM/Created
- SIM/Updated
- SIM/Deleted
- SIM/Replaced
Simplified events mean that admins can now configure the EventSender handler to send one event (SIM/Updated) to an external application, notifying it at once about several changes in the SIM profile, such as status change from “In use” to “Disposed”, default PIN change, or product replacement.
The simplified version of the EventSender events is enabled by default, admins can explicitly see the full list of simplified events and subscribe to the required ones on the PortaBilling web interface. Simplified provisioning events allow developers to build external applications faster and easier, ensuring a saving of resources with application development.
Service providers save costs and resources on mobile services provisioning to MNO’s core.
Subscription to the simplified events (version 2) for the EventSender handler
Simplified provisioning events in the EventSender handler are now available in the PortaBilling web interface. Events are grouped by category (e.g., Account) and can be enabled individually. For example, the Account/Bundle/Changed event can be activated with one click. This reduces setup time for webhook-based provisioning by letting admins view and configure events directly in the UI.
Admins can also filter events by category across all event handlers in PortaBilling, making configuration faster and more precise.
Additionally, the EventSender handler now clearly indicates which version of the event is being used for provisioning – standard (v.1) or simplified (v.2). The configuration of the EventSender handler is done via the Event handlers in the PortaBilling web interface.
Admins save time on setting up external provisioning.
Transcription of voicemail messages
You can now use AI-driven speech-to-text services to offer automated voicemail transcriptions to your customers. This is especially useful for cloud PBX and call center users – when they are unable to listen to audio messages, they can quickly read the message instead.
Voicemail transcriptions use the same Add-on Mart module as call recording transcriptions. When a new voicemail is received, the audio is automatically transcribed by a speech-to-text service. Using the PortaBilling API, you can display both the voicemail audios and the transcriptions in your own account self-care portal or mobile app. You can also allow users to configure an external email address and receive voicemail transcriptions directly by email.
As with call recordings, voicemail transcription can be monetized as an add-on subscription or included in a usage-based bundle with a specific number of hours of recorded calls and voicemails.
To use the speech-to-text transcription of voicemails and call recordings:
- Sign up for an account with an external service (Whisper)
- Subscribe for the corresponding module in Add-on Mart
- Configure the integration:
- Obtain an API key from the external service and enter it in the Add-on Mart module’s Configuration UI
- If this is the first module you activate, specify the Add-on Mart credentials in PortaBilling
- Service providers can expand their cloud PBX or call center offering with voicemail transcription and generate additional revenue.
- End users can read voicemails at a glance and respond quickly.
Call activity reports
Call center admins and supervisors (managers) can now view activity reports of their agents. These reports help track agent productivity and assess support quality by highlighting unusually low or high talk time. For example, low talk time may suggest that an agent is rushing through calls, while high talk time may indicate difficulty in handling the calls.
The newly introduced call activity reports show total talk time over a selected period and can be filtered by hunt group, agent, and call type (incoming or outgoing). Additional metrics such as average handle time, hold time, and waiting time in the queue will be added soon.
If you want your custom portal to display call activity reports, you can use the new Customer/get_call_activity_metrics method of the PortaBilling API. The new feature will be available in the CloudPBX Self-Care Portal (accessible via the Add-on Mart) in future releases.
Call center and PBX admins can measure agent performance.
To allow viewing call reports, admins should open the PortaBilling web interface and enable the Advanced hunt group call tracking feature (Customer > Services > Voice calls).
By default, the call reports can be generated during the two-month period after handling the call. To increase this period, go to the Configuration web server interface and set a new period for the Metrics.CallActivityMetricsKeepMonth option.
Announce the position for the first caller in the queue
With this release, the first caller, just like all other callers in the queue, is clearly informed about being queued. For this, a new prompt has been introduced – “Currently, you are the [position] caller in the queue”. This allows the first and other subsequent callers to know their exact position in the queue and thus reduce the number of abandoned calls. Previously, only the second and subsequent callers in the queue were informed about the number of callers ahead of them, meaning the first caller received no announcement.
The custom portal should be adjusted to use the announce_position API parameter of the PortaBilling API to support the new functionality (will be available in the CloudPBX Self-Care Portal in future versions).
- Service providers can offer cloud PBX with better call queues.
- Cloud PBX and call center customers can improve the caller experience.
Suspended status for debit accounts
With this release, accounts with insufficient funds to cover subscription charges are now automatically marked as Suspended. This means that services for such accounts have been automatically suspended, though the account can still access the self-care portal. Once the balance becomes sufficient to cover subscription charges, the account is automatically reactivated.
Previously, such accounts were marked as Blocked, making it unclear whether the suspension was made by the system or manually by an admin. Now, administrators can clearly identify the reason for suspension and take appropriate action.
PortaBilling can also notify external systems, such as custom-built web apps or apps based on PortaOne Workflows integration, when debit accounts are suspended or reactivated due to insufficient funds. This allows those systems to display accurate account statuses to users and act upon them. For this, you can use the new Account/Status/Suspended and Account/Status/SuspensionRemoved provisioning events.
Former Account/Status/Suspended and Account/Status/SuspensionRemoved were renamed to Account/Status/CustomerSuspended and Account/Status/CustomerSuspensionRemoved to avoid confusion.
This enhancement reduces the risk of human errors and simplifies integrations with external systems.
To automatically suspend debit accounts due to insufficient funds for pending subscription charges in PortaBilling, enable the Suspend debit accounts option on the customer class configuration. If you need to suspend all of the customer’s accounts, you can also enable the Suspend customers option.
To notify external applications about automatic suspension due to insufficient funds for pending subscription charges, use the new provisioning events for an account – Account/Status/Suspended and Account/Status/SuspensionRemoved.
To inform an external app when account records are manually blocked or unblocked by the admins, subscribe the event handler in PortaBilling to the existing Account/Blocked and Account/Unblocked events.
View all routing attempts on the Trace session page
Your engineers can now see each routing attempt for a call directly on the Trace session page. This makes it easier to quickly check for failed call attempts and identify underperforming vendor connections.
Previously, when a call was routed through several vendor connections (e.g., due to no response from the first connection), the system displayed only one aggregated call log. Now, engineers can switch the mode on the Trace session page to see each routing attempt (vendor xDR) as a separate record. To enable this, they simply go to the search settings and select Display xDRs > separately (search in vendor xDRs only).
For each routing attempt, engineers can view the disconnect cause (e.g., Switching equipment congestion) to spot vendor-related issues and adjust routing rules to increase the percentage of successfully connected calls.
To help engineers quickly identify failed calls, a new Status filter has been added.
Plus, additional columns Country/Destination and Customer name (disabled by default) have been added to show more context for each entry.
A customer of Owl Telecom contacts customer service to report that several of their recent calls to South Africa were dropped. An engineer opens the Trace Session page and filters xDRs by destination and time. He sees that the system tried to route the call through a GlobalNet vendor connection, but the attempts failed with the message “Switching equipment congestion.”
To determine if this is part of a larger issue, the engineer searches for other recent calls to South Africa. The page returns several failed calls from different customers, all routed through GlobalNet. Based on this, the engineer updates the routing settings to prioritize other vendors in the routing list and contacts GlobalNet to report the issue.
Engineers can quickly catch routing issues and take action before more customers are affected.
To determine and display the reason why a specific call attempt failed, the system uses the SIP response received from the vendor (e.g., 503 Service Unavailable) and maps this response to an internal code – h323-disconnect-cause – which explains why the call failed (e.g., 41 Temporary failure). This information appears on the Trace Session page to help engineers identify routing issues.
Web interface changes
Redesigned “Subscription plans” page
This release introduces a new “Subscription plans” page to streamline subscription plan management. Here are the changes:
- When creating a new subscription plan, admins can now configure fee settings, promotional periods, and prepaid plans within the same side sheet – simply by switching between tabs. There’s no need to add these details separately afterward. This streamlines the setup process, saving time and reducing the risk of missing important settings.
- Editing subscription plans is now consistent with other pages – admins can simply click Edit
in the list.
- To make searches more precise, admins can now adjust the Name filter by clicking Matching mode
and selecting a condition – contains, starts with, ends with, or exactly matches. This helps narrow down results and makes it easier to find the right entry.
- All settings are now available on the Configuration page, organized into three tabs. Each tab uses the full-screen width, so most options are visible at once – even without scrolling.
These enhancements reduce the time admins spend setting up subscription plans.
Notification sets moved to a dedicated page
In PortaBilling, templates for customer or admin notifications are grouped into notification sets. These sets are now managed on a separate page in the web interface, apart from templates used for invoices and rate uploads/downloads.
More intuitive navigation for admins managing notification-related settings.








