Source record · tier 1 standards and regulators
RFC 3261 — SIP: Session Initiation Protocol
- Publisher
- IETF / RFC Editor
- URL
- https://www.rfc-editor.org/rfc/rfc3261.html
- Published
- 2002-06
- Updated
- unknown
- Accessed
- 2026-09-04
- HTTP status
- 200
- License
- IETF Trust / BCP 78; permitted with the RFC's own copyright and license notices intact
Claims citing this source
- A 403 Forbidden means the server understood the request and is refusing to fulfil it and that authorisation will not help and the request should not be repeated. fact in context
- A 404 Not Found means the server has definitive information that the user does not exist at the domain in the request address or that the domain is not one it handles. fact in context
- A 480 Temporarily Unavailable means the destination system was contacted successfully and the user is currently unavailable for example not signed in or in a state that precludes communication or with do not disturb active. fact in context
- A 486 Busy Here means the destination system was contacted successfully and the user is not willing or able to take additional calls at that end system. fact in context
- A 488 Not Acceptable Here means the request may succeed elsewhere and applies only to the resource addressed and may carry a body describing the media capabilities the responder does support. fact in context
- A 503 Service Unavailable means the server is temporarily unable to process the request through overloading or maintenance and a client receiving one should try an alternate server. fact in context
- A 603 Decline means the destination machine was contacted successfully and the user explicitly does not wish to or cannot participate and is returned only when the client knows no other endpoint will answer. fact in context
- A 1xx response is provisional and every other class is final and a final response completes the transaction. fact in context
- SIP response codes fall into 6 classes: 1xx provisional 2xx success 3xx redirection 4xx request failure 5xx server failure and 6xx global failure. fact in context
- RFC 3261 names 8 lettered timers: A and E set a request retransmit interval starting at the round trip estimate B and F set a transaction timeout at 64 times it C sets a proxy timeout above 3 minutes G sets a response retransmit interval H sets the wait for an acknowledgement at 64 times the estimate and D I J and K set wait times for retransmissions to die out. fact in context
- Because all four retransmission timers are 0 on a reliable transport, a capture taken over TCP or TLS contains no request retransmission at all, so the absence of retransmissions in such a capture is a property of the transport and is not evidence about the network or the peer. inference in context
- Timer C is the only transaction timer given as an absolute duration rather than a multiple of the round trip estimate and it is stated as greater than 3 minutes. fact in context
- Timer G sets the interval at which a server retransmits an INVITE response starting at the round trip estimate and capped by the 4 second maximum. fact in context
- Three constants underlie every SIP transaction timer: a round trip estimate defaulting to 500 milliseconds a maximum retransmit interval of 4 seconds for non-INVITE requests and INVITE responses and a maximum network lifetime of 5 seconds for a message. fact in context
- Timer H sets the wait for an acknowledgement at 64 times the round trip estimate and its expiry is what ends a server transaction that never received one. fact in context
- Four timers are scoped to an unreliable transport and become 0 on a reliable one: A and E do not retransmit at all and D I J and K wait 0 seconds instead of their unreliable values. fact in context
- The acknowledgement of a 2xx response to an INVITE is a separate transaction from the INVITE it acknowledges. fact in context
- A branch identifier written by an implementation of this specification must begin with the 7 characters z9hG4bK so that a server can tell it was constructed to this specification. fact in context
- The branch parameter on the topmost routing header is the transaction identifier and must be unique across space and time for every request a user agent sends. fact in context
- Two requests reuse the branch and sequence number of the request they refer to by design: a cancellation must carry a single routing header matching the top one of the request being cancelled and the identical numeric part of the sequence header, and an acknowledgement of a non-2xx response must carry a routing header equal to the top one of the original request and the same sequence number with the method set to acknowledge. fact in context
- The sequence header identifies and orders transactions and consists of a number and a method that must match the request. fact in context
- A request repeated with the same branch identifier and the same sequence number is the same transaction retransmitting rather than a new request except in the 2 cases where the protocol reuses both by design. inference in context
- An INVITE is not retransmitted over a reliable transport and retransmissions cease altogether once a provisional response arrives. fact in context
- The INVITE server transaction is destroyed as soon as it passes a 2xx final response to the transport so retransmitting that response is the responsibility of the user agent rather than the transaction layer. fact in context
- The INVITE transaction timeout is 64 times the round trip time estimate whose default is 500 milliseconds giving 32 seconds. fact in context
- The originating user agent must generate an acknowledgement for each 2xx it receives with the same sequence number as the INVITE and the method set to acknowledge. fact in context
Cite this source record
APA
WarmTransfer. (n.d.). RFC 3261 — SIP: Session Initiation Protocol. WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-3261-sip
BibTeX
@misc{warmtransfer-rfc-3261-sip,
title = {RFC 3261 — SIP: Session Initiation Protocol},
author = {{WarmTransfer}},
year = {2002},
url = {https://warmtransfer.net/knowledge/sources/rfc-3261-sip},
note = {IETF / RFC Editor, accessed 2026-09-04}
}