Think of a hotel front-desk phone system. The front desk (a Call Control Server) manages all the phone lines — it knows which lines are ringing, which are on hold, and which are active. The guest rooms (a Call Control Client) have a handset that can pick up a ringing line, ask to hold a call, or dial out — but the actual phone carrier is managed at the front desk.

In the Bluetooth world, your smartphone is the front desk (Server) and your wireless headset is the guest-room handset (Client). The “phone lines” are the bearer services (TBS/GTBS).

Before learning the profile itself, it is important to see where CCP fits in the overall Bluetooth architecture. CCP is an application-layer profile that relies on GATT for its transport. GATT in turn sits on top of ATT (Attribute Protocol), which runs on the BLE L2CAP layer.

CCP defines exactly two roles. Every device involved in a CCP interaction must play one of them.

CCP does not define the GATT characteristics directly — those are defined in a companion document called the Telephone Bearer Service (TBS) specification. CCP tells you which procedures to use and when; TBS tells you what the characteristics look like.

What Is a Bearer?

A bearer is a specific telephone channel. Your phone might have a cellular bearer (your SIM card) and a VoIP bearer (a WhatsApp/Teams call). Each bearer is an independent path for making calls.

The Client must implement a specific set of GATT sub-procedures. Think of these as the “vocabulary” the Client uses to talk to the Server. The table below summarises requirements (M = Mandatory, O = Optional, C = Conditional).

BlueZ — Enabling Notifications via gatttool

After discovering the CCCD handle for the Call State characteristic, enable notifications:

# Step 1: Connect to the CCP Server (smartphone / peripheral)
gatttool -b AA:BB:CC:DD:EE:FF -I

# Step 2: Inside gatttool interactive shell
[AA:BB:CC:DD:EE:FF][LE]> connect
Connection successful

# Step 3: Discover all primary services to find GTBS
[AA:BB:CC:DD:EE:FF][LE]> primary
# Look for GTBS UUID: 0x184C  (assigned number)
# Look for TBS  UUID: 0x184B

# Step 4: Discover characteristics within GTBS service handle range
[AA:BB:CC:DD:EE:FF][LE]> characteristics 0x0010 0x0040

# Step 5: Find the CCCD handle for Call State characteristic
# Call State char UUID = 0x2BBE
[AA:BB:CC:DD:EE:FF][LE]> char-desc 0x0020 0x0025
# Identify the descriptor handle (type = 0x2902 = CCCD)

# Step 6: Write 0x0100 to CCCD handle to enable notifications
[AA:BB:CC:DD:EE:FF][LE]> char-write-req 0x0024 0100
# Server will now push Call State updates whenever a call changes

BlueZ C — Reading a Characteristic Value (GLib/D-Bus pattern)

/*
 * Sketch: Read the Bearer Provider Name characteristic using BlueZ D-Bus API.
 * Real BlueZ GATT client code uses GDBus; this shows the logical flow.
 *
 * Characteristic UUID: Bearer Provider Name = 0x2BB3
 */

#include <gio/gio.h>
#include <stdio.h>

void read_bearer_provider_name(GDBusConnection *conn,
                               const char *char_path)
{
    GError  *err  = NULL;
    GVariant *ret = NULL;

    /* Call org.bluez.GattCharacteristic1.ReadValue */
    ret = g_dbus_connection_call_sync(
        conn,
        "org.bluez",           /* bus name   */
        char_path,             /* object path, e.g. /org/bluez/hci0/dev_AA_.../serviceXX/charYY */
        "org.bluez.GattCharacteristic1",
        "ReadValue",
        g_variant_new("(a{sv})", NULL),  /* options dict, empty */
        G_VARIANT_TYPE("(ay)"),          /* returns byte array  */
        G_DBUS_CALL_FLAGS_NONE,
        -1, NULL, &err);

    if (err) {
        g_printerr("ReadValue failed: %s\n", err->message);
        g_clear_error(&err);
        return;
    }

    GVariant *bytes_v;
    g_variant_get(ret, "(@ay)", &bytes_v);

    gsize len;
    const guint8 *data = g_variant_get_fixed_array(bytes_v, &len, 1);

    printf("Bearer Provider Name (%zu bytes): ", len);
    for (gsize i = 0; i < len; i++)
        printf("%c", (char)data[i]);   /* UTF-8 string */
    printf("\n");

    g_variant_unref(bytes_v);
    g_variant_unref(ret);
}

All characteristics are defined in the TBS specification, but CCP’s procedures revolve around them. Here is a quick reference of the key characteristics you will encounter as a developer.

Each call on a bearer has a state. The Call State characteristic encodes the current state of every active call. State changes are delivered to the Client via GATT notifications. Here are the fundamental call states:

Each entry in the Call State characteristic contains three fields: Call_Index (1 byte, unique ID for the call), Call_State (1 byte, the state enum above), and Call_Flags (1 byte, whether URI/name is withheld).

The Call Control Point (CCP) characteristic is the command channel. The Client writes an opcode plus parameters to this characteristic to perform a call action. The Server responds with a notification on the same characteristic (if the Client has enabled notifications on it).

BlueZ — Writing an Opcode to the Call Control Point

/*
 * Write "Terminate" opcode (0x01) for Call_Index 0x01
 * to the Call Control Point characteristic.
 *
 * Using gatttool command-line:
 *   char-write-req <handle> <value>
 *
 * Byte format: [opcode] [call_index]
 *              0x01     0x01
 */

/* ---- gatttool interactive session ---- */
// [AA:BB:CC:DD:EE:FF][LE]> char-write-req 0x0030 0101
// Characteristic value was written successfully
// notification handle = 0x0030 value: 01 01 00
//   ^-- Server responded: opcode=Accept(0x00?), index=0x01, result=Success(0x00)

/*
 * C snippet: write using BlueZ D-Bus GattCharacteristic1.WriteValue
 */
#include <gio/gio.h>

#define CCP_OPCODE_TERMINATE   0x01
#define CCP_OPCODE_ANSWER      0x00
#define CCP_OPCODE_LOCAL_HOLD  0x02
#define CCP_OPCODE_ORIGINATE   0x04

int ccp_write_opcode(GDBusConnection *conn,
                     const char *ccp_char_path,
                     guint8 opcode,
                     guint8 call_index)
{
    GError   *err = NULL;
    guint8    buf[2] = { opcode, call_index };
    GVariant *bytes  = g_variant_new_fixed_array(
                            G_VARIANT_TYPE_BYTE, buf, 2, 1);
    GVariant *opts   = g_variant_new("a{sv}", NULL);
    GVariant *params = g_variant_new("(@ay@a{sv})", bytes, opts);

    g_dbus_connection_call_sync(
        conn,
        "org.bluez",
        ccp_char_path,
        "org.bluez.GattCharacteristic1",
        "WriteValue",
        params,
        NULL,
        G_DBUS_CALL_FLAGS_NONE,
        -1, NULL, &err);

    if (err) {
        g_printerr("CCP WriteValue error: %s\n", err->message);
        g_clear_error(&err);
        return -1;
    }
    return 0;
}

/* Usage: terminate call index 1 */
// ccp_write_opcode(conn, "/org/bluez/.../char0030",
//                  CCP_OPCODE_TERMINATE, 0x01);

Many TBS/GTBS characteristics are notify-capable. The Client should subscribe to the ones it cares about so the Server can push updates without the Client polling. This is critical for real-time call management.

BlueZ — Receiving Notifications via bluetoothctl

# Using bluetoothctl (BlueZ 5.x) to monitor GATT notifications

$ bluetoothctl

# Scan and connect
[bluetooth]# scan on
[bluetooth]# connect AA:BB:CC:DD:EE:FF
[bluetooth]# menu gatt

# List attributes discovered after connection
[AA:BB:CC:DD:EE:FF]# list-attributes AA:BB:CC:DD:EE:FF

# Select the Call State characteristic
[AA:BB:CC:DD:EE:FF]# select-attribute /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF/service0010/char001e

# Enable notifications (writes 0x0100 to CCCD automatically)
[AA:BB:CC:DD:EE:FF:/service0010/char001e]# notify on

# Now incoming calls / state changes appear in the terminal:
# [CHG] Attribute /org/bluez/.../char001e Value:
#         01 01 00
#   Call_Index=0x01, Call_State=0x00 (INCOMING), Call_Flags=0x00

# Answer the call — write Accept opcode
[AA:BB:CC:DD:EE:FF:/service0010/char001e]# back
# Select the Call Control Point characteristic
[AA:BB:CC:DD:EE:FF]# select-attribute /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF/service0010/char0030
[AA:BB:CC:DD:EE:FF:/service0010/char0030]# write 0x00 0x01
# 0x00 = Accept opcode, 0x01 = Call_Index

Phone calls contain sensitive information. CCP enforces encryption and bonding. Here is what you need to know as a developer.

BlueZ — Setting Up Pairing and Bonding

# Enable Bluetooth agent for pairing
$ bluetoothctl
[bluetooth]# agent on
[bluetooth]# default-agent

# Set pairing capability: KeyboardDisplay for SSP/LE Secure Connections
[bluetooth]# power on
[bluetooth]# pairable on
[bluetooth]# scan on

# Once device appears:
[bluetooth]# pair AA:BB:CC:DD:EE:FF
# Confirm passkey / accept pairing request when prompted

# Trust the device so it auto-connects in future
[bluetooth]# trust AA:BB:CC:DD:EE:FF

# Verify security: check if link is encrypted
$ hcitool con
# Should show: <handle> AA:BB:CC:DD:EE:FF  type:LE  encrypted:yes

# In BlueZ source (C): enforce minimum security level before GATT operations
# bt_att_set_security(att, BT_SECURITY_MEDIUM);
# /* BT_SECURITY_MEDIUM = SM1 L2 = encrypted + bonded */

The Generic Access Profile (GAP) layer handles device discovery and connection setup. CCP has specific requirements at this layer.

Server (Peripheral) — Advertising

• 1
  Must use extended advertising PDUs (not legacy). Advertise in Limited or General Discoverable mode when looking for new connections.
• 2
  Should include Service UUID AD type containing TBS UUID (0x184B) and/or GTBS UUID (0x184C) so Clients can discover it efficiently.
• 3
  For bonded devices: use Directed Connectable mode or Undirected Connectable mode with an advertising filter to accept only the bonded peer.

Client (Central) — Connection

• 1
  Use Limited or General Discovery procedure to find the Server.
• 2
  Connect using any GAP connection procedure (Auto, General, Selective, or Direct).
• 3
  Negotiate a tight connection interval to reduce call control latency.

  Recommended Connection Interval: 10 ms – 30 ms

BlueZ — Requesting Connection Parameters

/*
 * Request a tighter connection interval after connecting.
 * Uses HCI LE Connection Update command via BlueZ socket API.
 * Values are in units of 1.25 ms.
 * 10 ms  = 0x0008  (8 * 1.25 = 10 ms)
 * 30 ms  = 0x0018  (24 * 1.25 = 30 ms)
 */

#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>

void request_ccp_connection_params(int hci_sock, uint16_t conn_handle)
{
    struct hci_request        rq  = { 0 };
    le_connection_update_cp   cp  = { 0 };
    uint8_t                   status;

    cp.handle           = htobs(conn_handle);
    cp.min_interval     = htobs(0x0008); /* 10 ms  */
    cp.max_interval     = htobs(0x0018); /* 30 ms  */
    cp.latency          = htobs(0x0000); /* no slave latency */
    cp.supervision_timeout = htobs(0x01F4); /* 5 s   */
    cp.min_ce_length    = htobs(0x0000);
    cp.max_ce_length    = htobs(0x0000);

    rq.ogf    = OGF_LE_CTL;
    rq.ocf    = OCF_LE_CONN_UPDATE;
    rq.cparam = &cp;
    rq.clen   = LE_CONN_UPDATE_CP_SIZE;
    rq.rparam = &status;
    rq.rlen   = 1;

    if (hci_send_req(hci_sock, &rq, 2000) < 0)
        perror("hci_send_req LE_CONN_UPDATE failed");
}

Here is the full lifecycle from boot to an answered call, showing every layer of CCP working together.