OpenIMSD

Ringback tone

2026-05-14T12:42:00+02:00

Ringback tone

What is a ringback tone?

The ringback tone is a tone which originates from circuit switch old telephone lines to tell the caller that the phone of the callee is ringing.

It tells you when you call someone, that the phone at the other end is ringing. For mobile networks, the behaviour is as much other things, well defined, but complex.

While placing a VoLTE call, the ringback tone was missing on postmarketOS/Google Pixel 3a.

2G phone call / circuit-switched call

For 2G/GSM networks, it depends how the network is working and maybe even on the load of the network. Eeg. a phone is calling a land line, the network can decide to save radio resources, it can assign the phone the traffic channel for voice data (TCH) only after the other side accepted the call. However if it does this, there may some lost voice samples, because the network & phone needs some time to establish the traffic channel. In this case, the phone has to generate the ringback tone.

But if the network has enough resources, it may assign the phone the traffic channel for voice data early which improve the user experience, because there isn't the lost audio at the beginning.

4G phone call / VoLTE / packet-switched call

There are no traffic channel to save, but there is bandwidth, even a VoLTE calls uses only a little bit of bandwidth. VoLTE is based on SIP (Session Initiation Protocol). For SIP calls, the default case is the ringback tone generation is done on the phone. There is a special case, called early media, where the network will generate the ringback tone, but usually this is only used when giving you a custom ringback tone.

Qualcomm basebands

Back to OpenIMSd. When I started to do VoLTE calls with the Pixel 3a or Oneplus 6T, there were no ringback tone.

Qualcomm basebands has a special TLV for ringback tone generation in the voice call status messages, I've not yet tested the exact behaviour with 2G networks yet, but for 4G network, the baseband adds the TLV and tells the user space to generate the ringback tone.

Missing bits and peaces to get ringback tone generation for VoLTE calls

libqmi needs to decode the TLV, the QMI messages are already present, only this TLV wasn't known. I've created a merge request for libqmi to add it.

ModemManager needs to announce the local ringback via d-bus. Merge request for ModemManager

I'm using phosh with postmarketOS on the device, so gnome-calls is connecting to ModemManager to handle the voice calls. Thankfully there is already a ringback tone generation for SIP which I could use as well. Merge Request for gnome-calls

QCOM baseband profile manager

2026-01-26T23:42:00+01:00

QCOM baseband profile mangaer

I've written a profile manager for the QCOM baseband which talks to the PDC service.

The PDC is the persistent device configuration. It controls similar settings as the carrier configuration on Android, such as the APN, SMSC, the IMS functionality, the 5G functionality, ... But the PDC profiles have more control over the baseband than the Android carrier configuration does.

As far as I understand, those PDC profiles are loaded into the baseband also via the PDC, but are persistent and usually updated via Android system updates. The PDC profiles are stored as foo.mbn files under various locations.

I wonder if it is possible to update the PDC profiles without an Android update. I would have expected an OTA mechanism which every other carrier/operator/provider can use. Maybe using OMA DM (Open Mobile Aliance Device Management). But so far I've not found any evidence for this.

The new qcom-baseband-profile-manager is a daemon which selects the "best" available profile for you without any user interaction. It is configured by a toml config file and selects the profile based on the simcard and the available profiles. It also notices if the simcard changes and selects a different profile based on it.

For further information see the README.md

There is also a binary repo for postmarketos containing the package until the packages are available in the package repositories of alpine and postmarketos.

The APKBUILD files are available at the alpine gitlab as a fork of aports and on the postmarketos gitlab as a fork of pmports.

How to install qcom-baseband-profile-manager

You can either use python tooling (pip/poetry) to install it from the repo. Or as alternative use alpine packages on a phone.

To use alpine packages download the binary repo onto the phone:

cd /root
git clone https://gitlab.postmarketos.org/modem/openimsd/apk-binary-repo
cp apk-binary-repo/keys/pmos@local-692c9b1e.rsa.pub /etc/apk/keys/
apk apk-binary-repo/edge/aarch64/{py3-gsm0338,py3-osmocom,py3-statemachine,py3-qcom-baseband-profile-manager}*.apk
# copy config from the repo
wget "https://gitlab.postmarketos.org/modem/openimsd/qcom-baseband-profile-manager/-/raw/main/pdc.toml?ref_type=heads&inline=false" -o /root/pdc.toml
qcom-baseband-profile-manager -d qrtr://0 -c /root/pdc.toml

How VoLTE is working

2025-10-20T23:42:00+02:00

How does VoLTE works on Qualcomm based SoC?

Introduction

Currently VoLTE isn't just working when your Qualcomm based smartphone is switch to LTE (at least for 95% of the phones). The data connection works just fine, but voice calls either doesn't work at all or your phone has to switch to 2G or 3G to do the voice calls.

To reverse engineer VoLTE on Qualcomm SoCs, I've used an OnePlus 6T as a target which is based on an Qualcomm SDM845. The OnePlus 6T has been released in 2018. I'll use LineageOS instead of the vendor-provided Android OS, because it makes it easier to get root access. Further it allows to get a newer Android version onto the device.

First of all, VoLTE works only when both Android and the baseband are working together. I'll use the term Android for software running on the APU (Application processor, the ARM processor) and baseband for the proprietary firmware running on the Hexagon DSP.

QMI

Most of the communication between the baseband and Android is done using QMI messages.

A short recap on QMI:

QMI has 3 types of messages:

Request
Response
Indication

Android does a request towards the baseband and it answers with a response. QMI has message ids to match a request to a response, allowing multiple requests and responses as the same time.

An indication is a message informing the Android side about a state change or an event. An incoming call is an indication. Also if the network cell changes, an indication is sent to the Android. Some indication are sent, without asking for, For others, a request must be used to enable them.

You could describe QMI with the common server/client model: The baseband is the server and Android the client.

If there would be only a single service on the baseband, the amount of message types would be huge. QMI offers multiple services instead. This also allows to have more contained code. The service for the UIM (sim card) doesn't have to know anything about the radio frequencies.

Android runs multiple daemons and each daemon can open a QMI connection to a service or to multiple services at the same time.

While libqmi supports many services, there are more. Also some OEMs may create additional vendor specific ones Here are the most important services:

CTL (Control), controls the QMI connections, used to establish a connection towards a service
DMS (Device Management Service), controls device power, e.g. airplane mode
NAS (Network Access Service), access and selection of the mobile network
UIM (User Identification Module), access to the sim card, enter the PIN
WDS (Wireless Data Service), manage the data session, create, close
WMS (Wireless Messaging Service), SMS, cell broadcast

If you know a public specification or documentation of QMI, please reach out to me.

IP multimedia subsystem / VoLTE

The IMS functionality of the baseband consists of multiple QMI services, in difference to the other logical functions, which are usually concentrated into a single service.

IMS Application (IMSA)
IMS Settings (called IMS by libqmi)
IMS Presence (IMSP)
IMS RTP (IMSRTP)
IMS DCM (IMSDCM)

The IMS application is at the top level view of the current state of the IMS. "Is the phone registered to VoLTE?"

The IMS settings service is the configuration endpoint, it allows settings many configurations options, from basic enable VoLTE, over codec, over handover and many more.

The IMS presence controls the SIP presence.

The IMS RTP service, RTP settings, but no data frames (as long as I've seen). I've not looked into this service more deeply.

The IMS DCM service, data control manager (not yet certain, what DCM stands for). But this is where many of the magic happens.

At the moment, I expect I've to use only IMS application, settings and DCM services to have a fully functional IMS service.

IMS DCM

The DCM service doesn't fit into the common case of the baseband being the server and Android being a client, because it's vice versa. Android is the server and the baseband the client!

The baseband requests a data session for the VoLTE traffic over the DCM service. Android will open a PDN session by talking again to the WDS service and responds back to the baseband.

Message sequence chart

There are a couple of unknown parts in there:

Why is the modem opening the IMS PDN (on the LTE) before the Start Network of the IMS daemon? Is there an unknown service? Or because of the PDC profile?
Why are there calls towards WDS and QOS to bind the subscription and set the mux? Maybe legacy API and modern API?
How does the IMSDCM daemon knows the IPv6 address? Does it sent the IPv6 RS and handles the RA (IP selection)?
The IMSDCM sends back PDP Connection Id 0x14. Is this local generated by the IMSDCM or has it something to do with the WDS connection id? But if it would be the WDS connection id, how does it know it?

Even with a couple unknowns left, I'm confident to have the required parts to implementing a daemon to talk to the IMS services.

What's next?

The next step is a PDC (Persistent Device Configuration) daemon, to select a baseband profile which supports IMS.

Afterwards I'll implement prototype openimsd prototype.

QMI trace of VoLTE registration

2025-10-18T16:00:00+02:00

TLDR; the trace

To document and improve the understanding of VoLTE, I've created pcap traces of the QMI message of the VoLTE registration.

The original pcap file has been created using a Oneplus 6T running lineageos/Android with a german 1&1 simcard of the brand maxxim, which uses the Vodafone network in Germany.

To capture the traffic I've used SCAT and qmi-frida-tracer.

SCAT is used to capture radio packets within the same trace, it both exports NAS-EPS (radio management), but also user traffic. It makes it easier to put QMI messages into relation with messages on the radio side and improve the understanding. E.g. a NAS-EPS or SIP message trigger an event on the QMI side. Also if a QMI TLV is unknown, we might use the radio message to decipher it.

qmi-frida-tracer was ran against the following daemons:

qcrild (first pid)
qcrild (second pid)
imsdatadaemon
imsqmidaemon

I've put the Oneplus 6T into an usb mode supporting all 3: diag,adb and rmnet.

rmnet is required to use qmicli later to set the correct PDC profile to allow the Android to register to VoLTE.

Test setup

The setup consist of 2x VMs:

1x VM where all the tools ran and the Oneplus 6T is connected (192.168.56.108)
1x VM where the traffic is captured and wireshark runs. (192.168.56.1)

Put the Oneplus 6T into the correct usb mode:

adb root; sleep 1; adb shell setprop sys.usb.config diag,serial_cdev,rmnet,adb

Running SCAT (git version 7eac9c5bea) with: scat -u -t qc -v 0x05c6 -p 0x9091 -i 0 -H 192.168.56.1

qmi-frida-trace to pass traffic to 192.168.56.1 (modify line where 127.0.0.1 is set as target):

./qmi-frida-tracer.py -n imsdatadaemon
./qmi-frida-tracer.py -n imsqmidaemon
./qmi-frida-tracer.py -p 1584 # first qcrild pid
./qmi-frida-tracer.py -p 1598 # second qcrild pid

Additional I'll set later a VoLTE capable PDC profile using qmicli -d /dev/cdc-wdm0 --pdc-activate-config=software,2F:1D:0C:4C:28:2D:50:FC:03:84:D8:9E:F3:92:81:C7:DB:A5:1A:7E.

Modification of the trace

For privacy reasons the pcap file which has been published here, has been filtered, but the essential parts are present. All packets which contain either the IMSI, IMEI, phone number or location have been removed. Further:

Service 0x44 was removed. The service is still unknown, but not suspected to interact with IMS (yet).
All radio packets (from SCAT) except a couple ones, have been removed, because most of them contains privacy related informations.
All data packets have been removed including SIP, RTP traffic, because those contains both the IMEI, phone number and called phone number.
The responses of the simcard (service: uim) to Read Transparent File or Read Record and request/responses of Send APDU.
NAS: Get Signal Info has been removed, because it clutters the pcap.
Voice service: Dial Call and All Call Status were removed, but no IMS specific parts.

To get the most use out of the pcap, please use the wireshark dissector embedded into the .tar.gz of the pcap.

wireshark -X lua_script:qmi_dissector_gen.lua -X lua_script:scat.lua ./trace_volte.pcapng

I've commented on a couple packets, there are some QMI messages which are unknown to libqmi, I've looked them up, but all aren't related. To most I've added comments to the packet in the pcap. I recommend adding the comment coloumn to the packet overview. It is possible to use the source port of the UDP/GSMTAP message to determine which process received or sent the QMI message.

From the traffic I deduct:

44303: imsdatadaemon
39675: qcrild (it could be also imsqmidaemon, but the traffic contains to much additional traffic)
58075: qcrild
49595: scat (radio packets)

The most interesting parts of the pcap are:

filter qmi.service_id == 0x0012 || qmi.service_id == 0x302 showing IMS subsystem traffic
filter udp.srcport == 44303 showing traffic of the imsdatadaemon

If you would like to know more about the pcap or have questions about the removed parts, you can reach us by the matrix channel #openimsd:postmarketos.org

Test report

All times in UTC:

10:48: Reboot phone
10:49: Put phone into airplane without simcard, enable adb root, switch mode to rmnet/qmi + diag + adb
10:49: start scat
10:50: attach frida to current rild processes
10:54: put simcard into the phone
11:01: enter required pin 4556
11:02: check if qcrild still have correct pids (sometime they change)
11:15: enable frida also for imsqmidaemon & imsdatadaemon
11:18: disable airplane
11:20: enable airplane
11:23: check if qcrild still have correct pids (sometime they change)
11:24: libqmi: set pdc profile, failed CID allocation failed. timed out
11:25: qmicli: pdc: exceute monitor-refresh, get software list, re-do libqmi set pdc profile again, works now
11:26: disable airplane
11:30: check VoLTE registration via phone info debug ui (*#*#4636#*#*), VoLTE registered!
11:39: calling another phone
11:42: get called by another phone
11:43: terminate call
11:44: enable airplane

wireshark filter

To filter for privacy I used the following chaos filter:

((frame.marked == true) || ((((!(qmi.service_id == 0x0047) ) && !( (qmi.message_id == 0x0039) && qmi.service_id == 0x0b)) && !((qmi.message_id == 0x0020) && (qmi.service_id == 0xb) && (qmi.trans_response == 1)) && !((qmi.message_id == 0x0021) && (qmi.service_id == 0x0b)  && (qmi.trans_response == 1)) && !((qmi.message_id == 0x0024) && (qmi.service_id == 0x02)  && (qmi.trans_response == 1))) && !lte_rrc &&  !((qmi.message_id == 0x0043) && (qmi.service_id == 0x03)  && (qmi.trans_response == 1)) &&  !((qmi.message_id == 0x004d || qmi.message_id == 0x00ac) && (qmi.service_id == 0x03)  && (qmi.trans_response == 1)) &&  !(((qmi.message_id == 0x0082) || (qmi.message_id == 0x00c3 || qmi.message_id == 0x004e || qmi.message_id == 0x0051) ) && (qmi.service_id == 0x03)  && (qmi.trans_indication == 1)) && ((qmi.message_id == 0x003b) && (qmi.service_id == 0x0b))  && !gsm_a.ccch  && !lte_rrc  && (!qmi.service_id ==0x44) && !evs && !amr && !udp.port == 47290 && !(ip.flags.mf == True) && !lte_rrc && !nas-eps))

The trace

VoLTE test setup

2025-09-09T16:00:00+02:00

To improve testing and developing with VoLTE and LTE, I've created a full VoLTE setup in a single VM including the EPC. The scripts to create the VM can be found on the gitlab of postmarketOS. A full debian image containing the network with PLMN 901/70 can be downloaded from the blog. Additional documentation is also available in the project repository.

Everything on the graph except the eNodeB is in the VM:

The setup is build with the following software components:

MME: open5gs-mmed
SGW: open5gs-sgwcd/sgwud
PGW: open5gs-amfd/upfd
HSS: pyhss
IMS: kamailio as p-cscf, i-cscf, s-cscf
PBX: asterisk
dns: dnsmasq to offer dns overrides
redis: pyhss internal communication
mariadb: pyhss & kamailio persistent db
pyhss-cli: a simple cli to manage pyhss subscribers

The VM network setup is:

first interface: dhcp client. This interface will be used to nat UE traffic and for the VM iteself.
second interface: RAN interface, to connect a eNodeB (static addresses, no dhcp)

If you've a good SDR and GPSDO available, you can also use srsRAN to create a eNodeB.

PyHSS and PyHSS cli

2025-09-09T14:59:00+02:00

One of the milestone of the journey to a good VoLTE support is a test setup containing a fully working LTE and VoLTE network.

While doing so, I've came across PyHSS, a 4G HSS (central database), which will be used in the test setup. However the problem of PyHSS is, there wasn't any good tooling to interact with. PyHSS itself offers a REST interface, but not cli. There is a webinterface written by zarya - pyhss-gui but it requires nodejs and couple of npm dependencies.

So I've started writing a minimal cli in python using click and httpx.

Even though PyHSS offers a swagger.json I went manual implemented those calls, because parsing the swagger.json also requires a lot of dependencies. Further only a couple API calls are needed to get basic subscriber management. The project can be found on https://codeberg.org/lynxis/PyHSS-cli

Activating Voice over LTE on Android

2025-06-22T01:23:00+02:00

While looking into VoLTE for Android, you find tons of manuals, how to enable it on a phone where it is disabled.

The main parts are:

enable root (depends, sometime optional)
enable QC diag on USB
use the PDC tool on a lapop to switch the profile (windows, QXDM tool)

This usually works until the next sim switch or sometimes reboot of the phone.

What is the PDC?

PDC stands for Persistent Device Configuration. libqmi already supports talking to the PDC.

But how does it work?

Since every HowTo tells activate QC Diag, it must depend on QC Diag. QC Diag seems a door to a world with thousands doors and services (like in the matrix).

I'm using a Oneplus 6t with LineageOS and root enabled for this. Enable diag via: adb root; sleep 1; adb shell setprop sys.usb.config diag,adb

Somehow it didn't worked directly. The QXDM tools connected to my device, but the PDC tool didn't.

Later I tried a different command: adb root; sleep 1; adb shell setprop sys.usb.config diag,serial_cdev,rmnet,adb

Now the PDC tools shows it, but it doesn't connect, but with this error:

So it is using QMI, but over Diag?

That's very interesting. It would be very helpful while developing to access the QMI port from the dev machine instead of going over the phone OS. Also it would allow accessing it while running Android to peek and poke around.

After a reboot of the phone, it started to work with this adb line adb shell setprop sys.usb.config diag,serial_cdev,rmnet,adb.

And shows all profiles.

So how does it work?

I have a USB sniffer around, a Cynthion (you could also use a Windows VM but since I've this tool around, I want to use it).

My Cynthion was already flashed with recent firmware. I use packetry to record the trace.

Paketry saves the trace as pcap and can be also used with wireshark.

While looking into it, I saw those frames in the usb output, with readable strings of the PDC profiles. My wireshark filter is just "usb".

In the lower corner, in the hexview you can find a name of a carrier profile: TGL_Comb_Attach-Lab-CMCC Now I'm looking into the whole USB packet.

Exporting the control USB packet from wireshark to look more into it.

01500080240104280028004400010200000010040026000000110400b86500001219001854474c5f436f6d625f4174746163682d4c61622d434d4343130400462001081404000000000016040046200108

014c008024010429002800400001020000001004002700000011040004b90000121500144e53494f545f566f4c54452d4c61622d434d4343130400552001081404000000000016040055200108

Now I'm trying to figure out, where the QMI header is in this packet start. Starting with the QMI header from libqmi/src/libqmi-glib/qmi-message.c (git rev: 22405e4c9e1d8f10748f085fc2ea4aa411cdd3aa).

struct full_message {
      guint8 marker;
      union {
          struct qmux_header qmux;
          struct qrtr_header qrtr;
      } header;
      union {
          struct control_message control;
          struct service_message service;
      } qmi;
} PACKED;

Replacing the unions by using QMUX and a service, because it must be a service. It could be also a QRTR message instead of QMUX, but I'll start trying to use QRTR. The struct will look:

struct full_message {
    guint8 marker;
    struct qmux_header {
        guint16 length;
        guint8 flags;
        guint8 service;
        guint8 client;
    }
    struct service_message {
        struct service_header {
            guint8 flags;
            guint16 transaction;
            guint16 message;
            guint16 tlv_length;
        }
        struct tlv tlv[];
    }
}

Taking the hex reprensentation:

01500080240104280028004400010200000010040026000000110400b86500001219001854474c5f436f6d625f4174746163682d4c61622d434d4343130400462001081404000000000016040046200108

It contains 81 byte or 0x51 bytes. Other infos we might know is the PDC service number (from libqmi).

// src/libqmi-glib/qmi-enums.h
QMI_SERVICE_PDC     = 0x24

Looking for a 0x24 in the data:

01 50 00 80 24 01 04280028004400010200000010040026000000110400b86500001219001854474c5f436f6d625f4174746163682d4c61622d434d4343130400462001081404000000000016040046200108

// Merging it into the struct:
    guint8 marker = 0x01;
    struct qmux_header {
        guint16 length; = 0x0050
        guint8 flags = 0x80;
        guint8 service = 0x24;
        guint8 client = 0x01;
    }

This looks already very good. The length 0x0050 is only 1 byte of our full length. Also the marker is always set to 0x01. But there isn't any data in front it. I would have expected some Diag encapsulation or prefix. Typical 0x7e in front of it or otherwise escaped.

Trying to validate the QMI data further. QMI is using TLV (Type-Length-Data) to split the values. With 1 byte type, 2 byte length, 'length' bytes value and QMI is usually encoding those sorted by the type.

struct tlv {
  guint8 type;
  guint16 length;
  guint8 value[];
};

[01] [5000 80 24 01] [04 2800 2800 4400] [010200000010040026000000110400b86500001219001854474c5f436f6d625f4174746163682d4c61622d434d4343130400462001081404000000000016040046200108]

// Merging it into the struct:
    guint8 marker = 0x01;
    struct qmux_header {
        guint16 length; = 0x0050
        guint8 flags = 0x80;
        guint8 service = 0x24;
        guint8 client = 0x01;
    }
    struct service_message {
        struct service_header {
            guint8 flags = 0x04;
            guint16 transaction = 0x0028;
            guint16 message = 0x0028;
            guint16 tlv_length = 0x0044;
        }
        struct tlv tlv[]; // <- this should be 0x0044 bytes long, which also matches our remaining data.
    }

Decoding further by hand:

(Only TLV part: T Length Value)
[01 0200 0000   10 0400 26000000 11 0400 b8650000 12 1900 1854474c5f436f6d625f4174746163682d4c61622d434d4343 13 0400 46200108 14 0400 00000000 16 0400 46200108]

Type   Len  Value
    01 0200 0000
    10 0400 27000000
    11 0400 04b90000
    12 1500 144e53494f545f566f4c54452d4c61622d434d4343
    13 0400 55200108
    14 0400 00000000
    16 0400 55200108

So is correct and matches \o/. But why isn't there a QC Diag header in front?

The pcap shows the packets are exchanged with endpoint: (wIndex 0x2 which is part of the 2nd Interface). To know more about this endpoint, we must look at the USB descriptor and the choosen configuration. Look for the GET DESCRIPTOR Response CONFIGURATION packet, here is a wireshark snippet from the trace:

USB Link Layer
USB URB
CONFIGURATION DESCRIPTOR
INTERFACE DESCRIPTOR (0.0): class Vendor Specific
    bLength: 9
    bDescriptorType: 0x04 (INTERFACE)
    bInterfaceNumber: 0
    bAlternateSetting: 0
    bNumEndpoints: 2
    bInterfaceClass: Vendor Specific (0xff)
    bInterfaceSubClass: 0xff
    bInterfaceProtocol: 0x30
    iInterface: 0
ENDPOINT DESCRIPTOR
    bLength: 7
    bDescriptorType: 0x05 (ENDPOINT)
    bEndpointAddress: 0x81  IN  Endpoint:1
    bmAttributes: 0x02
    wMaxPacketSize: 512
    bInterval: 0
ENDPOINT DESCRIPTOR
    bLength: 7
    bDescriptorType: 0x05 (ENDPOINT)
    bEndpointAddress: 0x01  OUT  Endpoint:1
    bmAttributes: 0x02
    wMaxPacketSize: 512
    bInterval: 0
INTERFACE DESCRIPTOR (1.0): class Vendor Specific
    bLength: 9
    bDescriptorType: 0x04 (INTERFACE)
    bInterfaceNumber: 1
    bAlternateSetting: 0
    bNumEndpoints: 3
    bInterfaceClass: Vendor Specific (0xff)
    bInterfaceSubClass: 0x00
    bInterfaceProtocol: 0x00
    iInterface: 0
UNKNOWN DESCRIPTOR
UNKNOWN DESCRIPTOR
UNKNOWN DESCRIPTOR
UNKNOWN DESCRIPTOR
ENDPOINT DESCRIPTOR
    bLength: 7
    bDescriptorType: 0x05 (ENDPOINT)
    bEndpointAddress: 0x83  IN  Endpoint:3
    bmAttributes: 0x03
    wMaxPacketSize: 10
    bInterval: 9
ENDPOINT DESCRIPTOR
    bLength: 7
    bDescriptorType: 0x05 (ENDPOINT)
    bEndpointAddress: 0x82  IN  Endpoint:2
    bmAttributes: 0x02
    wMaxPacketSize: 512
    bInterval: 0
ENDPOINT DESCRIPTOR
    bLength: 7
    bDescriptorType: 0x05 (ENDPOINT)
    bEndpointAddress: 0x02  OUT  Endpoint:2       <- This is our target. Scroll up to which interface this endpoint belongs.
        0... .... = Direction: OUT Endpoint
        .... 0010 = Endpoint Number: 0x2
    bmAttributes: 0x02
    wMaxPacketSize: 512
    bInterval: 0

So our endpoint 0x02 is part of the bInterface 1 with the interface class "Vendor Specific (0xff)", bInterfaceSubClass: 0x00, bInterfaceProtocol: 0x00.

After looking into it further. This interface is the rmnet part the adb shell setprop sys.usb.config diag,serial_cdev,rmnet,adb. rmnet is the same mode which most of the Qualcomm based mini-pcie and m.2 devices uses over USB.

libqmi can just interact with it if the linux kernel is exposing it as /dev/cdc-wdm. The linux kernel depends on the usb id and the amount of interface.

Sadly I hoped to find a path to QMI over QC Diag.

Unlock VoLTE by using libqmi on Linux

Now putting everything together: We will use a Linux on a Laptop to change the profile via QMI on a OnePlus6T with LineageOS on it (and root).

I've inserted a different Simcard into the Oneplus 6T and VoLTE doesn't work.

qmicli -d /dev/cdc-wdm0 --pdc-list-configs=software

And looking for the active profile:

Configuration 2:
    Description: Oversea-Commercial_DS
    Type:        software
    Size:        78772
    Status:      Active
    Version:     0x801F13A
    ID:          87:CA:4A:4D:52:48:CF:BF:13:2A:DB:C4:08:B2:2A:29:E0:CA:A5:67

Ok, the Oversae-Commercial_DS doesn't work. Here is a complete list of my device:

qmicli -d /dev/cdc-wdm0 --pdc-list-configs=software
Total configurations: 25
Configuration 1:
    Description: Telefonica_UK_Commercial
    Type:        software
    Size:        107336
    Status:      Inactive
    Version:     0x8010C9D
    ID:          E6:84:2A:02:AE:DA:D1:1A:08:14:E1:F4:CF:93:ED:6D:E9:7E:68:DC

Configuration 2:
    Description: Norway_Telia_Commercial
    Type:        software
    Size:        109448
    Status:      Active
    Version:     0x8012432
    ID:          BA:0F:0B:0E:9E:BC:0C:38:29:7F:C0:D9:AB:B9:9C:80:9E:7D:B2:AB

Configuration 3:
    Description: Oversea-Commercial_DS
    Type:        software
    Size:        78772
    Status:      Inactive
    Version:     0x801F13A
    ID:          87:CA:4A:4D:52:48:CF:BF:13:2A:DB:C4:08:B2:2A:29:E0:CA:A5:67

Configuration 4:
    Description: Telenor_Denmark_Commercial
    Type:        software
    Size:        105796
    Status:      Inactive
    Version:     0x8014326
    ID:          75:69:C0:4B:1C:63:AF:5C:3E:5A:9C:AA:0E:6D:BF:9A:D1:BB:64:D7

Configuration 5:
    Description: ROW_Commercial
    Type:        software
    Size:        45556
    Status:      Inactive
    Version:     0x8010809
    ID:          81:8A:AB:E9:B5:CD:F9:5C:89:FB:04:06:ED:E4:6C:6B:85:D7:20:3A

Configuration 6:
    Description: YTL_Commercial
    Type:        software
    Size:        49412
    Status:      Inactive
    Version:     0x8012D0C
    ID:          30:7F:09:F0:1B:0A:CD:A1:63:5C:BC:F8:AA:BB:5E:AC:18:48:D1:17

Configuration 7:
    Description: TaiwanMobile_Commercial
    Type:        software
    Size:        99208
    Status:      Inactive
    Version:     0x8014108
    ID:          3C:C1:1C:E0:A5:9B:73:C2:1E:8E:D6:0D:87:20:2E:DB:78:D8:91:0A

Configuration 8:
    Description: FarEastOne_Taiwan_Commercial
    Type:        software
    Size:        105312
    Status:      Inactive
    Version:     0x8014009
    ID:          BA:13:DC:4D:F5:3D:47:73:17:62:21:B8:2F:09:F5:2B:22:37:74:25

Configuration 9:
    Description: ChunghwaTel_Taiwan_Commercial
    Type:        software
    Size:        104792
    Status:      Inactive
    Version:     0x8014F09
    ID:          56:6E:CB:75:81:FA:C3:3F:65:46:8F:8F:16:2D:8F:D3:4D:5A:06:9C

Configuration 10:
    Description: MTNL-BSNL
    Type:        software
    Size:        78088
    Status:      Inactive
    Version:     0x801ED31
    ID:          3A:67:96:BB:B4:E1:07:40:FB:75:11:A2:E0:1A:5E:EC:27:C8:77:64

Configuration 11:
    Description: Volte_OEM_Lab
    Type:        software
    Size:        71016
    Status:      Inactive
    Version:     0x801F221
    ID:          D8:EF:7F:E2:16:24:38:15:AB:FD:BA:CE:2F:B6:A8:A3:49:30:C4:62

Configuration 12:
    Description: Volte_OEM_PTCRB
    Type:        software
    Size:        58864
    Status:      Inactive
    Version:     0x801EE2D
    ID:          0D:14:B5:E9:D2:52:AA:21:6C:FD:7D:C0:63:91:B8:6F:38:6F:CF:D3

Configuration 13:
    Description: CDMAless-Verizon
    Type:        software
    Size:        109344
    Status:      Inactive
    Version:     0x8010108
    ID:          FE:D6:7A:D3:0C:2F:8A:49:B0:A3:00:9C:80:09:A5:84:47:83:FA:7B

Configuration 14:
    Description: Commercial-TMO
    Type:        software
    Size:        70656
    Status:      Inactive
    Version:     0x8010536
    ID:          2F:1D:0C:4C:28:2D:50:FC:03:84:D8:9E:F3:92:81:C7:DB:A5:1A:7E

Configuration 15:
    Description: VoLTE-ATT
    Type:        software
    Size:        69028
    Status:      Inactive
    Version:     0x8010348
    ID:          12:A1:7C:8A:11:6E:A9:2F:D1:A7:98:57:AB:7A:E7:A3:E0:71:D5:99

Configuration 16:
    Description: FirstNet
    Type:        software
    Size:        69084
    Status:      Inactive
    Version:     0x8010337
    ID:          E6:E0:E0:E4:52:27:E0:C8:FC:6D:41:6D:FD:6D:31:E1:29:AC:C5:9E

Configuration 17:
    Description: Netherlands-VoLTE-Vodafone
    Type:        software
    Size:        105220
    Status:      Inactive
    Version:     0x80104F6
    ID:          EC:5E:DD:F2:73:13:73:23:1A:04:00:D6:F6:17:EB:FA:D3:56:A7:B5

Configuration 18:
    Description: Telia_Sweden
    Type:        software
    Size:        108948
    Status:      Inactive
    Version:     0x8012411
    ID:          86:DB:03:CF:2C:8E:13:43:D9:D4:42:69:0C:05:95:AF:77:A6:2D:A3

Configuration 19:
    Description: Telia_Finland
    Type:        software
    Size:        107208
    Status:      Inactive
    Version:     0x8012446
    ID:          14:1C:D1:A5:B3:82:B0:88:76:43:26:DC:2B:52:96:5D:17:ED:BD:1C

Configuration 20:
    Description: Telia_Denmark
    Type:        software
    Size:        108744
    Status:      Inactive
    Version:     0x8012486
    ID:          6B:7E:98:85:3B:64:BB:94:CF:10:E5:3B:C0:66:3E:00:BD:DE:6A:C5

Configuration 21:
    Description: Telenor_Sweden_Commercial
    Type:        software
    Size:        108956
    Status:      Inactive
    Version:     0x8014305
    ID:          6C:60:AD:96:58:90:36:F3:6E:63:00:B1:AB:3B:99:3B:D6:FD:E4:77

Configuration 22:
    Description: H3G_UK_Commercial
    Type:        software
    Size:        106264
    Status:      Inactive
    Version:     0x8012A75
    ID:          FD:E7:BF:6E:BF:F6:53:37:49:7B:A0:8E:37:8D:ED:D1:7D:26:D1:B6

Configuration 23:
    Description: H3G_Denmark_Commercial
    Type:        software
    Size:        105944
    Status:      Inactive
    Version:     0x8012A98
    ID:          74:64:58:13:06:F6:6B:20:0A:A2:0B:1B:EB:D2:5A:CB:9E:75:B4:CD

Configuration 24:
    Description: Elisa_Finland
    Type:        software
    Size:        106220
    Status:      Inactive
    Version:     0x8014418
    ID:          5A:A8:80:FD:97:47:95:9B:D1:F4:E5:9C:4B:74:A0:6F:C5:10:B4:AB

Configuration 25:
    Description: Commercial-EE
    Type:        software
    Size:        107940
    Status:      Inactive
    Version:     0x8012220
    ID:          4D:67:BF:E2:C6:F9:E6:90:F9:90:A1:28:2D:AD:2A:FC:BD:CB:44:91

So which one will give me working VoLTE? I've no idea, but I'll throw a random dice and pick Norway_Telia_Commercial.

The Telia profile works for my german simcard. But better is Volte_OEM_Lab. The Telia profile also sets a specific APN when attaching to the LTE network (even when its configured on Android for a different one).

qmicli -d /dev/cdc-wdm0 --pdc-activate-config=software,D8:EF:7F:E2:16:24:38:15:AB:FD:BA:CE:2F:B6:A8:A3:49:30:C4:62
[/dev/cdc-wdm0] Successfully requested config activation

Great! Now let's take a look into the debug menu reachable via *#*#4636#*#* and select 'Phone information' and on the 3 dots menu 'IMS Service Status'.

There you can see:

Yay, it works.

Creating QMI traces from Android phones

2025-06-17T01:23:00+02:00

Introduction

To investigate how the Voice over LTE stack in Qualcomm based phones works, I have to look into the QMI interface. QMI is a structured interface using TLV. Furthermore, QMI is a protocol which can be used over different interface and offers communication between services. A service usually handles a logical component of the baseband, e.g. the communication with the simcard is handled by the UIM (User Identity Module). Or the NAS handles the high level Network Access. QMI also supports multiple clients at the same time. It allows two daemons to communicate via QMI at the same time without the need to synchronize with each other.

QMI supports at least communication over the following transports (not a full list):

USB (e.g. mini-pcie)
Shared memory (SoC)
Socket (kernel socket class, but internally over shared memory)
Tunneled over Qualcomm Diag

To research the QMI VoLTE messages of a stock Android, we need to able to capture those messages. When I first encountered QMI and researched how the "legacy" voice calls are working on Qualcomm based phones, I used Qualcomm Diag for it using the osmo-qcdiag project. Sadly osmo-qcdiag only supports Qualcomm Diag when exposed as TTY on Linux via /dev/ttyXXXX, but not (as many other projects by now) directly via USB without a kernel driver. The issue with the kernel driver is the limited support of devices. When enabling Qualcomm Diag for a new phone, it requires a small patch to add the USB ID to the driver. Other projects like SCAT or QCSuper can use libusb to directly communicate with the phone.

Because of this I tried to add QMI sniffing in SCAT, but it didn't work with the phone. I didn't receive any messages after subscribing to the QC Diag messages.

But there are other methods to get the QMI messages:

a) Compile a custom Android image which sniffs all messages
b) Use a debugger and attach to a running process

I've noticed Frida which was used to capture QMI message on iPhones, described in this paper. To summarize: they used Frida, which attaches similar as a debugger to processes and injects code into the running binary to sniff the QMI messages.

iPhones communicate in a different way than Android, but I could use the same approach. The idea is:

Use a rooted OnePlus 6T (running Android)
Use Frida over adb with root privileges
Export QMI as GSMTAPv3 (to be able to capture them with tcpdump)

How does it work?

Frida has two parts:

A remote server, running on the Android phone
A client, running on a Laptop (implemented as Python library)

The client will instruct the server over adb to inject a JavaScript engine into a process, then connect to the JavaScript engine and upload a script. The script contains callbacks and code to extract the QMI message, Frida will transfer those to the client and the client will encapsulate QMI into GSMTAPv3.

How to use qmi-frida-tracer

Requirement: use a rooted LineageOS on an Android (OnePlus 6T).

qmi-frida-tracer was developed with Frida 16.6.6!

Download the server from github.

# ensure adb is able to run as root
adb root

# copy and run Frida server
adb push frida-server-16.6.6-android-arm64 /tmp/
adb shell chmod 700 /tmp/frida-server-16.6.6-android-arm64
# keep the server running
adb shell /tmp/frida-server-16.6.6-android-arm64 &

Now prepare and run qmi-frida-tracer:

git clone https://gitlab.postmarketos.org/modem/openimsd/qmi-frida-tracer
cd qmi-frida-tracer

# create a virtualenv and install frida
virtualenv venv
. venv/bin/activate
pip install -r requirements.txt

# like a `ps`. Show all processes
frida-ps -U
# use rild pid
./qmi-frida-tracer.py -p 9595

qmi-frida-tracer is sniffing all QMI messages of a process and encapsulate it into GSMTAPv3 and transmits it as UDP to localhost:4729.

Capture the QMI traffic as pcap and decode QMI messages:

tcpdump -i lo udp port 4729 -w /tmp/qmi.pcap
# and/or
# compile & run qmi-gsmtap-decode
cd ./qmi-gsmtap-decode/
mkdir build
cd build
cmake .. ; make
./qmi-gsmtap-decode | tee -a qmi.log

There are still some smaller parts open to improve.

Simulate a client ID
Wireshark support for GSMTAPv3 with QMI decoding

Example captures

<<<< QMI
QMI QRTR:
QMI   length  = 21
QMI   service = "nas"
QMI   client  = 255
QMI QMI:
QMI   flags       = "indication"
QMI   transaction = 227
QMI   tlv_length  = 9
QMI   message     = "Signal Info" (0x0051)
QMI TLV:
QMI   type       = "LTE Signal Strength" (0x14)
QMI   length     = 6
QMI   value      = B4:F6:90:FF:2E:00
QMI   translated = [ rssi = '-76' rsrq = '-10' rsrp = '-112' snr = '46' ]
>>>> QMI

<<<< QMI
QMI QRTR:
QMI   length  = 16
QMI   service = "wds"
QMI   client  = 255
QMI QMI:
QMI   flags       = "none"
QMI   transaction = 3
QMI   tlv_length  = 4
QMI   message     = "Set IP Family" (0x004D)
QMI TLV:
QMI   type       = "Preference" (0x01)
QMI   length     = 1
QMI   value      = 06
QMI   translated = ipv6
>>>> QMI

<<<< QMI
QMI QRTR:
QMI   length  = 19
QMI   service = "wds"
QMI   client  = 255
QMI QMI:
QMI   flags       = "response"
QMI   transaction = 3
QMI   tlv_length  = 7
QMI   message     = "Set IP Family" (0x004D)
QMI TLV:
QMI   type       = "Result" (0x02)
QMI   length     = 4
QMI   value      = 00:00:00:00
QMI   translated = SUCCESS
>>>> QMI

More information

If you would like to contribute to OpenIMSD or follow its development, see these links:

Matrix: #openimsd:postmarketos.org
IRC: #openimsd on OFTC

Hello World OpenIMSd

2025-03-02T01:23:00+01:00

Current free mobile phone OSes (like postmarketOS, …) only support voice calls for 2G and 3G on Qualcomm based devices. Calls via 4G using VoLTE are not supported (*except CSFB, which redirects to 2G/3G) because the modems require a lot of addional configuration and implement VoLTE with a lot of complexity. This is specially relevant because 2G and 3G networks are in the process of being shut down all around the world.

Our goal is to support VoLTE on Qualcomm based phones.

We choose Qualcomm based Android phones, because they are the commonly used phones and widely available. Also Qualcomm baseband has received a lot of reasearch (and reverse engeering) over the years and a lot of knowledge has been collected in the open.

To archive our goal we plan to:

Document the relevant ABIs and add support to libqmi
Implement a IMS configuration daemon (OpenIMSd) which will communicate with the baseband using QMI (Qualcomm MSM interface) to configure the relevant services
Integrate OpenIMSD into FOSS smartphone OS (postmarketOS, …)

Our implementation will heavily use the baseband in the same way as Android is use the baseband to allow VoLTE. By using the baseband, it should be possible to allow handover between 2G/3G and VoLTE while in a call.

We thank NLnet for funding our work (https://nlnet.nl/project/VoLTE-Qualcom/).