A browser and a desk phone can be the two ends of one call even though they handle media differently.
Choosing between them treats features deliberately assigned to one layer as if they belonged to the other.
Are they alternatives?
No. They sit at different layers and each one leaves the other's job undone.
SIP is signalling. It finds the far end, negotiates what media will be exchanged, rings, connects and tears down. It does not carry the audio. RFC 3261 is blunt about the boundary: "SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture."
WebRTC is the media stack a browser has. It gets audio and video between two endpoints, handles the network address translation problem that makes that hard, and secures it. Its own specification, RFC 8825, an IETF Standards Track document from January 2021, says the media format is the Real-time Transport Protocol (RTP). It requires the Secure Real-time Transport Protocol (SRTP): "Implementation of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is REQUIRED for all implementations".
SIP arranges calls without carrying media. WebRTC carries media without arranging calls.
What does WebRTC leave out, and why?
The signalling, on purpose, and the specification says so in as many words.
RFC 8825 describes the arrangement as a trapezoid. The media travels directly between the two browsers. The signalling travels through servers, which "can modify, translate, or manipulate the signals as needed". The specification does not pick a signalling protocol:
The choice of protocols for client-server and inter-server signaling, and the definition of the translation between them, are outside the scope of the WebRTC protocol suite described in this document.
That is not an omission waiting to be fixed. It is what lets a chat application signal over its own WebSocket messages while a telephony platform signals over SIP, with the same media stack underneath both. The same document names the telephony option directly, describing a deployment that uses "a standardized signaling mechanism (e.g., SIP over WebSockets)" between the browser and the server.
SIP over WebSocket is specified in RFC 7118, from January 2014, which defines "a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments". It changes how SIP messages travel and not what they say, which is why a browser and a desk phone can be the two ends of one ordinary call.
What does that look like on Bird?
To connect a browser through Bird, use SIP over a WebSocket.
The dashboard's own phone is the worked example. The browser acts as the SIP client. The dashboard mints a short-lived session credential for it rather than shipping a long-lived secret into a page. The API describes the credential's handshake_token as a "Short-lived token required when upgrading the WebSocket connection". It "authorizes the connection only; each call still authenticates with password". The handshake token authorizes the connection, while the password authenticates each call.
Browser compatibility depends on the trunk's digest algorithms. Browsers answer a SIP digest challenge with MD5 and nothing else. A trunk accepts only the algorithms it offers. A trunk configured to offer SHA-256 alone therefore refuses every browser call, including the dashboard's phone. Keeping MD5 in the offer is what makes a trunk callable from a browser, and SIP trunks covers the setting.
The call otherwise lands on the same trunk, checks the same verified caller ID, obeys the same enabled destinations, and produces the same record as a call from a private branch exchange (PBX).
So which do I use?
Pick by where your endpoint runs, and expect to use SIP either way.
WebRTC requires encrypted media. A SIP trunk's TLS transport encrypts the signalling in transit instead of the audio. An encryption review therefore needs to cover both paths.
- A browser. You do not really get a choice about the media: a web page uses the browser's WebRTC stack. You choose how to signal it. SIP connects it to the telephone network rather than only to other browsers.
- A desk phone, a PBX or a session border controller (SBC), which controls calls at a network boundary. Plain SIP over UDP, TCP or TLS. WebRTC has nothing to offer equipment that already speaks RTP.
- A voice AI agent. Whichever your runtime already implements. An agent in a browser or on a runtime built around browser media APIs will speak WebRTC and needs signalling attached. An agent built on a telephony stack speaks SIP and RTP directly. What is a voice AI agent covers the rest of that path, including the part where the agent has to terminate the audio and not only the signalling.
In short
The question compares two different layers.
WebRTC is a media stack for browsers with no signalling protocol. SIP is a signalling protocol that does not carry media. Neither replaces the other.
WebRTC leaves signalling out deliberately.
Its own overview puts the choice of signalling protocol outside the specification's scope, and names SIP over WebSockets as one standard way to fill the gap.
A browser call on Bird is a SIP call.
The browser acts as the SIP client, the connection is upgraded to a WebSocket with a short-lived token, and each call still authenticates with a digest password.
Encryption sits in different places in each.
WebRTC requires SRTP for the media. A SIP trunk's TLS transport encrypts the signalling, which is a separate thing from the audio.