Demo Video

Why build video calls over Bluetooth?

The idea behind MeshLive was to let nearby devices communicate using the radios they already have, even when normal internet connectivity isn't available.

Offline text messaging was already possible. I wanted to experiment with extending that to live audio, video calling and broadcasting.

The first challenge wasn't creating a calling interface. It was getting continuous, time-sensitive media through a connection with very limited and inconsistent throughput.

A video file can take longer to transfer without causing much trouble. A live conversation cannot.

If the network falls behind, audio delay becomes noticeable quickly.

That difference shaped many of the later architectural decisions.

How does MeshLive send video without internet?

MeshLive uses Bluetooth Low Energy for nearby device discovery and Bluetooth connections for control and media transfer.

On Android, the sender pipeline is roughly:

1. Capture video through Camera2.
2. Encode it using VP9 or AV1.
3. Encode microphone audio using Opus.
4. Packetize audio and video using shared presentation timestamps.
5. Encrypt and authenticate the session.
6. Send the packets across the selected Bluetooth transport.
7. Decode and play them on the receiving device.

For livestreams, a receiving device can also forward the stream to another device.

The app doesn't need an internet server to handle discovery or media transfer. Participating devices establish their own local connections.

Why support three Bluetooth transports?

No single Android Bluetooth transport worked equally well across the phones I tested.

MeshLive therefore supports BLE GATT, LE L2CAP CoC and Bluetooth Classic RFCOMM.

GATT became the default because it has broad compatibility and doesn't require pairing.

But its behaviour also exposed one of the biggest audio latency problems: a large media write could keep smaller audio packets waiting.

L2CAP CoC offers a byte-stream interface with credit-based flow control, but device compatibility has been a problem. Certain Android versions and vendor stacks have channel lifecycle issues or unreliable setup.

Bluetooth Classic RFCOMM can deliver more throughput on suitable phone combinations, but normally requires pairing and has different privacy characteristics.

Rather than silently switching every session to whichever transport appears fastest, the application keeps transport choices explicit.

That makes debugging and comparing phone combinations much easier.

How did video frames end up delaying audio?

Initially, audio and video could compete for the same send path.

When a large video frame occupied that path, audio accumulated behind it.

Adding queue capacity addressed overflow but didn't fix the time audio spent waiting.

I tested two related changes.

Fragment interleaving: Large video frames are split into smaller authenticated pieces. Waiting audio can be transmitted between those pieces rather than waiting for the complete video frame.

Speech-led playback: Late video is prevented from increasing the shared call playback delay indefinitely. The tradeoff is that video can lag speech rather than forcing speech to wait for video.

On one recorded Samsung M31/ASUS GATT comparison, fixed-size fragments reduced p95 audio queue age from 457 ms to 140 ms, with roughly 4% framing overhead.

Adding speech-led playback in a separate test also reduced the median shared playback delay.

Those improvements are specific to the measured development builds and configurations. The test suite still identified other problems, including weak-device video performance.

That's an important distinction: improving one bottleneck doesn't mean the complete video call has passed every quality target.

The full A/B record is public on GitHub.

How do calls and livestreams travel through other devices?

MeshLive uses local relay relationships instead of requiring one device to maintain a global view of the entire network.

For a livestream, a device can receive the stream from its parent and forward the media to a downstream device.

Each relay deals with its immediate connections. It doesn't need to know every device in the network.

The stream is encoded once at the source. A forwarding device can pass along the encrypted media rather than encoding another video stream from scratch.

That saves processing work, but it doesn't eliminate the Bluetooth airtime cost.

Each relay still needs to receive and transmit.

For a real-time call, the problem becomes bidirectional. Both endpoints produce media, and the intermediate devices have to forward traffic in both directions.

The Android 0.4.0-beta release introduces experimental private-call relaying, enabled manually under Settings > Advanced.

The intermediate devices forward encrypted media without holding the endpoints' content keys.

There are also hop-local admission checks and overload controls, because a device shouldn't continue accepting downstream traffic when it cannot deliver it.

It's a useful step toward longer-range communication, but it isn't unlimited range. Each additional hop introduces more opportunities for delay, congestion and disconnection.

What made desktop support difficult?

Extending MeshLive beyond Android wasn't simply a matter of reproducing the interface.

Windows, macOS and iOS expose different Bluetooth APIs, advertising capabilities and connection roles.

For example, Android can use custom manufacturer data in BLE advertisements.

The Apple discovery implementation has to work within CoreBluetooth's advertising restrictions, so it represents compact discovery information through a service UUID instead.

Android then needs to recognize and decode that format.

The advertisement is only a discovery hint. It isn't treated as proof of identity; authentication still happens after connection.

Background advertising on iOS also behaves differently from Android, making discovery less straightforward when the app isn't in the foreground.

Desktop implementations introduce their own connection-role and compatibility constraints.

The goal is to keep the same authenticated communication protocol while adapting to what each operating system actually allows.

The current platform status is:

The Windows-to-phone demo is one of the clearest examples of the progress so far.

How is privacy handled without accounts?

MeshLive doesn't depend on an online account or identity server.

The Android implementation generates a persistent cryptographic identity and uses authenticated handshakes with fresh ephemeral keys.

Communication has two layers of protection: authentication and encryption between neighbouring devices, plus separate end-to-end protection for the original endpoints.

That distinction matters for relaying.

A relay can forward traffic and observe metadata such as timing and packet sizes, but it shouldn't be able to decrypt the contents of a private call.

Android also uses rotating discovery identifiers, changing every 15 minutes by default.

When an unknown caller connects, the initial identity is temporary rather than immediately exposing the callee's long-term identity.

The latest release tightens the caller verification process before audio/video is transmitted and applies blocking rules to livestreams and relays.

There are still limitations.

Bluetooth advertisements remain observable. Some operating systems expose device names or addresses. Livestreams reveal information that private calls do not, and traffic metadata isn't hidden.

The protocol hasn't received an independent security audit.

These limitations are documented in MeshLive's privacy reference.

What did testing across different phones reveal?

Possibly the biggest lesson has been that Bluetooth compatibility cannot be assumed from a device supporting Bluetooth on paper.

I've tested with phones from Samsung, Xiaomi, ASUS and OPPO running different Android versions.

The same application can encounter very different connection behaviour, throughput and codec performance across these devices.

A change that improves one phone pair might have no effect on another.

That led to a more measurement-driven development process:

• Reproduce the failure on actual devices.
• Identify the affected stage: capture, encode, queue, transport, receive, decode or playback.
• Compare changes under the same requested media settings.
• Keep experimental alternatives switchable.
• Record measurements, unsuccessful approaches and known limitations.

Most of the code has been developed with Claude Code's assistance, but the physical measurements and engineering decisions remain essential. AI-generated code passing unit tests cannot establish how a particular Bluetooth controller will behave.

The public decision log and device compatibility table are intended to make that work reproducible.

What's next for MeshLive?

The immediate priorities are improving compatibility, connection reliability and latency, particularly for relayed calls and cross-platform communication.

There's also work planned around additional communication features and using Wi-Fi Direct/Aware as higher-bandwidth options where supported, while retaining Bluetooth for nearby discovery and control.

Those are future directions, not completed features.

For now, MeshLive remains an experimental beta. The aim is to keep testing, documenting problems and improving the implementation across more devices.

Frequently asked questions

Can MeshLive make calls without Wi-Fi or mobile data?

Yes. Compatible nearby devices running MeshLive can establish voice/video calls over Bluetooth without an internet connection. Bluetooth must remain enabled.

Can a call reach someone outside direct Bluetooth range?

Android 0.4.0-beta has experimental call relaying through intermediate MeshLive phones. It must be enabled manually and is not guaranteed to work on every device combination.

Is MeshLive available for Windows, macOS and iPhone?

Android APKs and an experimental Windows beta are available. The native Mac and early iPhone implementations currently require building from source. There is no public iOS App Store or TestFlight binary yet.

Try MeshLive

• Android 0.4.0-beta
• Windows beta
• macOS and iPhone source
• Project repositories

MeshLive is free, open source and licensed under GPL-3.0-or-later.

If you're interested in Bluetooth networking, Android development, media codecs or cross-platform communication, I'd appreciate feedback, device test results and contributions.

Video: https://youtu.be/I9_oEuNFcQE?si=iBAZGOC00_8EC9VW

I started working on it because I wanted nearby phones to keep communicating when internet access wasn’t available. Voice and live video felt worth exploring alongside offline messaging.

Getting a picture onto another phone was only part of the work. Making a conversation usable meant dealing with slow links, video blocking audio, different Bluetooth stacks, and an iPhone that couldn’t announce itself the same way an Android phone could.

Here are a few of the problems behind the app.

Which Bluetooth transports does MeshLive use?

MeshLive supports BLE GATT, LE L2CAP CoC, and Bluetooth Classic RFCOMM. GATT is the default, while CoC remains experimental. Each path involves different tradeoffs in phone compatibility, pairing, throughput, and how long media writes occupy the connection.

A connection working once also doesn’t tell you much about what happens after repeated calls, a Bluetooth restart, or a change in which phone initiates the connection. That has made testing actual phone pairs a large part of the work.

Why did video frames make the audio wait?

A large video write could occupy the connection while smaller audio packets waited behind it. I had to address two problems: audio filling the shared queue, and the writer having no opportunity to send that audio until the video write finished.

While a large video frame was being written, audio accumulated in the shared queue. The queue filled, video was dropped, and recovery requested a keyframe. That larger recovery frame could then block the writer again.

The first change was to give audio its own queue headroom, separate from the video budget. This addressed the overflow problem.

But audio could still wait behind a video write already in progress. In some GATT tests, that wait was roughly 0.6–1.2 seconds behind a single frame. Having room in the queue didn’t make the connection available any sooner.

This is head-of-line blocking: a large item at the front prevents smaller, more urgent items from moving.

The next change was to split larger video frames into roughly 2 KB authenticated fragments, with opportunities to send waiting audio between them. That gives speech a chance to move before the entire video frame has finished.

In the recorded Samsung M31/ASUS GATT comparison, the p95 windowed audio queue-age metric fell from about 457 ms to 140 ms with fixed-size fragments, at roughly 4% framing overhead.

That measures time waiting in the sender’s queue. It doesn’t establish the complete delay between speaking into one phone and hearing the other. Those test runs also missed other quality targets, so there is still work to do.

Why did the receiver also delay speech?

Audio and video shared a playback clock. When video arrived late, the receiver could increase their shared buffering delay and keep speech waiting, even after the audio had moved through the sender’s queue more quickly.

I added a speech-led playback policy that limits how much extra delay late video can introduce. The tradeoff is that the picture may lag speech more during a bad video burst.

The useful approach involved both ends of the connection: create opportunities to send audio, then limit how much late video can delay its playback.

Fixed-size fragments and speech-led playback are now enabled for normal direct GATT calls when the peers support them.

There is also an experimental alternative that sizes fragments around a target amount of transmission time. A fixed number of bytes takes very different amounts of time on fast and slow links. Smaller fragments create more scheduling opportunities, but add framing overhead. That alternative remains off by default.

How do Android and iPhone discover each other?

MeshLive uses Bluetooth Low Energy for discovery. Android advertises manufacturer data, while the iPhone implementation packs its announcement into one 128-bit service UUID. Android recognizes that compact announcement with a masked UUID scan filter, allowing the phones to find each other before connecting.

After discovery, the connection can proceed through the existing transport and authenticated handshake. The announcement is a hint about a nearby peer; authentication still happens when connecting.

There are limits: this iPhone discovery path currently requires the app to be in the foreground, and it advertises one role at a time.

The iOS implementation is still early, with no published consumer binary yet.

Why does relaying consume more Bluetooth capacity?

A nearby phone can extend a broadcast’s reach by forwarding it. That phone has to receive and transmit using the same radio, so each extra link consumes airtime.

Forwarders pass along the existing encrypted media without re-encoding it for the next viewer. That saves processing, but the transmission cost remains. Short chains and modest media rates are the practical focus.

Broadcast forwarding and private-call relaying also have different maturity levels. Call relaying remains experimental and off by default.

What is the current status of MeshLive?

Recent beta work has added audio-only live broadcasts, improved the calling experience, enabled initial Android–iPhone interoperability, and addressed slow-link and Bluetooth reconnect problems.

After the latest beta update, I’ve also finally submitted the closed alpha to Google Play for review.

Now I wait for approval so I can move into the next stage of testing and work toward a public Play Store release.

The Android APK is already available for anyone who wants to try it. It is still beta software, and the project hasn’t had an independent security audit yet.

If you try it with two phones, a useful report is the phone models, Android versions, what you tried, and where it worked or failed. Different phone combinations are especially valuable.

And if you work with Android Bluetooth, real-time audio/video, or iOS networking, I’d appreciate a look at the implementation and the decisions behind it.

• Source code and documentation
• Download the Android beta
• Early iOS implementation