SIP Protocol Overview

Two Separate Jobs: Setting Up a Call, and Carrying the Actual Audio

A VoIP call actually involves two distinct concerns: signaling (setting up, managing, and ending the call) and media transport (carrying the actual digitized audio, as covered in the previous note). SIP (Session Initiation Protocol) specifically handles the signaling part.

What SIP Is Responsible For

• Locating the party being called.
• Negotiating the details of the session - such as which codec both sides will actually use.
• Establishing the call once both sides agree.
• Managing the call while active - for example, placing it on hold.
• Terminating the call cleanly when it ends.

A Simplified SIP Exchange

Caller  ---- INVITE ------------->  Callee   "I'd like to start a call"
Caller  <--- 180 Ringing -----------  Callee   "It's ringing on my end"
Caller  <--- 200 OK ----------------  Callee   "Call accepted"
Caller  ---- ACK ------------------>  Callee   "Confirmed, let's begin"
       (media/audio now flows directly between the two parties)
Caller  ---- BYE ------------------>  Callee   "Ending the call"

This flow closely echoes the pattern of an HTTP request/response exchange (covered earlier in this project) - not a coincidence, since SIP deliberately borrows several conventions from HTTP's design.

Why SIP Itself Never Carries the Actual Audio

Once SIP has finished negotiating and establishing the call, the actual audio flows through a completely separate protocol (commonly RTP - Real-time Transport Protocol), directly between the two parties - SIP's job ends at setup, management, and teardown, not carrying the media itself.

Why Keeping Signaling and Media Separate Is a Deliberate Design Choice

Separating these two concerns - much like the layered separation covered throughout this entire project - lets each piece be optimized independently for its own specific job, rather than one single protocol trying to do both jobs at once.