603+ FAQs

Q. The PeerEdge Orchestrator maintains a dynamic “Spam” list of numbers that is updated regularly by a reputation provider, would blocking incoming and/or outgoing calls involving numbers on that list be considered analytics-based blocking?

Yes, blocking calls based on a dynamic “Spam” list maintained by a reputation provider is considered analytics-based blocking.

Under the definitions and requirements established in the Eighth Report and Order (FCC 25-15) and associated technical standards, this scenario is governed by the following principles:

The technical standard ATIS-1000099 defines analytics as the analysis of a call request to determine how likely it is to be fraudulent or undesirable for reasons not specific to the intended recipient.

A reputation provider’s “Spam” list is the result of exactly this kind of analysis: assessing the likelihood that a valid number is being used for illegal, fraudulent, or otherwise unwanted purposes.

The FCC explicitly recognizes that service providers often meet their analytics and mitigation obligations through third-party vendors.

In its rules for the Robocall Mitigation Database (RMD), the Commission requires providers to describe the call analytics systems they use, including whether they rely on a third-party vendor and the identity of that vendor.

Accordingly, using a list supplied by an external reputation provider is a standard implementation of an analytics-based blocking program.

Because this is analytics-based blocking, the service provider would be required to use SIP code 603+ when rejecting these calls on IP networks.

Terminating providers must return SIP code 603+ so that callers are informed when and why their calls were rejected, which supports redress when blocking occurs in error.

The response must include:

It is important to distinguish a reputation-based “Spam” list from a Do-Not-Originate (DNO) list.

DNO lists are intended for numbers that should never originate calls, such as:

Blocking based on a DNO list is generally exempt from the 603+ notification requirement.

Spam lists generally apply to valid numbers that are behaving suspiciously based on behavioral or reputational analytics, such as:

Because these lists often involve valid NANP numbers, there is a greater risk of erroneous blocking. That is one reason the FCC requires the more transparent 603+ Network Blocked response for this category.

A dynamic “Spam” list maintained by a reputation provider would generally be treated as an analytics-based blocking mechanism. As a result, blocking based on that list would typically fall within the 603+ Network Blocked framework rather than the exceptions that apply to DNO-based or purely administrative blocking.

Q. If a service provider manually maintains a list of phone numbers that its customers are not permitted to use, and rejects a SIP INVITE whenever the customer’s ANI matches a number on that list, would that call flow be considered analytics-based blocking? If so, should the response be 603 Decline with a SIP Reason phrase of Network Blocked instead of 608 Rejected?

The described call flow—blocking calls based on a manually maintained list of prohibited ANIs—is likely not considered analytics-based blocking, and therefore SIP code 603+ should not be used.

The technical standard ATIS-1000099 defines Analytics as the analysis of a call request to determine how likely it is to be fraudulent or undesirable. This generally implies a dynamic evaluation of risk, rather than a simple binary check against a manually maintained list.

By contrast, your scenario is better characterized as TN Authorization and Screening, meaning:

The requirement to use SIP code 603+ with the reason phrase Network Blocked applies only when providers block calls based on analytics.

The FCC has clarified that immediate 603+ notification is not required when blocking occurs:

You noted that the current response is 608. The FCC has required providers to stop using 603 (standard version), 607, or 608 to indicate analytics-based blocking once they implement 603+.

However, because your use case appears to be a policy-based rejection rather than an analytics-based determination, using 603+ would not align with the ATIS-1000099 definition of analytics.

Likely no. It appears to be an administrative access control or screening function.

No. That code is intended only for calls blocked as a result of an analytical determination that the call is likely fraudulent or otherwise undesirable.

Because this appears to be a policy-based rejection, not analytics-based blocking:

A manually maintained prohibited-ANI list is best understood as an administrative screening mechanism, not an analytics engine. As a result, this call flow would generally not fall under the 603+ "Network Blocked" requirement.

If a service provider automatically builds a temporary “404 Not Found” list of numbers based on receiving SIP 404 responses from an upstream vendor, and removes numbers from that list after a defined period (for example, 30 days), would applying that list to a customer route plan be considered analytics-based blocking when the provider rejects the call locally with SIP 404 Not Found instead of attempting to forward the call upstream?

Based on the Eighth Report and Order (FCC 25-15) and the technical definitions in the standards, the scenario you described would likely not be considered analytics-based blocking. Instead, it would more likely be classified as blocking based on a reasonable Do-Not-Originate (DNO) list.

This distinction matters because it determines whether the provider is required to use the SIP 603+ Network Blocked notification.

The FCC’s requirements for a reasonable DNO list explicitly include categories of numbers that should not be originating calls because they are technically invalid or unassigned.

Your “404 Not Found” list aligns closely with two of those categories:

A SIP 404 response is an objective network signal that a number is currently non-existent or unused in the upstream network. Using that signal to populate a block list makes the list functionally similar to a DNO list.

The technical standard ATIS-1000099 defines Analytics as the analysis of a call request to determine how likely it is to be fraudulent or undesirable.

That generally implies a dynamic, multi-factor risk assessment, such as:

By contrast, your scenario is based on a single, binary network condition: receipt of a 404 Not Found response.

Although the list is managed automatically and entries expire after a defined time period, the basis for the block is still an objective network state, not a subjective or probabilistic determination that the call is likely fraudulent.

The FCC explicitly clarified that the mandatory requirement to use SIP code 603+ applies only when providers block calls based on analytics.

The Commission further stated that providers are not required to provide immediate 603+ notification when blocking is based on a DNO list.

No. It is better understood as an objective validity check used to populate a dynamic DNO-style list.

No. Because the block is based on a DNO-style list of invalid or unused numbers, it would generally fall outside the 603+ requirement.

Using SIP 404 Not Found as described appears consistent with the logic of the scenario. The sources also indicate that providers may continue to use the standard SIP code 603 with the reason phrase Decline where otherwise appropriate, so long as it is not being used to signal analytics-based blocking.

While blocking based on a Do-Not-Originate (DNO) list is technically ANI-based—because it checks the originating number in the SIP From header—it is conceptually tied to the DNIS because the list identifies numbers that are legitimate only when functioning as a destination.

In other words, the mechanism checks the ANI, but the reason the number is on the list is that it is supposed to be used only as a DNIS.

The main reason a number is placed on a DNO list is that it is designated as inbound-only.

In signaling terms, that means the number is intended to function only as a DNIS and should never appear as an ANI.

If a call arrives with an originating number that is designated as inbound-only, that strongly indicates illegal spoofing because there is no legitimate reason for that number to originate a call.

The FCC identifies several categories of numbers where the destination-only nature of the number is what justifies blocking when that number appears as the caller identity.

Examples include:

In each case, the number is blocked as an ANI because it is known to be valid only as a DNIS.

DNO blocking helps protect the integrity of numbering resources by ensuring that numbers assigned as destinations are not misused as spoofed originators.

By checking the ANI against a list of known destination-only numbers, providers can stop fraudulent traffic at the network edge before it reaches downstream consumers.

DNO blocking is:

So even though the network performs the check against the caller ID, the policy basis for the block comes from the fact that the number is only supposed to function as a DNIS.