> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/connect-telephony/direct-routing/direct-routing-routing-scenarios-and-testing.md). # Routing scenarios and testing Review the main Direct Routing call-flow patterns and the migration-testing approach used before production cutover. Use this page to understand the main Direct Routing call-flow patterns for a Connect model deployment and the testing pattern recommended before production cutover. For the Direct Routing overview and OnePortal configuration workflow, see [Telephone Connection for Dialogue Cloud Neo (Connect)](/connect-telephony/direct-routing.md). ## Start with the baseline routing model The routing scenarios on this page all depend on the same core rule: the customer Session Border Controller (SBC) decides whether a call should: * continue on the regular Microsoft Teams or Internet Telephony Service Provider (ITSP) path * be routed to Dialogue Cloud for UCC behavior * be returned to Microsoft Teams first because the call resulted from an Enhanced Direct Routing (EDR) transfer flow Across the scenarios, the network model includes: * the external caller or callee * the ITSP * the customer SBC * Microsoft Teams * the agent's Microsoft Teams endpoint * the Dialogue Cloud SBC * the Dialogue Cloud service layer ## Basic UCC call routing In the basic scenario, a caller dials a UCC number and the ITSP forwards the call to the customer SBC. The SBC recognizes the UCC destination and forwards the call to Dialogue Cloud instead of directly to Microsoft Teams. Dialogue Cloud then: 1. accepts the incoming call 2. runs the required UCC logic such as greeting, IVR, or queue handling 3. creates a new call leg toward the selected agent The agent-facing leg uses `A365-AgentHunt: 1`, which tells the customer SBC to route that leg toward Microsoft Teams. ## Direct Call Interceptor Direct Call Interceptor (DCI) is the outbound pattern where an agent starts a call from an AnywhereNow client and Dialogue Cloud first calls the agent before placing the destination leg. The durable routing pattern is: 1. Dialogue Cloud creates an agent call leg that routes to Microsoft Teams. 2. After the agent answers, Dialogue Cloud creates the destination call leg. 3. The agent leg and destination leg are then connected. The destination-facing leg usually uses `A365-AgentHunt: 0`, which tells the SBC to continue the call toward a non-Teams destination. ## Inbound interception Inbound interception is the pattern where a direct call to an agent number is routed first to Dialogue Cloud instead of directly to Microsoft Teams. If the agent is eligible for interception, Dialogue Cloud performs the required service behavior and then creates a new call leg back toward the intended agent. That returned leg again uses `A365-AgentHunt: 1`. When original caller identity behavior is enabled for inbound interception, the agent can still see the original caller identity on that returned leg instead of a generic service identity. If the agent is not signed in or not eligible for interception, Dialogue Cloud returns `SIP 408 Request Timeout`. The customer SBC should then continue normal routing toward Microsoft Teams. ## Outbound interception Outbound interception is the pattern where a direct call from an agent number is routed first to Dialogue Cloud instead of directly to the ITSP. The durable routing pattern is: 1. the Microsoft Teams user starts an outbound call 2. the customer SBC recognizes the originating number in the SIP `From` header 3. the call is routed to Dialogue Cloud 4. Dialogue Cloud applies the required service behavior 5. Dialogue Cloud creates a new destination call leg back through the SBC This destination-facing leg typically uses `A365-AgentHunt: 0`, which signals that the leg should continue to a non-Teams destination. When original agent identity behavior is enabled for outbound interception, the external callee can still see the original agent identity instead of a generic service identity. If the outbound intercept is not active because the agent is not signed in, Dialogue Cloud returns `SIP 408`, after which the SBC should continue normal outbound routing. ## Transfer behavior with EDR Transfer handling changes when EDR is active because Dialogue Cloud supports SIP `REFER` and marks transfer-generated calls with `A365-IsRefer: 1`. The durable transfer patterns kept for Atlas are: * cold transfer to Microsoft Teams * cold transfer to a PSTN destination * cold transfer to another UCC * consultative transfer to Microsoft Teams, PSTN, or another UCC In all cases, route the transfer-generated call leg through Microsoft Teams first when the EDR transfer marker is present. {% hint style="info" %} This page focuses on durable routing rules and cutover validation. Keep detailed signaling diagrams or vendor-specific engineering reference material in a separate support guide when deeper troubleshooting detail is required. {% endhint %} ## Test before production cutover Before production cutover, use a staged test pattern where production numbers are provisioned in Dialogue Cloud before the customer fully switches live telephony. Use this testing sequence: 1. Assign the future production numbers to the production UCCs in Dialogue Cloud. 2. Fully configure the UCCs and the required users before telephony cutover. 3. Create a number plan that maps temporary PSTN test numbers to those production numbers. 4. Configure SBC manipulation rules that translate the test numbers to the production numbers and route them to Dialogue Cloud. 5. Test against the temporary numbers until the end-to-end call flow is approved. 6. Repoint the real production numbers only after the migration test is complete. This pattern lets the customer validate the production Dialogue Cloud configuration before the final telephony cutover. {% hint style="warning" %} Do not repoint the live production numbers until the temporary-number test path is stable and approved. The cutover step should be the last routing change, not the first test. {% endhint %} ## Verification 1. Confirm the customer SBC routes UCC numbers, intercepted agent numbers, and outbound intercepted calls to the intended destination. 2. Confirm agent-facing call legs with `A365-AgentHunt: 1` route to Microsoft Teams and destination-facing legs with `A365-AgentHunt: 0` route to the intended non-Teams destination. 3. Confirm EDR transfer scenarios route transfer-generated legs through Microsoft Teams first when `A365-IsRefer` is present. 4. Confirm a failed intercept path returns to the normal Microsoft Teams or ITSP route when Dialogue Cloud returns `SIP 408`. 5. Confirm the temporary-number migration test path reaches the production UCC configuration before any live-number cutover. ## Related topics Go to **Telephone Connection for Dialogue Cloud Neo (Connect)** for the OnePortal SBC configuration workflow and EDR enablement steps. {% content-ref url="/pages/P2EMkmV52Ncf5FcJC6rT" %} [Connect model: Direct Routing](/connect-telephony/direct-routing.md) {% endcontent-ref %} Go to **Direct Routing SBC configuration** for the secure trunk, routing-rule, and transfer-handling settings that support these scenarios. {% content-ref url="/pages/j7GEJKwhnmfP1eK6G9N6" %} [Configure the customer SBC for Direct Routing](/connect-telephony/direct-routing/direct-routing-sbc-configuration.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://atlas.anywhere.now/connect-telephony/direct-routing/direct-routing-routing-scenarios-and-testing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.