Reply comments on immediate blocking notification rules

Here’s the final round of reply comments to proposed rules for immediate call blocking notification. There are some much more substantive comments on both sides the issue in this round. Here’s a review and recap of themes.

The following ten reply comments documents were filed with 80 pages of remarks.

Recurring themes

Here are a few recurring themes that we noticed:

  • SIP 603 advocates no longer say that the current SIP 603 is adequate, but an enhanced version with a reason header would be adequate.
  • SIP 607/608 advocates say that transparency and redress required by the TRACED Act are not available now and can only be provided with SIP 607/608.

All of these comments are worth a look, but we want to draw your attention to a few noteworthy examples that vividly illuminate the issues at hand:

  • AT&T says they’re using an enhanced SIP 603 now.
  • Eliot Steele Robinson and TCN share their experiences in attempting redress for calls blocked in error.
    • Compare that to TNS, who sees almost no erroneous blocking of calls.
  • Verizon says the FCC would have to step in and guide the technical details for SIP 607/608 standards development.

Commenters are getting feisty! Ok, let’s have a look.


Here are quick summaries of each comment filing. You can read the entire filing by clicking the heading above each comment section.

AT&T Services, Inc.

  • AT&T has already added information to the SIP Code 603 reason header to provide actionable information to the calling party without causing an issue with network equipment.
  • The message AT&T has inserted into the SIP Code 603 reason header informs the caller that the call was blocked so the caller can seek redress, if necessary.
  • A standardized message in the reason header with SIP Code 603 can be implemented much quicker than SIP Codes 607/608 and with less disruption to the interoperable voice calling network.
  • SIP 607, used to indicate that the called party refused the call, is unnecessary and inappropriate.
    • Immediate notification requirement only applies to blocking by analytics.
    • SIP 607 raises privacy concerns.
  • SIP 603 with an industry standardized reason header should be sufficient. If not, the Commission should allow the ATIS/SIP Forum IP-NNI Task Force to finish its work.
    • AT&T does not oppose VON’s suggestion that standards should be finalized by December 31, 2022.

Eliot Steele Robinson doing business as Robinson Management Service (RMS)

  • RMS and its client were delayed by more than one month in identifying and correcting erroneous blocking because of woefully inadequate and inconsistent identification of why the calls were blocked and who blocked the calls.
  • Carriers and their vendors should at least send SIP 608 for automated call rejection.

National Opinion Research Center (NORC)

  • The TRACED Act requires that call blocking provide callers with transparency and effective redress options.
  • NORC is a high-volume caller and has had great difficulty identifying the carrier erroneously blocking calls using analytics.
  • SIP Codes 607 and 608 should be endorsed by the FCC as part of any continued communications service provider safe harbor for analytics-based call blocking.

NTCA—The Rural Broadband Association

  • The FCC should direct the industry to pursue in parallel enhancements to SIP 603 while standards work on SIP 607/608 continues.
  • If SIP 603 enhancements are sufficient and easier, then it may present a better option.
  • Until it is known if SIP 603 enhancements are a workable option, the Commission shouldn’t put all its eggs in one basket.
  • The Commission should set a deadline for resolution of this issue.
group discussion

Shockey Consulting LLC

  • SIP 603 can, with modest enhancements, fulfill the role the FCC requires without overly burdening telephone companies.
  • SIP 607/608 are not ready for use.
  • Existing networks would accommodate the expanded use of SIP 603, while SIP 607/608 are new and would require software updates.
  • Standards work on expanding SIP 603 would be substantially faster than the work required for SIP 607/608.

TCN Inc.

  • TCN encourages the Commission to require the use of SIP 607/608 as the only permanent solutions without delay.
  • Permanently permitting the use of SIP 603 would undermine the TRACED Act’s statutory requirement.
  • SIP 607/608 provide callers with the transparency and effective redress required by the TRACED Act.
  • SIP 603 is inadequate as a permanent solution
  • Each blocking event TCN has experiences has required 10–20 hours of investigation and outreach using service providers’ redress processes. In no instance did the voice service provider resolve the improper blocking issue. Current redress procedures are ineffective and fail to satisfy the TRACED Act’s and Commission’s requirements.

Transaction Network Services, Inc.

  • TNS urges the FCC to allow SIP 603 as alternative notification indefinitely.
  • SIP 603 can serve the purpose of call blocking notification and can better serve that purpose with enhancements.
  • Why mandate SIP 607/608 when SIP 603 can serve redress purposes just as well and in a manner that is easer to implement?
  • TNS sees almost no erroneous blocking of calls.
  • TNS found no current data in the FNPRM comments indicating that blocking of legitimate calls is a problem.

USTelecom - The Broadband Association

  • Most calls blocked with SIP 603 being retried likely were from illegal robocallers.
  • SIP 607/608 are new. Introducing these would be likely to have unintended consequences, particularly if the process is rushed due to an arbitrary deadline.
  • Responsible high-volume calling requires analyzing and investigating calls that do not get through.
  • Enhancements to SIP 603 would require standards work, but less time than operationalizing SIP 607/608.
  • Upgrading SBCs to pass enhanced SIP 603s would be faster and less costly than upgrading them to pass SIP 607/608.


  • The FCC should mandate SIP 603 as the industry-wide method for notification of analytics-based call blocking. SIP 603 should be the only notification method.
  • If the current SIP 603 is insufficient, network operators could use optional parameters already present in SIP 603 to develop standardized header and text for blocking notification. This would be faster than introducing SIP 607/608.
  • Verizon has not experienced problems with the volume of retries when it sends a SIP 603 response.
  • Verizon does not retry calls when a SIP 603 response is received.
  • “603 Plus” would be faster than SIP 607/608.
  • The FCC would have to guide the industry standards organization on the development of SIP 607/608.

Voice on the Net Coalition, INCOMPAS, Cloud Communications Alliance

  • SIP 603 is a general kill code and does not provide information necessary for redress.
  • Smaller enterprises do not have the resources to analyze SIP 603s. It’s an inefficient, Herculean effort.
  • Claims that SIP 603 is sufficient and contains the same information as SIP 607/608 are not supported by the facts.
  • ATIS should consider whether adding a jCard to SIP 608 would be troublesome. If so, then the FCC should confirm that only terminating service providers should send SIP 608. All terminating service providers that use SIP 608 without jCard should have their redress process included in the USTelecom Redress list.

TransNexus solutions

TransNexus is a leader in developing innovative software to manage and protect telecommunications networks. The company has over 20 years’ experience in providing telecom software solutions including toll fraud prevention, robocall mitigation and prevention, TDoS prevention, analytics, routing, billing support, STIR/SHAKEN and SHAKEN certificate services.

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.