Branded Calling ID

Branded Calling ID™ (BCID) is the only industry-led, branded calling ID service that uses a standards-based Rich Call Data (RCD) ecosystem engineered to be secure-by-design and to deliver trusted, branded calls nationwide. BCID is an industry initiative facilitated by CTIA – The Wireless Association and its members, partners, and developers.

BCID™ is a service mark of CTIA — The Wireless Association. Sansay is an authorized BCID Signing Agent.

Sansay NSS with BCID

 Sansay NSS supports the BCID ecosystem in conjunction with STIR/SHAKEN. When it is tasked to sign a call, NSS checks if the caller matches vetted data in BCID. If it does, NSS proceeds to insert a rich call data claim inside the SHAKEN PASSPorT which may include a name, reason for call or a logo previously vetted by BCID.

In addition to call signing, NSS integrates with BCID Call Delivery Platform that helps correlate call signing and call delivery activity amongst participating Service Providers. 

BCID support has been added in version 5.5.596.x and later.

How It Works

 For simplicity we will define the BCID call process in two:

• BCID platform integration (A-D).
• Real-time call delivery (1-6).

BCID Platform Integration

• (A) An Originating Service Provider (OSP) works with BCID on-boarding and vetting agents to get enterprise customers and their brand and telephone numbers vetted.
• (B) Once the on-boarding and vetting process completes the enterprise and enterprise data is submitted to the BCID platform.
• (C) NSS periodically fetches vetted BCID data used for BCID call signing.
• (D) NSS obtains a STI certificate used for BCID call signing.

Real-time Call Delivery

1. An enterprise customer originates unsigned traffic to its provider (Originating Provider/OSP).
2. The OSP sends the query to NSS serving as the Signing Agent.
   1. NSS will compare the incoming query against BCID data.
      1. If there's a match will sign the call with BCID data and a SHAKEN PASSPorT with RCD.
      2. If there's no match will sign the call with local policies and a standard SHAKEN PASSPorT.
3. The OSP sends signed traffic with RCD claims within a SHAKEN PASSPorT.
4. The PASSPorT traverses the network and reaches a Terminating Service Provider (TSP) that honors the RCD claims.
5. The TSP supported devices display the RCD claims in the form of a Display Name, Reason for Call and/or Logo.
6. The TSP and OSP make use of BCID Platform Confirmation API to correlate call delivery.

Setup

1. Whitelist NSS IP to STI-PA staging and production environments.
2. Whitelist NSS IP to CTIA CA staging and production environments.
3. Whitelist NSS IP to BCID's staging and production environments.
4. Configure BCID signing agent user name and API auth token on the specific environment (staging or production).
5. Obtain BCID CA certificate.
6. Mapping specific enterprise customers (EID) with SBC trunks.

Testing and Troubleshooting

We maintain the first open STIR/SHAKEN testing ecosystem with support for BCID. By dialing one of our test numbers you can see STIR/SHAKEN and BCID results in real-time. Please visit our testing ecosystem at https://test-shaken.sansay.cloud

Our STIR/SHAKEN decoder is capable of rendering the logo if one is part of the STIR/SHAKEN PASSPorT.

Annex

Multiple Call Reasons

The BCID ecosystem allows for a telephone number (TN) to support up to 10 call reasons. This allows for a vetted enterprise to use a single TN for various reasons, for example:

• Upcoming Delivery
• Order Confirmation
• Snow Alert
• Technical Support
• School Closing Alert
• Agent Call Back

When a TN has been vetted for multiple call reasons, the selection is made on the signing query. If the query is using REST we have added support for the optional "crn" parameter. If the request matches a DRID CRN, then this call reason is selected.

REST:

curl https://192.168.10.165:3334/stir/v1/signing -k -s -X POST \ -H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d "{\"signingRequest\":{\"orig\":{\"tn\":\"$ani\"},\
"dest\":{\"tn\":[\"$dnis\"]},\"iat\":$nt,\
"otg\":\"50\",\"crn\":\"Technical Support\"}}

If the incoming request is SIP, selective call reason placed anywhere in SIP (header or SDP) thanks to SMC. The below example takes a SIP INVITE using IETF draft draft-ietf-sipcore-callinfo-rcd-06.

Note: We don't require the Call Reason to come in this format. This is one example how we can ingest CRN (call reason). 

Incoming INVITE:

Call-Info: <cid:12155551000@example.com>;purpose=jcard;call-reason= \
  "Technical Support"

NSS SMC Script:

{
    "ProfileID": 143,
    "ProfileName": "Call Reason",
    "Rules": [
        {
            "MsgType": "REQUEST",
            "ReqMethod": "INVITE",
            "StoredVariables": [
                {
                    "VariableName": "{$Call-Reason}",
                    "Header": "Call-Info:",
                    "HeaderAttr": "HEADER_SECTION_ONLY",
                    "RegEx1": "reason=[a-zA-Z \"-]+",
                    "RegEx2":"[a-zA-Z \"-]+"
                }
            ],
            "Conditions": [
                {
                    "Header": "Call-Info:",
                    "HeaderAttr": "HEADER_SECTION_ONLY",
                    "Operator": "NEQ",
                    "RightOperand": ""
                }
            ],
            "Action": "REPLACE_MSG",
            "ReplaceDefs":
[ { "ReplaceType": "ADD_LINE",
"Header": "From:",
"HeaderAttr": "HEADER_SECTION_ONLY",
"Output": "Sansay-SMC-{$SIP.Export}: CRN=\"{$Call-Reason}\"" } ] } ] }

OTG to EID Mapping

To prevent a situation where the incoming request has a matching TN in the BCID ecosystem but the incoming call does not belong to the vetted enterprise we have implemented OTG mapping. With OTG/EID mapping we take the BCID matching criteria one step further beyond the TN. 

Imagine the following scenario:

Your network has a few SBCs (SBC 1 and SBC 2). To only match Sansay, Inc's calls against BCID 14434453aabb1 vetted Enterprise ID with vetted TN records, NSS is configured to match on Sansay, Inc's Trunk Group and SBC (e.g. in case another enterprise on another SBC uses the same Trunk Group). This is found under STI-AS > BCIDOTG Mappings.

Frequently Asked Questions

Which mobile carriers are currently using BCID? 

While this landscape is rapidly changing at this time the list includes T-Mobile. Verizon is expected in Q1 2025. More carriers are in the works. We recommend checking directly with BCID on this topic, however.

What mobile devices support BCID?

BCID is based on standards-based Rich Call Data (RCD). RCD is supported on Apple iOS 17 and Android 13.

What's the cost per DID to include BCID information in the database?

The BCID ecosystem is structured in different roles:

1. On-Boarding Agents
2. Vetting Agents
3. Signing Agents
4. Originating Service Providers
5. Terminating Service Providers

As a Signing Agent we do not have a cost per DID or brand. Please consult with an On-Boarding Agent and Vetting Agent to understand the costs involved in getting your customers data vetted into the platform.  The list of Authorized Partners is in this link. 

How does BCID interact with our existing STIR/SHAKEN signing process? 

Any time a query arrives at NSS the query the following attributes will be used to sign the call:

• The originating switch/SBC
• The originating trunk-group (or other context conveyed in the query). This is optional but highly recommended.
• The originating TN (ANI).

With BCID enabled, we first check that the caller is authorized for BCID with the OTG EID Mapping described above. If it is we look for a match in the updated BCID data. If there's a match for the Enterprise and the Telephone Number the call is signed with the attributes provided by BCID.  If there's no match we sign the call as usual (without BCID) using standard SHAKEN policies.