# SIP methods and requests

> 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.

- Canonical URL: https://www.broadnet.me/reference/sip-methods-and-requests
- Language: en
- Last updated: 2026-07-18
- Publisher: BroadNet (https://www.broadnet.me)

Every SIP request method and what it does: the six core RFC 3261 methods (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) and the common extensions (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, 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.

*Core SIP methods (RFC 3261)*

| 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.

*Common SIP extension methods*

| 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.

*The start of an INVITE request*

```text
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: 142
```

## Frequently asked questions

### 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.

## Sources

- [IETF RFC 3261 — SIP](https://datatracker.ietf.org/doc/html/rfc3261)
- [IETF RFC 6665 — SIP-Specific Event Notification](https://datatracker.ietf.org/doc/html/rfc6665)

## Related

- [SIP protocol overview](https://www.broadnet.me/reference/sip-protocol-overview)
- [SIP response codes](https://www.broadnet.me/reference/sip-response-codes)
- [SIP headers](https://www.broadnet.me/reference/sip-headers)
- [SIP call flow](https://www.broadnet.me/reference/sip-call-flow)
- [Voice API & SIP trunking](https://www.broadnet.me/answers/voice-api-sip-trunking)