A comparison of call blocking notification methods

There was an extensive discussion of call blocking notification in recent comments to the FCC on their Eight Further Notice of Proposed Rulemaking for robocalls. We thought it might be helpful to show examples of the two notification methods, SIP 603+ and SIP 608, to help readers understand how these methods differ.

The TRACED Act requires the FCC to establish rules for effective and transparent redress options for callers and consumers. The Commission responded with a rule that service providers send immediate call blocking notifications so that callers can contact the call blocking entity for redress. The rule was paused pending further discussion of notification methods.

Call scenario

We will compare call blocking notification methods for a call example in which the Bob Credit Union calls Alice, and Alice’s voice service provider blocks Bob Credit Union’s call using call analytics.

In the following examples, we will examine SIP message responses and highlight the portions of response messages that provide redress information.

SIP 603

Here’s a plain vanilla standard SIP 603 message sent by Alice’s voice service provider after blocking the call.

SIP/2.0 603 Decline
Via: SIP/2.0/TLS sip.clearip.com:5061;branch=z9hG4bK9be8.014bd7437c71ff56dac6cf4533a08eaa.0;i=02402fb6;received=::ffff:10.0.14.227
Via: SIP/2.0/TCP 172.29.0.9:3000;received=18.232.213.34;branch=z9hG4bK-24679-1-0
To: "Alice" <sip:+14045559876@1.2.3.4:5060>;tag=8942ca80-d650-4832-937c-49c8327a4d1e
From: "Bob Credit Union" <sip:+14045551234@172.29.0.224:3000>;tag=1
Call-ID: 1-25948@172.29.0.224
CSeq: 1 INVITE
Content-Length: 0

Notice that there’s no redress information. Therefore, this message would not satisfy either the TRACED Act redress requirements or the Commission’s intended rule.

SIP 603+

The following message follows the ATIS-1000099 standard for embedding redress information in a Reason header field of a SIP 603 message. It’s like the SIP 603 message above, except for the first line reason phrase and Reason header field.

SIP/2.0 603 Network Blocked
Via: SIP/2.0/TLS sip.clearip.com:5061;branch=z9hG4bK9be8.014bd7437c71ff56dac6cf4533a08eaa.0;i=02402fb6;received=::ffff:10.0.14.227
Via: SIP/2.0/TCP 172.29.0.9:3000;received=18.232.213.34;branch=z9hG4bK-24679-1-0
To: "Alice" <sip:+14045559876@1.2.3.4:5060>;tag=8942ca80-d650-4832-937c-49c8327a4d1e
From: "Bob Credit Union" <sip:+14045551234@172.29.0.224:3000>;tag=1
Call-ID: 1-25948@172.29.0.224
CSeq: 1 INVITE
Reason: SIP; cause=603; text="v=analytics1;email=remediation@example.com";location=RLN
Content-Length: 0

This example provides an email address, remediation@example.com. Therefore, this response would satisfy the TRACED Act requirements and Commission’s intended rule. It also provides a location code, RLN, to convey that call blocking occurred in the network serving the called party.

SIP 608

Here’s a SIP 608 message with a signed jCard that provides an email address for redress.

SIP/2.0 608 Rejected
Via: SIP/2.0/TLS sip.clearip.com:5061;branch=z9hG4bK9be8.014bd7437c71ff56dac6cf4533a08eaa.0;i=02402fb6;received=::ffff:10.0.14.227
Via: SIP/2.0/TCP 172.29.0.9:3000;received=18.232.213.34;branch=z9hG4bK-24679-1-0
From: "Bob Credit Union" <sip:+14045551234@172.29.0.224:3000>;tag=1
To: "Alice" <sip:+14045559876@1.2.3.4:5060>
Call-ID: 1-25948@172.29.0.224
CSeq: 1 INVITE
Call-Info: <https://example.com/complaint-jws-identifier>;purpose=jwscard

The URL in the Call-Info field links to a JSON Web Signature (JWS) generated for this blocking event and stored on a publicly-accessible server.

The JWS consists of a header and payload, which are Base64 encoded, and a digital signature generated from the encoded header and payload using a private key. Here is an example.

ewogICJhbGciOiAiRVMyNTYiLAogICJ0eXAiOiAidmNhcmQranNvbiIsCiAgIng1dSI6ICJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIgp9.ewogICJpYXQiOiAxNTQ2MDA4Njk4LAogICJqY2FyZCI6IFsKICAgICJ2Y2FyZCIsCiAgICBbCiAgICAgIFsKICAgICAgICAidmVyc2lvbiIsCiAgICAgICAge30sCiAgICAgICAgInRleHQiLAogICAgICAgICI0LjAiCiAgICAgIF0sCiAgICAgIFsKICAgICAgICAiZm4iLAogICAgICAgIHt9LAogICAgICAgICJ0ZXh0IiwKICAgICAgICAiUm9ib2NhbGwgQWRqdWRpY2F0aW9uIgogICAgICBdLAogICAgICBbCiAgICAgICAgImVtYWlsIiwKICAgICAgICB7CiAgICAgICAgICAidHlwZSI6ICJ3b3JrIgogICAgICAgIH0sCiAgICAgICAgInRleHQiLAogICAgICAgICJyZW1lZGlhdGlvbkBleGFtcGxlLmNvbSIKICAgICAgXQogICAgXQogIF0KfQ._V41ThRJ74MktxeLGaZQGAi.r8pcIvmB6OQEMgS4Ym7FPwGxm3tDUTRTpQ5X0relYset-EScb9otFNDxOCTjerg

Ok, any questions? Just kidding—here’s the decoded and formatted text.

{
 "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@example.com"]
  ]
 ]
}
r8pcIvmB6OQEMgS4Ym7FPwGxm3tDUTRTpQ5X0relYset-EScb9otFNDxOCTjerg

This SIP 608 example provides an email address in a jCard within the JWS payload. Therefore, this response would satisfy the TRACED Act requirements and the Commission’s intended rule.

Redress contact types

Both the SIP 603+ and SIP 608 standards require at least one redress contact type, although multiple contact types are allowed. The following table illustrates the contact types supported.

MethodSIP 603+ ExamplesSIP 608 Examples
Emailemail=remediation@example.com[“email”, {“type”:”work”}, “text”, “remediation@example.com”]
Telephonetel=+12155551212[“tel”, {“type”:”work”}, “uri”, “tel:+12155551212”]
Websiteurl=https://example.com[“url”, {“type”:”work”}, “text”, “https://example.com”]
Address(not supported)[“adr”, {“type”:”work”}, “text”, [“Argument Clinic”, “12 Main St”,”Anytown”,”AP”,”000000”,”Somecountry”]]

Our thoughts

As you can see from these examples, the SIP 608 syntax is more complex and verbose. It uses a larger data model based on the vCard standard, which provides 38 contact properties. The SIP 608 standard requires that User Agent Clients must be prepared to receive a full jCard.

In contrast, the SIP 603+ data model requires only three parameters: cause, text, and location. The text parameter defines five attribute-value pairs, and only two are required. SIP 603+ provides everything a caller would need to initiate redress and uses a design that’s much simpler and easier to implement. Sometimes less is more.

The SIP 603+ method provides a powerful feature with no counterpart in the SIP 608 design: the text parameter provides an optional ID attribute-value pair. The blocking provider can put whatever they want in this field to help them identify the blocked call in case the caller contacts them for redress. This has the potential to speed up the redress process. Since the vCard standard provides 38 properties, there’s probably some property that could be used for this purpose. However, there is no standardized property for this use case as there is with the SIP 603+ method.

We think the examples above demonstrate that the SIP 603+ method is a simpler, more streamlined method of conveying redress information for call blocking notification than the SIP 608 method.

More information

less is more

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.