What’s new in MR103

Service providers can significantly increase the security level of administrators’ and resellers’ access to PortaBilling by using two-factor authentication (2FA). With enabled 2FA, users can log in to the system only after entering a valid one-time password (OTP) in addition to their login and regular password. The time-based OTP is generated by a 2FA application, such as Google Authenticator, installed on the user’s smartphone. So, even if an unauthorized person gains access to user credentials, they can’t access the system without the OTP.

For the following entities 2FA can be enabled in PortaBilling web UI or via the PortaBilling API:

• Users (PortaBilling admins)
• Resellers (individually and at the customer class level)
• Customers (individually and at the customer class level)
• Customer individuals
• Distributors

For the following entities 2FA can be enabled only via the PortaBilling API:

• Accounts
• Representatives

• Secure access to PortaBilling system for administrators and resellers.
• Compliance with security policies and ability to pass security audits.

1. Users need to install a 2FA application on their smartphone or PC to generate OTPs.
2. For successful 2FA, the time on a user’s device should be synchronized with an Internet time server.

This is how it works:

Let’s say a service provider Panda Telecom hires Adam, a new engineer. To provide Adam with access to the PortaBilling web interface, the administrator (Root user) creates a new user, enables 2FA for it, and passes the credentials to Adam.

Adam opens the PortaBilling UI page and enters his login and password. Since it’s the first time he logs in, PortaBilling generates the 2FA key and Adam sees the “Activate two-factor authentication” dialog.

Adam installs the Google Authenticator application on his smartphone and scans the QR code to save the 2FA key in Google Authenticator.

Now, Google Authenticator generates a 6-digit OTP that is based on the current time and valid for the next 30 seconds. Adam enters the OTP in the dialog.

PortaBilling also generates an OTP based on the server time and compares it with the entered one. Since the OTPs match, Adam gets access to the PortaBilling UI. He receives a notification about the successful 2FA activation in the email. Also, if anyone tries to log in with Adam’s credentials and an invalid OTP, Adam will receive a notification in the email.

When logging in next time, Adam enters his login and password, and then he just needs to open Google Authenticator on his smartphone and enter an OTP.

Suppose, a week later, Adam loses his smartphone, where the Google Authenticator with the active 2FA is installed. He asks the PortaBilling administrator (Root user) to reset the 2FA key for his user. After the reset, Adam will need to activate 2FA on the new smartphone as described above.

• When the administrator is redirected to self-care portals from the PortaBilling UI, e.g., to troubleshoot an issue reported by the customer, the OTP is not required.
• If a user is logged in while the administrator enables 2FA, the current session will not be dropped, and they will be required to set up 2FA only the next time they log in.

Find the configuration details here.

Service providers operating in Singapore can now assess Goods and Services Tax (GST) for their customers. GST is levied on services consumed domestically, e.g., voice calls and messages between users in Singapore.

To access GST, a service provider enables the GST plug-in on the PortaBilling web interface and sets the current GST rate, e.g., 7%, globally (for all billing environments). It’s possible to prepare for upcoming changes to the GST rate in Singapore by presetting a new rate with an “effective from” date (e.g., 8% starting from January 1, 2023), and the new rate will be automatically applied starting from the desired date.

The GST plug-in automatically applies the set rate to domestic service (calls and messages made within Singapore) or zero rate to international service (e.g., when a user from Singapore makes a call or sends a message to a non-Singapore number).

Applying GST to different types of charges, e.g., manual charges applied by the administrator, is determined by the tax code used with the charge (the tax code value equals the GST rate, e.g., tax code “0” means zero-rated tax).

In case the administrator needs to adjust the amount to be paid in invoice, it’s possible to automatically add GST on top of the adjustment amount to ensure correct calculations.

Service providers that operate in Singapore can comply with local tax regulations.

Find the configuration details here.

When a call center agent has a call with a client, a new call from the queue that arrives on the agent’s phone can disturb or distract the agent from the client they are currently attending to. Normally, managers in larger call centers with a large staff want to keep each agent focused on their current call, so all other calls from the queue are dispatched to other agents who are available at the moment.

However, small businesses with only a few agents on staff may benefit from sending multiple calls to agents even if they are already engaged.

Let’s consider an example.

The ABC company has a small call center. Bob is a manager of this call center (the PBX administrator). John and Jane work as customer support agents. Jane leaves on vacation and Bob configures the call queue so that John can receive new calls from the call queue even while he is busy assisting a client. It will help to keep the queue short enough so that callers do not abandon their calls.

John is on a call with a client. As nobody else is available, the second call from the call queue arrives on his phone – John hears short tones. To retain a new call and give the client attention, John puts the current call on hold and switches to the new call. He asks the client for the phone number to call them back once he becomes available. Afterward, John returns to the initial call to continue the conversation.

With this release, PBX administrators of call centers can adjust the call queue behavior to the specific needs of their business. This functionality doesn’t depend on or affect the settings of direct calls, e.g., a call from a colleague.

PBX administrators can configure the Dispatch calls to busy extensions option on the Call Queue page on the customer self-care interface. Starting from MR103, the Dispatch calls to busy extensions option is disabled by default.

If the agents that are busy on a phone need to handle new calls from the queue before ending the current call, the administrator can enable this option anytime for a specific huntgroup.

• PBX administrators can control the call queue behavior according to the specific needs of their business.
• Service providers can attract new call center customers by offering flexible queues.

Now, it’s possible to protect access to the system from brute-force attacks by unauthorized users, which take the form of multiple, rapid-fire attempts to guess a correct combination of login and password. With access via the SSH (Secure Shell) protocol, the system detects failed login attempts from a specific IP address, and if the number of these attempts exceeds the limit – for example, 3 failed attempts during a 60-second period – that IP address is automatically blocked for a defined period.

To ensure that access from authorized users such as the PortaOne support team will not be blocked, these IP addresses are included in the “whitelist”. A service provider can “whitelist” any specific IP addresses they don’t wish to block (the service provider’s installation IP addresses are not blocked by default).

Service providers can protect the system against brute-force attacks via SSH.

Find the configuration details here.

Before, events such as “Credit limit exceeded”, “Invoice is overdue”, “Account screened”, etc., could only be used to send email/SMS notifications to customers via PortaBilling.

Now, service providers can configure the event handler in PortaBilling to send these events by ESPF to external applications (custom-built web applications or Add-on Mart Workflows) that can trigger further actions, e.g., an application can send notifications to users via WhatsApp.

The list of supported events is extended with the following groups of events (see the full list of events here):

• Notification/BalanceChange, e.g., Credit limit exceeded
• Notification/Billing, e.g., Invoice is overdue
• Notification/CustomerManagement, e.g., Customer is about to be closed
• Notification/FraudPrevention, e.g., Session unauthorized location
• Notification/PasswordRecovery, e.g., Web self-care password change
• Notification/Reports, e.g., New call recording is available

Note that currently, only the EventSender handler can process such events in PortaBilling.

With this release, in addition to the entity id and notification name, the event also includes the notification message that was previously sent via email. The notification message is generated based on the customer class notification template assigned to a customer.

For example, the customer’s invoice becomes overdue. PortaBilling sends the HTTP POST request to the external application via the ESPF. It includes the event type (Notification/Billing/InvoiceIsOverdue), customer ID, and a notification message (a summary of charges for the overdue invoice with the amount due). The application then receives and processes the data (e.g., sends the notification about the overdue invoice to the customer via WhatsApp). The administrator can check a specific event log in PortaBilling.

This enhancement allows tighter integrations with external systems and opens new opportunities for automation.

With this release, service providers that use Odoo CRM can configure it to correctly send notifications to customers depending on the commitment termination reason. PortaBilling sends a notification to Odoo that now includes the account ID and the termination reason, i.e., the commitment was terminated due to overdue invoices or on request, or account closure by admin.

If the commitment is automatically terminated due to non-payment, Odoo sends the customer an SMS message or email about commitment termination with a corresponding notification, “Disconnected due to debt”.

For example, John Doe is provided with Internet service for $25 per month within a 24-month commitment. The customer goes on vacation and forgets to pay the invoice for August. The invoice remains unpaid for the whole month and becomes overdue (the period defined in the customer invoicing configuration).

Eventually, PortaBilling terminates the commitment and sends Odoo a notification with the account ID and termination reason – “Unpaid invoice”. Odoo then sends an SMS message to inform John that the Internet service has been disconnected due to debt.

This enhancement allows CSPs to notify customers of commitment termination with the proper reason.

The administrator can now end the search before it’s completed, on any search panel. For example, if they want to change the search criteria and start a new search right away.

Say, the administrator searches for accounts with a specific account ID but mistypes the ID’s first digits and clicks Apply filters. While the system is searching for accounts, the administrator notices the typo, and stops searching – by pressing “Esc” on the keyboard or clicking Stop on the search panel. The administrator fixes the typo and starts a new search.

The administrator saves time, as they don’t have to wait to start a new search.

With this release, the administrator can apply a specific multi-month prepaid plan, e.g., for 6 months of use, to a group of accounts at a time using the Batch update functionality.

The list of available prepaid plans is configured in the in-advance subscription assigned to the product.

When the administrator changes the product of accounts in a batch, they can now select the charging period for the main and each add-on product that includes the in-advance subscription with the multi-month prepaid plans. Also, the administrator can change the charging period for products already assigned to accounts in a batch.

With this enhancement, the administrators save time by applying the prepaid plans to multiple accounts at a time.