> 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-sbc-configuration.md).

# Configure the customer SBC for Direct Routing

Configure the customer SBC for secure signaling, secure media, routing rules, transfer handling, and Dialogue Cloud SIP behavior.

Use this page to prepare the customer Session Border Controller (SBC) for a Connect model integration with Dialogue Cloud.

For the Direct Routing overview and OnePortal configuration workflow, see [Telephone Connection for Dialogue Cloud Neo (Connect)](/connect-telephony/direct-routing.md).

## Prerequisites

Before you change the customer SBC, confirm:

* the assigned Dialogue Cloud region, hostname, and firewall path are already confirmed
* Direct Routing already works between the customer SBC and Microsoft Teams Phone
* the customer SBC administrator can apply SIP, TLS, media, and routing-policy changes on the production trunk
* the transfer scenarios used by the business are known before cutover

## Secure the signalling path

### Use SIP over TLS

Dialogue Cloud recommends Transport Layer Security (TLS) for SIP signalling because the SBC connection crosses the public internet. Use TLS `1.2` or `1.3` on the SIP trunk.

### Confirm the certificate trust path

Use the current public certificate chain provided for the Dialogue Cloud SBC before you enable the secure trunk. Confirm the trust chain with your AnywhereNow representative if your SBC requires explicit root or intermediate import.

### Review cipher-profile expectations

Dialogue Cloud supports a default TLS profile and a stronger optional profile. If your customer security baseline requires stricter cipher handling, confirm compatibility for the selected SBC vendor and software release before go-live.

## Secure the media path

### Use SRTP

Dialogue Cloud recommends Secure Real-time Transport Protocol (SRTP) for media. Enable SRTP only when SIP over TLS is also active so the media-key exchange remains protected.

### Keep the preferred SRTP profile

Use the following SRTP behavior as the preferred Dialogue Cloud interoperability profile:

* `AES-CM-128-HMAC-SHA1-80`
* RTP authentication enabled
* RTCP encryption enabled
* `MKI` size `1`
* symmetric `MKI`
* no rekey on `REINVITE`
* no session-expiry rekey unless it is explicitly required

{% hint style="info" %}
Vendor implementations differ. Apply the closest equivalent settings your SBC platform supports while preserving the same security and media behavior.
{% endhint %}

## Keep codec and numbering rules aligned

### Codecs

Dialogue Cloud supports:

* `G711U` as the preferred codec in NORA
* `G711A` as the preferred codec in other regions

### Number format

Send voice-routing addresses in `+E.164` format. Extra URI parameters in the `To` or `From` values can lead to failed call handling.

If `user=phone` is present, keep the user part of the SIP URI as a real `+E.164` number.

## Build routing logic on the SBC

The customer SBC needs routing logic for:

* calls to UCC phone numbers
* inbound interception for selected agent phone numbers
* outbound interception for selected agent-originated calls

You can implement the routing logic with number-based rules, external lookup systems, or a route-to-Dialogue-Cloud-first pattern. Choose the routing model that fits the customer number plan and SBC platform.

{% hint style="warning" %}
For inbound interception, enable the interception decision only on the incoming ITSP or PBX trunks. This reduces the risk of routing loops.
{% endhint %}

## Support transfer handling with EDR

Enhanced Direct Routing (EDR) depends on Microsoft Teams transfer option `#2`, where the transfer request is delegated to the underlying SIP layer.

To support that model, the customer SBC should:

* forward SIP `REFER` requests toward Dialogue Cloud instead of handling them locally
* preserve the SIP `Allow` behavior that advertises `REFER`
* route Dialogue Cloud transfer-generated legs through Microsoft Teams first when the transfer marker is present

Dialogue Cloud marks transfer-generated call legs with the `A365-IsRefer` header. When that header is present, the SBC should route the new call leg to Microsoft Teams first.

## Preserve Dialogue Cloud SIP headers

Dialogue Cloud can add specific SIP headers that help the customer SBC decide how to route a call leg.

| Header                 | Use in this design                                                                                                      |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `X-MS-RoutingPolicies` | Preserve and forward this header toward Microsoft Teams so the forwarding decision can take effect for that call leg    |
| `A365-TenantId`        | Identifies the tenant on shared or partner-hosted trunks in multitenant designs                                         |
| `A365-IsRefer`         | Marks a call leg that resulted from a Microsoft Teams-initiated transfer and should route through Microsoft Teams first |
| `A365-AgentHunt`       | Distinguishes call legs that should route to Microsoft Teams from legs that should route elsewhere                      |

{% hint style="info" %}
For single-customer trunks, the main reader-facing headers are usually `X-MS-RoutingPolicies` and `A365-AgentHunt`. Multitenant and PSTN-agent scenarios may need additional SBC-specific exceptions.
{% endhint %}

## Preserve the remaining SIP and media constraints

Also apply these interoperability rules:

* `a=sendonly` and `a=inactive` can lead to different hold behavior
* DTMF should follow RFC2833 or RFC4833 with payload `101`
* early media is supported for `180 Ringing` and `183 Session Progress`
* `REPLACES` is not supported and can result in `SIP 420`
* bandwidth modifiers should be removed from SDP
* the customer SBC should continue generating RTCP even when the call is on hold

### User-Agent handling

Microsoft Teams-originated traffic may require an egress manipulation rule on the customer SBC if the forwarded `User-Agent` value still contains Microsoft PSTN hub details. Review that behavior before cutover if the Microsoft Teams leg is forwarded through the customer SBC toward Dialogue Cloud.

## Keep multitenancy scoped

Use `A365-TenantId` only as the tenant marker for multitenant partner trunks. Treat this as a specialized design rather than the default single-customer setup.

{% hint style="warning" %}
Multitenancy over one trunk is supported only within one region. If the partner serves multiple regions, configure a separate regional connection.
{% endhint %}

## Verification

1. Confirm the secure trunk uses the approved TLS version and trust chain for the assigned Dialogue Cloud endpoint.
2. Confirm the SBC media profile matches the required SRTP and codec expectations for the deployment region.
3. Confirm the SBC routes UCC, interception, and transfer call legs to the intended destination.
4. Confirm transfer scenarios work with SIP `REFER` forwarding and the transfer-routing rule for `A365-IsRefer`.
5. Confirm the SBC preserves or rewrites required SIP headers consistently during pilot testing.

## Related topics

Go to **Telephone Connection for Dialogue Cloud Neo (Connect)** for the OnePortal SBC configuration workflow and Enhanced Direct Routing (EDR) enablement steps.

{% content-ref url="/pages/P2EMkmV52Ncf5FcJC6rT" %}
[Connect model: Direct Routing](/connect-telephony/direct-routing.md)
{% endcontent-ref %}

Go to **Direct Routing network and firewall** for the regional endpoint, port, and allowlist planning that should be complete before SBC cutover.

{% content-ref url="/pages/FQvXNaSeZDyh1Bd5qvZd" %}
[Network and firewall](/connect-telephony/direct-routing/direct-routing-network-and-firewall.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-sbc-configuration.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.