User Profile
solidpro
Copper Contributor
Joined Jan 27, 2020
User Widgets
Recent Discussions
Teams with Direct Routing - phantom calls which can't be answered get stuck in MS call queues
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!4.5KViews0likes3CommentsRe: Direct Routing - routing outbound calls based on SBC rather than dialled number...
rovert506 Hi. We tested it and it worked, but with a limitation. When adding the second PSTN usage to the policy, if the Primary SBC was alive, but no routes were available to carry the call onward to the PSTN, the SIP messaging is sent back to MS PBX from the Primary SBC to try the second PSTN Usage and SBC. In this scenario, the fallback worked and the call routed over the second SBC. However if the primary SBC is not responding whatsoever. I.E. is completely offline, the fail over does not occur. MSPBX simply tries the primary PSTN usage forever. This was tested after 30 minutes and signing in and out. This proves the VRP is able to fail over to a backup usage upon receiving a 'no route available' or similar message back from the primary SBC, but does not work when the primary does not respond at all. Is this a bug, limitation or something that could be resolved by further configuration?6.9KViews0likes1CommentRe: Direct Routing - routing outbound calls based on SBC rather than dialled number...
rovert506 Hi - could you help me confirm one detail? If we are to attempt this in TAC rather than powershell, I believe your second suggestion "If you want ordered failover for calls within a single "Class of Service", you'd have a voice policy that has two PSTN Usage assigned" is achieved within TAC under Voice / Voice Routing Policy / Click on the policy and then add a second PSTN usage record - is this correct? We are going to test this on Monday, followed by a 20 minute tea break and logout and in of apps... Thanks!6.8KViews0likes0CommentsRe: Direct Routing - routing outbound calls based on SBC rather than dialled number...
rovert506 Thanks again. We did exactly as you suggested - "voice policy that has two PSTN Usage" and virtually the same as you described, and it never failed over to the other one. Although the difference was we didn't wait at least 15 minutes.... Maybe it's best to try again.... "The SIP failure an SBC will provide when it cannot route a call " - in our testing we take the primary SBC out of service altogether - the SBC is entirely offline and there is no response to it's FQDN whatsoever - so in this case there would not be a response whatsoever from the SBC to route the call. Specifically this testing is not proving that the SBC sends the correct information back that no route is available or for the SBC to find alternate onward routes, it's for MS Phone System to seek out a different SBC when making an outbound call when the primary is not available whatsoever... These are Ribbon SBCs so they definitely qualify...6.9KViews0likes0CommentsRe: Direct Routing - routing outbound calls based on SBC rather than dialled number...
rovert506 thank you for taking the time to write a detailed response. I agree, that the wildcard .* is very inflexible, but we have a really simple setup with no need for any restrictions, no physical handsets and no need to route calls based on destination number. So we have put each SBC into it's own PSTN Usage and Voice Route and then created 2 policies - one for East coast users and one for west coast users. This works fine when a user is in a policy with 1 route/1 Usage/ 1 SBC. However if we add the second route in the policy or a second usage in the route, the calls *never* use the second SBC. We tried changing the ordering as well as disabling the primary route at the SBC itself (either via it's trunk to MSPBX or it's external/public IP address) - it never goes to the second SBC. We can remove the first and only THEN does either the route or the policy use the other/alternate SBC. So is this something that is just 'broken'!? Thank you!7KViews0likes5CommentsDirect Routing - routing outbound calls based on SBC rather than dialled number...
Hi This is a bit old fashioned but we have 3 SBCS connected to Microsoft Phone System within our Teams Admin Centre / O365 tenant and we are trying to shape our outbound voice routing policies to simply try SBC#1 and SBC#2 in that order, rather than looking at the dialled number to decide which SBCS to use. It appears that MS Phone System outbound routing policies (what I would usually call trunks and trunk groups in PBX language) don't really allow for this. It feels like the only priority ordering exists for all policies together, when we want to put a user in a policy that simply tries 1 of 2 SBCs geographically local to them and nothing else. Am I just looking at this all wrong or is there a way to simply shape a Policy to try 1 SBC then another regardless of what number they dial? Currently we simply look for .* as the dialled number and pass it through to the SBC and then the SBC shapes the call accordingly. This works fine for us, but whatever we do, we cannot get it to try the second SBC if the first one is taken administratively offline.... ThanksSolved7.9KViews0likes7CommentsDirect Routing call log - 7015 and 7000 "Call ended by media agent"
We're using Direct Routing to route all our calls into Auto Attendant and then some of them onto Teams users via call queues. In the downloaded CSV of call logs there are 2 columns called : Final Microsoft subcode Final SIP Phrase We are trying to go definitive on which subcode or phrase actually means and I cannot find a definitive description of these 2 anywhere on the internet... We are guessing the 7000 "Call Ended by Media Agent" is when something within MS Phone System cuts the call off - like an auto attendant which ends with a hang up, or an announcement which also ends with a hang up. Is this correct? Could the 7000 be caused by an error somewhere? Similar for 7015 "Call Ended by media agent because transfer completed successfully" - we are guessing that the Media Agent is MS Phone System but we can't determine if this 'transfer' is when a Teams user transfers the call to another part or when the Auto Attendant or Queue transfers the caller from a queue to a user... Any ideas would be gratefully received...SolvedDirect Routing Powershell -can't set sip signalling port (or confirm it is set)
Hi We’re trying to setup DR for Teams but having an issue with setting the CsOnlinePSTNGateway – because it appears the spelling of SipSignallingPort has changed. Powershell doesn’t accept the spelling with two ‘L’s anymore so we set it using “Set-CsOnlinePSTNGateway -Identity sbc1xxxxxx.com -SipSignalingPort 5061” which it likes, but when you check back using a get, nothing is set for the signalling port, although we get options back from microsoft, we don’t recieve any FROM it. Also in admin.microsoft.com it shows the SBC as having SIPSignalling set to NONE… any ideas!? Thanks Alex2KViews0likes1Comment
Recent Blog Articles
No content to show