# 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)](outbound-trunk-reference.html#outbound-trunk-cli-settings) and [Destination
dialing settings](outbound-trunk-reference.html#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](outbound-sip-information.html#services-voice-out-auth-realm) 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](mailto:support%40didww.com). |
| **Twilio Account SID** | Authenticates the trunk using its Twilio Account SID. | Available for the [Twilio integration](../../integrations/twilio/index.html). |
| **phone.systems(TM)** | Authenticates calls originating from a phone.systems(TM) 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](outbound-trunk-reference.html#outbound-trunk-create-authentication) for the
corresponding User Panel
fields and [Authentication flow](#authentication-flow) for the Credentials & IP-Based SIP Digest
exchange.
For detailed requirements and availability, see
[Authentication method values](outbound-trunk-reference.html#outbound-trunk-auth-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
IP-Only"]
T2["Trunk 2 - 203.0.113.0/24
IP-Only"]
T3["Trunk 3 - 203.0.113.5/32
Credentials & IP-Based"]
T4["Trunk 4 - 203.0.113.0/24
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
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](outbound-sip-information.html#services-voice-out-auth-realm). The full
digest exchange, including the
SIP headers involved, is shown in [Authentication flow](#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](#outbound-trunk-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: ;tag=as1fc3fe35
To:
Contact:
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: ;tag=as1fc3fe35
To:
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:
Record-Route:
Via: SIP/2.0/UDP 192.0.2.10:5060;received=192.0.2.10;branch=z9hG4bK48496580;rport=5060
From: ;tag=as1fc3fe35
To: ;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: ;tag=as1fc3fe35
To: ;tag=10-67E5E9A8-603FCD270008B2AB-ED917700
Contact:
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: ;tag=as1fc3fe35
To:
Contact:
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: ;tag=as1fc3fe35
To:
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](routing-dialing/call-flow-examples.html) 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](outbound-trunk-reference.html#outbound-trunk-cli-settings) | 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](outbound-trunk-reference.html#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](outbound-trunk-reference.html#outbound-trunk-limits-and-notification) | The number of simultaneous calls. | A new call cannot proceed when the configured capacity has been reached. |
| [24 hour limit (USD)](outbound-trunk-reference.html#outbound-trunk-limits-and-notification) | 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](outbound-trunk-reference.html#outbound-trunk-status-values) | 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](how-to-guides/enable-disable-outbound-trunk.html) 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](how-to-guides/view-outbound-trunk-credentials.html), or replace the
password using [Regenerate outbound trunk credentials](how-to-guides/regenerate-outbound-trunk-credentials.html).
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](outbound-sip-information.html#voice-out-network-transport).
### 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](outbound-trunk-reference.html#outbound-trunk-media-encryption-values) for reference
information and
[Outbound SIP encryption](outbound-sip-information.html#voice-out-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
- Configure [Allowed SIP IP addresses](outbound-trunk-reference.html#outbound-trunk-create-authentication) and [Allowed RTP IP
addresses](outbound-trunk-reference.html#outbound-trunk-create-authentication) with only the addresses
used by your equipment. Avoid allowing `0.0.0.0/0`.
- Keep PBXs, SBCs, firewalls, and routers updated with supported security
fixes.
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](outbound-trunk-reference.html#outbound-trunk-limits-and-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](../../logs-analytics/call-logs/outbound-logs.html#outbound-cdr-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](outbound-trunk-reference.html) for all configurable security fields and
available values.
On this page