In this post I describe how you can fix a call loop and cause code issue with busy on busy enabled in Microsoft Teams Direct Routing in conjunction with a Audiocodes Mediant Session Border Controller. In one of my recent Teams Direct Routing deployments I came across an issue as soon as I enabled Busy on Busy in the Microsoft Teams Admin Center, as described in one of my previous blog posts, here.
- Microsoft Teams Direct Routing
- Audiocodes Mediant VE Session Border Controller (SBC) V 7.20A.256.721
- PSTN SIP Trunk Provider
- Microsoft Teams Busy on busy (BoB) enabled for the user/s
Enabling busy on busy on Teams caused call loops, many missed calles shown in the call history in the Teams client.
Usual calls incoming, outgoing, call forwarding etc. worked fine but after assignment of the policy including the enabled busy on busy the caller caused a “call loop” and many missed calls in the call history while the callee was still on a call with someone else.
Actually the above SIP flow looks ok but why on earth is the second caller’s number showing up that often? That’s the loop we get and the many missed calls as long as the called person is still busy on another call.
Usually, 486 Busy Here should be ok towards the PSTN SIP Trunk provider because this says “busy”. However, it did not really say “busy” or provide the “busy” tone to the second caller.
After some research I came across an helpful blog post from Luca Vitali describing a similar issue with the difference that he’s seeing this in a TDR deployment with a TDM PSTN trunk and a different cause code sent by Microsoft 365 Phone System.
So, I checked the SIP reason header in more detail for the “486 Busy Here”. Viewing the SIP message logs by using the SysLog Viewer I found REASON: Q.850;cause=34;text=”171015b7-8b51-4fca-b9c0-d5f052823334;User is busy and currently active on another call.” There I noticed “cause=34” which means “no circuit available”. Is this not ok? That could be the possible issue because Microsoft 365 Phone System sends the above in a BoB scenario and probably the PSTN SIP Trunk provider looks not only on the “486 Busy Here” but also in the details of the Reason including the Q.850 cause codes which does not include the right code for “busy”.
So, just set up a message manipulation rule on the Audiocodes SBC to change the cause in the SIP reason line.
Example of the message manipulation rule to change the Header Reason Cause Code:
[ MessageManipulations ] FORMAT Index = ManipulationName, ManSetID, MessageType, Condition, ActionSubject, ActionType, ActionValue, RowRole; MessageManipulations 2 = "MM-Teams-486BusyHere-34-17", 1, "Any", "Header.Reason.Reason.Cause == '34'", "Header.Reason.Reason.Cause", 2, "'17'", 0; [ \MessageManipulations ]
This message manipulation rule is based on the message manipulation set id assigned to the IP Group for Teams as an inbound message manipulation.
Please note that the above is just provided as-is and might require adjustments for your deployment. Also, the above manipulation of the cause code might be adjusted if Microsoft Phone System was changed and it sends out another cause code in the Reason Header. I thought of using “…!= ’17′” to always change the cause code in the Reason Header but that’s no good idea because it can cause other issues.
After the message manipulation was implemented I successfully re-tried.
And also the SBC SIP flow is now fine, no more loops due to BoB and the second caller gets his regularly busy tone.
It’s also an option to remove the reason header instead of changing the Header.Reason.Reason.Cause.
In this post I describe how you can backup your Audiocodes Mediant VE on Microsoft Azure. Let’s start with some basics before configuring your SBC backup on Azure.
First of all, if you deploy your Audiocodes Session Border Controller (SBC) for Teams Direct Routing or any other SBC I’d recommend to save the configuration. For instance, on Audiocodes Mediant SBCs you can easily save the configuration file (config.ini) and/or packages.
Take a (“on-system”) snapshot
Another option is to directly save a snapshot on the Audiocodes SBC which enables you to quickly revert to this “restore point”.
Enable Azure Backup for virtual SBC
Hereinafter, I’ll show an example on how you can enable and configure your Audiocodes Mediant VE getting backed up on Azure.
Here you can configure retention, how long which type of backup should be kept.
After the validation is ok, your done.
You could trigger an ad hoc backup now, to check if it works.
If configured you should also restore the system once, to ensure that you know that it works and how to restore a VM.
Conclusion, opinion and summary
To backup your virtual SBC on Azure is a good thing in my opinion. Especially if you maybe want to revert the SBC after a firmware upgrade to an earlier release or just quickly bring back another configuration if you’ve missed to download the config.ini or config package before you made this one big change on the system.
This post is about a newly released white paper by Audiocodes on software-defined voice networks to optimize network performance and reduce operational costs for communication, especially voice, solutions.
The white paper points out the challenge on managing complex (voice) networks and versatile workloads in times in which businesses have to master their digital transformation. Audiocodes emphasizes that many carriers abandon their legacy PSTN technology backbone to transition from ISDN to All-IP. This also causes a change at the enterprises. Therefore, software-defined voice networks is described as an approach to cope with the technology change by to keep voice networks manageable and cut operational costs.
The advantages of software-defined (voice) networks [SDvN] as mentioned in the white paper are:
- decoupled voice network infrastructure and voice control layer
- overlay network
- agil and dynamic
- vendor agnostic
- centralized network and call routing management
- optimized call routing
Conclusion, opinion and summary
As I wrote in the past network reliability and performance for your communication and collaboration services (incl. voice) are essentials.
SDN can provide options to reduce operational costs and make your network more reliable and perform better. Audiocodes’ white paper outlines what SD(v)N in complex voice networking environments could offer to fulfill today’s and tomorrow’s business requirements in the digital era. SD(v)N, definitely something you should consider in case you have large and multi-national/-site (voice) network.
In this post I want to notify about the release of the latest Audiocodes One Voice Operations Center (OVOC) version and briefly explain what OVOC is and where it might help you.
In OVOC 7.6.1116 some remarkable features were added to the product as well as some changes were made to overcome limitations of previous versions.
What’s Audiocodes OVOC?
The One Voice Operations Center is a single pane of glass which helps you to manage voice endpoints and voice service in your voice infrastructure and network. It enables you via browser to globally manage voice devices, monitor your voice network service/s, support you to troubleshoot issues within your voice network (also with SFB) and it provides rich reporting to gain insights.
There are two versions available: Basic and Advanced. The basic version provides (only) device management.
What’s new in Audiocodes OVOC 7.6?
- Dashboard at the OVOC landing page
- Monitoring improvements for Audiocodes device performance
- Increased number call exports
- SmartTAP Call Recording Support
- FQDN authentication support with SSL
- LDAP support for multi-tenant environments
- Jabra and Poly (formerly Polycom) VVX device support in the Device Manager (more in product notice #0356)
- New OVOC agent for device management
Conclusion, opinion and summary
In my opinion OVOC is a must if you deploy several (voice) devices across your enterprise to have the ability to centrally manage and monitor these devices and the voice service operation. The more components the more important and inevitable it becomes. Especially, if your responsibility is to ensure a good voice user experience you should definitely consider to deploy OVOC for your Audiocodes voice network if not done yet.
- Audiocodes Product Notice #0356 + #0358 (Blog)
- Audiocodes Product Notice #0358 (PDF release notes download)
- Audiocodes Product Notice #0356 (PDF release notes download)
- Audiocodes OVOC
- Audiocodes Services Portal (to download OVOC, as registered user)
- Audiocodes Insights from Microsoft Ignite Tour EMEA (video)
This post is about news regarding the Audiocodes CLI Reference Guide. If you configure Audiocodes Session Border Controllers (SBCs) or Gateways you may know that there are some features and settings you might need or prefer to set them via command line (SSH/telnet).
In the past you downloaded the latest reference guide from the Audiocodes Library as PDF. Now there is a new site where all the commands can be found and looked up. You can find the guides as before via the Audiocodes Library.
Conclusion, opinion and summary
I prefer to use the site instead of the PDFs because the commands are easier to find at least for one version. However, it would be nice to have the option to switch between versions. E.g. if you have still a SBC with 7.0 a version selection which enables you to switch from 7.20 reference guide to 7.0 would be nice. Otherwise you had to navigate via the Library to that version. Finally, this new content delivery is nice and all you need. I like it.