Authentication and security#

Outbound SIP trunks are exposed to public networks and can be targeted by automated scans, credential attacks, and toll fraud. DIDWW combines authentication, address restrictions, service limits, and monitoring controls to reduce these risks.

How outbound trunk authentication works#

Authentication verifies which system sent a request. It is separate from authorization rules such as Allowed CLI(s) and Destination dialing settings, which control what an authenticated trunk can do.

DIDWW applies different authentication checks depending on the trunk’s configured method:

Method

Authentication checks

Availability

Credentials & IP-Based

Combines source IP validation with a SIP Digest challenge for the strongest supported authentication protection.

Default method, available through self-service configuration.

IP-Only

Validates the source IP address without a SIP Digest challenge.

Not available through self-service. Contact DIDWW Technical Support.

Twilio Account SID

Authenticates the trunk using its Twilio Account SID.

Available for the Twilio integration.

phone.systems™

Authenticates calls originating from a phone.systems™ Cloud PBX instance.

The system trunk is created automatically.

If a request fails the checks required by its trunk’s method, DIDWW rejects the call. See Authentication settings for the corresponding User Panel fields and Authentication flow for the Credentials & IP-Based SIP Digest exchange.

For detailed requirements and availability, see Authentication method values in the Outbound trunk reference.

Authentication priority#

When an account contains outbound trunks with overlapping Allowed SIP IP ranges, a single request can match more than one trunk. This can occur, for example, when one matching trunk uses IP-Only authentication and another uses Credentials & IP-Based authentication.

The applicable trunk is selected using two priority rules:

  1. Authentication method. IP-Only trunks are checked before Credentials & IP-Based trunks.

  2. IP address specificity. Within the same authentication method, the trunk with the narrowest matching Allowed SIP IP range is checked first. For example, /32 is more specific than /24.

The following example shows an INVITE from 203.0.113.5. This address matches both 203.0.113.5/32 and 203.0.113.0/24, so all four trunks are candidates:

        %%{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 SRC ["Incoming request"]
        REQ["INVITE from 203.0.113.5"]
    end

    subgraph TRUNKS ["Matching trunks"]
        T1["Trunk 1 - 203.0.113.5/32<br/>IP-Only"]
        T2["Trunk 2 - 203.0.113.0/24<br/>IP-Only"]
        T3["Trunk 3 - 203.0.113.5/32<br/>Credentials & IP-Based"]
        T4["Trunk 4 - 203.0.113.0/24<br/>Credentials & IP-Based"]
    end

    subgraph PRIORITY ["Authentication check order"]
        P1["1st"]
        P2["2nd"]
        P3["3rd"]
        P4["4th"]
    end

    subgraph RESULT ["Result"]
        A1["Trunk 1 selected<br/>INVITE sent downstream"]
    end

    classDef request fill:#e0f2fe,stroke:#0066cc,color:#1f2d3d,stroke-width:1.5px
    classDef trunk fill:#ccfbf1,stroke:#2dd4bf,color:#1f2d3d,stroke-width:1.5px
    classDef priority fill:#fef3c7,stroke:#facc15,color:#1f2d3d,stroke-width:1.5px
    classDef result fill:#ccfbf1,stroke:#2dd4bf,color:#1f2d3d,stroke-width:1.5px

    class REQ request
    class T1,T2,T3,T4 trunk
    class P1,P2,P3,P4 priority
    class A1 result

    REQ --> T1
    REQ --> T2
    REQ --> T3
    REQ --> T4

    T1 --> P1
    T2 --> P2
    T3 --> P3
    T4 --> P4

    P1 --> A1

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

The resulting check order is:

  1. Trunk 1 — IP-Only with 203.0.113.5/32.

  2. Trunk 2 — IP-Only with 203.0.113.0/24.

  3. Trunk 3 — Credentials & IP-Based with 203.0.113.5/32.

  4. Trunk 4 — Credentials & IP-Based with 203.0.113.0/24.

Authentication method takes precedence over IP address specificity. This is why Trunk 2, an IP-Only trunk with a /24 range, is checked before Trunk 3, a Credentials & IP-Based trunk with the narrower /32 range.

In this example, Trunk 1 is selected and its IP-Only authentication requirements are applied. Because the source IP address matches and no SIP Digest challenge is required, the INVITE is sent downstream.

Once a trunk is selected, that trunk’s authentication requirements are applied. If authentication fails, the request is rejected rather than passed to a lower-priority trunk.

SIP Digest authentication#

SIP Digest authentication verifies the trunk’s username and password before DIDWW accepts a request. It is used together with IP-based authentication for Credentials & IP-Based trunks, and skipped entirely for IP-Only trunks.

Trunks have unique usernames and passwords, so credentials generated for one trunk do not work on another. Your PBX, SBC, or SIP platform must present them in the SIP Authorization header when DIDWW challenges a request, using the fixed realm out.didww.com. The full digest exchange, including the SIP headers involved, is shown in Authentication flow below.

If a request has no credentials, incorrect credentials, or credentials for a different trunk, DIDWW does not accept the call. Credential lifecycle explains how credentials are generated, viewed, and replaced.

Authentication flow#

For Credentials & IP-Based trunks, the first INVITE is challenged. The call is accepted after the credentials are validated:

        %%{init: {
  "theme": "base",
  "themeVariables": {
    "fontSize": "14px",
    "actorBkg": "#e0f2fe",
    "actorBorder": "#38bdf8",
    "actorTextColor": "#1f2d3d",
    "actorLineColor": "#38bdf8",
    "signalColor": "#0066cc",
    "signalTextColor": "#1f2d3d",
    "noteBkgColor": "#fef3c7",
    "noteBorderColor": "#facc15",
    "noteTextColor": "#1f2d3d",
    "labelBoxBkgColor": "#ccfbf1",
    "labelBoxBorderColor": "#2dd4bf",
    "labelTextColor": "#1f2d3d",
    "loopTextColor": "#1f2d3d"
  }
}}%%
sequenceDiagram
    participant SYS as Customer SIP gateway
    participant SERVICE as Outbound SIP service

    SYS->>SERVICE: INVITE (no Authorization header)
    SERVICE-->>SYS: 401 Unauthorized (WWW-Authenticate, nonce)
    SYS->>SERVICE: ACK
    SYS->>SERVICE: INVITE with Authorization header
    SERVICE-->>SYS: 100 Trying, call proceeds
Full SIP message exchange

This example shows the SIP INVITE authentication flow from a customer gateway with IP address 192.0.2.10 to destination number 12025550199 with Caller ID 12025550100, for a Credentials & IP-Based trunk.

During the first step, the UAC sends an INVITE without an Authorization header:

192.0.2.10.5060 > 46.19.209.44.5060: SIP, length: 992
    INVITE sip:12025550199@out.didww.com SIP/2.0
    Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK48496580;rport
    Max-Forwards: 70
    From: <sip:12025550100@sbc.example.com>;tag=as1fc3fe35
    To: <sip:12025550199@out.didww.com>
    Contact: <sip:12025550100@192.0.2.10:5060>
    Call-ID: 479b59102ffeda0c04eed76d17304eb5@sbc.example.com
    CSeq: 102 INVITE
    User-Agent: customer-switch v1.22
    Date: Wed, 03 Mar 2021 17:53:43 GMT
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
    Supported: replaces, timer
    Content-Type: application/sdp
    Content-Length: 325

    v=0
    o=root 2120298149 2120298149 IN IP4 192.0.2.10
    s=customer-switch 1.22
    c=IN IP4 192.0.2.10
    t=0 0
    m=audio 12348 RTP/AVP 18 0 8 101
    a=rtpmap:18 G729/8000
    a=fmtp:18 annexb=no
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20
    a=maxptime:150
    a=sendrecv

46.19.209.44.5060 > 192.0.2.10.5060: SIP, length: 334
    SIP/2.0 100 Trying
    Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK48496580;rport=5060;received=192.0.2.10
    From: <sip:12025550100@sbc.example.com>;tag=as1fc3fe35
    To: <sip:12025550199@out.didww.com>
    Call-ID: 479b59102ffeda0c04eed76d17304eb5@sbc.example.com
    CSeq: 102 INVITE
    Server: Y balancing node
    Content-Length: 0

46.19.209.44.5060 > 192.0.2.10.5060: SIP, length: 609
    SIP/2.0 401 Unauthorized
    Record-Route: <sip:46.19.209.8;r2=on;lr;ftag=as1fc3fe35>
    Record-Route: <sip:46.19.209.44;r2=on;lr;ftag=as1fc3fe35>
    Via: SIP/2.0/UDP 192.0.2.10:5060;received=192.0.2.10;branch=z9hG4bK48496580;rport=5060
    From: <sip:12025550100@sbc.example.com>;tag=as1fc3fe35
    To: <sip:12025550199@out.didww.com>;tag=10-67E5E9A8-603FCD270008B2AB-ED917700
    Call-ID: 479b59102ffeda0c04eed76d17304eb5@sbc.example.com
    CSeq: 102 INVITE
    WWW-Authenticate: Digest realm="out.didww.com", qop="auth", nonce="603FCD4151d08b2d92526f23f65208788a5425a1"
    Server: DIDWW Y SBC node
    Content-Length: 0

192.0.2.10.5060 > 46.19.209.44.5060: SIP, length: 441
    ACK sip:12025550199@out.didww.com SIP/2.0
    Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK48496580;rport
    Max-Forwards: 70
    From: <sip:12025550100@sbc.example.com>;tag=as1fc3fe35
    To: <sip:12025550199@out.didww.com>;tag=10-67E5E9A8-603FCD270008B2AB-ED917700
    Contact: <sip:12025550100@192.0.2.10:5060>
    Call-ID: 479b59102ffeda0c04eed76d17304eb5@sbc.example.com
    CSeq: 102 ACK
    User-Agent: customer-switch v1.22
    Content-Length: 0

The outbound SIP service responds to the initial INVITE with 401 Unauthorized and returns a nonce value, 603FCD4151d08b2d92526f23f65208788a5425a1. The UAC uses this value to calculate the response in the Authorization header of the next request:

192.0.2.10.5060 > 46.19.209.44.5060: SIP, length: 1251
    INVITE sip:12025550199@out.didww.com SIP/2.0
    Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK34d0ea96;rport
    Max-Forwards: 70
    From: <sip:12025550100@sbc.example.com>;tag=as1fc3fe35
    To: <sip:12025550199@out.didww.com>
    Contact: <sip:12025550100@192.0.2.10:5060>
    Call-ID: 479b59102ffeda0c04eed76d17304eb5@sbc.example.com
    CSeq: 103 INVITE
    User-Agent: customer-switch v1.22
    Authorization: Digest username="WwAPO4asrLsk5Mhv", realm="out.didww.com", algorithm=MD5, uri="sip:12025550199@out.didww.com", nonce="603FCD4151d08b2d92526f23f65208788a5425a1", response="78381cc4a3258cc5418888988ad68552567", qop=auth, cnonce="58c9df37", nc=00000001
    Date: Wed, 03 Mar 2021 17:53:43 GMT
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
    Supported: replaces, timer
    Content-Type: application/sdp
    Content-Length: 325

    v=0
    o=root 2120298149 2120298150 IN IP4 192.0.2.10
    s=customer-switch 1.22
    c=IN IP4 192.0.2.10
    t=0 0
    m=audio 12348 RTP/AVP 18 0 8 101
    a=rtpmap:18 G729/8000
    a=fmtp:18 annexb=no
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=ptime:20
    a=maxptime:150
    a=sendrecv

46.19.209.44.5060 > 192.0.2.10.5060: SIP, length: 334
    SIP/2.0 100 Trying
    Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK34d0ea96;rport=5060;received=192.0.2.10
    From: <sip:12025550100@sbc.example.com>;tag=as1fc3fe35
    To: <sip:12025550199@out.didww.com>
    Call-ID: 479b59102ffeda0c04eed76d17304eb5@sbc.example.com
    CSeq: 103 INVITE
    Server: Y balancing node
    Content-Length: 0

The outbound SIP service checks the username and response values of the Authorization header against the trunk’s stored credentials and authenticates the INVITE once they match.

Note

IP-Only trunks do not use SIP Digest authentication, so the challenge and authenticated INVITE retry are skipped. Authentication succeeds when the source IP address matches an allowed SIP IP address. The request then proceeds to the remaining trunk checks.

See Call flow examples for step-by-step SIP message exchanges covering authentication, call establishment, and termination for both authentication methods.

Additional checks after authentication#

Successful authentication verifies the request source, but the call must still pass these authorization and operational controls:

Control

What it checks

Outcome

On CLI mismatch

Whether the Caller ID in the SIP From header matches a number allowed by the trunk.

Send Original CLI forwards a non-matching Caller ID unchanged. Reject Call stops the call.

Destination dialing settings

Whether the called country and number prefix are permitted.

Allow All blocks only the listed prefixes. Reject All permits only the listed prefixes.

Capacity limit

The number of simultaneous calls.

A new call cannot proceed when the configured capacity has been reached.

24 hour limit (USD)

The accumulated charges during the rolling 24-hour period.

Reaching the limit disables the trunk, blocks new calls, and disconnects active calls shortly afterward.

Status

Whether the trunk is enabled.

Enabled allows calls that pass the other checks. Disabled blocks new outbound calls. Use Enable or disable an outbound trunk to change its status without deleting its configuration.

Together, these controls provide protection beyond authentication. They restrict what an authenticated trunk is allowed to do, help prevent calls using unapproved Caller IDs or destinations, limit traffic and spending, and stop new calls when necessary.

Credential lifecycle#

Only Credentials & IP-Based trunks have SIP digest credentials. When you create one, DIDWW automatically generates a unique SIP digest username and password. View or reveal them using View outbound trunk credentials, or replace the password using Regenerate outbound trunk credentials.

Regenerating replaces the password. The username does not change. Once replaced, the previous password no longer authenticates new requests, so update every system that uses the trunk with the new password at the same time you regenerate it.

Signaling and media encryption#

Authentication and encryption are configured separately. The selected authentication method verifies the source of a request, but it does not encrypt SIP messages or call audio.

TLS signaling encryption#

To encrypt SIP signaling, configure your system to connect using TLS on port 5061. SIP over UDP or TCP on port 5060 is not encrypted.

TLS protects SIP messages exchanged between the outbound SIP service and your equipment. It does not encrypt RTP media or automatically enable media encryption. Port and transport details are covered in Network and transport protocols.

Media encryption modes#

To encrypt call audio, select an option under Media encryption mode when creating or editing the outbound trunk. Disabled is selected by default. Your PBX or SBC must support and use the mode selected for the trunk.

Option

Behavior

Disabled

Uses unencrypted RTP for call audio. TLS can still be used separately to encrypt SIP signaling.

SRTP SDES

Encrypts RTP media and carries the encryption key in the SDP body. Use TLS to protect the SIP signaling that contains the key.

SRTP DTLS

Encrypts RTP media and negotiates keys directly over the media path using DTLS. TLS must be configured separately if SIP signaling also needs to be encrypted.

ZRTP

Encrypts RTP media and negotiates keys directly between the media endpoints instead of carrying them in SIP signaling. TLS is not required for ZRTP key negotiation, but it is still needed when SIP signaling must also be encrypted.

Enabling media encryption does not automatically enable TLS signaling.

See Media encryption mode values for reference information and Outbound SIP encryption for the supported mechanisms.

Encryption applies only to the connection between the outbound SIP service and your equipment. It does not provide end-to-end encryption across every call leg.

Outbound trunk security best practices#

Use these recommendations to protect trunk credentials, prevent unauthorized calls, and reduce unexpected charges.

Important

Before carrying production traffic, restrict SIP and RTP source addresses, limit permitted destinations, and configure appropriate capacity and spending limits.

Restrict signaling and media access
Limit calling and financial exposure

  • Permit only the destinations required for normal traffic, and review the restrictions regularly.

  • Set capacity and rolling 24-hour spending limits appropriate for expected traffic.

  • Enable the Voice OUT Trunk usage limit notification to receive an email when usage reaches 80% of the 24-hour limit, no more than once every 12 hours.

Protect credentials and administrative access

  • Restrict administrative access to staff who need it.

  • Store trunk credentials in an approved secret-management system. Never place credentials in documentation, support tickets, chat messages, or screenshots.

  • Do not reuse credentials across unrelated systems or trunks.

  • Remove credential and administrative access when staff or vendors no longer need it.

Monitor and respond to suspicious activity

  • Monitor outbound call logs for unfamiliar destinations, unusual call volumes, and unexpected charges.

  • Regenerate the trunk password immediately after any suspected exposure.

  • Maintain an internal response process for suspected unauthorized calling or credential compromise.

See Outbound trunk reference for all configurable security fields and available values.