Update (14/01/2020): the latest build of 8.0.3 appears to resolve this issue and you no longer need the port defined in the SIP profile as described in the comments.
I am currently deploying a new Ribbon SBC Edge running that latest firmware 8.0.3. We where having issues with calls failing to establish media – the calls rang and you could answer them, however nothing could be heard either side. Upon investigation we found that the firewall was blocking port 5061 inbound from Microsoft Teams, even though this specific trunk was configured to use port 5063. Opening port 5061 resolved the issue, however it didn’t explain why this was happening. Looking at the Ribbon SIP ladders I could now see that calls were being initiated on port 5063, but then switched to 5061 mid-call.
I checked with a friend at Microsoft who confirmed that this shouldn’t happen and was able to replicate it in their lab. They also noticed that the contact header didn’t include the port. To confirm this issue was Ribbon software related I rolled back to build 8.0.2, and sure enough the port that was missing in the contact header had returned.
Here you can see the difference:
I am currently working with Ribbon on this issue. For now I suggest you hold off any planned upgrades. I will report back on this post once Ribbon have confirmed.
Hi Andrew. You can configure the headers “From” and “Contact” as static in Teams SIP Profile and use your.fqdn.com:5063. That will solve your problem with signaling ports. Let me know if it helped!
Or :5061 if you are binding this port on Teams Signaling Group, but according to default TLS protocol port, it should use correctly the port 5061. Usually this problem happens when we use ports different of the defaults ones. What is interesting is that I noticed this strange behavior from 8.0.1 to 8.0.2 and not 8.0.2 to 8.0.3. Anyway, I hope it helps!
I typically prefer to use 5061, but last time I checked, Teams wouldn’t let me use the same port for multiple gateways even when the FQDN was different. I might need to re-check that is true….
I didnt think to add the port there, I’ll give it a go and report back. Thanks! I find it odd that it doesn’t do the port change mid-call in 8.0.2 then all of a sudden in 8.0.3 it starts doing this. Did you discuss with Ribbon? Bug?
This change was made intentionally to support certain SIP trunking providers, in 8.0.3 we only add the port to the contact header when it is specified in the SIP header customization as Rui mentioned.
The contact is only used for new SIP transactions which makes the behaviour confusing.
We realize that this will create more confusion are backing out this change and re-releasing 8.0.3 without this. We will provide an alternative solution for the SIP trunking providers.
Thanks Kevin appreciate you getting in touch and good to know you are working on a fix.
PS I don’t mind having to add the port to the static host, it’s probably more flexible actually. However, for existing configs I’d suggest you add a config element to say whether you want to enable this new behaviour to avoid things breaking.
No, I didn’t discuss with Ribbon about that, but it sounds like a terrible bug to me.
Until version 8.0.1, the engine read the binding port from Signaling Group and if you define the port on SIP Profile, you would see something like fqdn.domain.com:5063:5063, so, you couldn’t specify the port as static. Since 8.0.2 it stopped getting the port from SG and I needed to specify it on SIP Profile.
It looks like they didn’t tested all of the configuration according to Direct Routing requisites and according to the version, I’ve found different bugs. Are you using SWe Lite ou SBC 1K2K? I found most of these bugs on SWe Lite only.
Interesting. I hadn’t come across those changes in the past, but it might explain some strange media establishment issues I had recently. Im going to re-look at that. Thanks again!