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.
erik365.blog 
Hi – thanks for the useful article. We have experienced the same thing but now a step further – in MS call queues. After applying these manipulation rules for the 486 busy now (but in our case on a Ribbon Edge SBC), we still get spam calls into queues which become phantoms that cannot be dropped. We are pursuing this with other avenues for a solution but I wondered if you’d tested your issue here, but in the case of a call queue..?
In our case only yesterday we can see via the TAC call logs that a call came in from a number which can’ t be called (you get a ‘not in service message, which suggests its an automated/SPAM call), when delivered to a member of the queue, they cannot answer the call – the Teams client gives a message on the screen along the lines of “busy now, try again later”.
The Final SIP phrase and cause code are shown in the logs as 486 / Busy Here yet the call is not disconnected – it just sits in the queue bouncing around all of the agents until the 2700 second timeout in the queue occurs and the call queue/media agent forcibly drops the call….
LikeLike
Hi Alexander,
I did not come across this issue after enabling BoB. Does the behavior change if you disable BoB for call queue agents?
I’d recommend to open a support ticket at Microsoft Support and/or Ribbon.
LikeLike