INVITE uses a three-way handshake (INVITE / 2xx / ACK) rather than a two-way exchange because sessions require resource allocation (media ports, codec negotiation) and the callee must know the caller received the final response before assuming the session is established. The ACK also handles the long delay between ringing and answering, during which retransmitted 200 OKs would otherwise be ambiguous.

sip, realtime

RFC 3261 replaces RFC 2543 strict routing with loose routing, separating the final destination (Request-URI) from intermediate proxies (Route header). Strict routing destroyed the Request-URI when a Route header was present, making it impossible to route to a specific target through a configured proxy set and causing interoperability problems with chained proxies.

sip

SIP elements that implement strict routing (following RFC 2543 rules) will place themselves in the Request-URI rather than a Route header when Record-Route is used, breaking loose-routing proxies. Section 16.12.1.2 defines specific procedures for a loose-routing proxy to detect and correct for a strict-routing proxy in the path.

sip

A proxy MUST NOT forward a request whose Max-Forwards value is zero; it MUST return 483 (Too Many Hops). Every proxy forwarding a request MUST decrement Max-Forwards by exactly one.

sip

A UAS receiving a request with a Require header listing unsupported option tags MUST reject the request with 420 (Bad Extension) and list unrecognized tags in an Unsupported header field. A proxy encountering an unrecognized Proxy-Require tag MUST similarly return 420.

sip

Applications sending SIP messages MUST include SIP-Version 'SIP/2.0'. Implementations MUST send upper-case, though the string is case-insensitive for reception.

sip

Every new request MUST include a Via branch parameter that is unique across space and time. To distinguish RFC 3261 transactions from RFC 2543 ones, the branch value MUST begin with the magic cookie 'z9hG4bK'. This enables reliable transaction matching by all elements.

sip

Implementations MUST accept both long and compact forms of each header name (e.g., 'Via' and 'v', 'From' and 'f', 'To' and 't', 'Contact' and 'm'). A compact form MAY be substituted for the longer form at any time without changing message semantics.

sip

Requests addressed to a SIPS URI MUST be sent over TLS, guaranteeing encrypted transport from caller to the callee's domain. From there, the callee's domain is responsible for securing the final hop per its own policy.

sip, tls, security

The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in angle brackets '<>'. This prevents ambiguity in request-line parsing.

sip

A dialog is a peer-to-peer SIP relationship uniquely identified by the triple: Call-ID, local tag (From tag), and remote tag (To tag). Dialogs are established by 2xx responses to INVITE and persist until terminated by BYE.

sip, realtime

Record-Route and Route headers enable proxies to remain in the signaling path for a dialog's lifetime. A proxy inserts a Record-Route entry into INVITE requests; both endpoints accumulate the resulting route set and include it as Route headers in all subsequent dialog requests.

sip

SIP defines six core methods: REGISTER for registering contact information, INVITE/ACK/CANCEL for session setup, BYE for session termination, and OPTIONS for capability queries. Standards-track RFCs may define additional methods.

sip, realtime

SIP defines two URI schemes: 'sip:' (insecure) and 'sips:' (requires TLS end-to-end to the target domain). URI comparison rules handle case-insensitivity, default port equivalence (5060 for sip, 5061 for sips), and default transport, ensuring consistent matching across implementations.

sip, tls

The Contact header field carries a SIP/SIPS URI giving a direct route to the sending UA. Unlike Via (used for routing the current response), Contact tells other elements where to send future requests within the dialog, and is the mechanism by which endpoints bypass proxies for mid-dialog messages.

sip

The CSeq header contains a monotonically increasing 32-bit integer and a method name. Each new non-ACK, non-CANCEL request within a dialog MUST increment the CSeq number, providing ordering and retransmission detection across a dialog's lifetime.

sip

The Via header field records each hop's address and branch parameter as a request traverses the network, enabling responses to be routed back along the same path without requiring stateful proxies or DNS lookups on the return path. Each proxy adds its own Via entry and removes it when forwarding responses upstream.

sip

RFC 3261 establishes IANA registries for: SIP Option Tags (Section 27.1), SIP Warn-Codes (Section 27.2), SIP Header Field Names (Section 27.3), SIP Methods and Response Codes (Section 27.4), the 'message/sip' MIME type (Section 27.5), and Content-Disposition parameter values (Section 27.6).

sip, registry

HTTP Digest authentication in SIP does not protect message bodies or most header fields, does not provide mutual authentication unless auth-int QOP is used, and does not prevent man-in-the-middle attacks against the initial challenge. TLS or S/MIME must be used in conjunction with Digest for stronger security guarantees.

sip, security, crypto

Registration hijacking occurs when an attacker forges REGISTER requests to redirect a victim's incoming calls. Mitigation requires authenticating REGISTER requests via HTTP Digest or mutual TLS to ensure only the legitimate user can update location bindings.

sip, security

S/MIME is specified for protecting SIP message bodies and for tunneling a signed copy of SIP headers inside an encrypted MIME body to prevent proxy modification. This provides end-to-end integrity and confidentiality even when the signaling path traverses untrusted proxies.

sip, security, crypto

SIP is vulnerable to DoS amplification because Via headers can be forged with a third party's IP address, causing SIP elements to flood that address with responses. Implementations SHOULD use TLS (which prevents source-address spoofing) and SHOULD authenticate requests to reduce amplification risk.

sip, security

Non-INVITE client transactions have states: Trying (request sent, Timer F started), Proceeding (1xx received), Completed (final response received; Timer K absorbs retransmissions on unreliable transport), and Terminated. Timer E drives retransmissions on unreliable transport while in Trying/Proceeding.

sip

The INVITE client transaction has four states: Calling (initial; retransmits INVITE on Timer A for unreliable transport), Proceeding (1xx received), Completed (3xx-6xx received; ACK sent, Timer D started to absorb retransmissions), and Terminated. Timer B in Calling state causes timeout failure if no response arrives.

sip

The INVITE server transaction has four states: Proceeding (retransmits latest provisional on INVITE retransmissions), Completed (3xx-6xx sent; retransmits on Timer G for unreliable transport, awaits ACK), Confirmed (ACK received; Timer I absorbs ACK retransmissions), and Terminated. 2xx responses are passed directly to the TU and bypass the server transaction.

sip

A SIP message consists of a start-line, zero or more header fields, a mandatory empty CRLF line, and an optional message-body: 'start-line *message-header CRLF [message-body]'. The empty CRLF separator line MUST be present even when the body is absent. SIP is text-based using UTF-8.

sip

The Request-Line encodes Method, Request-URI, and SIP-Version separated by single SP characters, terminated by CRLF: 'Method SP Request-URI SP SIP-Version CRLF'. No CR, LF, or linear whitespace is permitted within any element.

sip

The Status-Line encodes SIP-Version, a 3-digit Status-Code, and Reason-Phrase separated by single SP characters, terminated by CRLF: 'SIP-Version SP Status-Code SP Reason-Phrase CRLF'. Status-Code classes 1xx through 6xx indicate provisional, success, redirection, client error, server error, and global failure.

sip