De-provisioning users in an organisation is always handled by the identity and access team. Rarely do de-provisioning processes get updated and often trying to bake the changes into the process can be challenging as we meet resistance both in workforce and in tooling.
In Skype for Business, disabling an enterprise voice user was a simple process, run disable-csuser command and then disable the AD object of that user. This stopped Skype for Business routing inbound calls to the DDI assigned to this user ensuring that the call is handled properly and the PSTN carrier received the correct response to terminate the call and provide the caller with the correct tone or message.
For reference a number not found would normally have a SIP 404 response which would map to a Q.850 cause code of 26 and the PSTN caller would be played the invalid number tone.
Moving into the Cloud and organisations de-provisioning process for Microsoft 365 users is to disable them in the Admin Center of Microsoft 365 or AzureAD. Whilst this disables user authentication and de-licenses them, it does not clear the user object in Teams / Skype for Business Online.
Why is this a problem?
To date Microsoft Teams voice routing still uses elements of Skype for Business Online backend to handle enterprise voice traffic. The user object still exists in the Skype for Business Online database (Get-csOnlineUser) and correctly in a disabled state. However, the number being still assigned to the LineURI of that object cause debatably incorrect handling on inbound calls received to this number from the PSTN.
You would think that Teams would respond with the same 404 / 26 code to any inbound call to a number still assigned to a disabled user object. But it doesn’t instead sends a 403 / 63 response to the received invite.
Explaining the Problem
Two main reasons:
- If your PSTN carrier handles 403 responses as non-terminating errors and uses them as redirect triggers, say between an active / passive SBC / route then they will flood your SBCs with continual Invites until the caller gives up trying to dial.
- In conjunction to this the caller does not receive the correct error tone, instead hears silence until they decide to give up. They think that there is something wrong with their phone and keep trying to dial and get the same response
In all you get into a vicious circle of receiving potentially hundreds of incoming invites to your SBC taking up capacity and causing performance issues.
How do you Stop this?
There are three ways to solve this problem.
- The most appropriate resolution of course is to modify your de-provisioning process to remove the LineURI from the user object prior to disabling. Not only does this solve the issue, it also give you back a DDI in your range you can allocate elsewhere. It also prevents you allocating the same DDI to another user and causing a 485 Ambiguous error which means that the system has a duplicate number assigned and can’t be routed.
- The second way is to talk to your PSTN carrier to see if they can modify their cause code redirects so that when they receive the 403, they terminate the call appropriately
- The third way is to rewrite the 403 response to 486 / 17 error which tells the PSTN carrier that the called number is busy thus breaking out of their redirects and getting their SBC to play a busy tone to the caller.
Here is a screenshot of the response from Teams
How to handle this with an AudioCodes SBC
You will need an outbound message manipulation to your PSTN Carrier SIP circuit.
Go to Message Manipulation > Message Manipulations
Create a new manipulation
Set the Manipulation Set ID to the ID of the set assigned to your outbound manipulation set ID on the PSTN Carrier IP Group
Give the rule a friendly name e.g. “replace 403 with 486”
Set the Message Type to “Invite.Response” – This is so that the rule only applies to responses to an incoming invite
Set the Condition to “Header.Reason.Reason.Cause==’63’ – This is the reason code we see above and so that the manipulations only apply to responses that match the condition
Set the Action Subject to “Header.Reason.Reason.Cause – The header we are targeting for manipulation
Action Type, set to Modify because we want to change the value to something else
Action Value, set to ’17’ – the Q.850 cause code for User Busy which translates to SIP 486
Save the rule and then attempt the call. The caller will hear a busy tone.
Tracing the subsequent call you will see that the code has changed on the outbound response from the SBC to the PSTN carrier, thus causing it to handle as a busy tone.
