Faster troubleshooting of API requests
Developers can now save time on troubleshooting failed API requests when building apps that “talk” with PortaSwitch via its API, such as a customer self-care portal. With MR117, external apps can pass a unique identifier (trace ID) in the “X-trace-id” header with each API request, which is then returned with each response. This allows developers to quickly locate failed requests in the logs and correlate them with the debugging information from their side to quickly understand what went wrong.
Example
Say Mark, a developer, is building a new customer portal that will display the call history according to each customer’s local time zone. During testing, he notices that there was an error when retrieving customer’s current product from PortaBilling. Mark analyzes the debugging info on the self-care portal’s side and sees that there was an API request with the trace ID “123” which failed with “500 application server error.” To investigate, Mark searches the PortaBilling logs using the trace ID “123.” The logs reveal that the failure was caused by a temporary loss of connection with the database during scheduled maintenance, not an error in Mark’s code.
What’s improved?
Easier development
Developers can save time in identifying issues in their apps.
Find more details here.
Advanced bulk account management through the API
With MR117, you can now use the API to update multiple accounts under a specific customer at once – whether all accounts or those filtered based on criteria like associated products or email domains – even if they belong to different batches. This is particularly helpful when automating account management tasks using scripts.
Example
“Owl Telecom” provides premium spam call protection using a custom script that applies call screening rules to subscribed accounts. “ABC Company” subscribes to the Owl Telecom service, and requests that all of their accounts with email addresses ending in @abccompany.com be protected from spam calls. Owl Telecom uses the domain as a filter parameter, and their script creates call screening rules for all users with an @abccompany.com email address.
What’s improved?
Streamlined account administration
Simpler development of scripts for automated account management.
Find more details here.
Internet bandwidth control using the netElastic virtual Broadband Network Gateway
Mobile virtual network operators (MVNOs) typically depend on their host mobile network operator (MNO) to set internet speed limits for their mobile subscribers, which often restricts the MVNOs’ ability to launch new products. For example, if an MVNO wants to offer an unlimited data package, they need to be able to reduce speeds for users who exceed a specific limit, such as 30 GB, to prevent network overuse.
With this release, you can use a netElastic virtual Broadband Network Gateway (vBNG) to gain greater control over such bandwidth settings without contacting your host MNO. The internet traffic flows from the MNO’s network through vBNG, where different bandwidth profiles (e.g., one for high speed and one for limited speed) are configured. PortaBilling authenticates and authorizes user sessions on the MNO’s network and then instructs vBNG on which profile (i.e., high or limited speed) to apply the user session.
Example
Owl Mobile, an MVNO, offers an “Unlimited wireless data for $39.99 per month” plan with a Fair Usage Policy that reduces speed from 1 Mbps to 128 kbps after 30 GB of usage. The MVNO sets up two bandwidth profiles: “Uncapped_LTE_regular” (1 Mbps) and “Uncapped_LTE_limited” (128 kbps). When John Doe, a customer, signs up and starts using data, PortaBilling assigns the high-speed profile. Once John reaches the 30 GB threshold, the system switches him to the lower-speed profile, reducing his internet speed to 128 kbps while keeping his session active.
What’s improved?
Increased flexibility for MVNOs
Configure bandwidth throttling independently of your host MNO, and respond swiftly to market needs.
Find more details here.
User-friendly configuration of pass-through headers
PortaSIP generally removes unknown headers from incoming SIP requests for security reasons. However, there may be specific headers that need to pass through. For example, vendors may require the “Diversion” header, which stores information about call forwarding, for custom services like personalized call handling.
Now, configuring which SIP headers should pass through PortaSIP has become easier:
- Admins can select from a dropdown list of commonly used headers, such as “Diversion.” This reduces the risk of manual data entry errors.
- A warning icon will alert admins to conflicting settings. For instance, if an admin attempts to add “Diversion” as a pass-through header without turning off the conflicting “Restrict PortaBilling Controlled Headers” option, the warning icon will prompt them to disable that option first.
What’s improved?
Easier administration
Avoid misconfigurations and save time when configuring pass-through headers.
Find more details here.
