Architectural Limitation: Move LBR from Gateway to Voice Routes for Shared Trunks
The Problem: Currently, Location-Based Routing (LBR) in Microsoft Teams is hard-locked to the root OnlinePSTNGateway object (e.g., via -GatewaySiteLbrEnabled). This creates two major administrative roadblocks: Derived Trunk Limitations: For organizations utilizing multi-tenant partner architectures and derived trunking models (such as AudioCodes Live Pro/Express), the underlying global gateway configuration is owned and managed by the provider. Because administrators lack root modification rights over these shared gateway objects, they cannot enable or configure LBR. https://imgur.com/a/RzTE4nu Managing gateways via the Teams Admin Center (Voice > Direct Routing > SBCs) results in restricted or failing LBR configurations. Rigid Global Enforcement: Forcing LBR as a strict hardware-level switch creates deployment roadblocks, such as entirely blocking unmapped or remote workers. This is overly restrictive in regions like North America, where strict anti-toll-bypass compliance is not a legal mandate (unlike regions like India). The Proposed Solution: Decouple LBR from the Gateway Object: Shift LBR evaluation away from the root hardware gateway switch toggle and allow it to occur at the Voice Route, PSTN Usage, or Calling Policy layer. Support Derived & Shared Trunks: This decoupling will instantly make LBR compatible with multi-tenant SBC models, allowing enterprises to manage geographic routing via distinct voice routes (which are already peered with gateways), bypassing the need for root gateway property access. Regional Flexibility & Compliant Enforcement: Enable regional flexibility so enterprises can bypass unnecessary toll-bypass blocks in regions where they aren't mandated (like North America) without breaking calls for "Unknown" network sites. Crucially, for heavily regulated regions like India, system-enforced policies should automatically lock LBR on to strictly maintain local country regulations without relying on manual overrides. Business Impact: This enhancement will unlock advanced routing flexibility for thousands of enterprises utilizing modern cloud-hosted and derived trunking architectures. It bridges the gap between legacy PBX design constraints and modern multi-tenant cloud voice management, significantly reducing deployment friction for global organizations.
Local Survivability with Operator Connect
Wanted to see if anyone out there has stood up a form of Local Survivability for PSTN access in the event someone loses connectivity back to the Teams tenant or an M365 outage? Not sure if it's on the roadmap to have SBA's work in parallel with OC clients? I'd hope you could have the IP Phone register to both OC and the SBA and in the event OC was unreachable the phone would use the SBA to dial out to the PSTN. I understand we can standup different ISP's for carrier diversity but if both went down to a fiber cut, this client needs access to 911 as they are a city with many recreational facilities for the residents that use them. Any thoughts on how we can roll out a Local Survivability option with Operator Connect would be appreciated . Thanks!
Calls from Microsoft Teams App compared to Teams web app
Hello Bit of a tricky one but I believe it maybe a network issue. I have a situation where the client calls a business contact, goes through to an IVR, press's the required selection and after getting put through to the agent all audio drops from the call. Strange aspect is, if you make the call with the Teams app, it works, make it with the Teams web app and it fails (I have tested this by calling from two numbers that go over completely separate carriers). I have captured network logs and can see a continuous stream of UDP so I know the call is not failing, it seems the audio process is being dropped when being routed through the webb app. Has anyone had this before or would know the difference route/process a teams app phone call makes to a teams web app? I believe it is probably a network issue on the B Party side, but as with most calls, proving that is half the work. I am going to do my own research but not come across clear yet, if anyone has anything to add that would assist in this I would be grateful (as well as if I come up with the answer I will put this down as it is an inconvenience for the client).
Delay transferring out from auto attendant
We have been testing Teams with Direct Routing trunks provided by a carrier partner. All inbound and outbound calls direct to/from Teams users connect without issue. We are using the Teams apps on Windows and iOS - no deskphones are involved yet. I have a simple auto attendant set up which greets the caller with the text-to-speech feature, and then transfers to a queue. This queue plays the default music on hold while alerting queue members. The problem I have is that a caller will dial the number associated with the auto attendant, the call will be answered within a couple of seconds, and then immediately the greeting will be read out and the user will be transferred to the call queue. There is then a silent period of between 5-10 seconds before the music on hold for the queue is heard - this varies with each call, at the lower end it's an acceptable delay, but when it gets to 10s of silence it really isn't workable. If I set the routing on the call queue to put the caller back into the auto attendant after a wait period this happens without any silence - the maximum wait period for the queue is reached and the greeting is played as soon as the music on hold ends. I am not able to determine whether the delay is happening within the auto attendant as it just waits after playing the greeting, or whether it's an issue at the start of the call queue. I opened a support ticket and was told that this delay is expected behavior and it is designed that way - the problem is that it's long enough for people to abandon calls as they think there is a problem. The queue is in conference mode, but this isn't an issue with users answering calls from queues so I don't think that is relevant anyway. Is it true that this delay is expected behavior? Is it expected due to a technical limitation or is it really designed that way?
Teams rejects call with error 422
Hi all, I'm having some trouble with calling from a Swyx pbx to Microsoft Teams direct routing. When I place a call from Swyx pbx to Teams, the call get's denied. When I checked the logs I noticed the following: 422 Session Interval Too Small error Teams is rejecting the call because Swyx is sending a 90 sconds field in the Session Expires Header. I searched the web for adjusting the allow Session Expire field in Teams but can't find anything. According to this document: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc4028&d=DwQFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=bdJuGgXBNv0oDSVCTB7425Pr5HE_IuvCvTQjeMBSyCY&m=Zhit76GWb3DmbRr8CyjjghCgJs-1NPqU-VoW9OGEmtc&s=K1xEJ3gnHuUcjX2iTfjRR6d_HICQJe5jTpmNfanBp-s&e= The rule is to have at least a 90 seconds Header. So Swyx does nothing wrong with that. Can anybody help me with this? Or point me in a good direction. Thanks!Customized name display for Resource Account
Good day, I am struggling to customize a name display when a user makes an outbound call on behalf of a Resource Account. Currently our Resource Accounts are built with a display name of 'CompanyABC Purchasing', 'CompanyABC Operations', etc. As the first 15 characters are delivered to the PSTN, we would like to only display the name 'CompanyABC' instead of 'CompanyABC Purc' and 'CompanyABC Oper'. We attempted to modify the display name by adding five spaces after CompanyABC and then continuing with the remainder of the name, but only one space is shown once the update has been saved. We can build a test Caller ID Policy, but I am unsure how to apply it to the Resource Account or the associated Call Queue we are using for our teams. Any suggestions on how this can be completed? Shaneinduce delay on ringback tone
using direct routing with teams phone system ... noticed when a teams client dials out to external pstn number it pretty much straightaway sends calling party the ring back tone ... so there could be 2-3 ring back tones on the calling end (approx. 4-5 secs.) before the called party eventually receives the first ringing tone .. is there a way to induce a delay in that initial ring back tone Teams phone system sends to the Teams client ? i just don't want to start giving ringback tone straight away when 180 ringing from itsp is not received for another good 3-4 seconds. thanks.
