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.

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.

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 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 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, 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 or use the BGP Anycast endpoint, and allow all signaling and RTP addresses listed under 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 for media encryption.

Supported SRTP key negotiation mechanisms:

• SDES

• DTLS

• ZRTP

Configure the required mechanism in the trunk’s Media encryption mode 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, 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.

• 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 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 respond automatically to incoming OPTIONS requests.

Related resources

• Authentication and security — Understand the authentication and security model.

• Outbound trunk reference — Look up trunk list fields, statuses, and configuration settings.

• View outbound trunk credentials — Look up or regenerate trunk credentials.