Protocol guide · SIP
The Complete
SIP Protocol Guide
Architecture, messages, methods, call flows, media negotiation, routing, security and troubleshooting—explained for telecommunications professionals.
Standards note: This educational guide summarises SIP for practical use. For normative implementation requirements, always consult the applicable RFCs and your interconnection agreement.
What is SIP?
Session Initiation Protocol (SIP) is an application-layer signalling protocol used to create, modify and terminate real-time communication sessions. Those sessions may carry voice, video, messaging or other media.
SIP coordinates who is communicating, where they can be reached and which session parameters are accepted. It normally does not carry the audio itself. Media is commonly described with SDP and transported separately using RTP or SRTP.
Core SIP architecture
SIP roles are logical and can change from one transaction to another. A single platform may perform several roles.
User Agent Client (UAC)
Generates a SIP request—for example, the endpoint sending an INVITE.
User Agent Server (UAS)
Receives a request and generates one or more responses.
Proxy server
Routes requests toward their destination. A proxy may operate statefully or statelessly and can enforce routing, authentication and policy.
Registrar
Accepts REGISTER requests and associates an address-of-record with one or more current Contact locations.
Redirect server
Returns a 3xx response containing alternative locations rather than forwarding the request itself.
Location service
Provides routing information that a proxy or redirect server can use to locate a target.
Session Border Controller
A common deployment component—not a core RFC 3261 role—used at network boundaries for policy, topology control, security, interoperability and media handling.
SIP messages and essential headers
SIP is a text-based protocol. A message contains a start line, header fields, a blank line and an optional body. Requests begin with a method, Request-URI and SIP version; responses begin with the SIP version, numeric status code and reason phrase.
INVITE sip:bob@example.net SIP/2.0
Via: SIP/2.0/TLS client.example.com;branch=z9hG4bK-1234
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=a73kszlfl
To: Bob <sip:bob@example.net>
Call-ID: 1j9FpLxk3uxtm8tn@client.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.example.com;transport=tls>
Content-Type: application/sdp
Content-Length: [body byte length]
[SDP body omitted]This is an abbreviated structural example: the SDP body and its calculated byte length must be supplied in a transmitted message, and SIP uses CRLF line endings on the wire.
Common SIP methods
INVITEEstablishes a session or modifies an existing session when sent in-dialog.
ACKConfirms receipt of a final response to INVITE. ACK handling differs for 2xx and non-2xx responses.
BYETerminates an established dialog and its associated session.
CANCELAttempts to stop a pending request; it does not terminate an already established session.
REGISTERCreates, refreshes or removes Contact bindings at a registrar.
OPTIONSQueries capabilities or reachability without establishing a session.
PRACKAcknowledges reliable provisional responses when the RFC 3262 extension is used.
UPDATEModifies session parameters without changing dialog state, subject to extension support.
REFERRequests that the recipient initiate another request, commonly used for transfer.
SUBSCRIBE / NOTIFYCreate and deliver event-state subscriptions under the SIP events framework.
INFOCarries application-level information within a dialog; usage depends on an agreed package.
MESSAGETransports an instant message using the SIP MESSAGE extension.
SIP response codes and meanings
The first digit defines the response class. A reason phrase is human-readable, but automated behaviour should be based on the numeric code. The detailed reference below covers the core RFC 3261 codes and frequently encountered operational responses; extensions define additional codes.
Provisional
Request received; processing continues. Examples: 100 Trying, 180 Ringing, 183 Session Progress.
Successful
The request succeeded. The central example is 200 OK.
Redirection
Further action is needed to reach the user. Examples: 301 Moved Permanently, 302 Moved Temporarily.
Request failure
The request cannot be fulfilled as submitted. Examples: 400 Bad Request, 401 Unauthorized, 404 Not Found, 407 Proxy Authentication Required, 408 Request Timeout, 486 Busy Here, 487 Request Terminated, 488 Not Acceptable Here.
Server error
A server failed to fulfil an apparently valid request. Examples: 500 Server Internal Error, 503 Service Unavailable.
Global failure
The request cannot be fulfilled at any destination. Examples: 600 Busy Everywhere, 603 Decline.
Individual code reference
Trying
The request was received and processing is continuing.
Ringing
The destination user agent is alerting the user.
Call Is Being Forwarded
The call is being redirected to another destination.
Queued
The called party is temporarily unavailable and the request has been queued.
Session Progress
Provides call-progress information and may carry SDP for early media.
OK
The request succeeded. For INVITE, the session was accepted.
Accepted (Deprecated)
A legacy success response. RFC 6665 deprecated it for SUBSCRIBE and NOTIFY, and RFC 7647 requires 200 OK instead for REFER.
Multiple Choices
Several possible destinations are available.
Moved Permanently
The user can be reached permanently at the Contact address supplied.
Moved Temporarily
The user can temporarily be reached at the supplied Contact address.
Use Proxy
The requested resource must be reached through the specified proxy.
Alternative Service
The call failed, but the response describes alternative services.
Bad Request
The request is malformed or cannot be understood.
Unauthorized
Authentication with the user agent server is required.
Payment Required
Reserved in the core specification.
Forbidden
The server understood the request but refuses to fulfil it.
Not Found
The server has no information indicating that the requested user exists at this domain.
Method Not Allowed
The method is understood but not permitted for this resource.
Not Acceptable
The requested resource can only generate a response with unacceptable characteristics.
Proxy Authentication Required
Authentication with the proxy is required.
Request Timeout
The server could not produce a response within the required time.
Gone
The requested user existed previously but is no longer available here.
Request Entity Too Large
The request body is larger than the server will process.
Request-URI Too Long
The Request-URI is longer than the server will process.
Unsupported Media Type
The message-body format is not supported.
Unsupported URI Scheme
The URI scheme is not supported.
Bad Extension
A required SIP extension is not understood.
Extension Required
The server requires an extension that was not listed as supported.
Interval Too Brief
The requested expiry interval is shorter than the server permits.
Temporarily Unavailable
The destination is currently unavailable.
Call/Transaction Does Not Exist
The request does not match an existing dialog or transaction.
Loop Detected
The server detected a forwarding loop.
Too Many Hops
Max-Forwards reached zero.
Address Incomplete
The Request-URI is incomplete.
Ambiguous
The Request-URI does not identify a unique destination.
Busy Here
The specific destination is busy.
Request Terminated
The original request ended, commonly because it was cancelled.
Not Acceptable Here
The session description or requested parameters are unacceptable at this destination.
Request Pending
Another request is still being processed for the same dialog.
Undecipherable
The request contains an encrypted MIME body the recipient cannot decrypt.
Server Internal Error
An unexpected server condition prevented fulfilment.
Not Implemented
The server does not support the functionality needed for the request.
Bad Gateway
An upstream server returned an invalid response.
Service Unavailable
The server is temporarily overloaded or under maintenance.
Server Time-out
An upstream server did not respond in time.
Version Not Supported
The SIP version in the request is not supported.
Message Too Large
The message exceeds the server’s processing limit.
Busy Everywhere
The called party is busy at every known destination.
Decline
The user or service explicitly declined the request.
Does Not Exist Anywhere
The requested user does not exist anywhere known to the server.
Not Acceptable
The user cannot accept the session described in the request.
Implementations may use extension response codes not shown here. Always inspect the applicable RFC, the complete response and the interconnection profile before deciding operational behaviour.
Transactions, dialogs and sessions
These terms describe different layers of SIP state:
- Transaction: a request and the responses associated with it. INVITE and non-INVITE transactions use different state machines.
- Dialog: a peer-to-peer SIP relationship identified by Call-ID, local tag and remote tag. A 101–199 provisional response with a To-tag to a dialog-forming request can create an early dialog; a 2xx final response to INVITE establishes a confirmed dialog.
- Session: the actual media relationship negotiated by the participants, commonly through SDP.
A dialog can contain multiple transactions—for example, an initial INVITE, a re-INVITE and a BYE. Signalling and media may take different network paths.
Basic SIP call flow
- The UAC sends an INVITE, usually containing an SDP offer.
- Proxies resolve and forward the request. A 100 Trying response can stop upstream INVITE retransmissions.
- The UAS may send provisional responses such as 180 Ringing or 183 Session Progress.
- A 200 OK accepts the invitation and normally contains the SDP answer.
- The UAC sends ACK. The dialog is confirmed and media flows according to the negotiated addresses and codecs.
- Either endpoint can send BYE. The peer responds with 200 OK; no ACK follows a BYE response.
SDP offer/answer and RTP media
SIP can carry SDP bodies, but SDP is a separate protocol. The offer/answer model negotiates media types, addresses, ports, codecs and attributes. The selected codec is not simply the first payload type in every deployment; it must be supported and accepted according to the offer/answer rules and local policy.
v=0
o=alice 2890844526 2890844526 IN IP4 192.0.2.10
s=-
c=IN IP4 192.0.2.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecvRTP typically carries the media and RTCP reports control and quality information. SRTP protects media confidentiality and integrity when correctly negotiated and deployed. SIP signalling success does not prove that media is flowing; one-way audio commonly indicates a media-routing, NAT, firewall or SDP-address problem.
Routing, registration and DNS
A SIP URI commonly resembles sip:user@example.com. Routing can involve local policy, location-service lookups, Route sets and DNS procedures. RFC 3263 defines the use of NAPTR and SRV records to determine supported transports, servers and ports, followed by address resolution.
REGISTER does not establish a call. It creates a binding between an address-of-record and one or more Contact URIs. Registrations expire and must be refreshed; a Contact with an expires value of zero removes a binding.
Routing checks
- Confirm Request-URI and next-hop selection.
- Check NAPTR, SRV, A and AAAA resolution where applicable.
- Verify Route and Record-Route processing.
- Inspect Via branches and Max-Forwards for loops.
- Validate Contact reachability and registration expiry.
Transport, NAT and security
SIP can use transports including UDP, TCP and TLS. A sips: URI requires TLS protection across each SIP hop, but this hop-by-hop signalling protection is not end-to-end media encryption. WebRTC-facing systems may also use SIP over WebSocket. Transport choice affects connection management, message size, retransmission behaviour and security.
NAT can make addresses placed in Via, Contact and SDP unreachable. Common mechanisms include Via rport, persistent outbound flows, SBC/media-relay functions and ICE-related media techniques. The correct solution depends on the network and trust boundary.
Protect signalling
Use current TLS configurations on appropriate trust boundaries. RFC 8996 deprecates TLS 1.0 and 1.1.
Authenticate correctly
Use SIP Digest authentication with current algorithms and nonce handling; RFC 8760 updates the original digest framework.
Validate identities
Do not equate the display-name or From URI with a verified caller identity. Apply the identity and attestation framework required by the relevant jurisdiction and interconnection.
Control exposure
Restrict trusted peers, rate-limit requests, detect scanning and malformed traffic, protect credentials and minimise information disclosure.
Protect media
Use SRTP and an appropriate key-management method where confidentiality and integrity are required.
Monitor behaviour
Correlate signalling, CDRs, media quality and security events; alert on abnormal destinations, rates, response patterns and call duration.
A disciplined troubleshooting workflow
- Define the failure boundary.Registration, call setup, ringing, answer, media, mid-dialog signalling or teardown?
- Identify the dialog.Use Call-ID and tags; use the Via branch and CSeq to distinguish transactions.
- Follow the full ladder.Inspect every request, provisional response, final response and ACK rather than a single packet.
- Verify routing.Check Request-URI, Route, Record-Route, Contact, Via, DNS result and actual next hop.
- Read the SDP.Compare offers and answers, media addresses, ports, codecs, direction attributes and secure-media requirements.
- Separate signalling from media.A 200 OK can coexist with no audio. Verify RTP/SRTP in both directions.
- Check timers and retransmissions.Repeated requests often identify packet loss, an unreachable response path or transport-state failure.
- Correlate systems and time.Use synchronised timestamps across endpoints, SBCs, proxies, firewalls and monitoring platforms.
Key SIP standards
RFC 3261 is the core specification, but production SIP relies on later updates and extensions. This selected map is a starting point rather than a complete registry.
Primary reference: RFC 3261 — SIP: Session Initiation Protocol. Consult the RFC Editor record for updates, errata and related standards.
Put SIP knowledge into practice
Build reliable signalling.
Protect every connection.
Successful SIP operations require more than protocol syntax. They depend on correct routing, disciplined interconnection, observable media, secure trust boundaries and continuous operational control.
Discuss your SIP requirements ↗