Call blocking notification issues

The FCC has asked for comments on immediate notification of call blocking. We’re hearing discussion of issues. In this article, we review the issues, questions, and answers.

First, let’s take a quick look at the two call blocking notification methods, SIP 607 and SIP 608. Figure 1 illustrates how and when each is used.

Figure 1: Call Blocking Notification Decision Tree

If the called person is responsible for blocking the call, the terminating provider would send a SIP 607. The caller could then contact the called party by some other means for redress.

If an intermediary (e.g., an analytics service or the terminating provider’s Call Validation Treatment) blocked the call, then the blocking entity would send a SIP 608 with a jCard. The caller could then reach out to the contact in the jCard for redress.

The FCC issued an Order on Reconsideration, which allowed providers to send SIP 603 Decline to satisfy the immediate call blocking notification.

In the same document, the Commission issued a Sixth Further Notice of Proposed Rulemaking (FNPRM) to ask questions and request feedback on the way forward.

Further Notice of Proposed Rulemaking

In the FNPRM, the FCC clarified their beliefs about immediate call blocking notification.

“[T]he design specifications for SIP Codes 607 and 608 provide important information that enables callers to contact blocking entities and initiate the redress process; such information is not contained in SIP Code 603.”

“We believe that these codes present the best long-term solution for immediate notification[…] We believe that the Commission should encourage standards-setting bodies to finalize their work and provide time for voice service providers to implement, test, and refine internal systems needed to return codes 607 and 608.”

Then the FNPRM asked for feedback:

• Comments on this belief?
• Whether and how to transition away from the use of SIP Code 603 for immediate notification?
• Does SIP Code 603 provide adequate information for callers?
• Does SIP Code 603 require additional modifications to make it useful for callers?
• Would such modifications eliminate any cost or times savings gained from allow its use?
• Would use of SIP 603 for such purposes undermine its value because its use is too varied?

Our thoughts

We think the authors of the SIP 607 and SIP 608 specifications knew what they were doing. They addressed legitimate issues in thoughtful ways. SIP 607 and 608 provide redress information that is not available when using SIP 603. If 603 were modified to make it suitable for immediate notification purposes, well, then we’d end with something a lot like SIP 607 and 608.

It comes down to timing and process for rolling out 607 and 608. How much time should that take? It might help to look at other questions circulating about the new standards, especially 608.

We have heard questions and discussion among industry insiders about deployment of immediate notification, especially SIP 608, which includes contact information in a jCard.

• Is SIP the right way to do this?
• Do SIP 6xx errors ever really reach the initiating party?

RFC 8688, A Session Initiation Protocol (SIP) Response Code for Rejected Calls, addressed these questions.

SIP 608 specifications

The specification explains that a sip.608 feature-capability indicator is put in the Feature-Caps header field of the INVITE request. Figure 2 illustrates a scenario where the originating service provider includes the sip.608 indicator in the INVITE. The terminating provider blocked the call using call analytics.

Figure 2: SIP 608 Sent Back the Call Path

When the blocking entity sees the sip.608 indicator, they must send a SIP 608.

If the INVITE doesn’t have a sip.608 indicator, then the blocker must convey the information some other way depending on the media type of the call. If it’s audio only, then generate an audio announcement to the caller. If the INVITE indicated real-time text, then the blocker would send the information in a text format.

What if the UAC doesn’t support SIP 608? Then the blocker would send the text or audio as appropriate.

What if the UAC doesn’t support SIP 608, but some intermediary along the call path does, and it added a sip.608 indicator to the INVITE? For example, figure 3 illustrates a scenario where the last intermediate provider before the terminating provider added a sip.608 indicator.

Figure 3: SIP 608 Along the Call Path with Media Notification

If this intermediary receives a SIP 608 response, it will correlate it with the original INVITE, see that it had added the sip.608 indicator, and this intermediary would convey the blocking notification in text or audio. The 608 would be sent too, but with no expectation that it would be used successfully.

We think these examples illustrate three things about the mechanics of immediate call notification with SIP 608:

1. Immediate notification seems simple enough at a high level, but when you get into the details, things can get tricky.
2. Those entities that told the FCC that it will take some time to implement SIP 608 support have valid concerns. There’s more to this than just generating a jCard.
3. The specifications were fairly in depth. Great effort was made to make them workable. But the devil is in the details. It seems reasonable to allow time for implementation and deployment.

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.

We provide an STI-CPS, the TransNexus CPS, which is available to any SHAKEN-authorized service provider free of charge. It’s part of the national network of STI-CPSs. We can also provide a private STI-CPS, either hosted or on-premises, to service providers.

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.