From Signaling to Media: What Each Phase Proves
The WebRTC and DTLS-SRTP ecosystem becomes easier to judge when a call is treated as a sequence of state changes rather than as one undifferentiated “secure connection.” This chapter follows a representative connection from application signaling to protected media, asking what each phase proves, what it merely assumes, and which later component consumes its result. The practical payoff is diagnostic: when a media server admits the wrong peer, the failure can be located at a transition instead of being blamed vaguely on encryption.
Before keys exist: signaling and consent establish the conditions
A WebRTC session starts before either side has a media-encryption key. The application first has to describe what it wants to connect and give the other endpoint enough information to attempt the connection. In the model described by the USENIX study, the signaling phase carries a Session Description Protocol message containing media parameters, ICE candidates, and a certificate fingerprint. The IETF WebRTC security architecture describes the same basic exchange while deliberately leaving the application’s signaling protocol open. A service may use HTTPS requests, WebSockets, or another application-defined channel; WebRTC specifies what the resulting description must accomplish, not one universal signaling service.
That flexibility makes signaling part of the security boundary. The message does not carry the audio or video itself, but it establishes the expectations under which later traffic will be interpreted. It says, in effect, which media sections exist, where a connection might be reachable, and which certificate fingerprint a peer should encounter during DTLS. The fingerprint is not a general public certificate authority. In WebRTC it can identify a self-signed certificate generated for a call or a domain. Its authority comes from the way the value is delivered and then checked, not from the certificate being globally trusted.
The signaling service may be an intermediary rather than a media endpoint. It can relay an offer from one participant and an answer from another, help the application choose the DTLS client and server roles, and pass along the candidate information needed for connectivity. That division is useful, but it also creates a handoff. A browser may trust the application’s HTTPS origin enough to accept its signaling messages, while the eventual media peer is authenticated through a different mechanism: the certificate fingerprint and, where deployed, an identity assertion bound to that fingerprint. A secure connection to the signaling service is therefore not by itself proof that the media endpoint is the intended participant.
The offer and answer also establish the shape of the later transport. Media sections can be multiplexed, and the fingerprint set associated with a session can be reused or changed as the session is modified. The RFC describes a common case in which RTP and RTCP are multiplexed and several media streams share one channel, resulting in one DTLS handshake. Other arrangements can create more than one DTLS connection. This is a small but important systems detail: a check that is correct for one connection does not automatically validate every other connection unless the implementation preserves the relationship between the media sections, their fingerprints, and the DTLS sessions created from them.
The first transition is from a proposed session to a set of connectivity checks. ICE—the Interactive Connectivity Establishment protocol—collects possible network paths and tests candidate pairs. A direct path may work between public addresses. A private network or firewall may require STUN to learn a server-reflexive address or TURN to relay traffic. In a service using a media server, the “far end” of the ICE relationship may be that server rather than another browser. The details of the path can change without changing the application’s intended call, but the selected path becomes the route over which the next protocol phase runs.
ICE proves something important but limited: a reachable endpoint has responded using the credentials for the candidate pair, and the endpoint is willing to exchange traffic. The RFC describes this as media consent verification. An attacker who is on the network path but is not associated with the signaling service cannot simply invent valid ICE responses without the ICE credentials. That property helps prevent traffic from being sent to an arbitrary destination. It does not, however, say that the responding endpoint is the account, browser, or media-server session named by the application. Reachability is a network fact; identity is a binding between a claim and a cryptographic key.
This distinction matters at the transition trigger. Once the required ICE checks complete, the endpoints may send non-ICE data and start the DTLS handshake. The selected candidate pair and its consent state are now inputs to the next stage. The SDP fingerprint, meanwhile, remains the expected description of the certificate that should appear. Neither fact has yet created an SRTP key. If an implementation confuses a successful ICE check with a successful peer-authentication check, it can carry an unresolved identity question into the cryptographic stage.
The lifecycle can be read as a series of handoffs:
The diagram shows a relayed topology, not the only possible one. In a direct call, the media endpoint may be another browser. In a conference, each participant can have a separate DTLS-SRTP session with the media server, and the signaling service may not be the same system as the server handling packets. The important point is ownership: the signaling layer supplies claims and parameters, ICE establishes a usable route, and the media endpoint must validate the cryptographic identity before treating that route as a secure session.
After connectivity: DTLS creates keys, and media creates a new authorization state
The DTLS handshake is the key-exchange phase, but it is more than a single certificate presentation. The client begins with a ClientHello describing supported protocol versions, cipher suites, and extensions. The server selects parameters and sends its certificate; depending on the configuration, it can request a client certificate as well. With an ephemeral key-exchange choice, the server sends a public key signed by the certificate’s private key. A client that has been asked to authenticate sends its certificate and a CertificateVerify signature over the handshake transcript. Both sides then complete the handshake with Finished messages that verify the transcript they believe they saw.
The exact wire details vary with the negotiated DTLS version, but the causal relationship is stable: the endpoints use the handshake to agree on ephemeral keying material, prove the signatures required by the chosen authentication mode, and derive a shared secret. The certificate itself is not enough. A certificate names a public key; the signature and key-exchange steps are what demonstrate control of the corresponding private key. In WebRTC, the peer must also compare the certificate’s fingerprint with the value committed during signaling. That comparison connects the cryptographic proof to the session the application intended to establish.
The transition from signaling to DTLS therefore carries several pieces of state at once. The DTLS role—client or server—was negotiated earlier. The selected candidate pair determines where handshake packets travel. The expected fingerprint comes from the signaling description. The certificate and ephemeral public key arrive in the handshake. A correct implementation must keep these values associated with the same connection and process messages according to the protocol state. If it verifies a signature over one key but derives the shared secret from another, or if it accepts a certificate without checking the expected fingerprint, a later encrypted channel can be internally coherent while its identity is wrong.
DTLS also has to tolerate the realities of datagram transport. Handshake messages can be retransmitted and, at the network level, arrive out of order. That does not mean an implementation may accept every message in every state. It must distinguish a legitimate retransmission from a message that changes keying material after the corresponding proof has already been checked. The study’s authentication probes target precisely this kind of boundary: whether an endpoint can be induced to omit a certificate or signature, process a message out of order, or use a public key that was not the one protected by the expected signature. The lifecycle view explains why these are not isolated message-format issues; they are attempts to make state advance without preserving the identity relationship established earlier.
When the handshake finishes, the shared secret is not normally handed to the web page as an ordinary application value. Instead, DTLS keying material is exported for the media protection layer. SRTP uses the resulting keys and salts to protect RTP media; SRTCP protects control traffic. The use_srtp extension participates in negotiating the SRTP protection profile. If the application opens a data channel, SCTP can be carried over DTLS and protected directly by that channel. The result is a set of encrypted and authenticated transports, but the transports inherit the identity decision made during the handshake. They do not independently rediscover which participant the application meant.
This is why a handshake completion is an intermediate state, not the final security verdict. The media server still has to associate the new protected connection with a call, participant, and stream. RTP synchronization-source identifiers help it map media streams, but they are metadata used in the media system, not replacements for certificate or identity verification. A server might require a valid SRTP packet, a data-channel setup, or another application message before it begins forwarding media. Those gates can limit the impact of a DTLS mistake, but they also show that “the handshake succeeded” and “the server authorized media” are separate transitions.
The security boundary changes most visibly when the server relays or mixes a conference. In a direct browser-to-browser session, each endpoint derives keys for the other endpoint’s transport. In a server-mediated session, the browser derives keys for its connection to the server, and the server may terminate that protection before forwarding or transforming the media. A participant can therefore have a properly encrypted channel to the media server while still lacking end-to-end cryptographic protection from that server. That is not necessarily a design flaw; recording and mixing may require the server to see media. It is a design fact that determines which endpoint must authenticate the participant and which endpoint can release the content.
The lifecycle also does not end at the first protected packet. RFC 8827 requires continuing consent freshness through periodic ICE-related keepalives. If consent fails and no new channel can be established, the session is terminated. This recurring check addresses whether a destination remains willing to receive traffic; it does not replace the one-time identity checks in signaling and DTLS. The system must preserve both kinds of state: the identity and key association that authorizes the channel, and the live consent state that determines whether sending should continue.
A useful operational reading is to assign each transition a question and an owner. The signaling and application layer owns the description of the intended session and its identity claims. The ICE machinery owns candidate checks and consent for the selected path. The DTLS endpoint owns certificate, signature, transcript, and key-state validation. The media server’s application layer owns the decision to map a protected connection to a participant and release media or data. These responsibilities interact, but none can safely be inferred from another. A server that receives a valid DTLS Finished message has evidence about a handshake transcript; it does not automatically have evidence that the connecting key belongs to the participant named by the service.
The next unresolved dependency is the fingerprint itself. A self-signed certificate can work in this architecture only if the value committed during signaling is faithfully carried into the DTLS comparison, and if any higher-level identity claim remains attached to that same fingerprint. The following chapter isolates that bridge: how it is supposed to work, and how encryption can remain intact when the binding to the intended peer does not.