the Session Initiation Protocol

Before two people can talk on a call, something has to do the equivalent of looking up the number, dialing, making the other phone ring, and agreeing on a language to speak. RTP carries the actual voice once a call is running — but it never arranges the call. That setup job belongs to a signaling protocol, and on the Internet the dominant one is SIP, the Session Initiation Protocol. SIP is the part that locates the other party, rings them, negotiates how the media will flow, and later tears the call down.

It works much like the web's HTTP, on purpose: SIP is a text-based request-reply protocol with readable methods. To start a call a caller sends an INVITE toward the callee's SIP address (which looks like an email address, e.g. sip:[email protected]); SIP servers along the way help locate where Alice currently is and forward the INVITE to her device. Her phone rings and, if she answers, replies with a 200 OK, the caller confirms with an ACK, and the call is up. Crucially, the INVITE and OK carry a small description of the media (codecs, addresses, ports — typically written in a companion format, SDP) so both ends agree on how to send RTP. To hang up, one side sends BYE. SIP also handles registration, so your phone tells the network where to reach you, and redirection, so calls can follow you between devices.

Why it matters: SIP is the signaling backbone of most VoIP systems, IP-based phone networks, and many video-conferencing setups — the modern replacement for the old telephone system's call-setup signaling. A clarifying point: SIP sets up and tears down the session but does not carry the voice or video itself; the actual media flows separately over RTP, often directly between the two endpoints. So a call really involves two cooperating channels — SIP to arrange it, RTP to carry it.