Call loops after enabling busy on busy for Microsoft Teams Calling with Audiocodes Mediant

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.

Scenario

  • 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

Issue

Enabling busy on busy on Teams caused call loops, many missed calles shown in the call history in the Teams client.

Screenshot – Teams Call History for a user enabled for BoB

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.

Screenshot – SysLog with BoB enabled

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.

Solution

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.

Screenshot – SysLog – Reason Header Analysis – Cause 34 is sent in a 486 Busy Here

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.

Screenshot – Audiocodes SBC \ Setup \ Signaling & Media \ Message Manipulation \ Message Manipulations

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.

Screenshot – Microsoft Teams Call History (after the msg. manipulation was live)

And also the SBC SIP flow is now fine, no more loops due to BoB and the second caller gets his regularly busy tone.

Screenshot – SIP Message Flow – 486 Busy Here adjusted Q.850 cause code

UPDATE 01.08.2020

It’s also an option to remove the reason header instead of changing the Header.Reason.Reason.Cause.

Additional resources

Comment / Kommentar verfassen

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.