Offer compliant 911 calling with Bandwidth
When a 911 call is placed, emergency services need to know the address to which help should be dispatched, even if the call is interrupted or the caller cannot speak. PortaSwitch now supports this through the new E911 (Bandwidth) module available in the Add-on Mart, helping service providers comply with US emergency calling regulations. The module connects PortaSwitch with Bandwidth, an E911 service provider with 100% emergency dispatch center coverage across the US and Canada, to route 911 calls with verified caller location to the correct dispatch center.
When a customer or admin specifies or updates an address for a location, such as an office or a specific phone line, PortaSwitch automatically validates and registers it as an emergency address with Bandwidth. When a user places a 911 call from an IP phone or application, PortaSwitch routes the call to Bandwidth with a special Geolocation SIP header that references the caller’s location stored in Bandwidth. Bandwidth uses this information to deliver the call to the appropriate Public Safety Answering Point (PSAP) and allow emergency services to dispatch help to the correct location.
Addresses can be defined at the account, customer site, or customer level. For accounts without an individual address, PortaSwitch automatically falls back to the customer site or customer address – so a single address entered for an office location can cover all phone lines there that do not have their own address. To set up the emergency calling, the admin simply selects Bandwidth as the E911 provider in a product.
- Service providers can offer compliant emergency calling for US customers.
- Specifying a single address for the entire customer, to be applied to all phones within the same office, saves time.
- PortaSwitch MR129 or later.
- An active Bandwidth account with E911 Dynamic Location Routing enabled.
- An active subscription to the E911 Bandwidth module in the Add-on Mart.
Extension self-care portal
Your PBX customers’ employees can now manage their own extension settings directly in the CloudPBX Self-Care Portal without waiting for the PBX admin to apply changes on their behalf. Each employee gets their own web credentials and access to a personal set of self-care features.
A PBX admin enables portal access per extension. Once enabled, the extension holder signs in to the CloudPBX Self-Care Portal using the same URL as the PBX admin.
Extension holders now have access to the following features:
- Update personal settings such as display name, password, preferred language, timezone, and date format.
- View recent call activity, active plan, and bundle amounts on the dashboard.
- Configure call forwarding rules for their extension, for example, forward calls when busy or unanswered.
- View hunt group membership and set hunt group availability status.
- Play or download call recordings and call transcriptions.
- View, play, download, or delete voicemail messages and voicemail transcriptions.
The ABC Company admin enables portal access in the CloudPBX Self-Care Portal for all employees, including Mary, so they can manage their extensions independently.
After a monthly meeting, Mary logs in to the CloudPBX Self-Care Portal using her credentials to review the call recording. Mary opens the call history, locates the recording, and listens to it. At the end of the day, Mary sets call forwarding so that all incoming calls to her extension are forwarded to Steve while she is on vacation.
- Extension holders get full control over the configuration of their extensions.
- PBX admins spend less time on routine extension changes.
End-user access to the portal requires:
- PortaSwitch MR125 or later
- CloudPBX Self-Care Portal version 8.1.1 or later
- The PBX admin must enable portal access per extension by setting up extension web credentials.
Callback option to avoid waiting in the queue
Call center owners aim to minimize abandoned calls caused by long queue wait times. With this release, callers waiting in the queue can request a callback instead of continuing to wait for an agent. This option allows callers to hang up and receive a call when an agent becomes available. Callback requests are processed in the same order as callers were placed in the queue. Callers can use the callback option when the queue is full (when the maximum number of callers has been reached), when the waiting time exceeds the configured limit, or when a call has been dispatched to an agent who doesn’t answer within the ringing timeout. After the caller specifies the callback number, the call is disconnected, and the callback request is then placed in the queue. When an agent becomes available, and the callback request becomes first in the queue, the system calls the caller back and connects them to the agent.
- Callback is offered after 60 seconds in the queue
- Maximum number of callback attempts: 3
- Delay between callback attempts: 2 minutes
- For service providers: More competitive offers for call centers.
- For call centers: Reduced number of abandoned calls and improved customer experience.
- This feature is available in the CloudPBX Self-Care Portal (accessible via the Add-on Mart), or you can implement it in your own portal using the PortaBilling API. Update your existing custom portals to support the new parameters in the relevant API methods for call queues (for example, /Customer/update_callqueue).
- Callback requests expire after 24 hours. The possibility to change the expiration period will be added in a future release.
- The maximum number of callback attempts is configurable (0–10, default 3). If all retry attempts fail or the request expires, the callback request is removed from the queue and recorded in the audit log.
- The delay between callback attempts is configurable (60–600 seconds, default 120). If the caller answers the callback but disconnects before an agent connects, the request is canceled with no further attempts.
Multiple bundle usage notifications
Service providers can now configure multiple notification thresholds per bundle item (an individual allowance within a bundle, such as data or minutes). For example, they can notify customers when 50%, 80%, and 100% of their data allowance is consumed. Previously, a maximum of two usage notifications could be sent: one at a configurable threshold and another when the allowance was fully consumed (100%).
This feature helps service providers comply with regulatory requirements in regions where notifications at multiple usage thresholds are mandatory, such as in South Africa. Customers receive more reminders before bundle allowances are exhausted – for example, before pay-as-you-go charges apply or services are limited.
Thresholds are configured separately for each bundle item as a comma-separated list of percentages or absolute units. Notifications can be triggered when a specified amount of the allowance is used or remains.
Owl Telecom offers a 30-day prepaid bundle with 1000 minutes of calls to European destinations. When the allowance is exhausted, calls are charged at the standard pay-as-you-go rate, which is significantly higher than the bundle rate. Notification thresholds are configured at 500, 200, and 0 minutes remaining.
Subscriber John Doe receives:
- an SMS when 500 minutes remain,
- another SMS when 200 minutes remain,
- and a final SMS when the 1000-minute allowance is exhausted.
John purchases additional 500 minutes for calls to Europe to avoid being charged at the higher rate.
- Service providers can comply with local notification requirements.
- Customers can manage their spending more predictably.
Find the specifics here.
Bulk tariff update with a new rate
When a new phone prefix is introduced, service providers receive an updated price list from their vendor that includes the new rate. After vendor tariffs are updated in PortaBilling, service providers must quickly add the new rate code with appropriate prices to their customer and reseller tariffs to ensure accurate call rating. Updating each tariff individually is inconvenient and time-consuming, especially when many customers have individual prices configured via override tariffs.
With this release, admins can add a rate for a new rate code to multiple tariffs in a single operation, saving time and minimizing pricing errors.
The Bulk tariff change tool guides admins through the process of adding a new rate to multiple customer and reseller tariffs. It works with two key concepts:
- Target rate code – the new rate code for which a rate will be added to the selected tariffs.
- Source rate code – an existing rate code that already has a rate defined in the tariff. The pricing parameters of this rate, such as interval and price, are copied to the new rate. If a tariff does not include a rate for the source rate code, that tariff is skipped.
Admins can review and adjust the list of tariffs to be updated and see a summary of the changes. For more details, refer to How to add a new rate to multiple tariffs.
Owl Telecom provides calling services to Philippine phone numbers for its US customers. A Philippine mobile operator, which already owns the 63920 prefix, is assigned a new prefix, 63925. The vendor sends Owl Telecom an updated termination price list that includes the new prefix, and Owl Telecom updates the vendor tariff in PortaBilling accordingly.
Owl Telecom has 35 customer tariffs with Philippine destinations and 150 override tariffs for customers with negotiated rates for Philippine destinations. The Owl Telecom admin must update all of these tariffs by adding a rate for the new 63925 rate code with the same pricing parameters as the existing 63920 rate.
The admin opens the Bulk tariff change tool, enters 63925 as the target rate code and 63920 as the source rate code, and confirms the list of affected tariffs. PortaBilling creates a new rate for each tariff, copying all pricing parameters (such as price per minute and interval) from the source rate of that tariff. Override tariffs that do not include the 63920 rate, do not get a new rate for 63925.
Calls to Philippine phone numbers starting with 63925 are immediately charged using the new rates.
For service providers: Faster reaction to vendor prefix updates.
For admins:
- Less time spent keeping multiple tariffs up to date.
- Fewer pricing errors when adding rates for new rate codes across tariffs.
Multiple add-ons in time-limited upgrades for commitments
When designing promotional upgrades for existing customers, service providers often need to combine several services into a single upgrade offer (e.g., a higher internet speed together with an extended TV package). Previously, a time-limited upgrade (a free trial of a more expensive package for an existing customer) could include only one add-on product, limiting such offers.
With this update, admins can assign multiple add-on products within a single time-limited upgrade for commitments.
Service providers upsell higher-tier packages by making trial offers more attractive to existing customers.
All add-on products in a time-limited upgrade share one expiry date and are tied to a single target commitment, which replaces the existing one if the customer agrees to upgrade permanently.
Audit log for event handler changes
With this release, PortaBilling records all changes to event handlers in the audit log. Event handlers are modules inside PortaBilling that automatically provision data to external systems – such as CRM platforms or mobile network components – when specific changes occur in PortaBilling. Admins now see who made a change to an event handler, when, and exactly what was modified.
The audit log is available on the Event handlers page and via the WebLog/get_web_log_list API method.
Tighter control over external integrations via ESPF.
Web interface changes
Manage web password expiration settings for specific customers
Previously, web password expiration was configured system-wide and applied to all entities, such as admins, customers, and resellers, without exception.
Now, admins can manage password expiration at the customer class level. This makes it possible to apply different expiration policies to specific groups of customers without affecting the entire system. If no value is configured for a customer class, the global setting is used.
Manage authentication for accounts via tokens from the web interface
Mobile apps tend to use one-time passwords (OTP) for user login, typically combined with token-based authentication for secure access, instead of standard passwords. This provides a better user experience, since users do not need to remember or update passwords. Now, mobile apps that work under account credentials can use token–based authentication, which is configured separately for each account.
Admins can manage API token–based authentication for accounts directly from the web interface.






