Our Signaling Architecture (Board ↔ Mosquitto ↔ Bridge ↔ Browser) — Is this setup correct?

[hsc6320]

Please let us know if our current connection architecture, topic layout, and payload format are correct, and what the recommended specification is — we will align the board implementation accordingly

WebRTC signaling via MQTT: No PUBLISH callback after SUBACK, JSON-RPC -32600, and intermittent TLS -28928 Environment / Topology

Board: Eyenix EN675 (Linux, using FreeRTOS coreMQTT + mbedTLS) Broker: Mosquitto (1883 MQTT, 8883 MQTT/TLS, 8080 WS) Browser/Bridge: WebSocket → Node.js bridge → MQTT Browser UI buttons: “Connect” and “Start WebRTC”

Expected Flow

Browser sends Offer → Board sets remote(offer) → Board creates and publishes Answer → ICE exchange → Connected.

Actual Symptoms

The board subscribes successfully to the following topics:

/webrtc/en675/{offer,answer,ice} /webrtc/{invoke,invoke/+}

and receives SUBACK OK for all.

When the browser presses “Start WebRTC”:

The board does not receive any PUBLISH callbacks, or

The board sends a message to /webrtc/invoke which the browser/bridge rejects with {"code":-32600,"message":"Invalid Request"} (JSON-RPC error).

Shortly after that, the board repeatedly reports

mbedtls_ssl_read() = -28928 MQTT_ProcessLoop -> 4 (MQTTRecvFailed)

— likely a timeout or WOULD_BLOCK from the TLS layer.

How to Reproduce

Run on board:

./peer_call -u mqtts://192.168.0.21:8883/webrtc/en675 -t en675

On browser: click Connect → Start WebRTC

Observe logs:

SUBACK OK for all topics

'After “Start WebRTC”, no PUBLISH events are received

Browser console shows JSON-RPC -32600 Invalid Request

Board logs show tls_recv ERR r=-28928

Broker (Mosquitto) Observation

Using mosquitto_sub -v -t '/webrtc/#', the bridge publishes multiple topic variants:

/webrtc/en675/offer – plain SDP (multi-line v=0 … m=video …) or JSON ({"type":"offer","sdp":"..."})

/webrtc/invoke/en675, /webrtc/en675/invoke, /webrtc/invoke – JSON-RPC style

{"jsonrpc":"2.0","method":"offer","params":"v=0 ...","id":86,"peerId":"en675","token":"en675"}

/webrtc/en675/ice – mixed payloads: plain "candidate:...", {"candidate":"..."}, {"ice":"..."}

So far, no PUBLISH messages have reached the board after “Start WebRTC,” but sending test messages manually with mosquitto_pub works.

Board Log (excerpt) SUBACK OK topic=/webrtc/en675/offer SUBACK OK topic=/webrtc/en675/answer SUBACK OK topic=/webrtc/en675/ice All topics subscribed successfully. MQTT_ProcessLoop -> 0 (MQTTSuccess) ##(After Start WebRTC) tls_recv ERR r=-28928 (req=16384) MQTT_ProcessLoop -> 4 (MQTTRecvFailed)

Browser/Bridge Response {"jsonrpc":"2.0","id":-1,"error":{"code":-32600,"message":"Invalid Request"}}

What We Have Tried

Manual Test: Sending to /webrtc/en675/offer works (PUBLISH callback triggered), but some JSON formats caused the board to misinterpret them as SDP or crash before safeguards were added.

TLS: Handshake always succeeds. -28928 appears only after signaling stops — probably due to idle timeout.

The mosq_ws_tls.conf file is configured as follows, and the broker is started with the command: mosquitto -c mosq_ws_tls.conf -v

=============================== allow_anonymous true

##MQTT TCP listener 1883 0.0.0.0

##MQTT over TLS listener 8883 0.0.0.0

cafile /etc/mosquitto/certs/mosq_ecdsa.crt certfile /etc/mosquitto/certs/mosq_ecdsa.crt keyfile /etc/mosquitto/certs/mosq_ecdsa.key tls_version tlsv1.2

##MQTT over WebSockets listener 9001 protocol websockets

======================================