Why we used STOMP with WebSocket?

Raw WebSocket provides a bidirectional pipe with no routing, subscriptions, or message structure. When building a voice call signaling system handling incoming calls, call events, and WebRTC negotiation simultaneously, this becomes a routing problem you must solve yourself. STOMP (Simple Text Oriented Messaging Protocol) adds destinations, subscriptions, and structured frames on top of WebSocket — similar to how HTTP adds structure over TCP. The post walks through a real Android signaling implementation using Ktor and a STOMP client, showing how three independent message streams (public calls, call events, WebRTC) share one WebSocket connection via STOMP subscriptions, with clean destination-based routing on the send side and a parsing layer that needs no routing logic because STOMP already handles delivery.