Release

Search

What’s new in MR117

Link copied to clipboard

Faster troubleshooting of API requests

Link copied to clipboard

Unique ID of the API requests for simplified troubleshooting Starting from MR117, your engineers can more easily locate failed requests made to or from your applications. Each request using the PortaBilling API and each response now includes a unique identifier called a “trace ID,” provided in the “X-trace-id” header of the request. The trace ID enables you to quickly find the specific request in the log file and identify the cause of the failure. You can configure your application to use a custom trace ID format, such as myApp-Node56-a7d8f9c3b2d4, or let PortaBilling automatically generate it in UUID format.

Trace ID format

Example
Developers create a new self-care portal that displays a list of calls made by the customer. On a separate page, the app shows the call history of a specific customer in their local time zone. The app first uses the [REST API] method “Customer.get_customer_xdrs” to get a list of calls. However, when the app tries to use the [REST API] method “Generic.get_time_zone_list” to display a human-readable name of the time zone, the request fails. To troubleshoot it, developers use the trace ID from the “X-trace-id” header of the failed request to quickly find the specific log on the server. The log reveals that the request failed due to a temporarily lost connection with the database – “Time zone list cannot be loaded because the database is not working”. The developer realizes that the error isn’t caused by a mistake in their code and attempts to open the call history page again. The app re-sends the request, this time it does receive the list of calls and time zones, and correctly displays the call history.
Benefit

Developers save time on troubleshooting API requests.

Advanced bulk account management through the API

Link copied to clipboard

This release introduces changes to the update_accounts_batch API method. Previously, multiple accounts could only be updated together if they were part of the same batch. Now, bulk updates can be applied to accounts that share the same product, contact information, or other common attributes. For example, you can apply call screening rules to all accounts belonging to the same customer or those that have the same email domain in their contact information.

Example

A service provider, Owl Telecom, offers their customers’ protection from spam calls as a premium service. To deliver this service, Owl Telecom develops a custom script that creates call screening rules for subscribed accounts based on a list of spam numbers. A relevant list of spam numbers is periodically retrieved from an authority.

When a customer like ABC Company subscribes to the service and requests that all accounts with email addresses ending in @abccompany.com be protected from spam calls, the script generates call screening rules for all users with such emails.

Benefit

Service providers can now develop scripts for account management, faster and easier.

Internet bandwidth control using the netElastic virtual Broadband Network Gateway

Link copied to clipboard

Mobile Virtual Network Operators (MVNOs) typically depend on their host Mobile Network Operators (MNOs) to set an internet speed limit for users. This reliance can restrict their ability to launch new products with specific bandwidth needs. For example, if an MVNO wants to offer an unlimited data package, they must implement a fair usage policy to reduce speeds for users who exceed a specific limit, like 30 GB, to avoid network overuse.

With this release, MVNOs can use a netElastic virtual Broadband Network Gateway (vBNG), a software-based gateway that manages internet services, to gain more flexibility and control over bandwidth settings, without the need to contact the MNO. In this scenario, internet traffic of MVNO subscribers flows from the MNO’s network through vBNG, where Quality of Service (QoS) profiles with different bandwidth limits are configured. PortaBilling authenticates and authorizes user sessions on the MNO’s network and informs the vBNG which QoS profile (such as “Uncapped_LTE_regular” or “Uncapped_LTE_limited”) should be applied to this user session, depending on whether the user has exceeded the defined quota (e.g., 30 GB).

Example

To provide data service, the MVNO “Owl Mobile” relies on the LTE network infrastructure of the host MNO, which provides a standard bandwidth of 100 Mbps. The MVNO is planning to introduce a new data plan: “Unlimited wireless data for $39.99 per month.” The MVNO’s Fair Usage Policy states that the speed should be reduced to 1 Mbps once usage reaches 30 GB.To achieve this, the MVNO implements a vBNG, integrating it with their PortaBilling system. On the vBNG, the MVNO creates the following QoS profiles:

  • “Uncapped_LTE_regular” (sets bandwidth to 100 Mbps)
  • “Uncapped_LTE_limited” (sets bandwidth to 1 Mbps)

Once customer John Doe signs up for the “Unlimited wireless data for $39.99 per month” plan on September 1st and initiates an internet connection, PortaBilling verifies that his available quota is 30 GB and instructs the vBNG to apply the QoS profile “Uncapped_LTE_regular,” allowing John to enjoy high-speed internet. After two weeks of usage, John reaches the 30 GB threshold. While his current session remains active, PortaBilling instructs the vBNG to switch to the QoS profile “Uncapped_LTE_limited.” John continues browsing, but his internet speed is now throttled to 1 Mbps.

Benefit

MVNOs can create competitive internet packages without being limited by MNO.

Web interface changes

Link copied to clipboard

User-friendly configuration of pass-through headers

Link copied to clipboard

PortaSIP generally removes unknown headers from incoming SIP requests for security reasons. However, some headers, particularly those containing the caller’s identity, may need to pass through. For example, vendors may require such headers to ensure that the caller’s identity remains consistent and verifiable, even as the call goes through multiple networks.

Configuring which specific SIP headers should pass through PortaSIP within a service policy is now more user-friendly:

  • Admins can now select among the most commonly used headers, such as ‘’P-Asserted-Identity’’ or ‘’h323-conf-id’’, in the dropdown list. This helps avoid typos and misconfigurations that occur when entering header names manually.

    Passthrough headers

  • A warning icon has been added to indicate conflicting configurations when the Restrict PortaBilling controlled headers attribute is enabled. In this case, SIP headers received from the calling party are not passed through PortaSIP, even if they are listed in the Passthrough headers.

    For example, if an admin tries to add ‘’P-Asserted-Identity’’ as a passthrough header without disabling the restriction, the warning icon will prompt them to deactivate the restriction first.

    Warning for Restriction

Benefit

This enhancement helps avoid misconfigurations and, therefore, saves the admin’s time.

On this page

Release
What's new
Admin manuals
Handbooks
API
UI help
Back to main menu
Search