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.
Method | SIP 603+ Examples | SIP 608 Examples |
---|---|---|
email=remediation@example.com | [“email”, {“type”:”work”}, “text”, “remediation@example.com”] | |
Telephone | tel=+12155551212 | [“tel”, {“type”:”work”}, “uri”, “tel:+12155551212”] |
Website | url=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
- The SIP 603+ standard: ATIS-1000099, Standard on Robocall Call Blocking Notification
- The SIP 608 standard: IETF RFC 8688, A Session Initiation Protocol (SIP) Response Code for Rejected Calls
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.
TransNexus has a comprehensive suite of robocall mitigation solutions to prevent the origination of unlawful robocalls.
Learn more about robocall mitigation