This article will assume you already have Teams Direct Routing in place. If you are not there yet, consider looking at my article on this subject: https://www.lee-ford.co.uk/teams-direct-routing-with-an-audiocodes-sbc/
Introduction to Media Bypass A welcome addition to Teams Direct Routing is Media Bypass. Before Media Bypass was released, all media when using Direct Routing would need to route up to one of six regional Teams Media Processors and back even if the Teams client and SBC were in the same location.
If you’re keeping count, this is the 3rd article on this topic. Previosuly, I have written about two other methods employed to deploying an AudioCodes SBC in Azure:
Using Azure Site Recovery Uploading a pre-packaged ‘Azure VHD’ to Azure Whilst both worked, it still involved uploading an up-to-date copy of the SBC to Azure and a bit of patience.
I’ve had quite a few users reach out to me and ask where they can download the ‘Azure VHD’, but it was never released for download by AudioCodes.
Whilst attending Evolve in Birmingham this year (which I highly recommend), I went to the AudioCodes booth and got on to the subject of their handsets. I’ve mainly used LPE or Polycom VVX so was intrigued by their offerings and they kindly offered to lend me a handset to test and review.
Today, I have an AudioCodes 450HD with expansion module (allows for an extra 22 one-touch keys). It is certified Skype for Business Online and On-Premises (in addition to ‘standard’ SIP).
Issue I’ve had this issue reported to me a few times. A customer will not be able to call certain numbers from Skype for Business/Teams. When I look at the SIP trace within Syslog there is an error message from the SIP provider - SIP/2.0 483 Too Many Hops. This isn’t an AudioCodes specific issue, but this is how to resolve it for AudioCodes SBC.
AudioCodes Syslog Trace showing error from SIP provider
Introduction Following on from Part 1, you should now have an AudioCodes SBC up and running in Azure. This article will cover any Azure specific setup to allow Teams Direct Routing to function.
For Direct Routing configuration you can follow my earlier blog post for instructions.
Note: In Azure, we are using a single NIC, so the “LAN” and “WAN” NIC mentioned is the same interface, so bear this in mind when configuring Media Realms, SIP interfaces etc.
This article is now out-of-date, please refer to this article for Deploying an AudioCodes SBC in Azure using the Azure Marketplace.
Introduction I’ve written in the past about deploying AudioCodes SBC into Azure by using Azure Site Recovery. Whilst this works, it’s not supported!
I recently asked AudioCodes if there were any plans to officially release an “Azure Edition” of the SBC and to my surprise, they said “Yes”. It’s about to hit GA, but I’ve been given a pre-release build to try.
Introduction Had this one recently. Just before ‘go-live’ we had an issue whereby some users were unable to receive calls. On testing, we noticed that an affected user had delegates (or a team-call) set to ring. Disabling the delegates from receiving calls and it worked again. If the delegates were set to ring after 0 seconds, the user got a missed call each second the call was not ringing. Odd!
Last Updated: 13th August 2020
Introduction Microsoft has released Direct Routing for Microsoft Teams. Direct Routing effectively allows you to connect up existing PSTN connectivity (e.g. SIP trunks) into a certified SBC and route directly to Teams. This differs from the Skype Online method of doing this, in that you no longer need any hardware (on-premises Skype for Business Server or a CCE) other than an SBC.
In this post, I’ll go over how to do this with an AudioCodes SBC and SIP trunks.
Edit 09/07/18 - There is now an easier, supported method to achieve this here.
Introduction For a while, I’ve been running SBCs and other virtual machines for my lab on physical servers, which consume a fair bit of power and most of the time sit there unused. I’ve managed to move other machines to Azure but wanted to also move an AudioCodes SBC too. One thought when Direct Route arrives, I could have a whole PSTN calling lab in Azure to play with.
Introduction Over the past few years browsers such as Chrome or Firefox have started deprecating known vulnerabilities in SSL/TLS encryption - vulnerabilities that can break the encryption. Where this post’s issue lies is that IETF have prohibited the use of RC4.
The Issue Now, what happens if you need to access something via HTTPS, say an AudioCodes that uses the RC4 cipher? You will probably be presented with an error such as in Chrome: “ERR_SSL_VERSION_OR_CIPHER_MISMATCH”.