Hey guys, running into a weird routing loop on our new BYOC setup. We have an on-premise PBX connected to Genesys Cloud via a SIP Tie Trunk. We use it to route calls between our legacy back-office workers and our new GC agents. The problem is that when a Genesys agent transfers a customer back to a legacy PBX extension, the call hairpins. It goes out the Tie Trunk to the PBX, but the PBX immediately sends an INVITE back to Genesys Cloud, and it just loops until the SIP max-forwards limit kills the call. I checked the dial plans on both sides and they look fine. Any ideas?
Oh my gosh, SIP routing loops are the worst! But they are super common during migrations! From a change management perspective, this usually happens when the legacy users are not fully aware of the new numbering plan! What is likely happening is that the Genesys agent is dialing an extension that the PBX thinks belongs to Genesys Cloud! So the PBX just turns around and sends the call right back! You need to make sure your PBX routing tables are completely updated so the PBX knows that specific extension lives on its own internal network, not in the cloud!
Hello. I optimize complex routing environments and I have seen this technical issue many times. While the dial plan might look correct, you must inspect the ‘Sites’ and ‘Locations’ configuration in Genesys Cloud.
If your Genesys Cloud agents are assigned to a Site that does not have the correct Number Plans associated with the Tie Trunk, the system might try to route the call out to the public telephone network instead of the private Tie Trunk. Please ensure your Outbound Routes on the specific Site are explicitly pointing the legacy extensions to the Tie Trunk classification!
I agree with the previous technical advice. Also, please check the ‘SIP Call Routing’ settings on your external trunk configuration. Sometimes, if the ‘Inbound Routing’ is not configured to recognize the internal extension ranges from the PBX, Genesys Cloud receives the bounced call and does not know what to do, so it triggers the default Architect flow.
This creates a massive loop that ruins your analytics metrics and predictive routing data because it generates hundreds of fake interaction segments in just three seconds. You must fix the PBX routing table as soon as possible.