# SIP scanning and telephony denial of service

Canonical: https://warmtransfer.net/knowledge/sip-scanning-tdos

Last verified: 2026-09-25

Telephony denial of service (TDoS) encompasses attempts to make a telephone system unavailable to intended users by preventing incoming or outgoing calls[^23]. SIP scanning and flood attacks operate across signaling protocols to enumerate targets and exhaust processing capacity[^53][^47].

## Threat models: Scanning, SPIT, and TDoS

The FBI defines a TDoS attack as an attempt to make a telephone system unavailable to its intended users by preventing incoming and/or outgoing calls[^23]. The FBI distinguishes manual TDoS, organized through social networks, from automated TDoS, where software places tens or hundreds of calls simultaneously or in rapid succession, including over VoIP and SIP, often with spoofed caller information[^22]. The FBI PSA identifies hacktivism, financial extortion, and harassment as motives behind TDoS attacks on emergency call centers[^24]. When reporting these attacks, the FBI asks for incidents to be reported to IC3 or a local FBI field office using the keywords TDOS, PSAP, and Public Safety[^25].

In standard protocol terminology, RFC 5039 (Informational) defines SPIT as a bulk unsolicited set of session initiation attempts, such as INVITE requests, to set up voice, video, IM or other sessions[^49]. RFC 5039 judges SIP black lists to have limited effectiveness because an attacker can easily change or spoof identities[^48]. In core SIP signaling, RFC 3261 warns that a request with a forged Via header can redirect responses to a third party, and requests directed to multicast addresses can amplify traffic, creating vectors for denial of service[^47].

Enable Security states that SIPVicious OSS, first published in 2007, is also known as friendly-scanner[^52]. SIPVicious OSS includes svmap (locates SIP servers across IP ranges), svwar (enumerates active extensions), svcrack (cracks digest passwords on registrars and proxies), svreport (manages and exports session data), and svcrash (sends responses crafted to crash svwar and svcrack)[^53].

## Cisco CUBE and Local Gateway protections

Cisco Unified Border Element (CUBE) includes dedicated TDoS Attack Mitigation functionality to stop the platform from responding to out-of-dialog SIP requests arriving from untrusted IP addresses[^10]. CUBE treats addresses configured in the `ip address trusted list`, IP addresses defined in dial-peer `session target` statements, and server group members as trusted[^11]. By default, with `silent-discard untrusted` enabled, CUBE silently drops SIP requests from untrusted sources without returning a response[^9]. When configured solely for TDoS mitigation, CUBE does not respond to REGISTER requests and consumes them[^8]. CUBE's trusted-source validation applies only to out-of-dialog SIP requests; in-dialog requests are not validated against the trusted list[^7]. To monitor these drops, the `show sip-ua statistics` command reports a "Total untrusted Request Consumed" counter, which can be reset using `clear sip-ua statistics`[^12].

For traffic spikes and resource consumption, CUBE call spike detection monitors the call arrival rate over a moving window and rejects calls above a configured threshold, which Cisco states protects against INVITE-based DoS attacks[^2]. CUBE returns an error code when rejecting a call under call spike detection, and this error code is configurable[^1]. In addition, `call threshold global` can admit or reject calls based on `cpu-5sec`, `cpu-avg`, `io-mem`, `proc-mem`, `total-calls`, or `total-mem`, each controlled by low and high thresholds[^5].

Cisco's CUBE hardening guide outlines several recommendations:
- Configure an `ip address trusted list` so that only known peer IPs can place calls through CUBE[^21].
- Retain silent discard of untrusted requests enabled, using `no silent-discard untrusted` only when needed[^20].
- Avoid catch-all dial-peer patterns such as `destination-pattern.T` in favor of specific number ranges or SIP URIs[^17].
- Disable plain UDP and TCP SIP listening on port 5060 (`no transport udp`, `no transport tcp`) and implement TLS 1.2 instead[^18].
- Apply Layer 3/4 access control lists at interface entry points before CUBE processes traffic, alongside Zone-Based Firewall inspection[^16].
- Deploy DoS mitigation comprising a dedicated RTP port range, call admission control on calls, CPU, memory, and bandwidth, and call spike detection[^19].

On a Webex Calling Local Gateway, Cisco describes the IP address trusted list as the list of hosts and networks from which the gateway expects legitimate VoIP calls, and uses it to protect against toll fraud[^33]. A Webex Calling Local Gateway blocks incoming VoIP messages from untrusted sources by default, requiring administrators to explicitly add allowed subnets[^28]. This trusted list should contain regional Webex Calling data center ranges, Unified CM server addresses, and PSTN trunk gateway addresses[^32]. Webex Calling Local Gateway trunks use either registration-based authentication with digest credentials or certificate-based authentication using mutual TLS with a publicly signed certificate[^31]. Webex for Government supports only certificate-based Local Gateway trunks[^29].

## Oracle SBC DoS architecture

The Oracle Communications Session Border Controller (SBC) categorizes signaling traffic into trusted, untrusted, and denied paths, policing each trusted device flow within its own queue[^42]. Untrusted traffic shares 2048 fairly scheduled queues so that a flooding device impacts only its share of the untrusted population[^44]. 

The Oracle SBC promotes an untrusted endpoint to trusted following a successful SIP registration or an established call[^40]. Conversely, it demotes an endpoint to denied status when the source exceeds configured SIP transaction rate, call rate, or invalid-signaling thresholds, retaining it in the denied state until a configured `deny-period` expires[^37]. On hardware platforms, packets from denied sources are dropped by the network processor before reaching the host CPU[^38].

To avoid dropping all devices behind a shared gateway, the Oracle SBC can deny an individual source IP and port rather than the entire IP, blocking the complete NAT address only after a configured threshold of endpoints behind it are demoted[^39]. In high-trust realms or session agents, the `dos-action-at-session` feature monitors per-session floods from trusted endpoints and can demote the source or terminate the offending session[^41]. The SBC signals these states by raising `apDosThresholdCrossTrap` and `apDosThresholdClearTrap` SNMP traps when traffic crosses or clears minor, major, or critical thresholds, and displays the current state via `show dos threshold counters`[^43].

## Host-based log filtering and edge controls

The fail2ban Asterisk filter bans source IPs matching log entries for failed registrations from wrong passwords, username mismatches, missing matching peers, ACL failures, or "Rejecting unknown SIP connection" messages[^14]. It also matches Asterisk security events, including `InvalidAccountID`, `ChallengeResponseFailed`, `InvalidPassword`, and `FailedACL`, taking the remote IP from them[^15].

For challenge-response exchanges, RFC 3261 specifies that a user agent server challenges via a 401 response and a `WWW-Authenticate` header, whereas a proxy server challenges via a 407 response and a `Proxy-Authenticate` header[^45].

At public trunk terminations, Twilio Elastic SIP Trunking requires at least an IP access control list or a credential list, enforcing both when both are configured[^54]. Twilio strongly recommends configuring user credentials on SIP trunks because IP ACLs alone do not guard against specific attack variants[^55]. WarmTransfer's reading of the sources is that source-IP trust and digest or TLS credentials serve as complementary controls, though vendors differ on whether IP trust alone is sufficient: Cisco documents IP trust as its primary toll-fraud control, while Twilio notes that IP ACLs alone remain insufficient[^27].

## Cloud provider allowlisting and overload standards

Direct Routing SIP signaling FQDNs for Microsoft 365, Office 365, and GCC resolve to 52.112.0.0/14, 52.120.0.0/14, and the IPv6 block 2603:1063:400::/40[^35]. Microsoft specifies that firewalls must permit Direct Routing signaling to and from all listed Microsoft Teams IP ranges rather than only addresses resolved via DNS[^34]. Direct Routing signaling uses SIP over TLS, connecting to the Microsoft SIP proxy on port 5061, while the Microsoft proxy connects to the SBC on the SBC's configured port[^36]. WarmTransfer's reading of the sources is that because Direct Routing signaling originates solely from published Microsoft ranges across TLS, an SBC can drop inbound SIP traffic on its Teams-facing interface from other sources, although Microsoft does not explicitly frame this design as scanner mitigation[^26].

For cooperative rate reduction, RFC 7339 (Standards Track, September 2014) defines SIP overload control, in which a server uses the Via parameters `oc`, `oc-algo`, `oc-validity`, and `oc-seq` to tell upstream clients to cut traffic, with loss-based control as the default algorithm[^51]. WarmTransfer's reading of the sources is that because RFC 7339 overload control relies on cooperating clients, it addresses legitimate overload among trusted peers and does not provide an isolated defense against hostile floods that disregard signaling feedback[^50].

## See also

See also [Toll fraud prevention and voice security](https://warmtransfer.net/knowledge/voice-security-toll-fraud).
See also [SIP trunk carrier turn-up and acceptance testing](https://warmtransfer.net/knowledge/sip-trunk-carrier-turn-up).
See also [TLS certificates and secure SIP failures](https://warmtransfer.net/knowledge/sip-oauth-and-tls).

## Applicability

## What remains uncertain

Carrier-side TDoS mitigation (network call blocking and traffic scrubbing for enterprise and PSAP trunks) is not covered by the sources below. Webex Calling cloud-side ingress protection and rate limits for Local Gateway and BYO-PSTN traffic are not covered by the sources below. The exact SIP response code CUBE sends to untrusted sources with no silent-discard untrusted is not covered by the sources below. The role of STIR/SHAKEN attestation and traceback in identifying spoofed TDoS sources is not covered by the sources below. CUCM SIP trunk security profile digest authentication and incoming-port settings are not covered by the sources below. The content of CISA Cyber Risks to 911 TDoS fact sheet is not covered by the sources below.

## Sources

[^1]: CUBE sends an error code when a call spike rejects a call, and that error code is configurable. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Call Admission Control](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-call-admission-control.html), Call Admission Control > Configure CAC Based on Call Spike Detection. Checked 2026-09-25.
[^2]: CUBE call spike detection watches the call arrival rate over a moving window and rejects calls above the configured threshold, which Cisco says protects against INVITE-based DoS attacks. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Call Admission Control](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-call-admission-control.html), Call Admission Control > Configure CAC Based on Call Spike Detection. Checked 2026-09-25.
[^3]: CUBE call spike can be set globally or per dial-peer, and when both are set the dial-peer setting takes precedence. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Call Admission Control](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-call-admission-control.html), Call Admission Control > Configure CAC Based on Call Spike Detection. Checked 2026-09-25.
[^4]: CUBE call spike takes a call count from 1 to 2147483647, a step count from 3 to 10, and a step size from 100 to 250 milliseconds. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Call Admission Control](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-call-admission-control.html), Call Admission Control > Configure CAC Based on Call Spike Detection (command syntax). Checked 2026-09-25.
[^5]: CUBE call threshold global can admit or reject calls based on cpu-5sec, cpu-avg, io-mem, proc-mem, total-calls or total-mem, each with low and high thresholds. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - Call Admission Control](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-call-admission-control.html), Call Admission Control > Configure CAC Based on Total Calls, CPU or Memory. Checked 2026-09-25.
[^6]: When silent discard is disabled, CUBE answers untrusted SIP requests with a 4xx error response instead of dropping them; the specific 4xx code is not stated in the source as retrieved. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - TDoS Attack Mitigation](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-tdos-attack-mitigation.html), TDoS Attack Mitigation > feature overview. Checked 2026-09-25.
[^7]: CUBE's trusted-source check applies only to out-of-dialog SIP requests; in-dialog requests are not validated against the trusted list. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - TDoS Attack Mitigation](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-tdos-attack-mitigation.html), TDoS Attack Mitigation > Restrictions. Checked 2026-09-25.
[^8]: When CUBE is configured for TDoS mitigation only, it does not respond to REGISTER requests and consumes them. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - TDoS Attack Mitigation](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-tdos-attack-mitigation.html), TDoS Attack Mitigation > Restrictions. Checked 2026-09-25.
[^9]: By default (silent-discard untrusted enabled) CUBE silently drops SIP requests from untrusted sources without sending any response. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - TDoS Attack Mitigation](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-tdos-attack-mitigation.html), TDoS Attack Mitigation > silent-discard untrusted configuration. Checked 2026-09-25.
[^10]: The CUBE TDoS Attack Mitigation feature stops Cisco UBE from responding to out-of-dialog SIP requests that arrive from IP addresses that are not trusted. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - TDoS Attack Mitigation](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-tdos-attack-mitigation.html), TDoS Attack Mitigation > Information About TDoS Attack Mitigation. Checked 2026-09-25.
[^11]: CUBE treats as trusted the addresses in the ip address trusted list, the IP addresses in dial-peer session target statements, and server group members. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - TDoS Attack Mitigation](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-tdos-attack-mitigation.html), TDoS Attack Mitigation > Information About TDoS Attack Mitigation. Checked 2026-09-25.
[^12]: The show sip-ua statistics command on CUBE reports a 'Total untrusted Request Consumed' counter, and clear sip-ua statistics resets it. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - TDoS Attack Mitigation](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-tdos-attack-mitigation.html), TDoS Attack Mitigation > verification (show sip-ua statistics). Checked 2026-09-25.
[^13]: CUBE prints untrusted-request syslogs to the console every 60 minutes once a threshold of 1000 SIP requests is passed. Source: [Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 Onwards - TDoS Attack Mitigation](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-tdos-attack-mitigation.html), TDoS Attack Mitigation > syslog note. Checked 2026-09-25.
[^14]: The fail2ban Asterisk filter bans source IPs from Asterisk log lines such as failed registrations for wrong password, username mismatch, no matching peer, or ACL failures, and 'Rejecting unknown SIP connection'. Source: [fail2ban/config/filter.d/asterisk.conf](https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/asterisk.conf), config/filter.d/asterisk.conf, failregex lines. Checked 2026-09-25.
[^15]: The fail2ban Asterisk filter also matches Asterisk security events InvalidAccountID, ChallengeResponseFailed, InvalidPassword and FailedACL and takes the remote IP from them. Source: [fail2ban/config/filter.d/asterisk.conf](https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/asterisk.conf), config/filter.d/asterisk.conf, security event failregex. Checked 2026-09-25.
[^16]: Cisco's hardening guide recommends Layer 3/4 access control lists at interface entry points, applied before CUBE processes the traffic, plus the Zone-Based Firewall for inspection. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), Access control lists / Zone-Based Firewall sections. Checked 2026-09-25.
[^17]: Cisco's hardening guide warns against catch-all dial-peer patterns such as destination-pattern .T and recommends specific number ranges or SIP URIs instead. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), Call routing / toll fraud section (generic dial-peer patterns). Checked 2026-09-25.
[^18]: Cisco's hardening guide recommends turning off plain UDP and TCP SIP listening on port 5060 (no transport udp, no transport tcp) and using TLS 1.2 instead. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), SIP transport / TLS sections. Checked 2026-09-25.
[^19]: As DoS mitigation for CUBE, Cisco's hardening guide lists a dedicated RTP port range, call admission control on calls, CPU, memory and bandwidth, and call spike detection. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), Denial of service mitigation section. Checked 2026-09-25.
[^20]: Cisco's hardening guide advises keeping silent discard of untrusted requests enabled and using no silent-discard untrusted only when needed. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), Toll fraud prevention / silent discard section. Checked 2026-09-25.
[^21]: Cisco's CUBE hardening guide recommends an ip address trusted list so that only known peer IPs can place calls through CUBE. Source: [Cisco Guide to Harden Cisco Unified Border Element (CUBE) Enterprise Devices](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html), Toll fraud prevention / IP trusted list section. Checked 2026-09-25.
[^22]: The FBI distinguishes manual TDoS, organized through social networks, from automated TDoS, where software places tens or hundreds of calls at once or in rapid succession, including over VoIP and SIP, often with spoofed caller information. Source: [Telephony Denial of Service Attacks Can Disrupt Emergency Call Center Operations](https://www.ic3.gov/PSA/2021/PSA210217), PSA I-021721-PSA, description of manual and automated attacks. Checked 2026-09-25.
[^23]: The FBI defines a TDoS attack as an attempt to make a telephone system unavailable to its intended users by preventing incoming and/or outgoing calls. Source: [Telephony Denial of Service Attacks Can Disrupt Emergency Call Center Operations](https://www.ic3.gov/PSA/2021/PSA210217), PSA I-021721-PSA, opening section. Checked 2026-09-25.
[^24]: The FBI PSA names hacktivism, financial extortion and harassment as motives behind TDoS attacks on emergency call centers. Source: [Telephony Denial of Service Attacks Can Disrupt Emergency Call Center Operations](https://www.ic3.gov/PSA/2021/PSA210217), PSA I-021721-PSA, threat section. Checked 2026-09-25.
[^25]: The FBI asks for TDoS attacks to be reported to IC3 or a local FBI field office, using the keywords TDOS, PSAP and Public Safety in the complaint. Source: [Telephony Denial of Service Attacks Can Disrupt Emergency Call Center Operations](https://www.ic3.gov/PSA/2021/PSA210217), PSA I-021721-PSA, reporting section. Checked 2026-09-25.
[^26]: Because Direct Routing signaling comes only from published Microsoft ranges over TLS, a Direct Routing SBC can drop inbound SIP on the Teams-facing interface from any other source; the Microsoft page does not itself frame this as scanner protection (inferred). Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling: FQDNs; SIP signaling ports. Checked 2026-09-25.
[^27]: Source-IP trust (the CUBE trusted list, Oracle ACLs, Twilio IP ACLs) and digest or TLS credentials are complementary controls, and vendors differ on whether IP trust alone is enough: Cisco documents IP trust as its primary toll-fraud control, while Twilio warns that IP ACLs alone are insufficient (inferred). Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Termination Settings > Authentication. Checked 2026-09-25.
[^28]: By default a Webex Calling Local Gateway blocks incoming VoIP messages from untrusted sources, so the administrator must add allowed subnets explicitly. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Toll Fraud Prevention section. Checked 2026-09-25.
[^29]: Webex for Government supports only certificate-based Local Gateway trunks, not registration-based trunks. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Certificate-based trunk section (Webex for Government note). Checked 2026-09-25.
[^30]: Cisco notes that where a firewall with restricted cone NAT protects the Local Gateway, the trusted list may be disabled on the Webex-facing interface because the firewall provides the external protection. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Toll Fraud Prevention section (NAT note). Checked 2026-09-25.
[^31]: Webex Calling Local Gateway trunks are either registration-based (digest credentials, IOS XE 17.6.1a or later) or certificate-based (mutual TLS with a publicly signed certificate, IOS XE 17.9.1a or later). Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Registration-based vs certificate-based trunk prerequisites. Checked 2026-09-25.
[^32]: The Local Gateway trusted list should include the regional Webex Calling data center ranges, Unified CM server addresses, and PSTN trunk gateway addresses. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Toll Fraud Prevention section (ip address trusted list entries). Checked 2026-09-25.
[^33]: For a Webex Calling Local Gateway, Cisco describes the IP address trusted list as the list of hosts and networks from which the gateway expects legitimate VoIP calls, and uses it to protect against toll fraud. Source: [Configure Local Gateway on Cisco IOS XE for Webex Calling](https://help.webex.com/en-us/article/jr1i3r/Configure-Local-Gateway-on-Cisco-IOS-XE-for-Webex-Calling), Toll Fraud Prevention section. Checked 2026-09-25.
[^34]: Microsoft says to allow Direct Routing signaling to and from all the listed Microsoft Teams IP ranges, not only the addresses returned by DNS. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling: FQDNs > Important note. Checked 2026-09-25.
[^35]: Direct Routing SIP signaling FQDNs for Microsoft 365, Office 365 and GCC resolve to 52.112.0.0/14 and 52.120.0.0/14, and to 2603:1063:400::/40 for IPv6. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling: FQDNs. Checked 2026-09-25.
[^36]: Direct Routing signaling is SIP over TLS: the SBC connects to the Microsoft SIP proxy on port 5061, and the proxy connects to the SBC on the port configured on the SBC. Source: [Plan Direct Routing](https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan), SIP signaling ports table. Checked 2026-09-25.
[^37]: The Oracle SBC demotes an endpoint to denied when it exceeds configured SIP transaction rate, call rate or invalid-signaling thresholds, and lets it back when the deny-period expires. Source: [Denial of Service Protection (Oracle Communications Session Border Controller Configuration Guide, Release 9.2.0)](https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/denial-service-protection.html), Denial of Service Protection > demotion and deny-period. Checked 2026-09-25.
[^38]: On hardware Oracle SBCs, packets from denied sources are dropped by the network processor before they reach the host CPU. Source: [Denial of Service Protection (Oracle Communications Session Border Controller Configuration Guide, Release 9.2.0)](https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/denial-service-protection.html), Denial of Service Protection > denied path. Checked 2026-09-25.
[^39]: To limit collateral damage behind NAT, the Oracle SBC can deny a single source IP and port rather than the whole IP, and blocks the whole NAT address only after a configured number of devices behind it are demoted. Source: [Denial of Service Protection (Oracle Communications Session Border Controller Configuration Guide, Release 9.2.0)](https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/denial-service-protection.html), Denial of Service Protection > Dynamic Deny for NAT Devices. Checked 2026-09-25.
[^40]: The Oracle SBC promotes an untrusted endpoint to trusted after a successful SIP registration or a successfully established call. Source: [Denial of Service Protection (Oracle Communications Session Border Controller Configuration Guide, Release 9.2.0)](https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/denial-service-protection.html), Denial of Service Protection > traffic promotion. Checked 2026-09-25.
[^41]: For high-trust realms or session agents, the Oracle SBC dos-action-at-session feature detects per-session floods from trusted endpoints and can demote the source or tear down the offending session. Source: [Denial of Service Protection (Oracle Communications Session Border Controller Configuration Guide, Release 9.2.0)](https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/denial-service-protection.html), Denial of Service Protection > session-level DoS protection (dos-action-at-session). Checked 2026-09-25.
[^42]: The Oracle Communications SBC sorts signaling traffic into trusted, untrusted and denied paths, and polices each trusted device flow in its own queue. Source: [Denial of Service Protection (Oracle Communications Session Border Controller Configuration Guide, Release 9.2.0)](https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/denial-service-protection.html), Denial of Service Protection > trusted, untrusted and denied paths. Checked 2026-09-25.
[^43]: The Oracle SBC raises apDosThresholdCrossTrap and apDosThresholdClearTrap SNMP traps when traffic crosses or falls below minor, major or critical DoS thresholds, and show dos threshold counters displays the current level. Source: [Denial of Service Protection (Oracle Communications Session Border Controller Configuration Guide, Release 9.2.0)](https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/denial-service-protection.html), Denial of Service Protection > DoS threshold monitoring and alerts. Checked 2026-09-25.
[^44]: Oracle SBC untrusted traffic shares 2048 fairly scheduled queues, so a flooding device affects only its share of the untrusted population. Source: [Denial of Service Protection (Oracle Communications Session Border Controller Configuration Guide, Release 9.2.0)](https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/denial-service-protection.html), Denial of Service Protection > untrusted path / traffic manager. Checked 2026-09-25.
[^45]: In SIP digest authentication a user agent server challenges with 401 and a WWW-Authenticate header, while a proxy challenges with 407 and a Proxy-Authenticate header. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Sections 22.1 and 22.3. Checked 2026-09-25.
[^46]: RFC 3261 advises SIP elements to challenge questionable requests with a single 401 or 407 response and to behave statelessly toward unauthenticated requests to limit DoS exposure. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 26.3.2.4 Denial-of-Service Protection. Checked 2026-09-25.
[^47]: RFC 3261 warns that a SIP request with a forged Via header can make responses go to a third party, and that requests sent to multicast addresses can amplify traffic, both of which can be used for denial of service. Source: [RFC 3261 — SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261.html), Section 26.1.5 Denial of Service and Amplification. Checked 2026-09-25.
[^48]: RFC 5039 judges SIP black lists of limited effectiveness because an attacker can easily change or spoof identity. Source: [The Session Initiation Protocol (SIP) and Spam](https://www.rfc-editor.org/rfc/rfc5039.html), Section 3.2 Black Lists. Checked 2026-09-25.
[^49]: RFC 5039 (Informational) defines SPIT as a bulk unsolicited set of session initiation attempts, such as INVITE requests, to set up voice, video, IM or other sessions. Source: [The Session Initiation Protocol (SIP) and Spam](https://www.rfc-editor.org/rfc/rfc5039.html), Section 2 Problem Definition (call spam). Checked 2026-09-25.
[^50]: RFC 7339 overload control depends on cooperating upstream clients, so it helps against legitimate overload between trusted SIP servers and is not by itself a defense against a hostile flood from sources that ignore the feedback (inferred). Source: [RFC 7339: Session Initiation Protocol (SIP) Overload Control](https://www.rfc-editor.org/rfc/rfc7339.html), Section 11 Security Considerations; Section 5. Checked 2026-09-25.
[^51]: RFC 7339 (Standards Track, September 2014) defines SIP overload control, in which a server uses the Via parameters oc, oc-algo, oc-validity and oc-seq to tell upstream clients to cut traffic, with loss-based control as the default algorithm. Source: [RFC 7339: Session Initiation Protocol (SIP) Overload Control](https://www.rfc-editor.org/rfc/rfc7339.html), Sections 4, 5 and 7. Checked 2026-09-25.
[^52]: Enable Security says SIPVicious OSS, first published in 2007, is also known as friendly-scanner. Source: [SIPVicious OSS - open-source tools for testing VoIP security - Enable Security](https://www.enablesecurity.com/sipvicious/), SIPVicious OSS page, introduction. Checked 2026-09-25.
[^53]: SIPVicious OSS contains svmap (finds SIP servers across IP ranges), svwar (enumerates working extensions), svcrack (cracks digest passwords on registrars and proxies), svreport (manages and exports sessions) and svcrash (sends responses meant to crash svwar and svcrack). Source: [EnableSecurity/sipvicious: SIPVicious OSS is a set of security tools that can be used to audit SIP based VoIP systems](https://github.com/EnableSecurity/sipvicious), README tool list. Checked 2026-09-25.
[^54]: Twilio Elastic SIP Trunking requires at least an IP access control list or a credential list for termination, and enforces both when both are set. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Termination Settings > Authentication. Checked 2026-09-25.
[^55]: Twilio strongly recommends configuring user credentials on SIP trunks because IP ACLs alone do not protect against certain types of attack. Source: [Elastic SIP Trunking](https://www.twilio.com/docs/sip-trunking), Termination Settings > Authentication. Checked 2026-09-25.