SIP requests are named by a method. RFC 3261 defines six: INVITE (start a session), ACK (confirm a final INVITE response), BYE (end a session), CANCEL (abort a pending INVITE), REGISTER (register a location) and OPTIONS (query capabilities). Extension RFCs add INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE and PUBLISH.
The six core methods
RFC 3261 defines the core request set that every SIP implementation supports. INVITE establishes a session and carries the initial SDP offer. ACK acknowledges a final response to an INVITE — it is unusual in being a request that completes the three-way INVITE handshake rather than expecting its own response. BYE terminates an established session. CANCEL aborts an INVITE that has not yet received a final response (a call still ringing). REGISTER tells a registrar where a user is reachable. OPTIONS queries a peer's capabilities and is widely reused as a lightweight keepalive.
| Method | Purpose | Note |
|---|---|---|
| INVITE | Initiate a session | Carries the SDP offer; creates a dialog |
| ACK | Confirm a final INVITE response | Completes the 3-way INVITE handshake |
| BYE | Terminate an established session | Sent by either party in the dialog |
| CANCEL | Abort a pending INVITE | Only before a final response (still ringing) |
| REGISTER | Register a user's Contact location | Refreshed periodically (Expires) |
| OPTIONS | Query capabilities | Commonly reused as a keepalive / health check |
Why ACK and CANCEL are special
Two core methods behave unlike the rest. ACK is not a normal request/response pair: it acknowledges the final response to an INVITE and carries no response of its own. For a 2xx it is sent end-to-end as a separate transaction; for a non-2xx failure it is generated hop-by-hop within the INVITE transaction. CANCEL only has meaning while an INVITE is still pending — once a final response arrives, use BYE instead. Getting these two right is the crux of a correct SIP state machine.
Common extension methods
Beyond the core six, a set of extension methods handles messaging, events and mid-call updates. SUBSCRIBE/NOTIFY implement the event framework (presence, message-waiting indication, dialog state). REFER triggers call transfer. MESSAGE carries instant messages / SMS-over-SIP. UPDATE modifies a session before it is fully established (early media). PRACK reliably acknowledges provisional responses. INFO carries mid-session information such as DTMF. PUBLISH submits event state to a server.
| Method | RFC | Purpose |
|---|---|---|
| INFO | RFC 6086 | Mid-session information (e.g. DTMF digits) |
| PRACK | RFC 3262 | Reliable acknowledgement of provisional (1xx) responses |
| UPDATE | RFC 3311 | Modify a session before final answer (early media) |
| SUBSCRIBE / NOTIFY | RFC 6665 | Event subscription and notification (presence, MWI) |
| REFER | RFC 3515 | Request a transfer to another party |
| MESSAGE | RFC 3428 | Instant message / page-mode messaging |
| PUBLISH | RFC 3903 | Submit event state (e.g. presence) to a server |
A request line on the wire
A SIP request begins with a request line: the method, the Request-URI (the current destination), and the SIP version. The headers and an optional body follow. The example is the start of an INVITE toward a callee; the Request-URI is rewritten by proxies as the request is routed, while the To header stays fixed as the logical target.
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=1928301774
Call-ID: a84b4c76e66710@host.example.net
CSeq: 314159 INVITE
Contact: <sip:alice@host.example.net>
Content-Type: application/sdp
Content-Length: 142Frequently asked
What are the six core SIP methods?
INVITE (start a session), ACK (confirm a final INVITE response), BYE (end a session), CANCEL (abort a pending INVITE), REGISTER (register a user's location) and OPTIONS (query capabilities). These are defined in RFC 3261; everything else is an extension.
What is the difference between CANCEL and BYE?
CANCEL aborts an INVITE that has not yet received a final response — a call that is still ringing. BYE ends a session that is already established. Use CANCEL before the call is answered and BYE after; using the wrong one leaves the state machine inconsistent.
Why does ACK not get a response?
ACK exists to acknowledge the final response to an INVITE and complete the three-way handshake, so it is defined not to have its own response. For a 2xx it is a separate end-to-end transaction; for a failure it is generated hop-by-hop inside the INVITE transaction.
How is DTMF sent in SIP?
Most commonly as RTP telephone-event packets (RFC 4733) in the media stream, and alternatively via SIP INFO messages carrying the digits in the signalling path. RTP telephone-event is preferred because it stays in time with the audio.
What method transfers a call?
REFER (RFC 3515). It asks the recipient to initiate a new request (typically an INVITE) to a third party named in the Refer-To header, implementing call transfer. NOTIFY messages then report the progress of the referred call back to the transferor.
Source specifications
The published standards this page is grounded in. Opens in a new tab.