Teams with Direct Routing - phantom calls which can't be answered get stuck in MS call queues

%3CLINGO-SUB%20id%3D%22lingo-sub-1647610%22%20slang%3D%22en-US%22%3ETeams%20with%20Direct%20Routing%20-%20phantom%20calls%20which%20can't%20be%20answered%20get%20stuck%20in%20MS%20call%20queues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1647610%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20experienced%20an%20issue%20in%20MS%20call%20queues%20where%20certain%20callers%20(we%20suspect%20automated%20spam%20callers%20-%20marketing%20companies%20etc%2C%20which%20wardial%20numbers%2C%20trying%20different%20DTMF%20issues%20if%20they%20don't%20get%20answered%20by%20a%20human%20etc)%20which%20enter%20the%20call%20queues%20via%20an%20AA%20and%20cannot%20be%20answered%20or%20killed.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20our%20case%20only%20yesterday%20we%20can%20see%20via%20the%20TAC%20call%20logs%20that%20a%20call%20came%20in%20from%20a%20number%20which%20can'%20t%20be%20called%20(you%20get%20a%20'not%20in%20service%20message%2C%20which%20suggests%20its%20an%20automated%2FSPAM%20call)%2C%20when%20delivered%20to%20a%20member%20of%20the%20queue%2C%20no%20user%20agent%20can%20answer%20the%20call%20-%20the%20Teams%20client%20gives%20a%20message%20on%20the%20screen%20along%20the%20lines%20of%20%22busy%20now%2C%20try%20again%20later%22%20(which%20doesn't%20really%20make%20sense%20since%20that's%20a%20message%20being%20given%20to%20someone%20being%20%3CEM%3Ecalled%3C%2FEM%3E%20not%20someone%20who%20is%26nbsp%3B%3CEM%3Ecalling%3C%2FEM%3E.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20Final%20SIP%20phrase%20and%20cause%20code%20are%20shown%20in%20the%20logs%20as%20486%20%2F%20Busy%20Here%20yet%20the%20call%20is%20not%20disconnected%20-%20it%20just%20sits%20in%20the%20queue%20bouncing%20around%20all%20of%20the%20agents%20until%20the%202700%20second%20timeout%20in%20the%20queue%20occurs%20and%20the%20call%20queue%2Fmedia%20agent%20forcibly%20drops%20the%20call....%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20the%20logs%20you%20can%20see%20the%20call%20come%20in%20initially%20over%20and%20over%2C%20disconnecting%20etc%20as%20we%20suspect%20it's%20trying%20different%20ways%20to%20navigate%20the%20front%20of%20house%20AA%2C%20then%20when%20it%20gets%20through%20it%20simply%20sits%20in%20the%20queue%2C%20unable%20to%20be%20answered%2C%20hassling%20every%20user%20agent%20for%2045%20minutes%2F%202700%20seconds%20until%20the%20Queue%20%2F%20Media%20Agent%20disconnects...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%20in%20conclusion%2C%20does%20anyone%20have%20any%20ideas%20why%20this%20call%20cannot%20be%20answered%2C%20and%20therefore%20disconnected%20manually%20by%20a%20UA%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWorst%20case%20scenario%20and%20a%20Teams%20Admin%20has%20to%20step%20in%2C%20is%20there%20a%20way%20to%20kill%20the%20phantom%20when%20it%20happens%20via%20a%20powershell%20command%3F%20We%20can%20block%20calls%2C%20but%20once%20they're%20in%20the%20queue%20that%20wouldn't%20help...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20ideas!!%3F%20Thank%20you!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1647610%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EBots%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ECalling%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EDirect%20Routing%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EMicrosoft%20Teams%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Highlighted
Occasional Contributor

We have experienced an issue in MS call queues where certain callers (we suspect automated spam callers - marketing companies etc, which wardial numbers, trying different DTMF issues if they don't get answered by a human etc) which enter the call queues via an AA and cannot be answered or killed.

 

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, no user agent can answer the call - the Teams client gives a message on the screen along the lines of "busy now, try again later" (which doesn't really make sense since that's a message being given to someone being called not someone who is calling.

 

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

 

In the logs you can see the call come in initially over and over, disconnecting etc as we suspect it's trying different ways to navigate the front of house AA, then when it gets through it simply sits in the queue, unable to be answered, hassling every user agent for 45 minutes/ 2700 seconds until the Queue / Media Agent disconnects...

 

So in conclusion, does anyone have any ideas why this call cannot be answered, and therefore disconnected manually by a UA?

 

Worst case scenario and a Teams Admin has to step in, is there a way to kill the phantom when it happens via a powershell command? We can block calls, but once they're in the queue that wouldn't help...

 

Any ideas!!? Thank you!

0 Replies