# Outbound SIP information

Use this reference to configure SIP signaling, authentication, media, and
connectivity monitoring for DIDWW outbound trunks.

## Signaling endpoints

Calls can be sent to any of our load balancers. Each load balancer operates
as a redundant cluster with multiple nodes using the same IP address.

Use the hostname rather than the raw IP address if your equipment
supports [DNS SRV](#voice-out-dns-srv).

| Location | DNS A/AAAA record | LB IPv4 address | LB IPv6 address |
| --- | --- | --- | --- |
| New York | nyc.us.out.didww.com | 46.19.209.44 | 2a01:ad00:1:1::44 |
| Los Angeles | lac.us.out.didww.com | 46.19.212.54 | 2a01:ad00:4:2::54 |
| Miami | mia.us.out.didww.com | 46.19.213.54 | 2a01:ad00:5:2::54 |
| Frankfurt | fra.eu.out.didww.com | 46.19.210.19 | 2a01:ad00:2:1::19 |
| Amsterdam | ams.eu.out.didww.com | 185.238.173.44 | 2a01:ad00:8:1::44 |
| Singapore | sg.out.didww.com | 46.19.214.54 | 2a01:ad00:6:2::54 |
| Hong Kong | hk.out.didww.com | 46.19.215.44 | 2a01:ad00:7:1::44 |

## Supported network and transport protocols

| Transport protocol | Port |
| --- | --- |
| UDP | `5060` |
| TCP | `5060` |
| TLS | `5061` |

TLS encrypts SIP signaling, as described in [Supported encryption](#supported-encryption).

Both IPv4 and IPv6 network protocols are supported for SIP signaling and media communication.

## Digest authentication realm

DIDWW uses a fixed realm value for Digest authentication:

```
out.didww.com
```

This value applies to all signaling endpoints.

Note

This setting applies only to Digest authentication. Ensure your SIP
equipment uses `out.didww.com` when responding to authentication
challenges.

## DNS SRV

[DNS SRV](https://www.rfc-editor.org/rfc/rfc2782) is a failover
mechanism that reroutes calls to a backup data center if the primary one
becomes unreachable. We recommend enabling DNS SRV if your equipment
supports it, since it improves redundancy for call routing without
requiring manual failover.

The following table lists the target hostname for each DNS SRV record,
its priority, weight, resolved addresses, and role.

| DNS SRV record | Priority | Weight | LB IPv4 address | LB IPv6 address | LB location | Role |
| --- | --- | --- | --- | --- | --- | --- |
| nyc.us.out.didww.com | 10 | 10 | 46.19.209.44 | 2a01:ad00:1:1::44 | New York | Primary |
|  | 20 | 10 | 46.19.213.54 | 2a01:ad00:5:2::54 | Miami | Backup |
| lac.us.out.didww.com | 10 | 10 | 46.19.212.54 | 2a01:ad00:4:2::54 | Los Angeles | Primary |
|  | 20 | 10 | 46.19.213.54 | 2a01:ad00:5:2::54 | Miami | Backup |
| mia.us.out.didww.com | 10 | 10 | 46.19.213.54 | 2a01:ad00:5:2::54 | Miami | Primary |
|  | 20 | 10 | 46.19.209.44 | 2a01:ad00:1:1::44 | New York | Backup |
| fra.eu.out.didww.com | 10 | 10 | 46.19.210.19 | 2a01:ad00:2:1::19 | Frankfurt | Primary |
|  | 20 | 10 | 185.238.173.44 | 2a01:ad00:8:1::44 | Amsterdam | Backup |
| ams.eu.out.didww.com | 10 | 10 | 185.238.173.44 | 2a01:ad00:8:1::44 | Amsterdam | Primary |
|  | 20 | 10 | 46.19.210.19 | 2a01:ad00:2:1::19 | Frankfurt | Backup |
| sg.out.didww.com | 10 | 10 | 46.19.214.54 | 2a01:ad00:6:2::54 | Singapore | Primary |
|  | 20 | 10 | 46.19.215.44 | 2a01:ad00:7:1::44 | Hong Kong | Backup |
| hk.out.didww.com | 10 | 10 | 46.19.215.44 | 2a01:ad00:7:1::44 | Hong Kong | Primary |
|  | 20 | 10 | 46.19.214.54 | 2a01:ad00:6:2::54 | Singapore | Backup |

## BGP Anycast

DIDWW provides a [BGP Anycast](https://www.rfc-editor.org/rfc/rfc4786)
signaling endpoint at `any.out.didww.com` (`185.238.172.4`). The
anycast prefix `185.238.172.0/24` is announced from all DIDWW
[Points of Presence](../../presence/index.html#presence), and BGP automatically routes each
request to the nearest announcing PoP based on your network's routing
path.

Note

- The BGP-selected path is not guaranteed to provide the best latency or call quality. Test the anycast endpoint in your environment before using it in production.
- UDP is the recommended transport for `any.out.didww.com`.

## Network redundancy

DIDWW operates multiple Points of Presence, and each PoP is interconnected
with more than one termination carrier. If a PoP or a carrier interconnect
becomes unreachable, outbound traffic is diverted to a healthy PoP or
carrier without requiring changes on your side:

```
        %%{init: {
  "theme": "base",
  "themeVariables": {
    "fontSize": "14px",
    "primaryColor": "#e0f2fe",
    "primaryBorderColor": "#38bdf8",
    "primaryTextColor": "#1f2d3d",
    "secondaryColor": "#ccfbf1",
    "secondaryBorderColor": "#2dd4bf",
    "secondaryTextColor": "#1f2d3d",
    "tertiaryColor": "#fef3c7",
    "tertiaryBorderColor": "#facc15",
    "tertiaryTextColor": "#1f2d3d",
    "lineColor": "#0066cc",
    "textColor": "#1f2d3d",
    "nodeTextColor": "#1f2d3d",
    "titleColor": "#1f2d3d",
    "clusterBkg": "#f8fafc",
    "clusterBorder": "#cbd5e1",
    "edgeLabelBackground": "#ffffff"
  }
}}%%

flowchart LR
    subgraph endpoints["Your equipment"]
        E1["Endpoint A"]
        E2["Endpoint B"]
    end
    subgraph pops["DIDWW PoPs"]
        FRA["Frankfurt"]
        SG["Singapore"]
        LAX["Los Angeles"]
    end
    subgraph carriers["Termination carriers"]
        C1["Carrier A"]
        C2["Carrier B"]
    end
    E1 ==>|"Primary"| FRA
    E1 -.->|"Failover"| SG
    E1 -.->|"Failover"| LAX
    E2 ==>|"Primary"| SG
    E2 -.->|"Failover"| FRA
    E2 -.->|"Failover"| LAX
    FRA --> C1
    FRA --> C2
    SG --> C1
    SG --> C2
    LAX --> C1
    LAX --> C2

    classDef endpoint fill:#e0f2fe,stroke:#0066cc,color:#1f2d3d,stroke-width:1.5px
    classDef popNode fill:#ccfbf1,stroke:#2dd4bf,color:#1f2d3d,stroke-width:1.5px
    classDef carrier fill:#fef3c7,stroke:#facc15,color:#1f2d3d,stroke-width:1.5px

    class E1,E2 endpoint
    class FRA,SG,LAX popNode
    class C1,C2 carrier

    style endpoints fill:#f8fafc,stroke:#cbd5e1,color:#1f2d3d
    style pops fill:#f8fafc,stroke:#cbd5e1,color:#1f2d3d
    style carriers fill:#f8fafc,stroke:#cbd5e1,color:#1f2d3d

    linkStyle default stroke:#0066cc
```

Within a PoP, calls first reach a redundant pair of load balancers, which
distribute traffic across multiple Session Border Controller (SBC) nodes. A
failed load balancer or SBC node is removed from rotation while the
remaining nodes continue to handle calls:

```
        %%{init: {
  "theme": "base",
  "themeVariables": {
    "fontSize": "14px",
    "primaryColor": "#e0f2fe",
    "primaryBorderColor": "#38bdf8",
    "primaryTextColor": "#1f2d3d",
    "secondaryColor": "#ccfbf1",
    "secondaryBorderColor": "#2dd4bf",
    "secondaryTextColor": "#1f2d3d",
    "tertiaryColor": "#fef3c7",
    "tertiaryBorderColor": "#facc15",
    "tertiaryTextColor": "#1f2d3d",
    "lineColor": "#0066cc",
    "textColor": "#1f2d3d",
    "nodeTextColor": "#1f2d3d",
    "titleColor": "#1f2d3d",
    "clusterBkg": "#f8fafc",
    "clusterBorder": "#cbd5e1",
    "edgeLabelBackground": "#ffffff"
  }
}}%%

flowchart LR
    EP["Your endpoint"]
    subgraph pop["DIDWW PoP"]
        LB1["Load balancer 1"]
        LB2["Load balancer 2"]
        SBC1["SBC node 1"]
        SBC2["SBC node 2"]
        SBC3["SBC node 3"]
        LB1 --> SBC1
        LB1 --> SBC2
        LB1 --> SBC3
        LB2 --> SBC1
        LB2 --> SBC2
        LB2 --> SBC3
    end
    PSTN["PSTN"]
    EP --> LB1
    EP --> LB2
    SBC1 --> PSTN
    SBC2 --> PSTN
    SBC3 --> PSTN

    classDef endpoint fill:#e0f2fe,stroke:#0066cc,color:#1f2d3d,stroke-width:1.5px
    classDef balancer fill:#fef3c7,stroke:#facc15,color:#1f2d3d,stroke-width:1.5px
    classDef sbc fill:#ccfbf1,stroke:#2dd4bf,color:#1f2d3d,stroke-width:1.5px
    classDef result fill:#e0f2fe,stroke:#0066cc,color:#1f2d3d,stroke-width:1.5px

    class EP endpoint
    class LB1,LB2 balancer
    class SBC1,SBC2,SBC3 sbc
    class PSTN result

    style pop fill:#f8fafc,stroke:#cbd5e1,color:#1f2d3d

    linkStyle default stroke:#0066cc,stroke-width:1.5px
```

To take advantage of this redundancy, enable [DNS SRV](#voice-out-dns-srv) or use the [BGP
Anycast](#voice-out-bgp-anycast)
endpoint, and allow all signaling and RTP addresses listed under
[Signaling endpoints](#signaling-endpoints) on your firewall or SBC.

## RTP and RTCP information

IP subnets for RTP traffic:

> - `46.19.208.0/21`
> - `185.238.172.0/22`

RTP and RTCP port range:

> - RTP port range: `16383-32767`
> - RTCP (Real-time Transport Control Protocol) uses the RTP port + 1 for sending and receiving.

## Supported codecs

The following audio codecs are supported:

- G.711 (A-law / µ-law)
- G.729
- G.723.1
- GSM
- telephone-event (DTMF)

## Supported encryption

DIDWW supports TLS for secure SIP signaling transport and [SRTP](https://www.rfc-editor.org/rfc/rfc3711) for media
encryption.

Supported SRTP key negotiation mechanisms:

- [SDES](https://www.rfc-editor.org/rfc/rfc4568)
- [DTLS](https://www.rfc-editor.org/rfc/rfc5764)
- [ZRTP](https://www.rfc-editor.org/rfc/rfc6189)

Configure the required mechanism in the trunk's [Media encryption
mode](outbound-trunk-reference.html#outbound-trunk-media-encryption-values) setting.

Note

Encryption applies only to the DIDWW ↔ Customer call leg. Encryption
is not maintained end-to-end, and any other call legs outside this
connection are not encrypted.

## P-Charge-Info header

The `P-Charge-Info` header lets customers append additional technical
and billing-related information to Call Detail Records (CDRs). DIDWW's
implementation follows the [P-Charge-Info
Internet-Draft](https://datatracker.ietf.org/doc/html/draft-york-p-charge-info-08),
which expired without becoming an RFC. It remains the only published
specification for this header.

- The `P-Charge-Info` value is stored in the CDR for future reference.
- This data can be used for billing purposes and integrated with the
  [CDR Streaming Tool](../../call-events/termination-call-events.html#termination-call-events).
- The header value format is optional, allowing flexibility in
  implementation.

Note

If your system cannot insert the standard `P-Charge-Info` SIP header but
supports custom SIP headers, use the `X-Charge-Info` header instead.
DIDWW will process the header value and include it in the call's CDR data.

## SIP registration mechanism

SIP registration is supported for outbound trunks, but it is not required
for placing outbound calls. It is available for additional compatibility
with customer equipment.

Even when SIP registration is used, outbound
calls are routed according to the configured outbound trunk settings and
the signaling endpoint selected by the customer equipment.

The same [DIDWW Signaling Endpoints](#voice-out-signaling-endpoints)
act as SIP registrars.

Note

A single outbound trunk can have a maximum of 10 active registrations.
Additional registration attempts beyond this limit are rejected with
`500 Server Internal Error`.

## SIP OPTIONS

SIP OPTIONS requests are supported for connectivity monitoring. They
provide a lightweight way to check availability and reachability without
placing a call. We recommend using SIP OPTIONS to monitor connectivity
with DIDWW.

The same [DIDWW Signaling Endpoints](#voice-out-signaling-endpoints)
respond automatically to incoming OPTIONS requests.

## Machine-readable network data

A machine-readable version of this page's network data is available as JSON:

[voice.json](/voice.json)

Use it to programmatically configure and monitor firewall or SBC allowlists,
instead of parsing this page.

## Related resources

- [Authentication and security](authentication-security.html) - Understand the authentication and
  security model.
- [Outbound trunk reference](outbound-trunk-reference.html) - Look up trunk list fields, statuses,
  and configuration settings.
- [View outbound trunk credentials](how-to-guides/view-outbound-trunk-credentials.html) - Look up or
  regenerate trunk credentials.

On this page