What’s new in MR119

In order to adjust to market conditions, telecom vendors in many countries have started charging different prices for calls to the same destination based on where the call originates. For example, a vendor might charge $0.10 per minute for calls to a mobile number in Turkey originating from Canada, $0.20 from Morocco, and $0.40 from Algeria. Typically, there is a standard base price for a specific destination, with additional surcharges applied for calls originating from specific countries or networks.

With this release, you can set the pricing in PortaBilling tariffs based on the combination of a destination (called) phone number and the originating (caller’s) phone number. Such tariffs offer standard prices per destination, with the possibility to either add a surcharge to the standard price or replace it with a new price if the caller’s number matches a specific rate code (e.g., country code). This feature enables accurate cost calculation for calls routed through vendors that use origin-based rating. Optionally, you can also implement this type of charging for your customers (e.g., large enterprises or call centers with end users in various countries) and resellers to ensure there is no revenue leakage.

Previously, the possibility to consider the call origination in tariffs was limited to calls made from within/outside the European Economic Area (EEA) or US interstate and intrastate calls, with only two prices per destination (e.g., one for calls from within the EEA and another for calls from all other countries).

Service providers can ensure profitability while working with vendors that apply additional charges based on the call’s origin.

If origin-based charges are set up in a reseller/customer tariff and the call origination number is defined, the reseller/customer will be charged according to their tariff, even if the call is terminated by a vendor for which the additional origin-based pricing is not configured.

Such functionality as rate upload, tariff cloning, tariff testing, and xDR re-rating is currently unavailable for tariffs used for charging based on both the destination and origination number. These features will be included in a future release.

See the configuration details here.

Starting with this release, creating custom voice applications for handling calls is easier with the simplified methods of the Call Control API. Developers can now create custom logic for playing prompts, collecting user inputs, redirecting calls based on the provided input, and performing other actions using just two new methods:

• CallControl/play – enables playing prompts and automatically stopping them, which previously required using two separate API methods (play_prompt and stop_play_prompt). This method also allows notifying applications if a prompt is interrupted by the end user before playback is finished, enabling automatic follow-up actions such as collecting inputs, repeating prompts, or transferring calls. In addition to the AU audio format, it supports WAV and MP3.
• CallControl/get_input – enables collecting DTMF inputs and managing input collection logic (e.g., specifying how long to wait for input or how many digits need to be entered before proceeding with the call), as well as notifying applications when input is collected, no input is provided, or the operation times out.

Developers save time on building call flows for custom voice applications.

The new CallControl/play method replaces the previous CallControl/play_prompt and CallControl/stop_play_prompt methods. Similarly, the new CallControl/get_input method takes the place of CallControl/start_dtmf_detect and CallControl/stop_dtmf_detect methods.

Call center owners typically configure incoming calls to be placed in a call queue while waiting for agents to become available. However, when agents transferred or forwarded calls to other departments (hunt groups), those calls could not previously be placed in call queues. To address this, call center owners set up auto-attendants, which routed such calls to call queues after receiving input from the caller.

With this release, agents and supervisors can directly transfer and forward calls from external callers to call queues using IP phones or external applications. Calls from outside the PBX are always placed in the call queue until an agent becomes available. For example, if a client calls the support department and has to wait for a long time, a supervisor can transfer the caller to the Second line support where the client would be served immediately, thereby reducing the wait time.

However, if the initial call originates from another agent (extension), such calls bypass the queue. For example, an employee of the company will not be placed in a queue when contacting their colleagues.

This eliminates the current dependency on auto-attendants for transferring/forwarding calls into queues, simplifying call management.

• Cloud PBX customers profit from a lower call abandonment rate.
• Call centers can improve customer service.
• Service providers can offer flexible cloud PBX/call center solutions and stay ahead of the market competition.

If the call queue exit option is set to go back to the initial menu (Return to Auto Attendant menu), but no auto attendant is configured, the call will be simply disconnected when the caller selects to exit the queue.

With this release, PortaBilling admins get a clearer view of how the payments are allocated – whether they were applied to one or multiple invoices, or placed under unallocated payments.

Previously, determining how payment was distributed across invoices required reviewing the customer’s/reseller’s audit log or generating a Customer statement report. Admin had to locate the payment record and trace subsequent automatic distribution actions. For example, part of the payment might cover an outstanding invoice, while the rest remains in unallocated payments. Now, admin can simply check the tooltip next to the invoice’s paid amount to see the allocated amounts and dates of payments. Similarly, the unallocated payments setting has a tooltip that displays a list of payments. Additionally, on the payment records in xDRs, admins can also view which invoice was covered by a specific payment. Please note that the history of the payment distribution is periodically cleaned up along with the payment xDRs; therefore, this is not accessible for records older than the KeepPaymentXDRs value set on the Configuration server.

PortaBilling admins can troubleshoot payments quicker.

It won’t be possible to track the application of payments that:

• were made before the system was updated to MR119
• have records that were cleaned up

With this release, admins and customers can track subscriptions with fully discounted charges. When a subscription with a 100% discount is applied to a customer, a zero-charge xDR is generated for the customer. Service providers can analyze how many customers are receiving services for free. Admins and customers can track these zero-charge xDRs in the PortaBilling web interface and invoices.

If you install MR119 or a later version from scratch, xDRs for subscriptions that do not incur charges (a 100% discount is provided) are created by default.

If you update the system to MR119, and want the system to create xDRs for subscriptions with a 100% discount, set the Subscriptions.Generate_Zero_CDRs option to “Yes” on the Configuration server web interface.

Service providers can track promotional offers’ uptake while ensuring customers clearly see the value they receive.

PortaBilling is now integrated with Huawei MOne acting as a Short Message Service Center (SMSC) in mobile networks. This integration enables mobile operators to deliver SMS messages to their subscribers and charge for them in real time.

PortaBilling communicates with Huawei MOne via the Diameter (Ro) interface, enabling real-time authorization and charging (AAA) for outgoing SMS messages. For example, when a subscriber attempts to send an SMS, PortaBilling authenticates the subscriber, authorizes sending the SMS, charges the user’s account, and Huawei MOne SMSC routes the SMS for delivery to the recipient.

MVNOs/MVNEs can charge for SMS services using Huawei MOne.

See the configuration details here.