Control what call duration data customers see in their CDRs
When calls are billed in increments, e.g., rounded up to the next full minute, the charged duration can differ from the actual call duration. Customers who reconcile billed calls with their internal logs need both values to reconcile records accurately.
PortaSwitch now lets you choose what call duration fields — actual duration, charged duration, connect time, and disconnect time — appear in customer call detail records (CDRs): in the self-care portal, in on-demand CSV downloads, and in CSV reports generated automatically at the end of the billing period.
Example
Owl Telecom bills in 60-second increments. For ABC Company, which needs to reconcile billed calls with its internal PBX logs, the Owl Telecom admin enables both actual and charged duration fields. For each call, ABC Company’s admin sees both values — for example, actual duration of 3:47 and charged duration of 4:00 — in the self-care portal and in CSV files. All other customers, using the standard setup, see only the charged duration.
What’s improved?
Fewer billing disputes
Customers can verify charges accurately, reducing support requests.
Customer-tailored call records
Show the right level of call detail for each customer.
Find more details here.
Provide one complete recording file for complex calls
Some call scenarios, such as transfers, involve multiple call parts. Previously, each part was saved as a separate recording file, so users had to locate and review multiple files to reconstruct the full conversation.
Starting with MR128, PortaSwitch automatically merges these call parts to produce a single recording file per call. Users access one recording file from the self-care portal or receive it by email. Transcriptions follow the same logic — one transcript is created per call.
Example
John, an account manager, calls the sales team to clarify contract details for a customer. Sarah picks up the call, answers his initial questions, and transfers it to Mike for pricing details. After the call, John opens the recording in the self-care portal and reviews both Sarah’s explanations and Mike’s confirmation in a single file before finalizing the agreement.
What’s improved?
Simpler call recording review for customers
Users spend less time reviewing call recordings by accessing the full conversation in one file.
Find more details here.
Restrict system access to trusted IP addresses only
Starting with MR128, your engineering team can allow access to PortaSwitch servers only from trusted IP addresses, while all other connections are blocked by default. Access rules are configured centrally in a single web interface and apply to selected servers and services (for example, SSH or web access).
Previously, engineers could only block specific IP addresses for all servers. Other access rules required manual firewall configuration on each server via the command line.
Now, engineers can create access rules by defining where a connection comes from and what it can/can’t access (i.e., a specific server or group of servers and a service such as SSH). Trusted IP addresses are allowed via allow rules, while a wildcard block rule denies all other connections.
Example
Owl Telecom needs to restrict server administration via SSH for its server subnet. The engineer:
- allows access from the office network and a remote admin
- blocks all other connections via SSH on that server subnet
What’s improved?
Lower risk of unauthorized access
Sensitive services are accessible only from explicitly defined IP addresses.
Less time spent managing access rules
Engineers manage access rules for all servers and services in one place, with no firewall configuration on individual servers.
Find more details here.
Build mobile apps without implementing password change flows
Password expiration improves web portal security, but it can interrupt access to mobile apps (such as a self-care app or a softphone) that rely on using the API for authentication and data retrieval. For example, mobile app users log in with a one-time password (OTP). If sometime after that their regular account password expires, the app running in the background loses the ability to connect to the API — which may result in inbound calls not delivered to the app and other negative UX. The only way to fix it was for the user to do a password change. Previously, supporting password change in custom apps required additional development effort and cost. Plus, after a user changes the password in one app (e.g., web self-care portal), the session in the softphone has already expired, so they have to re-login, which can be frustrating.
API token–based authentication for accounts solves this. API tokens were previously available for admin, customer, and reseller-level authentication in PortaBilling; MR128 extends this to accounts. An API token is a persistent credential stored on the account in PortaBilling. It can be used instead of a password for authentication via the API and is not affected by password expiration.
When a user logs in, they enter their login and OTP as usual. Behind the scenes, the app automatically includes the API token stored on their account in the authentication request sent to PortaBilling. If the credentials are valid, PortaBilling establishes a session for the app. The session remains valid even after the account password expires, so users experience no interruption. They are still prompted to change their password when accessing the web portal.
What’s improved?
Lower development effort for mobile apps
Developers do not need to implement password change flows inside mobile apps when using the PortaBilling API.
Find more details here.
Show operators which department or product an incoming call is for
Companies may use a single auto-attendant to handle calls for different departments, product lines, or marketing campaigns — each with its own phone number. Calls to each number are forwarded to the auto-attendant. When a forwarded call is routed to an operator, they need to know which department, product, or campaign the call is for — so they can respond in the right context without asking.
Starting with MR128, the name associated with the called number (e.g., department or product name) is displayed alongside the caller’s number when incoming calls are forwarded to an auto-attendant.
Example
ABC Company uses separate phone numbers for two product lines: SmartHome and SmartOffice. Incoming calls to these numbers are forwarded to a shared auto-attendant. The company is running simultaneous marketing campaigns for both products and wants operators to give each caller the right response straight away.
A prospect calls the SmartHome number. The call is received by the SmartHome account and then forwarded to the auto-attendant. After hearing the auto-attendant prompt, the prospect presses 0 to reach an operator. The operator sees the caller’s number and the label “SmartHome” and answers the call with the right product greeting — no clarification needed.
What’s improved?
Better cloud PBX service
Operators always know the context of an incoming call — even when a single auto-attendant handles calls for multiple numbers.
Find more details here.
Close mistakenly assigned subscriptions instantly (same day)
When a subscription is canceled, it normally remains active until the next off-peak processing. During this time, it is still considered active, which can block assigning another product that includes the same subscription.
With MR128, subscriptions activated on the same day can be closed immediately. This allows admins to correct assignment mistakes right away, avoid charges for that day, and proceed with the correct setup without waiting for scheduled processing.
Example
An admin assigns the “Rental equipment” subscription directly to a customer account. Shortly after, they realize it should have been included via the “Home internet” add-on product instead. The admin clicks Close subscription and confirms — the subscription closes immediately with no charge for the day. The admin then assigns the “Home internet” add-on product without conflict.
What’s improved?
No charges for same-day corrections
Prevent incorrect charges caused by accidental subscription activation.
Easier administration
Admins can fix assignment errors right away and continue with the correct product setup without delays.
Find more details here.
Web interface changes
Manage IP phones faster with a redesigned interface
The Phones/CPEs (customer premises equipment) page has been redesigned to reduce the time required to find and manage IP phones and CPE profiles (pre-configured sets of basic settings used for auto-provisioning):
- The lists of IP phones and CPE profiles are now organized into two tabs on a single page. Admins can edit or delete records on both tabs using the Actions column, consistent with other pages in PortaBilling.
- Search parameters have been moved from the left side panel to a single row at the top, allowing for more columns to fit on the screen without horizontal scrolling. Less frequently used search parameters are grouped under the More menu.
- CPE profiles, which customers can use to self-provision their own IP phones, is now accessible directly from the toolbar — no extra navigation required.
- Opening a phone record now displays all parameters on a single page, organized into sections — no additional clicks are needed to view device details.
- The Audit log is now available on the Phones/CPEs page, allowing admins to view the changes made to devices and profiles.
What’s improved?
Faster device management
Admins can manage IP phones with fewer clicks and no page switching.
Find more details here.
