SIP Methods and Responses Explained: INVITE, ACK, BYE, REGISTER and Timers
SIP methods and responses are essential concepts in Voice over Internet Protocol (VoIP), IP telephony, SIP trunking, and real-time communication systems. Understanding SIP requests, response codes, transaction timers, and session timers helps engineers troubleshoot call setup failures, registration issues, unexpected call disconnections, and audio problems.
In this practical guide, you will learn how the most common SIP methods work, understand INVITE versus non-INVITE transactions, explore important SIP response codes, and review real-world SIP call-flow examples.
What Is SIP (Session Initiation Protocol)?
Session Initiation Protocol (SIP) is a signaling protocol used to establish, modify, and terminate communication sessions over IP networks. It is widely used in VoIP phone systems, IP PBX platforms, SIP trunks, softphones, contact centers, and internet-based voice and video applications.
SIP handles signaling between communication endpoints and network elements. The actual voice media is commonly transported using the Real-time Transport Protocol (RTP), while the Session Description Protocol (SDP) is frequently used to negotiate media capabilities and connection details.
It is important to remember that SIP signaling and RTP media are different. A call can connect successfully at the SIP level but still have no audio because of firewall restrictions, NAT issues, codec incompatibility, or RTP routing problems.
What Are SIP Methods?
SIP methods identify the action requested by a SIP message. For example, INVITE requests session establishment, ACK acknowledges a final INVITE response, BYE terminates an established session, and REGISTER updates a user’s contact information with a registrar.
Each method has a defined purpose, and its expected response depends on the request, the receiving endpoint, and the applicable SIP specifications.
SIP Methods and Responses: Quick Reference Table
| SIP Method | Purpose | Typical Response |
|---|---|---|
| INVITE | Requests session establishment or modification. | 100 Trying, 180 Ringing, 200 OK |
| ACK | Acknowledges a final response to INVITE. | No separate SIP response is expected. |
| BYE | Terminates an established session. | 200 OK |
| CANCEL | Attempts to cancel a pending request, typically INVITE. | 200 OK to CANCEL; the original INVITE may receive 487 Request Terminated. |
| REGISTER | Registers contact information with a SIP registrar. | 200 OK after successful registration |
| OPTIONS | Queries capabilities or reachability information. | 200 OK when successfully processed |
| REFER | Requests another operation, commonly a call transfer. | 202 Accepted is common |
| NOTIFY | Delivers event notifications. | 200 OK when successfully processed |
| INFO | Carries application-level information within a SIP dialog. | 200 OK when successfully processed |
| UPDATE | Modifies session parameters. | 200 OK when successfully processed |
| PRACK | Acknowledges reliable provisional responses. | 200 OK when successfully processed |
| MESSAGE | Sends instant messages using SIP. | 200 OK when successfully processed |
These are typical examples rather than guaranteed responses for every situation. SIP behavior also depends on applicable extensions, transport, and endpoint implementation.
1. SIP INVITE Method: How a Call Starts
The INVITE method requests the establishment of a communication session. An initial INVITE commonly contains an SDP offer describing the caller’s supported codecs, media capabilities, and transport information.
Example of a SIP INVITE call flow
Caller Callee | | |-------- INVITE (SDP) -------->| |<------- 100 Trying -----------| |<------- 180 Ringing ----------| |<------- 200 OK (SDP) ---------| |-------- ACK ----------------->| | | |======== RTP Audio ============| | |
How the flow works:
- INVITE: Requests a new communication session.
- 100 Trying: Indicates that the request is being processed.
- 180 Ringing: Indicates that the destination is being alerted.
- 200 OK: Indicates successful acceptance of the INVITE.
- ACK: Acknowledges the successful final response.
- RTP: Commonly carries the actual audio after media negotiation and connectivity are established.
Not every call follows exactly this sequence. A call may include 183 Session Progress, early media, authentication challenges, or other provisional and final responses.
Common SIP INVITE response codes
- 100 Trying: Request processing has started.
- 180 Ringing: The destination is being alerted.
- 183 Session Progress: Provides provisional session progress information and may support early media.
- 200 OK: The INVITE has been accepted.
- 401 Unauthorized: Authentication is required or has not been satisfied.
- 403 Forbidden: The request has been refused.
- 404 Not Found: The requested destination or resource cannot be found.
- 408 Request Timeout: A request timed out.
- 486 Busy Here: The destination is busy.
- 487 Request Terminated: The request was terminated, commonly following cancellation.
- 488 Not Acceptable Here: The offered session parameters cannot be accepted.
- 500 Server Internal Error: The server encountered an internal error.
- 503 Service Unavailable: The server is temporarily unable to handle the request.
2. SIP ACK Method: Acknowledging an INVITE Response
ACK acknowledges a final response to an INVITE. Its handling depends on whether the final response is successful or unsuccessful.
For a successful 2xx response, the caller sends an ACK within the established dialog. For a non-2xx final response, ACK is handled through the INVITE transaction procedures.
Troubleshooting tip: If your SIP trace repeatedly shows 200 OK for an INVITE, check whether the corresponding ACK is being generated and routed correctly. Retransmissions of a 2xx response may occur when the required ACK is not received.
3. SIP BYE Method: Terminating an Established Call
The BYE method terminates an established SIP session. Either participant can normally initiate BYE within the appropriate dialog.
Example BYE call flow
Caller Callee | | |-------- BYE ----------------->| |<------- 200 OK ---------------| | | |========== Call Ended =========|
A successful BYE normally receives a 200 OK response. If no response arrives, investigate network connectivity, routing, packet loss, firewall rules, and endpoint behavior.
BYE and CANCEL have different purposes. BYE terminates an established session, whereas CANCEL attempts to stop a pending request before its final response has been received.
4. SIP CANCEL Method: Cancelling a Pending Request
CANCEL is commonly used to attempt to cancel an INVITE that has not yet received a final response.
Example CANCEL call flow
Caller Callee | | |-------- INVITE -------------->| |<------- 100 Trying -----------| |-------- CANCEL -------------->| |<------- 200 OK (CANCEL) ------| |<------- 487 Request Terminated| |-------- ACK ----------------->| | |
The 200 OK acknowledges the CANCEL request. It does not indicate that the original INVITE succeeded. When cancellation succeeds before acceptance, the original INVITE commonly receives 487 Request Terminated.
If the INVITE receives a successful 2xx response while cancellation is in progress, the session may already have been accepted. The endpoint may need to complete the dialog and use BYE if the call should be terminated.
5. SIP REGISTER Method: Registration and Authentication
REGISTER allows a SIP user agent to register contact information with a registrar so that incoming requests can be routed to the appropriate device or endpoint.
Example REGISTER authentication flow
SIP Phone Registrar | | |-------- REGISTER ------------>| |<------- 401 Unauthorized -----| |-------- REGISTER + Auth ----->| |<------- 200 OK ---------------| | |
A 401 Unauthorized response can be a normal part of SIP Digest authentication. The registrar challenges the client, which then sends another REGISTER request with the required authentication information.
A 407 Proxy Authentication Required response may also occur, depending on the authentication mechanism and network configuration.
Common SIP registration problems
- 401 Unauthorized: Check whether the authenticated REGISTER request follows the challenge.
- 403 Forbidden: Review account permissions, credentials, provisioning, and provider restrictions.
- 408 Request Timeout: Check network connectivity, DNS, firewall rules, and registrar reachability.
- Registration expires: Check the expiry interval and refresh behavior.
- Repeated authentication challenges: Review the authentication realm, username, credentials, and nonce handling.
Successful registration does not guarantee that outbound calls, inbound calls, or RTP audio will work correctly.
6. SIP OPTIONS Method: Checking Capabilities
OPTIONS can query the capabilities of a SIP server or endpoint. Depending on the target and implementation, its response may provide information about supported methods and extensions.
Monitoring System SIP Endpoint | | |-------- OPTIONS ------------->| |<------- 200 OK ---------------| | |
OPTIONS is commonly used for reachability checks and SIP monitoring. However, a successful OPTIONS response does not guarantee that a complete call or RTP audio session will work.
7. SIP REFER and NOTIFY: Call Transfer
REFER is commonly used to request a call transfer or ask another endpoint to initiate a request. When the relevant event-subscription procedures apply, NOTIFY messages may communicate the progress of the referred operation.
Simplified REFER flow
Transferor Recipient | | |-------- REFER --------------->| |<------- 202 Accepted ---------| |<------- NOTIFY ---------------| |-------- 200 OK -------------->| | |
A 202 Accepted response means the REFER request has been accepted for processing; it does not, by itself, prove that the transferred call succeeded.
When troubleshooting a failed transfer, inspect the REFER request, its response, the associated NOTIFY messages, and the resulting call attempt.
8. SIP INFO, UPDATE, PRACK and MESSAGE
INFO method
INFO carries application-level information within a SIP dialog. Some systems use it for DTMF signaling, but DTMF can also be transported through RTP telephone events or other supported mechanisms. Confirm the endpoint and provider's configuration before diagnosing INFO-related issues.
UPDATE method
UPDATE allows session parameters to be modified, including certain SDP offer/answer exchanges. It can be used before a session is fully established when the applicable SIP procedures permit it.
PRACK method
PRACK acknowledges reliable provisional responses when the 100rel extension is being used. It differs from ACK, which acknowledges final INVITE responses.
MESSAGE method
MESSAGE transmits instant messaging content using SIP. Its success depends on whether the destination supports the method and can process the message content.
INVITE vs Non-INVITE Transactions
A SIP transaction consists of a request and the associated response processing. INVITE transactions follow special rules because they establish communication sessions. Non-INVITE transactions use different transaction-state and timer procedures.
| Feature | INVITE Transaction | Non-INVITE Transaction |
|---|---|---|
| Purpose | Requests session establishment or modification. | Handles other SIP operations. |
| Examples | INVITE | BYE, CANCEL, REGISTER, OPTIONS, REFER, NOTIFY, INFO, UPDATE, PRACK and MESSAGE |
| Responses | May include 100 Trying, 180 Ringing and 200 OK. | Responses depend on the specific method and procedure. |
| ACK handling | ACK is required for final INVITE responses, with different handling for 2xx and non-2xx responses. | ACK is not generally used to acknowledge non-INVITE responses. |
| Session creation | An initial INVITE can establish a session. | These methods generally do not establish a new session on their own. |
Transaction timers and session timers are different. Transaction timers govern request/response processing, while session timers help refresh an established session.
SIP Response Codes Explained
SIP response codes are three-digit numbers. The first digit identifies the general response category.
| Code Class | Meaning | Examples |
|---|---|---|
| 1xx | Provisional response | 100 Trying, 180 Ringing, 183 Session Progress |
| 2xx | Successful response | 200 OK, 202 Accepted |
| 3xx | Redirection | 301 Moved Permanently, 302 Moved Temporarily |
| 4xx | Request failure | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 408 Request Timeout, 486 Busy Here, 487 Request Terminated, 488 Not Acceptable Here |
| 5xx | Server failure | 500 Server Internal Error, 502 Bad Gateway, 503 Service Unavailable |
| 6xx | Global failure | 600 Busy Everywhere, 603 Decline |
When investigating a SIP response, examine the request method, response code, SIP headers, Call-ID, CSeq, timestamps, and surrounding messages. A response code alone may not reveal the root cause.
SIP Transaction Timers Explained
SIP transaction timers manage request retransmissions, response waiting periods, and transaction cleanup. Timer behavior depends on the transaction type, transport protocol, and transaction state.
| Timer | Purpose |
|---|---|
| Timer A | Retransmits an INVITE request over an unreliable transport. |
| Timer B | Controls the overall timeout for an INVITE client transaction. |
| Timer D | Retains the completed state of an INVITE client transaction after a non-2xx final response. |
| Timer E | Retransmits a non-INVITE request over an unreliable transport. |
| Timer F | Controls the overall timeout for a non-INVITE client transaction. |
| Timer G | Retransmits a non-2xx final response from an INVITE server transaction over an unreliable transport. |
| Timer H | Waits for ACK to a non-2xx final response in an INVITE server transaction. |
| Timer I | Controls the confirmed-state duration after ACK for a non-2xx final response. |
| Timer J | Controls the completed-state duration of a non-INVITE server transaction. |
| Timer K | Controls the completed-state duration of a non-INVITE client transaction. |
These timers do not all apply to every SIP transaction. Exact values and behavior depend on the applicable SIP rules and transport. Use packet captures and the relevant transaction procedure to identify the actual cause of a timeout.
SIP Session Timers and RFC 4028
SIP session timers are different from transaction timers. RFC 4028 defines a mechanism for refreshing an established session so that participating endpoints can determine whether the session is still maintained.
Session refreshes commonly use re-INVITE or UPDATE, depending on endpoint capabilities and negotiated behavior. If a refresh fails or does not complete within the applicable interval, the session may be terminated according to the negotiated rules.
For calls that disconnect after a consistent duration, inspect the Session-Expires and Min-SE headers, refresher negotiation, re-INVITE or UPDATE exchanges, and relevant response codes.
A 422 Session Interval Too Small response indicates that the requested session interval is below the minimum accepted interval. The response provides a Min-SE value indicating the required minimum.
Common SIP Troubleshooting Scenarios
Problem 1: INVITE receives no response
- Verify the Request-URI and destination routing.
- Check DNS resolution and SIP transport connectivity.
- Review firewall rules, NAT behavior, and packet captures.
- Confirm that the destination server is reachable.
Problem 2: SIP 401 Unauthorized
- Determine whether the authentication challenge is expected.
- Check whether the client sends a subsequent authenticated request.
- Review the username, authentication realm, credentials, and nonce handling.
- Investigate repeated challenges or final authentication failure.
Problem 3: SIP 488 Not Acceptable Here
- Compare the SDP offer and answer.
- Check codec compatibility and media parameters.
- Review supported media types and transport profiles.
- Confirm the endpoint's media negotiation requirements.
Problem 4: Call connects but there is no audio
- Confirm that INVITE, 200 OK, and ACK signaling completed correctly.
- Inspect SDP connection addresses, ports, and negotiated codecs.
- Verify RTP packet flow in both directions.
- Investigate NAT, firewall, media relay, and routing issues.
Problem 5: Call disconnects after a fixed duration
- Check whether a BYE was sent and identify its source.
- Inspect session refresh messages and Session-Expires headers.
- Review missing ACK or session refresh responses where relevant.
- Compare endpoint, SBC, and packet-capture logs using timestamps and Call-ID.
Frequently Asked Questions About SIP Methods and Responses
What are the main SIP methods?
The main methods include INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS, REFER, NOTIFY, INFO, UPDATE, PRACK, and MESSAGE. Other SIP extensions define additional methods and behavior.
What is the difference between SIP INVITE and ACK?
INVITE requests a session or session modification. ACK acknowledges a final response to an INVITE and does not receive a separate SIP response.
What is the difference between BYE and CANCEL?
BYE terminates an established session, whereas CANCEL attempts to cancel a pending request, typically an INVITE that has not received a final response.
What does SIP 100 Trying mean?
100 Trying indicates that the request is being processed. It does not mean the call has been answered or that the session has been established.
What does SIP 180 Ringing mean?
180 Ringing indicates that the destination is being alerted. It does not necessarily mean the recipient has answered the call.
What does SIP 183 Session Progress mean?
183 Session Progress is a provisional response that can convey session progress information and may be associated with early media.
Is SIP 401 Unauthorized always an error?
No. A 401 response can be a normal authentication challenge, particularly during registration. It becomes a troubleshooting concern if authentication fails or the expected follow-up request does not occur.
What is the difference between transaction timers and session timers?
Transaction timers control SIP request/response processing and transaction cleanup. Session timers, defined in RFC 4028, help refresh an established communication session.
Does SIP 200 OK guarantee that audio is working?
No. SIP 200 OK indicates successful processing of a request, but it does not guarantee that RTP media is working. SDP negotiation, codecs, NAT, firewall rules, and RTP packet flow should be checked separately.
Which RFC defines SIP methods and transaction behavior?
RFC 3261 defines the core Session Initiation Protocol, including its fundamental methods, responses, and transaction behavior. RFC 4028 specifies SIP session timers.
Official SIP Standards and Further Reading
- RFC 3261 – SIP: Session Initiation Protocol
- RFC 4028 – Session Timers in SIP
- IANA SIP Parameters Registry – Methods and Response Codes
Conclusion
Understanding SIP methods and responses is essential for VoIP engineers, SIP administrators, telecom support teams, and developers working with real-time communication systems.
INVITE establishes a session, ACK acknowledges final INVITE responses, BYE terminates an established session, CANCEL attempts to stop a pending request, and REGISTER manages contact registration. Understanding common response codes and the difference between transaction timers and session timers makes SIP troubleshooting more effective.
Bookmark this guide as a practical reference for SIP call-flow analysis, VoIP troubleshooting, and technical interview preparation.
Related topics: SIP response codes, SIP INVITE troubleshooting, SIP registration failures, RTP audio troubleshooting, SIP transaction timers, and SIP session timers.
