SIP is a text-based, request/response protocol modeled in spirit on HTTP: methods, headers, URIs, and a message body. Endpoints are called User Agents; they send requests to one another, often through proxy servers that route on the Request-URI. A successful call setup is a dialog (identified by Call-ID plus tags) that lasts until someone sends BYE.
The protocol became the default control plane for business VoIP because it is extensible and because vendors converged on it for SIP trunks. It is not the only signaling protocol (H.323, Jingle, and proprietary APIs still exist), but it is the one you will see on a wire capture between a phone and a carrier.
What SIP does and does not do
SIP locates a party, offers a session, and agrees to change or end that session. The offer is usually an SDP body (Session Description Protocol, RFC 8866, formerly RFC 4566) that lists media types, codecs, IP addresses, and ports. Once both sides agree, they send media on those addresses. The media is almost always RTP (RFC 3550), not SIP.
- SIP: signaling. INVITE to start, re-INVITE or UPDATE to change, BYE to stop.
- SDP: a description of the media session nested in SIP (or in WebRTC signaling).
- RTP: the actual audio or video packets. Quality problems live here. See call quality.
Confusing SIP with the phone call itself leads to misdirected troubleshooting. A 200 OK to INVITE means the session was accepted. It does not mean the callee can hear you. Frozen audio is an RTP, NAT, or codec problem until proven otherwise.
A call in SIP terms: INVITE, ACK, BYE
A successful call setup follows a three-way handshake: INVITE, a final 2xx response, and ACK. ACK is a separate method, not an implicit TCP ack, because SIP can run over UDP and because proxies may need to see the confirmation. After the dialog is established, either party sends BYE to hang up. CANCEL aborts an INVITE that has not yet received a final response (the callee has not answered).
- Alice sends INVITE with an SDP offer (codecs, RTP port).
- Bob's phone rings (often after 180 Ringing). Bob answers with 200 OK and an SDP answer.
- Alice sends ACK. RTP flows both ways.
- When finished, either side sends BYE; the other responds 200 OK.
Provisional responses (1xx) can be important in practice. 100 Trying suppresses retransmissions. 180 Ringing drives local ringback. 183 Session Progress may include early media (SDP) so the caller hears a carrier message before answer. PRACK (RFC 3262) acknowledges reliable provisionals when both sides require it.
SDP and the media path
SDP is a session description, not a transport. Lines such as m=audio, a=rtpmap:0 PCMU/8000, and a=rtpmap:9 G722/8000 tell the peer which payload types map to which codecs. ICE attributes appear when the endpoint is WebRTC or a SIP user agent that implements trickle ICE. DTMF is often advertised as telephone-event (RFC 4733) alongside the audio codec. See DTMF.
The IP address in SDP may not be reachable. Enterprise phones sit behind NAT. Session Border Controllers (SBCs) rewrite SDP so media anchors on a public address. That is normal in SIP trunking. It also means a packet capture on the phone and a capture on the carrier will show different RTP tuples.
Registration and trunks
A SIP phone typically REGISTERs an Address of Record (AoR) such as sip:[email protected] to a contact URI that includes its current IP and port. Registrars store that binding so inbound INVITEs can be routed. Registration expires and must be refreshed. This is how a device stays reachable even as its network address changes.
A SIP trunk is a standing peering arrangement, not a physical circuit. The PBX may REGISTER as a single account, or it may use IP-authenticated trunks with no REGISTER, only INVITEs between known addresses. Carriers terminate and originate E.164 numbers over that peer. Capacity is measured in concurrent calls and often in calls per second, not in T1 timeslots, though many trunks are still sized in analog-line equivalents.
SIP methods
| Method | Specified in | Role |
|---|---|---|
| INVITE | RFC 3261 | Initiate or re-negotiate a session (re-INVITE) |
| ACK | RFC 3261 | Confirm a final response to INVITE |
| BYE | RFC 3261 | End a dialog |
| CANCEL | RFC 3261 | Abort a pending INVITE |
| OPTIONS | RFC 3261 | Query capabilities without offering a session |
| REGISTER | RFC 3261 | Bind an Address of Record to a contact |
| UPDATE | RFC 3311 | Modify session parameters without the INVITE transaction rules |
| PRACK | RFC 3262 | Acknowledge a reliable provisional response |
| INFO | RFC 6086 | Mid-dialog application data (sometimes DTMF, better sent via RFC 4733) |
| REFER | RFC 3515 | Ask the peer to send a request (call transfer) |
| SUBSCRIBE / NOTIFY | RFC 6665 | Event state (voicemail waiting, dialog events) |
| MESSAGE | RFC 3428 | Pager-mode instant messaging, not RTP audio |
SIP compared with WebRTC
WebRTC reuses RTP, SDP, and ICE. It does not require SIP. Browser sessions are often signaled over HTTPS with an application-specific schema, then the same ICE/DTLS-SRTP media path runs. A gateway can translate SIP to WebRTC so a browser agent can join a SIP conference. Treat them as two signaling styles over a shared media toolkit, not as mutually exclusive networks.
| SIP | WebRTC | |
|---|---|---|
| Primary standards | IETF RFC 3261 and extensions | W3C WebRTC, IETF RTCWEB / JSEP |
| Typical client | Desk phone, softphone, PBX, SBC | Browser or embedded mobile SDK |
| Signaling transport | UDP/TCP/TLS to port 5060/5061 (or SRV) | Whatever the app chooses (often WSS or HTTPS) |
| NAT traversal | STUN, rport, SBC, sometimes ICE | ICE required; STUN and TURN expected |
| Media security | Optional SRTP; many trunks still RTP inside a private network | DTLS-SRTP required in browsers |
| Numbering | sip: URIs and E.164 via trunks | Application identity; numbers via a SIP/CPaaS gateway |