What’s new in MR128

When calls are billed in increments (for example, rounding up to the next whole minute), the charged duration may differ from the actual call duration. This should be considered when customers reconcile their internal call records (e.g., from PBX) with the billed records received from the service provider.

PortaSwitch now lets you control which call duration fields customers see in call detail records (CDRs) – in the self-care web interface, in downloadable CSV files, etc.

You can decide whether customers see:

• Actual call duration (“Duration”)
• Charged duration (“Charged Duration”)
• Connect Time 
• Disconnect Time

You can choose which of these fields are visible to your customers:

• Self-care web interface and on-demand CSV downloads – the fields are controlled by customer access roles.
• CSV files automatically generated at the end of the billing period – the fields do not depend on access roles; they are defined on the Configuration server web interface and enabled in the customer class.

If a field is restricted by the customer’s access role, it is entirely hidden from their CDR view (it doesn’t appear as an empty column).

When admins open specific call details, they always see the full information. CSV files generated for admins always include the default set of fields (e.g., charged duration and connect time).

• Service providers can reduce billing disputes and save employee time.
• Customers can reconcile billed calls faster and with greater accuracy.

Some call scenarios produce multiple audio streams, such as a transferred or pulled call. Previously, a call recording file was produced for each audio stream, so a single call appeared as multiple recordings. Starting from this release, PortaSwitch automatically merges all audio streams of such a complex call into a single recording file. Users can download the single, complete recording file from the self-care web interface or receive it by email. The same applies to transcriptions, where a single, complete transcript is generated for the entire call.

End users review call recordings and transcripts faster.

• Recordings made before MR128 are not merged and remain available as separate files.
• In a multi-node call recording setup, any available node handles the call recording by default. To assign each call to one specific call recording node, set the Strict_Call_Per_Node_Processing option to Yes on the Configuration server web interface. This prevents duplicate processing when multiple call recording nodes are active simultaneously.
• If one or more audio streams cannot be processed, the merged recording file is produced without those streams.

Starting with MR128, you can restrict access to specific PortaSwitch servers or server subnets so that only connections from trusted IP addresses are allowed, and all other connections are blocked. This allows protecting critical services (e.g., SSH or web interfaces) without manually configuring firewall rules via a command-line interface on each server.

Previously, engineers could only block connections from specific IP addresses. These “block” rules applied across all servers and could not be scoped to a specific service (port and protocol). Any other access rules for a service required manual configuration on each server.

Now, engineers can specify “allow” rules for trusted sources and add a single “block” rule that denies all other incoming connections to a specific service (e.g., server administration via SSH) via the Configuration server web interface.

Each “allow” or “block” rule defines a source (where the connection originates from) and a destination (the server and service being accessed). For both the source and destination, engineers can specify an individual IP address (e.g., 198.51.100.5), a subnet – a range of IP addresses (e.g., 203.0.113.0/24), or a wildcard (0.0.0.0/0) to match all addresses. For the destination, engineers can specify a protocol and port to identify a specific service (e.g., tcp:22 for SSH).

Engineers can fully protect critical services from unauthorized access with less configuration effort.

• It’s not possible to set a rule where both the source and the destination are set to a wildcard “0.0.0.0/0” (e.g., “block all traffic from anywhere to anywhere”) – at least one side must identify a specific address or subnet.
• To apply the “allow” and “block” rules, they should be enabled using the corresponding options NetworkProtection.allow_connections_enable and NetworkProtection.block_connections_enable.
• PortaSwitch maintains a protected list of its own server addresses, cluster IPs, Docker internal network ranges, and PortaOne support IPs that cannot be blocked by user-configured rules. This ensures that internal server communication is never accidentally interrupted.
• When updating to MR128, the existing access rules are migrated automatically, preserving the effective behavior of the previous version.

Password expiration improves security for web portals, but it can prevent users from accessing mobile apps that rely on API-based authentication. For example, PortaPhone users sign in with a one-time password (OTP). If the standard account password expires in PortaBilling, login fails because the system requires a password change, which cannot be handled within the app. Supporting password change in such apps requires additional development effort and cost.

To prevent such situations, service providers can now allow API token–based authentication for accounts. Mobile apps such as PortaPhone authenticate users via account login, OTP, and an API token generated automatically for the account. They continue using the app without interruption, since API tokens are not affected by password expiration. However, when users access the web portal, they are forced to change their expired passwords.

Easier and faster app development using PortaBilling API.

• This feature requires updating your apps to use the new parameters added to the following PortaBilling API methods:
  • api_token parameter to Account/add_account and Account/update_account
  • get_auth_info to Account/get_account_info and Account/get_account_list
• Token-based authentication does not support two-factor authentication (2FA), allowing automated services and mobile apps to connect without additional authentication steps.

Companies may use a single Auto-Attendant to handle calls for different departments, product lines, or marketing campaigns – each with its own phone number. When a call is routed to an operator from the Auto-Attendant, they need to know which department, product line, or campaign number was dialed to respond in the right context.

Previously, the name assigned to the called number was displayed only for directly forwarded calls. Now the department or product name is displayed alongside the caller’s number when incoming calls are routed through an Auto-Attendant.

To preserve the forwarder’s name in calls forwarded through Auto-Attendant:

• Select Yes for the AllowForwarderToReplaceCallerName option on the Configuration server web interface.
• Navigate to Account > Voice calls > Service configuration > Call forwarding > and in the Calling party display field, select Caller number and forwarder name.

  

• For call centers: Better customer service with a clear call presentation on incoming calls.
• For service providers: More competitive service for call centers.

When an admin cancels a subscription, it remains active until the next scheduled off-peak processing, when the system automatically closes it. During this period, the subscription is still considered active, which prevents assigning another product that includes the same subscription.

With this release, subscriptions can be closed immediately if they were activated on the same day. This allows admins to quickly correct configuration mistakes, avoid unnecessary charges for that day, and assign the correct product without waiting for the off-peak period.

• Prevent incorrect charges caused by accidental subscription activation.
• Correct provisioning mistakes the same day, without waiting for the scheduled processing time.

This release introduces a redesigned Phones/CPEs page, making it faster for admins to search, review, and manage these entities:

• The device list and CPE profiles are now organized into two tabs on a single page. Admins can edit or delete any record using the Actions column.

  

• 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. Default profiles for upload via the self-care portal are now accessible from the Set default profiles button in the toolbar.

  

• Opening a Phone/CPE record now displays all parameters on a single page, organized into sections. No additional clicks are needed to view device details.

  

• An audit log is now available on the Phones/CPEs page. Admins can view a log of changes to phones, CPEs, and profiles.

  

Admins spend less time navigating between pages and panels while managing devices.