> 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/interceptor/configure-interceptor.md).

# Configure Interceptor

Prepare and validate Interceptor configuration for a Dialogue Cloud Neo (Connect) Direct Routing deployment.

Use this page to prepare Interceptor configuration changes for a Dialogue Cloud Neo (Connect) Direct Routing deployment.

Use this page to identify the Interceptor settings for inbound and outbound Direct Routing interception and to plan validation with the SBC and contact-center owners.

{% hint style="warning" %}
Before changing Interceptor settings for live numbers, coordinate the routing change with the SBC and contact-center owners. Validate the affected inbound and outbound call paths with pilot or test numbers before production.
{% endhint %}

## Prerequisites

Before you configure Interceptor, confirm that:

* The deployment uses Dialogue Cloud Neo (Connect) with Microsoft Direct Routing.
* The Direct Routing SBC configuration is active for the customer.
* The affected agent phone numbers and LineURI values are included in the Direct Routing design.
* The target Contact Center (UCC) and Service are identified.
* The customer scenario requires inbound interception, outbound interception, or both.
* A validation plan is agreed with the customer SBC administrator.

## Configuration workflow

Use the following workflow.

1. Identify the target Contact Center (UCC) and Service.
2. Confirm whether Interceptor is required for inbound direct calls, outbound direct calls, or both call paths.
3. Apply the Interceptor configuration settings for the required call paths.
4. Save the configuration after applying the required Interceptor settings.
5. Validate the inbound and outbound call paths with the customer SBC administrator before changing live production routing.

## Interceptor configuration settings

The following Interceptor configuration settings are used for Interceptor and recording scenarios.

{% hint style="warning" %}
Configure only the settings needed for the approved Interceptor scenario. Coordinate SBC and contact-center changes, and validate inbound and outbound call paths with pilot or test numbers before production.
{% endhint %}

| Interceptor setting               | Configuration purpose                                                                             | Planning guidance                                                                                                                                   |
| --------------------------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| `UseAudioRecording`               | Enables normal inbound Contact Center (UCC) recording.                                            | This is not an Interceptor requirement for regular inbound Contact Center calls. Keep detailed recording setup in the recording configuration area. |
| `EnableInboundInterception`       | Enables direct inbound or inbound-interception scenarios for direct calls to agents.              | Coordinate the inbound SBC routing change and validate the inbound pilot path before production.                                                    |
| `EnableOutboundInterception`      | Enables direct outbound or outbound-interception scenarios for direct calls from agents.          | Coordinate the outbound SBC routing change and validate the outbound pilot path before production.                                                  |
| `UseOriginalIdentityWithInbound`  | Preserves or shows the original caller identity toward the agent on inbound interception.         | Validate the caller identity shown to the agent as part of inbound pilot testing.                                                                   |
| `UseOriginalIdentityWithOutbound` | Affects which agent or caller identity is shown toward the called party on outbound interception. | Validate the caller identity shown to the called party as part of outbound pilot testing.                                                           |

## Recording impact

Interceptor changes can affect recording only for the call paths that use direct interception.

* **Normal inbound Contact Center (UCC) calls**: normal inbound Contact Center recording can be configured without Interceptor. `UseAudioRecording` is the configuration setting associated with this recording scenario.
* **Direct inbound calls to an agent**: direct inbound recording depends on inbound interception behavior. Plan this only when the scenario requires direct calls to an agent number to be routed through Dialogue Cloud before reaching the agent.
* **Direct outbound calls from an agent**: direct outbound recording depends on outbound interception behavior. Plan this only when the scenario requires direct calls from an agent number to be routed through Dialogue Cloud before reaching the external destination.

For the maintained recording configuration area, see [Manage Dialogue Cloud call recordings](/operate/recording-and-interaction-data/manage-call-recordings.md).

{% hint style="info" %}
Normal inbound Contact Center (UCC) recording can be configured without Interceptor; direct inbound and direct outbound agent call paths require interception behavior.
{% endhint %}

## Number manipulation

Interceptor can also affect the identity shown on direct inbound or outbound call legs when the original-identity behavior is enabled for the relevant direction.

* For inbound interception, `UseOriginalIdentityWithInbound` is the setting associated with preserving or showing the original caller identity toward the agent.
* For outbound interception, `UseOriginalIdentityWithOutbound` is the setting associated with which agent or caller identity is shown toward the called party.

{% hint style="warning" %}
Alternative Caller ID, CallOnBehalf endpoint behavior, and precedence between caller-ID sources are not covered by this page.
{% endhint %}

## Advanced inbound Direct Routing rerouting pattern

Inbound interception can be combined with routing-rule matching when a direct call to an agent should be handled by a Contact Center flow instead of reaching the agent directly.

Use this only as an advanced pattern. Configure the routing rule in the maintained routing-rule surface for the customer environment.

| Routing-rule element           | Pattern to confirm                                                                                                            |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| Interception dependency        | Inbound interception is enabled for the affected Contact Center (UCC) and agent call path.                                    |
| Target or match-to condition   | Match the affected agent SIP address or LineURI, for example `<agent-sip-address>` or `<agent-line-uri>`.                     |
| Source or match-from condition | Match the caller pattern that should be rerouted, for example `<caller-number>`, `<country-prefix>`, or `<approved-pattern>`. |
| Routing action                 | Route the matched call to the maintained Question, Skill, queue, or IVR branch used by the customer routing model.            |

Build the caller match pattern for the customer numbering plan and test both callers that should match and callers that should not match before production use.

For maintained routing-rule behavior and pattern-matching guidance, see [Configure queue routing rules](/contact-center-configuration/queues/configure-queue-routing-rules.md).

## Validate inbound interception

For inbound interception, validate the call path with a test number or approved pilot number before changing live production routing.

1. Place a direct inbound test call to an affected agent number.
2. Confirm the customer SBC routes the intercepted call to Dialogue Cloud.
3. Confirm the call is returned toward the intended Microsoft Teams endpoint when the agent is eligible for interception.
4. Confirm the fallback route behaves as designed when the intercept path is not active.

For the Direct Routing call-flow details, see [Interception behavior](/connect-telephony/direct-routing/interceptor/interception-behavior.md).

## Validate outbound interception

For outbound interception, validate the call path with an approved pilot scenario.

1. Start an outbound call from an affected agent number.
2. Confirm the customer SBC routes the call to Dialogue Cloud.
3. Confirm Dialogue Cloud creates the destination-facing call leg through the SBC.
4. Confirm the fallback route behaves as designed when the intercept path is not active.

## Disable or roll back Interceptor

Disable or roll back Interceptor only during the agreed change window and after preserving the previous configuration values needed for rollback.

Before disabling Interceptor:

* confirm which inbound and outbound call paths will return to normal Direct Routing behavior
* agree the change window with the customer SBC administrator
* define the post-change test calls
* preserve the previous configuration values or change record required for rollback

After disabling Interceptor, repeat the inbound and outbound validation paths that apply to the customer design.

## Configuration details not covered here

This page does not publish a full field-level setup procedure, default values, validation rules, propagation or restart behavior, rename history, Alternative Caller ID or CallOnBehalf precedence, Snapper or WebAgent procedures, agent-to-agent behavior, reporting or wallboard behavior, diagnostics, or media. Use the dedicated product documentation or customer change process for those details when they are required.


---

# 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/interceptor/configure-interceptor.md?ask=<question>&goal=<user_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.
