Session Initiation Protocol (SIP)

The Session Initiation Protocol (SIP) is the IETF application-layer signaling protocol, defined in RFC 3261 (June 2002), for creating, modifying and ending sessions such as internet phone calls, video calls and multimedia conferences.

How it works. SIP is a text-based request and response protocol whose messages look similar to HTTP. Endpoints are addressed with SIP URIs such as sip:alice@example.com. The core methods are INVITE (start a session), ACK (confirm the final response to an INVITE), BYE (end a session), CANCEL (abandon a pending request), REGISTER (bind a user’s address to a current location) and OPTIONS (ask about capabilities). Responses use three-digit status codes grouped by class, so 180 Ringing is provisional and 200 OK is success. SIP only signals: the session description, usually SDP, sets up media that flows separately, typically over RTP. SIP runs over UDP, TCP or TLS, with port 5060 as the default and 5061 for TLS.

Where it shows up. IP telephone networks signal calls with SIP. The SHAKEN caller ID framework, for example, is defined for calls that originate in SIP-based telephone networks (RFC 8588), and FCC rules require it in the IP portions of US voice networks. A phone call between two voice agents is still a phone call: it is signaled like any other, and each agent turns speech into text and back again.

Caller identity. Base SIP does not cryptographically prove who is calling. RFC 8224 adds an Identity header that carries a signed token about the calling number, and STIR/SHAKEN builds on it for caller ID authentication. That check covers the phone number. It does not identify the software on the line or the person it represents.

Compared with A2A. SIP connects two parties so they can talk in real time. A2A carries structured tasks, messages and artifacts between agents over HTTP or gRPC, so two agents can exchange data directly without passing it through speech.

Neighbouring terms. STIR/SHAKEN authenticates the caller ID on SIP calls.