What’s new in MR104

Now, there’s a simple way to set up SMS notifications for your customers when you need to remind them about billing or other important events. SMS notifications have high deliverability, so they allow you to notify customers promptly and reliably. They also tend to elicit a faster customer response than email, making them a good option for enforcing the payment collection process. For example, when an invoice due date is approaching, the customer automatically receives an SMS notification reminding them to make payment.

The possibility to send SMS notifications is available via the Add-on Mart and is now based on Twilio. Integrations with other SMS providers are intended in the future.

The integration will work with any PortaBilling version with no need for a full system update. Simply sign up for an account with the SMS provider and subscribe to the corresponding Add-on Mart module, and the integration will be set up by our PortaOne engineers. Then you can automatically notify your customers via SMS about events you define on the customer class level, e.g., the credit limit is exceeded, the invoice becomes overdue, etc.

Sending SMS via Add-On Mart utilizes modern REST APIs, offered by CPaaS providers like Twilio. Such a connection can be set up very quickly, it is easy to troubleshoot, and there is little room for errors. This makes it a much simpler alternative to sending SMS notifications using SMPP protocol – such connections are difficult to set up and tedious to troubleshoot.

Add-On Mart architecture makes it very easy to add a module that uses another SMS provider that offers API (such as HTTP REST) for sending SMS. So, if you want to add an SMS provider of your choice to appear as an option in the near future, contact our sales team.

• Better customer service using SMS notifications.
• Reduced time for setting up SMS notifications to customers.

Once an event configured on the customer class level for SMS notifications happens, PortaBilling sends the customer’s phone number along with the notification message body (specified in a template at the customer class level) to the Add-on Mart cloud infrastructure (AMCI). AMCI triggers an API request to the SMS provider via HTTPS and passes along the SMS details (message body and phone number). And then the SMS provider sends the corresponding SMS notification to your customer.

Find the PortaBilling configuration details and specifics here.

Compliance Solutions, Inc. (CSI) is a tax management company that offers tax assessment and reporting in the US at the federal, state, county, and local levels and can be used as an alternative to taxation companies such as SureTax and Avalara.

Starting from MR104, telecom providers can use CSI’s services in PortaBilling. The CSI integration is available via Add-on Mart. First, you need to sign up for an account with CSI, obtain the credentials, and consult with CSI about tax codes for your products. Then, you subscribe to the CSI module in the Add-on Mart, and the CSI taxation plug-in is activated by PortaOne engineers. Once it’s activated, you can select the CSI taxation plug-in on the PortaBilling web interface and configure the assessment of:

• Transaction taxes
• Per-line taxes
• Surcharges

If a customer has users (accounts) in different locations, you can enable tax assessment based on each user’s location.

CSI as a taxation plug-in can be used for configuring taxation on the customer class level as well as for individual customers.

• Service providers can use the CSI tax management company as an alternative with good customer service for tax assessment and reporting.

Tax assessment via CSI is done using the REST API. Since this integration is available via Add-on Mart, PortaBilling doesn’t send the requests directly to CSI. PortaBilling sends the request to the cloud (Add-on Mart), and Add-on Mart “talks” to CSI via API.

CSI receives xDRs, along with customer/account location information and tax codes, from PortaBilling. CSI assesses taxes and surcharges for the end users and returns this data to PortaBilling. Based on received data, PortaBilling generates tax xDRs and issues invoices for customers. The tax data is stored in the CSI’s database, so it can later be used when filing the tax report for the service provider. If a service provider wants to test tax processing via CSI, they can enable test mode for specific customers. With this mode, CSI assesses taxes for these customers, but the taxes are not stored on the CSI’s side and are not included in tax reporting.

Along with the taxes, CSI assesses surcharges. These are fees that the US telecom providers must pay to local government-administered funds. An example of such a surcharge is the Universal Service Fund (USF) fee used to support low-income households and high-cost areas by improving telecom infrastructure for them. The Federal Communications Commission (FCC) allows telecom providers to collect surcharges from their customers. The surcharges are shown in customers’ invoices in the tax section.

Some taxes/surcharges are applied as a percentage of revenue from interstate service usage. By default, the interstate traffic share is defined by SafeHarbor ratio, % for all service providers. If the real share of the interstate traffic, called Percent Interstate Usage (PIU) ratio, is different for a service provider, they can set the PIU ratio instead of the SafeHarbor ratio to assess taxes.

Service providers can set their PIU ratio to reduce taxes and surcharges (and the customer invoice total).

Let’s look at the assessment of a specific surcharge, e.g., Universal Service Fund (USF) fee, in detail.

For example, a Panda Telecom’s customer consumes $100 worth of voice calls. The USF fee is assessed as follows:

The SafeHarbor ratio of 65% means that 65% of voice traffic is considered interstate. The USF fee is 20%. Thus, the service provider must pay $13 (100 * 0.65 * 0.2) as a contribution to the USF. At the end of the billing period, the customer receives an invoice with a USF fee of $13.

To optimize taxes and, as a result, reduce the customer’s invoice total, Panda Telecom can study their interstate traffic to obtain the actual share of interstate traffic – PIU ratio. If it’s lower than 65% (SafeHarbor ratio), e.g., 40%, Panda Telecom can submit it with all the supporting evidence to authorities. After the new value is specified in the CSI plug-in configuration on the customer class level, the USF fee will be applied to 40% of the voice calls revenue instead of 65%, so that the customer will receive the invoice with a USF fee of $8 (100 * 0.4 * 0.2) instead of $13.

Find the PortaBilling configuration details and specifics here.

When a user calls a company, and all agents are busy, this call is placed in the call queue, which means that a user has to wait until an agent becomes available. If a user waits in the call queue for too long, they may eventually hang up. It’s crucial for most businesses not to miss any customer calls.

With this release, cloud PBX customers can provide better service to the callers by offering one of the following alternatives to waiting in a call queue:

• leave a voicemail,
• transfer the call to a specific extension,
• transfer the call to another department (queue),
• go back to the initial (auto attendant) menu.

Callers can hear a message with the alternative action when:

• they call the company, but the call queue is full (the limit of maximum calls in the queue is reached).
• waiting time in the call queue reaches the waiting limit.
• a call that is first in the queue has been dispatched to agents but no agent is picking up (the ringing limit is reached).

PBX administrator can configure the actions for these cases on the Call Queue page on the customer self-care interface. The options are disabled by default.

• Cloud PBX customers profit from a lower call abandonment rate and provide better customer service.
• Callers are confident that their requests will be addressed. They enjoy an improved customer experience.
• Service providers can offer flexible call queue configuration and stay ahead of the market competition.

Bob is a manager (PBX administrator) in the medical clinic. John works as a receptionist there and is the only one to handle all the incoming calls. Bob configures the call queue in such a way that patients can leave a voicemail after waiting in the queue for 5 minutes.

Jack, the patient of this clinic, calls reception to make an appointment. John is on a call with another patient. The announcement informs Jack that he is the third in the queue and the expected waiting time is 10 minutes. Jack waits for 5 minutes and then he is given the option to leave a voicemail instead of waiting for an agent to become available. Jack dials the code to exit the call queue and leaves a voicemail with the details of his request and his contact information. After that, he hangs up and waits for a callback from John.

Previously, only a generic call disconnection cause was sent to the calling/called party, and the real disconnection cause returned by your interconnect partner, e.g., an external gateway, was lost. Thus, your customers couldn’t always know what specific disconnection cause was behind a generic SIP error which left room for ambiguity in the interpretation. For example, the SIP error “404 Not found” could be interpreted that a call failed due to an incorrectly dialed phone number while actually, the call failed due to an error on the vendor’s side.

With this feature, your customers will receive the real disconnection codes transmitted in the “Reason” header in SIP messages. These codes allow the customers to accurately identify the cause for each call disconnection.

Say your SIP trunking customer makes a call from their PBX, and a vendor’s gateway ends the connection, indicating the disconnection reason with a specific code, e.g., “1” – an ISDN (Integrated Services Digital Network) code from SS7 network. When PortaSIP sends a SIP message such as “404 Not found” to PBX, it passes on this code in the SIP “Reason” header. And this code (“1”) represents the specific cause of this disconnection – in this case “unallocated (unassigned) number”.

The received disconnection codes empower the customers such as call centers to build accurate reports based on the call disconnection reasons, allowing them, for example, to monitor how many calls are not picked up or are hung up and how many are disconnected due to error.

Customers are able to build accurate reports on call disconnection causes.

Find the configuration details and specifics here.

You can now have comprehensive information on call disconnect causes, returned by your interconnect partners, in your system.

The real call disconnection causes that PortaSIP receives in the “Reason” header of a SIP message, are not only passed on to the calling/called party as described in the Provide improved clarity on call disconnection causes chapter, but also stored in PortaBilling xDRs.

Thus, you have access to accurate disconnection causes and can partner with your customers or vendors to analyze the call disconnection causes. For example, when your new customer wants to test the service and reconcile the call data in PortaBilling with the data on their side.

Your engineering team can manage reconciliations with customers or vendors more quickly and with less investigation.

Find the configuration details and specifics here.

Starting with MR104, resellers’ profiles are automatically switched to the new self-care web interface, which now covers all the functionality of the old interface.

The old web interface for resellers is set to be completely removed in 2024.

With this release, the developers can test PortaBilling API methods on the built-in API documentation page without entering an access token.

To test an API method from a specific realm, e.g., Admin or Reseller, a developer first needs to log in to the corresponding PortaBilling web interface and then switch to the documentation page. The authentication is done automatically and doesn’t require an access token.

The developers can also test API methods right away on the documentation page even if they are not logged in to the PortaBilling web interface. In this case, they need to run the “Session/login” request from the specific realm and enter the corresponding credentials there.

Note that to test custom API servers, the developers still need to acquire and enter the access token to run tests.

Simplified access to API testing for developers.

The Batch account update panel has been updated so that the administrator can manage account batches in a more user-friendly way. Here are the changes:

• Since the batch operations are available only when accounts are filtered by batch, the Batch account update panel opens automatically only after the administrator selects a specific batch and applies this filter on the Account search panel.
• The name of the filtered batch is displayed at the top of the Batch account update panel so that the administrator can clearly see which batch they are updating.
• The administrator can see the total number of Selected, Started, and Depleted accounts:
  • Selected – this shows the number of the filtered accounts in the selected batch.
  • Started – this shows how many accounts have been used at least once (by making a successful call/session or having been used in successful IP phone registration).
  • Depleted – this is the number of accounts that have been used up (have zero funds or the amount of funds is less than the main product breakage).

    

This enhancement simplifies batch management on the web interface.