How to fix Microsoft Teams SIP 486 Busy Here to Q.850 mappings in Ribbon SBC

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 CodeReason
17User 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.
63Service 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

8 thoughts on “How to fix Microsoft Teams SIP 486 Busy Here to Q.850 mappings in Ribbon SBC

Add yours

  1. 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.

    Liked by 1 person

  2. 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….

    Like

    1. 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.

      Like

      1. 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!

        Like

      2. 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

        Like

Leave a Reply

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.

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: