Will call blocking notification happen on January 1?

In their Fourth Report and Order on unlawful robocalls, the FCC requires Terminating Service Providers (TSPs) to provide callers with immediate notification of call blocking starting January 1, 2022. The Commission has received many requests to delay this rule. Some providers say they will stop blocking illegal robocalls if the rule goes into effect. What’s happening here? Let’s have a look.

The rules

Here’s a summary of the rules:

• TSPs must immediately notify callers of call blocking using either SIP 607 or SIP 608 in IP networks and ISUP 21 with cause location “user” in TDM networks.
• All providers in the call path must transmit these codes so that callers will receive them.

Details are in the Fourth Report and Order in the Matter of Advanced Methods to Target and Eliminate Unlawful Robocalls, CG Docket No. 17-59, paragraphs 52 and 56.

Blocking notification specifications

The Fourth Report and Order prescribes three methods for blocking notification. Here’s a brief explanation of each.

SIP 607 — called party rejects the call

SIP Code 607 is to be used when a called party indicates a call is unwanted. The SIP 607 response is initiated by the user agent, either in response to feedback from the called party or some user agent internal logic.

The SIP 607 response is more specific and less ambiguous than the existing SIP 603 response, which could be issued for a variety of reasons. Further, a SIP 603 may include a Retry-After header to indicate that the call was rejected for temporary reasons.

SIP 607 removes such ambiguity. The called party doesn’t want this call. Future attempts are likely to be rejected as well. Stop calling.

SIP 608 — analytics rejects the call

The motivation for creating a SIP 608 response is that, again, the SIP 603 response is too broad and ambiguous for call blocking notification.

Unlike SIP 607, however, SIP 608 indicates that an upstream intermediary rejected the call, before the call even reached the user. For example, the TSP could block a call based upon call analytics.

One of the goals in call blocking rules is to provide a way for a blocked caller to challenge the block so that errors can be corrected—a redress mechanism. Maybe the block was a mistake.

If the called party rejected the call, then the caller knows who to reach out to (although they may have to find another way to do that).

If an intermediary blocked the call, who does the caller reach out to? The caller has no way to figure that out.

To fill in this gap, the SIP 608 specification says the blocking intermediary must provide a Call-Info Header. This is how the blocking intermediary says, “I blocked this call. Here’s how you can reach me.”

The SIP 608 specification says that this Call Info Header is formatted as a jCard. Here’s what that looks like:

{ “alg”:”ES256”,
  “typ”:”vcard+json”,
  “x5u”:”https://certs.example.net/reject_key.cer”
}
{
  “iat”:1546008698,
  “jcard”:[“vcard”,
  [
    [“version”, {}, “text”, “4.0”],
    [“fn”, {}, “text”, “Robocall Adjudication”],
    [“email”, {“type”:”work”}, “text”, “remediation@blocker.example.net”]
  ]
 ]
}

We’ve highlighted the redress contact name and email address in this jCard.

This information would be encoded into base64url and signed with a private key to prevent tampering. The public key used to verify the signature is referenced in the x5u parameter, which identifies the certificate used to sign the Call Info Header.

Wait, where have we seen this before? That’s how SHAKEN works. Déjà vu all over again.

In summary, SIP 608 provides a blocking notice and adds contact info to facilitate redress. The contact info is signed with a digital signature to prevent tampering.

ISUP code 21

This ISUP code has multiple uses in TDM signaling. To help distinguish this use case for blocking notification, the FCC requires that the cause location be “user” when using ISUP code. (See footnote 133 to the Fourth Report and Order.)

The Commission also acknowledges that this method does not provide the same level of notification as the SIP 607/608 methods.

Use cases

The following chart shows how the different notification methods fit with their corresponding use cases. This illustrates when, where, and how these methods would be used.

Call Blocking Notification Decision Tree

Advocates against, and for

We’ll start with the arguments against the implementation deadline because they came first, then the proponents responded, followed by lots of filings back and forth.

Against

In May 2021, USTelecom filed a petition for reconsideration and request for clarification on this rule. They have followed up with several filings, which made the following points:

• The SIP 607/608 frameworks are not fully developed standards.
• Carriers may not be able to deploy these methods by January 1, 2022.
• Carriers should be allowed flexibility in blocking notifications.
• Notification should be required only when call analytics caused the block, not for calls that were blocked because of invalid/unassigned/Do Not Originate calls, etc.
• If the Commission requires these specific notifications be sent for blocked calls, then some carriers may have to stop blocking illegal robocalls.
• Let carriers use SIP 603 instead while these issues are addressed.

USTelecom has been joined in notices filed by AT&T, T-Mobile, Verizon, and others. Responses varied—some agreed with most issues raised by USTelecom, while others focused only on particular issues.

For

Several organizations representing the business community and high-volume callers have encouraged the Commission to proceed with the rules and deadline.

• If blocking notification is delayed, then blocking should be delayed too.
• Flexibility in notification would be unworkable. This should be standardized.
• The TRACED Act requires blocking notification.
• SIP 603, the proposed short-term alternative, is not up to the job. It doesn’t provide specific information available with SIP 607/608. It wasn’t designed for this.
• Using SIP 603 as a short-term alternative wouldn’t save time. Additional time would be required to piece together information available in SIP 607/608 but unavailable with SIP 603.
• Callers are suffering harm under the status quo.

Filers making these comments include the Voice on the Net Coalition, Ad Hoc Telecom Users Committee, INCOMPAS, BT Americas, Microsoft, Bandwidth, Telnyx, and the Cloud Communications Alliance.

Our view

This is an interesting standoff. Apparently, the FCC thought one year notice would be plenty of time to implement SIP 607/608. Either that is not the case, or perhaps opponents thought their objections would prevail and they wouldn’t have to build this capability anytime soon.

To be fair, we understand that developing and deploying substantial changes in a large Tier 1 network isn’t easy. Even if they floored the development gas pedal on January 1, 2020, would Tier 1 carriers have been able to roll this out in time?

The SIP 608 functionality is a lot like SHAKEN. That helps. But providers must also deal with switches and SBCs. Are those elements ready for this? And what about putting these features in TDM switches? How much time does that take? Are user agents capable of triggering a SIP 607 response? How does that work?

Advocates for the rule and deadline have a strong argument: The requirement is in the TRACED Act. We need this.

Opponents have an ominous reply: Well, then we’ll have to stop blocking illegal robocalls.

This will be interesting to watch.

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.

We also offer robocall mitigation solutions for non-U.S. service providers. These solutions will enable you to have your calls accepted by U.S. service providers in compliance with FCC rules.

Contact us today to learn more.