What’s new in MR112

You can now enable your PBX customers to use semi-attended transfer via applications, such as a receptionist console, developed in-house or by a third-party. This feature can be implemented via the call control API. Users who transfer calls to a colleague via an application, can now complete the call transfer upon hearing the ringing tone from the party to which the call is transferred, before that party actually answers.

The application can use the CallControl/join_calls and CallControl/originate_advanced_call methods to enable semi-attended transfer.

Say Alice, a receptionist, manages calls via a receptionist console app. She needs to transfer one of the ongoing calls to a manager. Alice clicks “Transfer,” selects the manager’s name, and waits for the ring tone from the manager’s extension to confirm availability (if that person’s phone is unavailable, Alice will hear a “busy” tone or a voicemail prompt). Upon hearing the ring tone from the manager’s extension, Alice can complete the transfer by clicking the corresponding button within the app. Alternatively, if the manager’s extension is unavailable, due to their phone being offline or set to “Do Not Disturb” mode, Alice can make an informed decision on how to proceed with the call, e.g., continue the call herself and inquire whether the caller would like to leave a voicemail message. This ensures that every client’s needs are addressed.

Service providers can develop applications allowing PBX users to provide better customer service.

The new version of the PortaBilling API has been extended with methods that allow for creating/deleting customers, as well as retrieving/updating customer information such as phone numbers or addresses.

Additionally, the PortaBilling API 2.0 now allows for retrieving/updating specific service features (e.g., call barring) for individual customers and obtaining a list of all service features associated with a customer.

The new version of the PortaBilling API simplifies the API structure by grouping related attributes such as the parts of the address information into a single section and providing better naming for attributes. Developers can now leverage the advantages of API 2.0 when implementing applications for customer management like sign-up portals.

Further expansion of API 2.0 is planned for future releases. If you’re interested in testing the new API version, please contact the PortaOne support team.

Easier and faster development of applications allowing to manage customer settings.

IP phones and VoIP apps commonly support notifying users about new voicemail messages and faxes. For example, upon receiving a new voicemail, Yealink T46G plays an alert tone, the LED indicator slowly flashes red, and a prompt, such as “1 New Voice Mail,” pops up on the screen. To inform phones/apps of mailbox changes for accounts, such as a new voicemail, PortaSwitch sends them notifications (SIP NOTIFY requests) using the Message Waiting Indication (MWI).

With MR112, the MWI service is automatically accessible on all processing nodes in the system. Since the notification processing is now spread evenly across the nodes, this eliminates delays and ensures scalability as your customer base grows, as it allows you to enhance processing speed with each new node you add.

Additionally, to reduce the load in the system, there is an option to send MWI notifications only to the phones/apps that are currently subscribed to the MWI (e.g., if a user of Yealink T46G explicitly enabled the MWI option for their account via the phone’s web UI). Thus, by avoiding sending unnecessary notifications to registered but not subscribed phones/apps (for instance, those that do not handle MWI at all), you can reduce the total load on PortaSIP servers.

Scalability of MWI service ensures prompt notifications even to a large customer base.

See the configuration details here.

With this release, additional search criteria for routing plans and bundles have been introduced. This allows admins to receive faster results when searching through these entities.

• On the Routing plan search panel, admins can now select the route category as a search filter. For example, if an admin wants to find all the routing plans that include the “Premium” route category, they can select “Premium” in the Route category field.

  

• On the Bundle search panel, admins can now filter bundles of a specific type. For example, if they need to filter all bundles of the “Repeated use with renewal” type, they just need to select this value in the Bundle type field. Additionally, it’s possible to filter bundles by Automatic renewal mode such as On sufficient funds or Never.

  

Admins can find the needed routing plans or bundles faster.

The panel that allows group operations with SIM cards has been made more convenient for admins:

• For clarity, the Group operations panel has been renamed to the Group operations with SIM cards.
• Upon selecting one or more SIM cards in the SIM cards list, the Group operations with SIM cards panel appears automatically.
• Admins can now delete SIM cards and change the “Manage by” assignment right on this panel, making all operations conveniently available in one place.

This enhancement simplifies the group operations with SIM cards on the web interface.

When viewing the xDRs summary for all customer services, admin can now see subtotals per service (e.g., voice calls, LTE).

For example, if a customer has a question about service usage (e.g., how many minutes/GB/SMS they used during a specific period and how much they were charged for this), admin can quickly find this information.

To have an overview of all services, admin should select Any in the Service field on the Search xDRs panel.

The breakdown of service charges in the xDR summary enables admins to quickly check and analyze charges associated with specific services.