SIP: Session Initiation Protocol
obsoleted by
- rfc-3261 — SIP: Session Initiation Protocol
- rfc-3262 — Reliability of Provisional Responses in Session Initiation Protocol (SIP)
- rfc-3263 — Session Initiation Protocol (SIP): Locating SIP Servers
- rfc-3264 — An Offer/Answer Model with Session Description Protocol (SDP)
- rfc-3265 — Session Initiation Protocol (SIP)-Specific Event Notification
Extracted elements (30)
SIP is text-based using ISO 10646 in UTF-8 encoding to allow easy implementation in languages like Java, Tcl, and Perl, easy debugging, and flexibility. Since SIP initiates multimedia sessions rather than delivering media, the overhead of text encoding is not considered significant.
SIP supports both UDP and TCP because UDP allows better timing control, parallel searches without per-request connection state, and multicast support, while TCP enables easier traversal of existing firewalls and is suitable when reliable transport is preferred.
The proxy server does not interpret the q (quality) parameter from REGISTER Contact headers when processing non-REGISTER requests because it is not clear how long a proxy should wait between trying addresses, making q insufficient alone to guide proxy behavior.
SIP is modeled on HTTP message format and borrows its header syntax and authentication mechanisms but is explicitly NOT an extension of HTTP. Unlike HTTP, SIP may use UDP and allows multiple transactions per datagram or TCP connection.
SIP URLs are case-insensitive: sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All URL parameters are included when comparing SIP URLs for equality.
A client SHOULD follow DNS lookup procedures using A/AAAA RRs to resolve the host part of the Request-URI, defaulting to port 5060 if none is present. If no transport is specified, the client tries UDP first; if that fails or is unsupported, it tries TCP.
A party receiving a BYE request MUST cease transmitting media streams specifically directed at the party issuing the BYE. A party SHOULD issue a BYE before releasing a call.
A proxy server MUST add itself to the beginning of the Via header list when forwarding a request. On the response path, each proxy MUST remove its own Via entry so that routing information is hidden from the callee and external networks.
A proxy server MUST check that it does not generate a request to a host already listed in the Via sent-by, via-received, or via-maddr parameters in order to prevent routing loops.
A re-INVITE to change an existing session MUST use the same Call-ID as the original but with a higher CSeq than any previous request from the client to the server. The user agent MUST update internal state if session parameters change.
A successful SIP invitation MUST consist of two requests: INVITE followed by ACK. The INVITE asks the callee to join a session; the ACK confirms receipt of the final response. If the caller no longer wants the call, it sends BYE instead of ACK.
Once a user agent server has received a CANCEL request, it MUST NOT issue a 2xx response for the cancelled original request. A redirect or user agent server responds 200 if the transaction exists, or 481 (Transaction Does Not Exist) if not.
Proxy, registrar, and redirect servers MUST implement both UDP and TCP transport. User agents SHOULD implement both UDP and TCP transport.
REGISTER requests sharing the same Call-ID MUST have increasing CSeq values. All registrations from a client SHOULD use the same Call-ID within a reboot cycle. Clients SHOULD avoid sending a new registration until the previous response is received.
UDP datagrams including all SIP headers SHOULD NOT be larger than the path MTU if known, or 1500 bytes if the MTU is unknown, to avoid IP fragmentation.
If a user's SIP address is guessable from their name and organizational affiliation, the traditional privacy model of an unlisted number is compromised. SIP mitigates this by offering authentication and access control mechanisms so clients can reject unauthorized or unwanted calls.
A call leg is identified by the triple of Call-ID, To, and From header fields. A SIP transaction is identified by the CSeq sequence number within a single call leg. The ACK has the same CSeq as its INVITE but constitutes a separate transaction.
A forking proxy issues multiple parallel requests to possible user locations upon receiving an INVITE. If one branch returns 2xx or 6xx, the proxy MAY send CANCEL to cancel remaining pending branches. The proxy collects all responses and forwards the best final response to the caller.
SIP defines six methods: INVITE (invite to session), ACK (confirm final response to INVITE), OPTIONS (query capabilities), BYE (release call), CANCEL (cancel pending request), and REGISTER (bind address-of-record to contact). The Method token is case-sensitive.
SIP status codes are grouped into six classes: 1xx Informational (progress, non-terminal), 2xx Success, 3xx Redirection, 4xx Client Error, 5xx Server Error, and 6xx Global Failure. All 2xx–6xx responses are final and terminate a SIP transaction.
The Contact header provides one or more URIs at which the sender of the message can be reached directly. In REGISTER requests it binds an address-of-record to contact URIs with optional q (preference) and expires (lifetime) parameters. A wildcard '*' contact with Expires: 0 cancels all registrations.
The CSeq header contains a sequence number and the method name. Requests in the same call leg MUST have monotonically increasing CSeq numbers. The ACK and CANCEL for an INVITE share the same CSeq number as the INVITE but use their own method token.
SIP defines IANA registries for option tags (Section 4.4.1), SIP methods, response codes, and header fields. New option tags must be registered with IANA; the Require header field is used by a UAC to require the server to support a given option tag, and Unsupported is returned when the server does not support it.
Embedding passwords in SIP URL userinfo (user:password@host) is NOT RECOMMENDED because passing authentication credentials in clear-text URIs has proven to be a security risk in every protocol where it has been used.
REGISTER requests MUST be authenticated because they allow an attacker to redirect future requests to a fraudulent address. An unauthenticated REGISTER can cause calls intended for the victim to be delivered to the attacker.
SIP supports end-to-end encryption of message bodies and selected header fields using PGP or S/MIME, and hop-by-hop encryption using TLS or IPsec. The Via field can be encrypted to hide routing topology from intermediaries.
SIP supports HTTP Basic and Digest authentication as well as a PGP-based authentication scheme for both user agents and proxies. Basic authentication is described but its use is not recommended because credentials are transmitted in the clear.
SIP messages follow RFC 822 generic-message format: a start-line (Request-Line or Status-Line), one or more header fields, a blank CRLF line terminating headers, and an optional message-body. Senders MUST terminate lines with CRLF; receivers MUST also accept bare CR or LF as line terminators.
SIP URLs have the syntax sip:[userinfo@]hostport[;url-parameters][?headers]. URL parameters include transport (udp|tcp), ttl (0–255), maddr (server/multicast address), user (phone|ip), and method. The transport, maddr, ttl, and headers elements MUST NOT appear in From, To, or Request-URI and are ignored if present.
The Request-Line format is: Method SP Request-URI SP SIP-Version CRLF. No CR or LF are allowed within the line except the final CRLF. The Status-Line format is: SIP-Version SP Status-Code SP Reason-Phrase CRLF.