5.1 The six core methods
The method is the first word of a request line. It says what the request asks for. RFC 3261 defines six methods; extensions add more. Every method has a different job, and each has a short ladder below. Select a card to turn it over, then step through its ladder.
Method cards
Fourteen methods, one job each
- SIP
- dialogCreates a dialog
- in dialogOnly inside a dialog
Core methods · RFC 3261
Extension methods
INVITE
Starts a session. Inside a dialog, a re-INVITE changes the session, for example to put a call on hold.
- Dialog
- Creates a dialog
- Body
- Usually an SDP offer
- Defined in
- RFC 3261 §13 ↗
The only method with a three-way handshake. A 2xx response is confirmed with ACK.
RFC 3261 §12.1 · Creation of a Dialog
“Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog.”
Read the section ↗
Alice's phone sends the INVITE with an SDP offer.
| Method | Asks the other side to… | Response? |
|---|---|---|
| INVITE | start a session, or change one (re-INVITE) | Yes. A 2xx is confirmed with ACK. |
| ACK | accept that the INVITE has its final response | Never |
| BYE | end the session | Yes |
| CANCEL | stop an INVITE that has no final response yet | Yes, and the INVITE gets 487 |
| REGISTER | bind an AOR to a Contact address (Module 12) | Yes |
| OPTIONS | say what it supports, without ringing | Yes |
CANCEL: only while the phone rings
CANCEL stops a pending INVITE: the caller hangs up while the callee’s phone still rings. It has strict rules.
- A CANCEL copies the Request-URI, Call-ID, From, To, CSeq number, and top Via branch of the INVITE. That is how the receiver finds the transaction to cancel.
- It may only be sent after a provisional response, such as 100 Trying or 180 Ringing:
“If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.”Read the section ↗
- It is hop by hop: each stateful proxy answers it at once with 200 OK, and sends its own CANCEL on the next hop.
- The cancelled INVITE ends with 487 Request Terminated, which is confirmed with ACK like any other failure.
Call flow · CANCEL
Alice hangs up while Bob's phone rings
- SIP
Alice's phone calls Bob through Proxy B.
All steps as text
- Alice → Proxy B: INVITE. Alice's phone calls Bob through Proxy B.
- Proxy B → Alice: 100 Trying. Proxy B answers 100 Trying. It keeps state for the INVITE transaction.
- Proxy B → Bob: INVITE. Proxy B forwards the INVITE to Bob's phone.
- Bob → Proxy B: 180 Ringing. Bob's phone rings.
- Proxy B → Alice: 180 Ringing. Alice hears the ringback tone.
- Alice → Proxy B: CANCEL. Alice hangs up before Bob answers. The CANCEL copies the Request-URI, Call-ID, From, To, and branch of the INVITE.
- Proxy B → Alice: 200 OK (CANCEL). Proxy B answers the CANCEL itself. CANCEL is hop-by-hop.
- Proxy B → Bob: CANCEL. Proxy B sends its own CANCEL on its own hop, with the branch of its own INVITE.
- Bob → Proxy B: 200 OK (CANCEL). Bob's phone stops ringing and answers the CANCEL.
- Bob → Proxy B: 487 Request Terminated. Bob's phone ends the INVITE transaction with 487.
- Proxy B → Bob: ACK. Proxy B confirms the 487 on its hop. This ACK reuses the branch of the INVITE.
- Proxy B → Alice: 487 Request Terminated. Proxy B forwards the 487 to Alice's phone.
- Alice → Proxy B: ACK. Alice's phone confirms the 487. The call never started.
Once the INVITE has a final response, CANCEL does nothing. An answered call ends with BYE.
“CANCEL has no effect on a request to which a UAS has already given a final response.”Read the section ↗
OPTIONS: “what can you do?”
OPTIONS asks a user agent or a server for its capabilities. The callee’s phone does not ring. The 200 OK lists the methods in Allow, the extensions in Supported, the body types in Accept, and often the codecs in an SDP body.
Call flow · OPTIONS
OPTIONS asks what Bob's phone can do
- SIP
Alice's phone asks Bob's phone about its capabilities. Bob's phone does not ring.
All steps as text
- Alice → Bob: OPTIONS. Alice's phone asks Bob's phone about its capabilities. Bob's phone does not ring.
- Bob → Alice: 200 OK. Bob's phone lists its methods in Allow, its extensions in Supported, and its media in the SDP.
“This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without "ringing" the other party.”Read the section ↗
5.2 Extension methods
Eight more methods are common. Each comes from its own RFC, and a user agent lists the ones it accepts in Allow. The method cards above show a ladder for each.
| Method | RFC | Typical use |
|---|---|---|
| PRACK | 3262 | Confirms a reliable 1xx, such as a 183 with early media |
| UPDATE | 3311 | Changes the session before or after the answer; session timer refresh |
| INFO | 6086 | Application data inside a call, with an Info Package |
| SUBSCRIBE | 6665 | Asks for notifications: presence, voicemail, call state |
| NOTIFY | 6665 | Sends those notifications |
| REFER | 3515 | Asks the other side to call a third party: call transfer |
| MESSAGE | 3428 | Instant messages, and SMS over IMS |
| PUBLISH | 3903 | Uploads presence or other event state to a server |
PRACK gives provisional responses the reliability that ACK gives to a 2xx response — useful for a 183 with early media, which must not be lost:
“The PRACK request plays the same role as ACK, but for provisional responses.”Read the section ↗
UPDATE changes the session without touching the dialog, so it also works while the phone still rings, when a re-INVITE is not allowed:
“It can be sent by a UA within a dialog (early or confirmed) to update session parameters without impacting the dialog state itself.”Read the section ↗
INFO carries application data inside an existing call:
“The purpose of the INFO message is to carry application level information between endpoints, using the SIP dialog signaling path.”Read the section ↗
SUBSCRIBE and NOTIFY form the SIP events framework: a subscriber asks for an event package, and the notifier reports the state at once and on every change. REFER builds on it. In call transfer, Alice asks Bob’s phone to call Carol, and Bob’s phone reports progress with NOTIFY:
“For instance, if Alice is in a call with Bob, and decides Bob needs to talk to Carol, Alice can instruct her SIP user agent (UA) to send a SIP REFER request to Bob's UA providing Carol's SIP Contact information.”Read the section ↗
“Specifically, an element accepting a REFER request MUST NOT reply with a 202 response code and MUST treat any 202 responses received as identical to a 200 response.”Read the section ↗
MESSAGE carries one instant message, outside any dialog. PUBLISH sends a user agent’s own state, such as “busy”, to the server that shares it with subscribers.
“MESSAGE requests normally carry the instant message content in the request body.”Read the section ↗
5.3 Which methods make a dialog
A dialog is the lasting relationship between two user agents for one call or one subscription (Module 9). Only some methods create one:
“Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog.”Read the section ↗
| Methods | How to recognise it in a trace | |
|---|---|---|
| Creates a dialog | INVITE, SUBSCRIBE, and REFER (through its implicit subscription) | No To tag in the request; the response adds one |
| Only inside a dialog | BYE, ACK for a 2xx, PRACK, UPDATE, INFO, NOTIFY, re-INVITE | The To header has a tag; the Request-URI is the other side’s Contact |
| Outside any dialog | REGISTER, OPTIONS, MESSAGE, PUBLISH | No To tag, and no dialog follows |
| Special | CANCEL, and the ACK for a failure | Part of the INVITE transaction they belong to |
A request inside a dialog is an in-dialog requestin-dialog request. A request sent inside an existing dialog. It carries both tags and follows the dialog's route set.. It carries both tags, the dialog’s Call-ID, and a CSeq one higher than the last request from that side. A BYE is the clearest example:
“A UA MUST NOT send a BYE outside of a dialog. The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs.”Read the section ↗
“Because SUBSCRIBE requests create a dialog usage as defined in [RFC3261], they MAY contain an "Accept" header field.”Read the section ↗
5.4 Capability headers
SIP grows through extensions. Each extension has an option tagoption tag. The name of a SIP extension, such as 100rel or timer, used in Supported, Require, and Unsupported., such as 100rel or timer. Five headers let two user agents agree on which extensions to use:
| Header | Means | Sent in |
|---|---|---|
| Allow | “These are the methods I accept.” | Requests and responses |
| Supported | “I understand these extensions. Use them if you want.” | Requests and responses |
| Require | “You must understand these extensions, or reject my request.” | Requests; reliable 1xx |
| Proxy-Require | Like Require, but for every proxy on the path | Requests |
| Unsupported | “I do not understand these extensions from your Require.” | 420 responses |
“The Supported header field enumerates all the extensions supported by the UAC or UAS.”Read the section ↗
If a user agent does not understand an option tag in Require, it must refuse the request:
“If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension). The UAS MUST add an Unsupported header field, and list in it those options it does not understand amongst those in the Require header field of the request.”Read the section ↗
“The Proxy-Require header field is used to indicate proxy-sensitive features that must be supported by the proxy.”Read the section ↗
The opposite case also exists: the callee needs an extension that the caller did not list in Supported. It can answer 421 Extension Required — but only as a last resort:
“A UAS SHOULD NOT use this response unless it truly cannot provide any useful service to the client.”Read the section ↗
Set what each phone supports or requires, and see which response comes back.
Capability negotiation
Supported, Require — and who says no
- SIP
- Error response
| Option tag | Alice's phone (UAC) puts it in… | Bob's phone (UAS)… |
|---|---|---|
100relReliable provisional responses, confirmed with PRACK · RFC 3262 | ||
timerSession timers: refresh the call, or end it if the other side is gone · RFC 4028 | ||
replacesThe Replaces header, used in attended transfer · RFC 3891 | ||
preconditionDo not ring until network resources are reserved · RFC 3312 | ||
norefersubREFER without the implicit subscription · RFC 4488 |
The call works. Both phones understand: timer, replaces.
Alice's INVITE
INVITE sip:bob@biloxi.example SIP/2.0 Supported: 100rel, timer, replaces
Bob's answer
SIP/2.0 200 OK Supported: timer, replaces
RFC 3261 §20.37 · Supported
“The Supported header field enumerates all the extensions supported by the UAC or UAS.”
Read the section ↗
- INVITE. Alice's phone lists its extensions in Supported and Require.
- 180 Ringing. Bob's phone rings. This 180 is not reliable.
- 200 OK. Bob answers. Supported lists what Bob's phone understands.
- ACK. Alice's phone confirms the 200 OK.
Common mistakes
Sending CANCEL after the 200 OK
When the callee answers at the same moment the caller hangs up, a phone may send CANCEL. But the INVITE already has its final response, so the CANCEL has no effect: the callee stays in the call, talking to silence. Once a 2xx arrives, the call exists — confirm it with ACK, then end it with BYE.
Broken
Broken: CANCEL after the 200 OK
- SIP
- RTP media
- ⚠Problem
Alice's phone calls Bob's phone.
All steps as text
- Alice → Bob: INVITE. Alice's phone calls Bob's phone.
- Bob → Alice: 180 Ringing. Bob's phone rings.
- Bob → Alice: 200 OK. Bob answers, at the same moment that Alice decides to hang up.
- Alice → Bob: ACK. Alice's phone confirms the 200 OK. The call is now set up.
- Alice → Bob: CANCEL. Alice's phone sends CANCEL to end the call. Problem: The INVITE already has its final response. CANCEL cannot end an answered call.
- Bob → Alice: 200 OK (CANCEL). Bob's phone accepts the CANCEL, but nothing else happens. Problem: Bob's phone stays in the call. Depending on timing, the answer is 481 instead.
- Bob → Alice: RTP still flows. Bob's phone still sends media. Bob hears silence and waits for Alice. Problem: The call stays up until Bob hangs up, or until a session timer ends it.
Putting an option tag in Require that the peer does not support
Require means “reject me if you do not understand this”. A phone that puts Require: 100rel or Require: precondition in every INVITE fails with every peer that lacks that extension — 420 Bad Extension, with the tag in Unsupported.
Remember: use Supported unless the call truly cannot work without the extension. Check the peer with OPTIONS first.
Using INFO for DTMF without an agreed Info Package
Many devices send key presses in INFO with a vendor body, such as application/dtmf-relay. Nothing in the call says that the other side understands it, so digits get lost between vendors.
“Companies have been using INFO messages in order to transport Dual-Tone Multi-Frequency (DTMF) tones. All mechanisms are proprietary and have not been standardized.”Read the section ↗
Remember: the standard way is RFC 4733 telephone-events inside the RTP stream (Module 16). Use INFO only with an Info Package that both sides announce in Recv-Info.
Sending CANCEL before any provisional response
A phone that cancels an INVITE before it receives 100 Trying or 180 Ringing breaks the rule in RFC 3261 §9.1. The CANCEL can overtake the INVITE, find no transaction, and get 481 — while the INVITE then rings the callee.
Remember: wait for a provisional response. If none comes, let the INVITE time out.
Expecting 202 Accepted for REFER
Old traces and old monitoring rules expect 202 Accepted for a REFER. Since RFC 7647, a REFER is accepted with 200 OK, and a 202 counts as a 200.
Remember: treat any 2xx to REFER as success.
Summary
- The method is the first word of a request. RFC 3261 defines INVITE, ACK, BYE, CANCEL, REGISTER, and OPTIONS.
- ACK is the only request without a response. CANCEL only works before the final response; after it, use BYE.
- Common extension methods are PRACK, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, and PUBLISH. A user agent lists the methods it accepts in Allow.
- INVITE and SUBSCRIBE (and REFER, through its subscription) create dialogs. BYE, PRACK, UPDATE, INFO, and NOTIFY only work inside one. REGISTER, OPTIONS, MESSAGE, and PUBLISH work outside.
- Supported offers extensions; Require demands them. An unknown tag in Require gets 420 Bad Extension with Unsupported. A callee that needs a missing extension can answer 421 Extension Required.