MS Teams - Troubleshooting PSTN Call Disconnection / Transferring Mode Issue in Call Queue Agents

 Hello Team

Hope everyone is doing great

I would like share my experience for the issue which i have had faced in MS Teams enterprise voice environment 



External Call to Auto-Attendant/Call Queue is not working for India based region SBC's and not able transfer the call to external numbers  or others


India SBC's are configured in Location based routing.

Issue : 

The real issue is something that , the inbound calls are unable to attend the by any of the call Queue agents, when some calls from external like mobile, or landline.


Attended the from MS teams client (hold for 4 second and got disconnected)

A newly created a Call Queue [India number assigned] was not able to receive the external calls from mobile, Teams to Teams calls is working fine if some one called from MS Teams client to the Call Queue number, however agents are unable to transfer the calls to any other numbers

We analysed the PSTN logs and found the below final SIP Phrase Code 


 

and Conference mode was enabled for the call queue 




As per the MS article below

Plan Location-Based Routing for Direct Routing - Microsoft Teams | Microsoft Learn    

Inbound PSTN calls from a Location-Based Routing enabled gateway are allowed to connect to an auto attendant or call queue.

Users enabled for Location-Based Routing are supported to receive inbound call transfers for these applications when they are located at the same site the inbound PSTN call originates from. To support Local Media Optimization and Media Bypass in these scenarios, Calls Queues must be configured for transfer mode (Conference Mode = OFF).


We turned it [conference mode] off and tried , but no luck, external calls were not getting through.

We engage Microsoft support team for further assistance 

the Microsoft engineer involved the Microsoft Product Group (PG) to further investigate the issue after verifying the Location-Based Routing (LBR) was configured correctly. Then, the backend team found that phone calls were not supported once routed to the queue from a Direct Routing gateway

From the calls Samples

From the call samples provided we see the below details 

  1. Call from PSTN to Call Queue - All good on this.
  2. Call from CQ to Agent - All good on this too.
  3. Call from Agent to SBC to replace first call.  Here SBC is responding with SIP/2.0 481 Call/Transaction Does Not Exist.



Logs of affected call show that first Call leg from SBC to Microsoft b03-d8-4c25-a3-b124ac works

Then Call from CQ to the Agent 8a1c9-850c-462-b739-3f53699f is also working, hence CQ agent receives the call toast. 

The Call from Agent to SBC to replace first call 0c68009b-f3-488-bb6e-eff73 fails with 481 response from SBC side. 



Investigation:-

 Since India has LBR restriction, Call Queues are supported with transfer mode only (Conference Mode Off)

So Call Queue places incoming call on MoH, then call queue will hunt agents like in a consultative transfer. 

Once an agent answers there would be an Invite from Agent to SBC to replace the first call leg. 

The replace SIP Invite doesn’t get a 200 OK from SBC and hence agents calls are dropped.




 SBC Vendor Team : 

We engaged SBC vendor Audio Codes from our end, and had a conference call along with Microsoft support team. SBC vendor fixed the issue at their end by fine tune the setting at their end

Root Cause

Apparently MS Teams use method replace instead of SIP Refer when call termination on MS Teams use Call Queue (consult transfer of Call Queue to Agent).


While SBC facing MS Teams configuration handle this locally already, the issue was on SBC facing PRI/PSTN (since all India SBCs use PRI and configuration is different with SIP trunking).

 When MS Teams sends Invite back to SBC for replace method, the SBC sends invite back to the PRI treating this as another call, instead of transfer.

Disabling the transfer mode on the PRI config port fixed the issue. By disabling this, the SBC provide control of any transfer and replace when triggered by other end point, facing the PRI/PSTN.

Note that local SBCs in India are also PRI gateways, so basically topic is slightly different from the rest which use cloud SBCs 

Happy Troubleshooting and Learning to all. I hope this would helpful for someone 😃

Comments