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.
Background With the preview release of Teams Direct Routing users are now able to make and receive PSTN calls using certified SBCs instead of Calling Plans. Part of setting this up involves setting up PSTN Usages, Voice Routes, Online Voice Routing Policies, PSTN Gateways etc. within Skype Online PowerShell. Much like Skype for Business, if your users have multiple calling requirements the amount of Voice Routes, PSTN Usages etc. can grow quickly and sometimes make it quite hard to fathom how a call will route.
Just a quick one here. I was busy setting up some Voice Routes and Online Voice Routing Policies for Direct Routing but it wasn’t behaving as I expected. I had purposely locked down my account I was using to only allow UK calls. But when making a call to Microsoft US, it worked. Odd! I double checked the routing I had in place and it was correct. Strange… I then made sure I didn’t have a Calling Plan assigned (as that will be used as a last resort)… I didn’t.
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: 4th 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.
Recently added to Skype Online and Teams is the ability to block inbound calls based on their caller ID. Useful for blocking nuisance callers. Once you’ve added the patterns, you ideally want to know: If the calling numbers you want to block will be caught in your patterns. Regex is not my strong suit so want to make sure it will match. Are some calls going to be inadvertently blocked?
Introduction In all my deployments of SRS up until now, I’ve used are using the same SIP domain and UPN or they’ve 100% Office 365, so not come across this before. In my scenario I had: Internal AD domain domain.co.uk - Used for the user’s UPN - in this scenario 100% on-premises so no Azure AD - they saw no need to change users UPN to match SIP domain.
Introduction For Skype Online there are various tools to report on user sessions: Call Analytics - This is great for looking at a user’s call history when diagnosing call issues. This is similar to the data we can glean from on-premises SSRS reports. Call Quality Dashboard - Again, great for looking at overall trends or metrics of call quality to pinpoint issues. Session Details - This is accessed from the Skype Admin Centre.