Hi All,
in this article I’ll show you how to solve a very strange behaviour of Ribbon SBC EDGE (1K/2K) in a Microsoft Teams Direct Routing scenario, where the SIP Response 486 Busy Here is not correctly converted in the Q.850 Cause Code 17 in a TDM (PRI/BRI) PSTN connection
How to enable Busy on Busy in Teams
Busy on Busy is a very common and required feature that block a second incoming call to a user who is already on call.
Caller will get a busy tone, callee do not get any disturbing alert or message, only a Missed Call notification in Calls History in Teams
To enable Busy on Busy, you need to enter the TAC (Teams Admin Center) via https://admin.teams.microsoft.com, go to Voice -> Calling policies -> <Policy name> and flag the “Busy on busy is available when in a call” option
Tracing a second call to a user (already in a call), we will get an inbound 486 Busy Here SIP Response Code from MS Phone Systems like this one
SIP/2.0 486 Busy Here
CSEQ: 2 INVITE
REASON: Q.850;cause=63;text="4656976f-d6a4-49de-9f8b-39b448e440f8;User is busy and currently active on another call."
In a SIP to SIP scenario, 486 Busy Here would be a clear command for both MS Phone System and for PSTN Carrier, but TDM lines (ISDN PRI E1/T1 or ISDN BRI) use instead Q.850 Cause Codes.
One of the SBC roles is to translate SIP Response Codes to Q.850 Cause Codes, using a RFC 4497 map table.
Two Q.850 Cause Codes are important here:
| Cause Code | Reason |
| 17 | User busy This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call. |
| 63 | Service or option not available. unspecified This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies. |
The Issue
When I started to test Busy on Busy with Teams Direct Routing I noticed that the caller of the second call do not received a busy tone, instead he get a Call Failed error. Not so good. Time to dig deeper….
Coming back to the SIP Trace in LX, I see the 486 Busy Here from MS Phone System and a Disconnect with
"Cause = 63, Service or Option Not Available, Unspecified"
This is the simplified Call Flow
The Fix
Follow these steps to fix this issue (bug?)
1. In Ribbon SBC web admin page, go to Settings -> SIP -> Message Manipulation -> Message Rule Tables and click + to create a new rule
2. In Create Message Rule Table enter a Description like “Busy Here” and select “486 Busy Here” as Message Selection like in the image below
3. Select the newly created Message Rule Table (Busy Here in the example) and click Create Rule -> Header Rule
4. Enter these value like the image below
Description: Header Result Type: Optional Header Action: Remove Header Name: Reason Header Ordinal Numer: All
5. Go to Signaling Groups and select the Teams Direct Routing SG.
Enable Message Manipulation (if not enabled yet) and click Add/Edit
4. Select the new Message Manipulation Table then OK then Apply
After this change, the Cause Code in the Disconnect Message is different
Cause = 17, user Busy
and the second Caller do not get any Call Failed error!
As always, I hope this article could help some of you.
Regards. Luca
Luca Vitali [MVP] 
Great and simple article. I’ll be adding this to my builds. Thanks Luca
LikeLiked by 1 person
Thank you James. Not clear if this is a bug or not, I’ll ask to Ribbon. Meanwhile it’s a simple fix to improve the UX 😉
LikeLike
Thank you for this post! I came across a similar issue regarding busy on busy in a recent Teams Direct Routing deployment but in a SIP-only scenario with an Audiocodes SBC and a PSTN SIP trunk.
Microsoft Phone System now seems to send REASON: Q.850;cause=34;text=”…;User is busy and currently active on another call.” Without any further configuration on the Audiocodes SBC this caused call loops.
I’ve just changed the SIP Reason Cause on the Audiocodes via message manipulations from 34 to 17 as you described here for the Ribbon SBC. That worked well on the Audiocodes SBC.
LikeLiked by 1 person
Hi Erik, glad this helped you. Best. Luca
LikeLiked by 1 person
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 (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..?
It’s not quite the same symptoms as the call doesn’t repeat dial into someone’s history when they’re already busy but the call logs report very similar traits in the cause codes and phrase.
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, we are lucky to not receive these kind of spam calls 🙂 From what I read i suggest to create an Inbound Transformation Rule to try to match these spam calls, for example anonymous calls or with strange NPI/TON values or the ones that cannot be recalled, and then drop them.
LikeLike
Hi – I think manipulating based on header values is likely to be an arms race we could never win…. could you please elaborate on what you mean ‘cannot be recalled’ though? Or do you know a method in which a call can be killed in O365?
Thanks!
LikeLike
Hi, I understand it’s not easy. I used the wrong terms with recalled, I’m sorry. I suggest to try to check if there are some common or recurring details into these spam calls, no other ideas at this moment, sorry
LikeLike