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

Source notes citing this source

In SIP digest authentication a user agent server challenges with 401 Unauthorized and a proxy challenges with 407 Proxy Authentication Required. in context
After a 401 the client retries with an Authorization header, and after a 407 with a Proxy-Authorization header. in context
SIP digest authentication does not protect the message body. in context
SIP registrations expire and must be refreshed before expiry to keep the binding active. in context
RFC 3261 says implementations SHOULD use TLS to protect SIP messages, and TLS encrypts the whole SIP message on each hop. in context
A back-to-back user agent receives a request as a UAS and generates its own requests as a UAC, and unlike a proxy it maintains dialog state. in context
In SIP the Call-ID header field carries a globally unique identifier for the call and groups the messages belonging to it. in context
A SIP dialog is identified by the combination of the Call-ID, the local tag and the remote tag. in context
SIP final failure responses fall into three classes: 4xx client error, 5xx server error and 6xx global failure. in context
In SIP a registrar or user agent challenges with 401 Unauthorized and a proxy with 407 Proxy Authentication Required, and the client retries with credentials. in context
The SIP OPTIONS method queries a server about its capabilities without setting up a call, which is what an out-of-dialog OPTIONS keepalive uses. in context
RFC 3261 says a UAC receiving 491 to a re-INVITE waits a random 2.1 to 4 seconds before retrying if it owns the Call-ID and 0 to 2 seconds otherwise. in context
RFC 3261 says that if a re-INVITE fails (for example with 488) the existing call does not fail and the session continues with the previously negotiated characteristics. in context
RFC 3261 says a UAC MUST NOT start a new INVITE (such as a hold or resume re-INVITE) while another INVITE transaction is in progress in the same dialog. in context
RFC 3261 defines a stateful proxy as one that maintains the client and server transaction state machines while processing a request, also called a transaction stateful proxy. in context
RFC 3261 defines a stateless proxy as a logical entity that does not maintain the client or server transaction state machines and forwards every request downstream and every response upstream. in context
RFC 3261 says a failed re-INVITE does not by itself cause the existing call to fail; the session continues with the previously negotiated parameters. in context
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. in context
RFC 3261 defines 403 Forbidden as a response where the server understood the request but refuses to fulfil it, states that authorization will not help, and says the request should not be repeated. in context
RFC 3261 has a registrar answer a REGISTER with 403 Forbidden when the authenticated user is not authorized to modify the bindings of the address-of-record. in context
RFC 3261 defines 404 Not Found as the server having definitive information that the user does not exist at the domain specified in the Request-URI. in context
RFC 3261 defines 484 Address Incomplete as a response indicating that the Request-URI was incomplete. in context
RFC 3261 states that the 484 status code allows overlapped dialling, in which a client that does not know the dial string length sends strings of increasing length until it no longer receives 484. in context
Under RFC 3261 a UAS whose Request-URI does not identify an address it is willing to accept should reject the request with 404 Not Found. 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. in context
A 408 that the caller's own UA or proxy reports after a run of retransmitted INVITEs with no response in the trace was most likely generated locally on transaction timeout, so the trace point where responses stop, not the 408, locates the fault. inferred in context
With RFC 3261 defaults over UDP, an unanswered INVITE is expected to be retransmitted at roughly 0.5, 1.5, 3.5, 7.5, 15.5 and 31.5 seconds after the first send (seven transmissions) before Timer B ends the transaction at 32 seconds; Cisco's default 'retry invite 6' with 'timers trying 500' produces the same count. inferred in context
RFC 3261 defines 408 Request Timeout as the server being unable to produce a response within a suitable amount of time, for example because it could not determine the location of the user in time. in context
A stateful proxy forwarding an INVITE runs Timer C, which must be greater than 3 minutes; if it fires without a final response the proxy cancels the branch or, absent a provisional response, treats it as a 408. in context
RFC 3261 recommends a default T1 (RTT estimate) of 500 ms and a T2 (maximum retransmit interval for non-INVITE requests and INVITE responses) of 4 seconds. in context
Over a reliable transport such as TCP or TLS, the INVITE client transaction does not retransmit the request, so a trace of a timed-out INVITE over TCP shows a single INVITE rather than a retransmission series. in context
Under RFC 3261 a UAC that receives a timeout error from its transaction layer treats it as if a 408 Request Timeout response had been received, so a 408 reported by a UAC need not have crossed the wire. in context
For an INVITE client transaction over an unreliable transport, Timer A starts at T1 and the retransmission interval doubles each time Timer A fires. in context
RFC 3261 sets the INVITE transaction timeout, Timer B, to 64*T1, which is 32 seconds with the default T1 of 500 ms. in context
Under RFC 3261 a fatal transport error (such as a fatal ICMP error over UDP or a TCP connection failure) is treated by the UAC as a 503 Service Unavailable, not as a 408. 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. 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. in context
Under RFC 3261 a failed re-INVITE does not tear down the existing call; the session continues with the previously negotiated characteristics. in context
RFC 3261 defines 415 Unsupported Media Type as the server refusing a request because the message body is in a format the server does not support for that method; it concerns the body type (for example the Content-Type) rather than codecs inside SDP. in context
RFC 3261 defines 488 Not Acceptable Here in section 21.4.26 as a 4xx rejection of the session description offered in the request, scoped to the addressed resource, with 606 Not Acceptable in section 21.6.4 as its global-failure counterpart. 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. 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. 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. in context
Under RFC 3261, a server that receives a request whose top Via sent-by host is a domain name, or an IP address that differs from the packet's source address, adds a received parameter carrying the actual source address to that Via. in context
The SIP Call-ID header carries a globally unique identifier for the call, and together with the To and From tags identifies a dialog. in context
The first digit of a SIP status code defines its class: 1xx provisional, 2xx success, 3xx redirection, 4xx client error, 5xx server error and 6xx global failure. in context
Under RFC 3261, if a UAS retransmits its 2xx response to an INVITE for 64*T1 seconds without receiving an ACK, the dialog is confirmed but the session SHOULD be terminated with a BYE. in context
In SIP an initial INVITE may carry an SDP offer in its body but is not required to; an INVITE without an offer is permitted by RFC 3261. in context
If the initial INVITE contains no offer, the offer is carried in the first reliable non-failure response from the UAS (the 2xx in base RFC 3261) and the answer must then be carried in the ACK. in context
A UAS that receives an INVITE without an offer must generate an offer in a reliable response. in context
A 1xx response is provisional and every other class is final and a final response completes the transaction. in context
RFC 3261 gives proxies an optional loop-detection check that inspects Via header values (sent-by plus branch parameter) and, on detecting a loop, responds 482 (Loop Detected). in context
The SIP response code 483 Too Many Hops means that the server received a request whose Max-Forwards value was zero; 482 Loop Detected means that the server detected a loop. in context
The SIP Max-Forwards header field limits the number of hops a request can make toward its destination and holds an integer that is decremented by one at each hop. in context
A SIP proxy that receives a request whose Max-Forwards value is zero must not forward it and returns 483 (Too Many Hops), except that it may answer an OPTIONS request addressed to itself. in context
When forwarding a request, a SIP proxy decrements Max-Forwards by one, and if the request carries no Max-Forwards header field the proxy adds one with the value 70. in context
RFC 3261 distinguishes a spiral from a loop: a request that returns to the same proxy with a different Request-URI (for example after call forwarding) is a spiral and is legitimate, not a loop. in context
RFC 3261 requires a SIP UAC to insert a Max-Forwards header field into each request it originates, with an initial value that should be 70. in context
RFC 3261 states the 1300-byte figure for unknown path MTU is based on assuming a 1500-byte Ethernet MTU. in context
RFC 3261 requires a SIP request to be sent over an RFC 2914 congestion-controlled transport such as TCP if it is within 200 bytes of the path MTU, or larger than 1300 bytes when the path MTU is unknown. in context
RFC 3261 explains the 200-byte margin below path MTU as allowance for SIP responses being larger than requests, for example because Record-Route values are added to responses to INVITE. in context
RFC 3261 gives the purpose of the size-based switch to a congestion-controlled transport as preventing fragmentation of SIP messages over UDP and providing congestion control for larger messages. in context
RFC 3261 requires all SIP elements to implement both UDP and TCP. in context
In RFC 3261 the From header indicates the logical identity of the request initiator, possibly the user's address-of-record, and is supplied by the user agent rather than asserted by the network. in context
An implementation that uses RFC 3261 default timers for an OPTIONS transaction with no response would give up after about 32 seconds (64 x 500 ms). Vendors can and do shorten this with their own retry and timeout settings. inferred in context
Per RFC 3261, a 200 OK to OPTIONS should carry Allow, Accept, Accept-Encoding, Accept-Language and Supported header fields describing the responder's capabilities. in context
In SIP, the OPTIONS method asks a UA or server for its capabilities without setting up a session, and it can be sent outside a dialog. in context
RFC 3261 says the response to an OPTIONS should be the one an INVITE would get: 200 if the server would accept an INVITE, 486 Busy Here if it currently cannot take new sessions. in context
In RFC 3261, the timeout for a non-INVITE client transaction (Timer F) is 64*T1, and T1's default is 500 ms. in context
A registrar or UAS challenges with 401 Unauthorized and a WWW-Authenticate header, which the UA answers with Authorization; a proxy challenges with 407 Proxy Authentication Required and a Proxy-Authenticate header, which the UA answers with Proxy-Authorization. in context
RFC 3261 registrar processing returns 403 Forbidden when the authenticated user is not authorized to change registrations for the address-of-record in the REGISTER. in context
RFC 3261 registrar processing returns 404 Not Found when the address-of-record in the To header is not valid for the domain in the Request-URI. in context
RFC 3261 lets a registrar send 423 only when the requested interval is greater than zero, less than one hour and below the registrar's configured minimum. in context
A registrar may reject a REGISTER whose requested expiration is too short with 423 Interval Too Brief carrying a Min-Expires header, and the UA may retry with every contact's expiration set at or above the Min-Expires value. in context
The first digit of a SIP Status-Code gives the response class (for example 4xx is a request failure), and the last two digits carry no categorisation role. in context
Under RFC 3261 a non-INVITE client transaction such as REGISTER over UDP retransmits on Timer E, which starts at T1 (500 ms default) and doubles up to T2 (4 s), and gives up when Timer F fires at 64*T1 (32 s by default). in context
RFC 3261 requires a request larger than 1300 bytes, or within 200 bytes of the path MTU, to be sent over a congestion-controlled transport such as TCP rather than UDP. in context
A 481 or 408 response to a re-INVITE, unlike other non-2xx responses, leads the UAC to terminate the dialog. in context
488 (Not Acceptable Here) means the responding party could not accept the media offered; a Warning header may accompany it to explain why. in context
On a 491 to a re-INVITE the UAC should wait a random 2.1 to 4 seconds if it owns the Call-ID, or 0 to 2 seconds if it does not, then retry the re-INVITE once more if it still wants the change. in context
In SIP digest authentication a user agent server challenges with 401 and a WWW-Authenticate header, while a proxy challenges with 407 and a Proxy-Authenticate header. in context
RFC 3261 advises SIP elements to challenge questionable requests with a single 401 or 407 response and to behave statelessly toward unauthenticated requests to limit DoS exposure. in context
RFC 3261 warns that a SIP request with a forged Via header can make responses go to a third party, and that requests sent to multicast addresses can amplify traffic, both of which can be used for denial of service. 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. in context
The ACK sent for a 2xx response to an INVITE is a separate SIP transaction, not part of the INVITE transaction. in context
When an INVITE receives a non-2xx final response, the ACK to that response is part of the same INVITE transaction. in context
The CSeq header carries an integer and a method name, and the CSeq number is incremented for each new request within a dialog. in context
In SIP a dialog is identified by the combination of a call identifier (Call-ID), a local tag and a remote tag. in context
A ladder tool that groups messages by Call-ID alone can merge separate dialogs that share a Call-ID; it should also key on the From and To tags to separate dialogs correctly. inferred in context
SIP responses fall into six classes: 1xx provisional, 2xx success, 3xx redirection, 4xx client error, 5xx server error and 6xx global failure. in context
Each SIP proxy uses the Via header field to decide where to send a response and removes its own address from the top Via before forwarding it. in context
In SIP, 486 Busy Here means the callee is busy and cannot take the call now, but the caller may try again later. in context
In SIP, a 503 Service Unavailable response means the server temporarily cannot process the request because of overload or maintenance. in context
In SIP digest authentication a user agent server challenges with 401 Unauthorized, while a proxy challenges with 407 Proxy Authentication Required. in context
SIP OPTIONS (RFC 3261 section 11) queries a peer's capabilities and may be sent outside a dialog; the capabilities come back in the 200 OK's Allow and Accept headers. in context
RFC 3261 defines 486 Busy Here as the callee's end system being reached but unwilling or unable to take additional calls, a callee condition rather than a server-capacity one. in context
RFC 3261 says a client receiving 503 Service Unavailable should try an alternate server and should not send further requests to that server for the Retry-After period if one is given. in context
RFC 3261 permits Retry-After with 500, 503 or 600 responses to tell the caller how long to wait before retrying. in context
Without an OPTIONS keepalive marking a peer down in advance, an element that fails over only on transaction timeout can wait on the order of Timer B (32 s at default T1) before trying the next server, unless a platform-specific shorter timer applies. inferred in context
RFC 3261 defines OPTIONS as a request for querying capabilities that may be sent outside a dialog, and it is the method platforms reuse as a trunk keepalive. in context
RFC 3261 sets INVITE client transaction Timer B to 64*T1, and with the default T1 of 500 ms that is 32 seconds. 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. 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. inferred 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. 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. 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. 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. 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. in context
The acknowledgement of a 2xx response to an INVITE is a separate transaction from the INVITE it acknowledges. 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. 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. 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. in context
The sequence header identifies and orders transactions and consists of a number and a method that must match the request. 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. inferred in context
An INVITE is not retransmitted over a reliable transport and retransmissions cease altogether once a provisional response arrives. 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. in context
The INVITE transaction timeout is 64 times the round trip time estimate whose default is 500 milliseconds giving 32 seconds. 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. in context
SIP 488 Not Acceptable Here indicates that the session description in the request could not be accepted by the user agent at that Request-URI, which is how an SRTP-only or crypto-incompatible offer is commonly rejected at the SIP layer. in context
RFC 3261 section 21 defines the SIP final response codes commonly seen on rejected calls, including 403 Forbidden (21.4.4), 404 Not Found (21.4.5), 480 Temporarily Unavailable (21.4.18), 486 Busy Here (21.4.24), 503 Service Unavailable (21.5.4) and 603 Decline (21.6.2). 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}
}