The ongoing debate over call blocking notification rules

The FCC’s Fourth Order on robocalling required voice service providers that block calls to immediately notify callers of such blocking. The implementation deadline is January 2022. USTelecom filed a petition for reconsideration and clarification, and many interested parties have jumped into the fray. Here’s a recap.

The Fourth Report and Order was issued in December 2020 for CG Docket 17-59, Advanced Methods to Target and Eliminate Unlawful Robocalls.

For those keeping score, we counted nine filings in favor of delaying or rescinding the rule and five opposed. To be fair, some filed more than once. Of course, these things aren’t decided by ballot count, but it’s interesting to see who has weighed in with an opinion and what they’re saying.

Executive summary

We can summarize the arguments in favor of USTelecom’s position this way:

  1. The proposed notification rules aren’t approved ATIS standards yet.
  2. There are some difficult technical issues yet unresolved.
  3. They are more expensive and difficult to implement than the FCC realizes.

The arguments against delaying the rules and sticking with the requirements are:

  1. The IETF has approved these standards.
  2. The technical requirements aren’t that difficult.
  3. There should be a single, well defined notification method, not an obscure range of flexible methods.

We’ve briefly summarized the filings below. These summaries are listed in the order they were filed. You can click the filer name to view their filing.

computer displaying charts


  • Give service providers the flexibility to select the appropriate code or tool to notify callers that their calls have been blocked.
  • Confirm that service providers are only required to provide notification of blocking calls based on opt-in or opt-out analytics. Not things like DNO, TDoS, etc.
  • The fourth order requirement relies on unfinished standards.

Voice on the Net Coalition

  • VON members have been negatively impacted by call blocking.
  • Disagrees that finalized standards are necessary.
  • Response codes would not facilitate reverse engineering.

Ad Hoc Telecom Users Committee

  • Ad Hoc members have suffered a troubling increase in carrier blocking.
  • Carriers should clearly and consistently use a single, uniform notification method.
  • Flexibility as to the method of blocking notification will only increase confusion.
  • SIP 607/608 standards are not complex.
  • USTelecom provided no evidence that carriers will be unable to meet the January 2022 implementation date.
  • Ad Hoc disagrees that notification is necessary only when blocking based upon analytics. Callers should be notified no matter how or why the blocking occurs.


  • Notification should apply only to analytics-based blocking.
  • It would take more time to enable SIP response codes than the order allowed.
  • Lumen relies on vendors, who say that support for SIP 607/608 will be a major undertaking.

INCOMPAS, Cloud Communications Alliance

  • The Commission should not extend the deadline.
  • IETF standards for SIP 607 and SIP 608 have been approved.
  • SIP 603 signifies the call was declined, but not that the call was unwanted or blocked.
  • USTelecom should explain why use of jCards pose significant challenges for the use of SIP 608.

ABA Joint Trades

  • The Commission should continue to require SIP 607 or 608 and ISUP 21.
  • SIP codes 607 and 608 represent the consensus of the IETF community.
  • The Commission should direct the IP-NNI task force to approve the codes expeditiously.
  • The Commission should require further explanation from USTelecom about technical impediments to using jCards.
  • If the Commission gives additional time to implement the SIP codes, it should designate alternative interim forms of notification.

NCTA—The Internet & Television Association

  • Supports USTelecom’s petition.
  • Returning SIP 607/608 or ISUP 21 would cause real world problems.
  • SIP Codes are for signaling between carriers. They are not audio messages, and the standards do not require the provider play any message for any code.
  • Should not require sending immediate notification when the fraudulent nature of the call is virtually certain.


  • The Commission should grant the relief requested by USTelecom.
  • The rule would give robocallers a tool to bypass blocking.
    • The 608 specification recommends that service providers not send call info with a release code unless the calling party has been authenticated.
    • It also notes that if service providers include their contact info, malicious actors may launch a denial-of-service attack.
  • The Commission should not prescribe requirements that are unvetted or not accounted for in the standards.
  • The Commission should not include the jCARD in the mandate.


  • Supports the USTelecom petition for reconsideration.
  • Providers should not have to send notification when the calling number info is obviously fraudulent, e.g., DNO, unassigned.


  • Supports USTelecom’s petition.
  • A flexible approach would be more effective.

National Opinion Research Center

  • The Commission should not allow service providers sole discretion of how to notify callers that their calls were blocked.


  • Implementing SIP 607/608 will take significantly more time and investment than the Commission anticipated.
  • Software vendor told Lumen it would require a major software platform upgrade.
  • Standards for SIP 607/608 are not yet finished.
  • If the mandate requires extensive and costly modifications, then the Commission must provide a cost recovery mechanism.


  • Best way to achieve call blocking notification in the short term is to rely on SIP 603. It provides actionable information.
  • The Commission should clarify that blocking notification is only expected when calls are blocked based on analytics programs, not DNO, invalid, subscriber initiated lists, etc.

Transaction Network Services

  • Agrees with USTelecom that SIP 603 is the only way to implement call blocking notification in the near term. TNS and others are using it today.
  • Numerous technical and cost considerations impede the use of SIP 607 and SIP 608.
    • Some providers keep retrying after receiving a SIP 607.
    • SIP 608 provides an optional jCard. The standard is still a proposal. Legacy network elements don’t support it.
  • The Commission should clarify that providers need only send SIP 603 and defer SIP 607 and 608 requirements until standards have been finalized and the technical complexities addressed.

Our opinion

TransNexus has not filed comments with the Commission on this issue. However, we can offer a few impartial observations based upon our experience.

We think that fair points have been raised by advocates on both sides. The truth probably lies somewhere in between the views expressed above. Implementing SIP 607/608 is not as difficult or expensive as some have claimed, but it isn’t as easy as their adversaries would have you believe either.

Just handling the jCard integrity requirements makes these enhancements non-trivial. However, we’ve been here before. For example, integrity checks are part of the Rich Call Data framework. We know how this should work.

We also understand TNS’s observation that some network equipment and software does not respond properly to a SIP 607/608 and will keep retrying the call. We’ve even seen that happen with a SIP 603. The network software has to be configured properly. Will some network software require a major enhancement to handle this? We’ll let the network vendors answer that for their products.

We stand ready to help our customers implement these requirements whenever they might go into effect.

TransNexus solutions

We offer STIR/SHAKEN and robocall mitigation solutions in our ClearIP and NexOSS software platforms. We can make your STIR/SHAKEN deployment a smooth process.

In addition, we help service providers with all aspects of STIR/SHAKEN deployment, including registering with the Policy Administrator and filing their certification with the FCC.

Contact us today to learn more.

Request information

* required

This information will only be used to respond to your inquiry. TransNexus will not share your data with any third parties. We will retain your information for as long as needed to retain a record of your inquiry. For more information about how we use personal data, please see our privacy statement.