SDP — the Session Description Protocol — is the negotiation document at the heart of setting up a WebRTC media session. It is a structured block of text that each side produces to describe its half of the conversation: which audio and video codecs it supports and in what preference order, transport parameters, the cryptographic fingerprints used to secure the media, any simulcast layers it will send, and the direction of each media stream (send-only, receive-only, or both). WebRTC's offer/answer model works by one side sending an SDP offer and the other replying with an SDP answer, converging on a common set of capabilities.
For a telemedicine engineering team, SDP usually stays invisible until a call fails in a way logs alone do not explain — and then it becomes essential. Many of the hard, intermittent failures in clinical video trace to the SDP: a codec line that got stripped so the two sides share no common video format, a security fingerprint that was altered ('munged') in transit so the encrypted handshake never completes, or a codec profile one device does not actually support despite advertising it.
You rarely author SDP by hand — the browser and WebRTC stack generate it — but reading it is a core debugging skill for anyone responsible for call reliability in a clinical setting, where a dropped consultation is not merely an annoyance. The common mistake is 'SDP munging,' the practice of manually editing the generated SDP to force a behavior; it can work, but it is brittle, easy to get subtly wrong, and a frequent source of failures that only appear on certain device or browser combinations.
