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.

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.

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.

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.

UPDATE 01.08.2020

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

Additional resources

• Busy on busy in Microsoft Teams
• Cause Code Mappings – ISUP to SIP
• Luca Vitali – How to fix Microsoft Teams SIP 486 Busy Here to Q.850 mappings in Ribbon SBC