What Is SIP? Session Initiation Protocol Guide

Analysing SIP: Separate the Layers Before Diagnosing

A common enterprise ticket reads: extension 1001 is registered, it receives an inbound call, the user hears the caller clearly, but the caller hears nothing. Registration status cannot explain this. A successful REGISTER proves only that SIP signalling reaches the registrar; it says nothing about where RTP packets are sent, whether a firewall accepts them, or whether the far end can decode them.

SIP separates session control from the media itself. SIP messages negotiate who talks to whom and with which media description; SDP bodies inside those messages describe addresses, ports and codecs; RTP then carries the audio independently, often along a different network path from the signalling. A fault in one plane can look like a fault in another unless each plane is checked against its own evidence.

A practical model uses four planes. The connectivity plane covers IP routing, DNS resolution, the chosen transport (UDP, TCP, TLS or WebSocket) and firewall state. The signalling plane covers requests, responses, transactions and dialogs. The session-description plane covers SDP: the connection address, the media port, the payload formats and the direction attributes. The media and application plane covers RTP and RTCP delivery, loss, jitter, decoding and what the user actually hears.

Good diagnostic notes record facts per plane rather than conclusions. For example: the INVITE received a 200 OK and the callee received the matching ACK; the SDP answer selected PCMA, payload 8, at 198.51.100.20:41000; RTP from 198.51.100.20 reaches 192.0.2.10, but RTP from 192.0.2.10 never gets past the branch firewall toward 198.51.100.20. A note like this points directly at the component that needs fixing.

Protocol Roles: SIP, SDP, RTP and RTCP in a VoIP Call

These terms are often used interchangeably in sales material, but each one names a different layer. VoIP is the overall practice of carrying voice over IP. SIP (RFC 3261) is the control protocol. SDP (RFC 8866) is the format that describes media. RTP (RFC 3550) carries the digitised audio. A SIP trunk is a service or interconnection that uses SIP between telephony systems, most often between an enterprise PBX and a provider that reaches the public telephone network.

The working model is simple: SIP coordinates the session, SDP describes the media parameters, and RTP moves the audio. Because these are separate flows, SIP messages may traverse one or more proxies while RTP travels directly between endpoints, or through a media relay such as an SBC, depending on the design. Never assume that the signalling path and the media path are the same.

SIP Entities: User Agents, Proxy, Registrar, B2BUA and SBC

A user agent (UA) is a logical endpoint function. It acts as a user agent client (UAC) when it sends a request and as a user agent server (UAS) when it receives a request and generates responses. The role is defined per transaction, not per device: an IP phone is a UAC when it sends INVITE and a UAS when it later receives BYE from the other party.

A proxy server receives requests and forwards them toward the target, making routing decisions from the Request-URI, its own policy and DNS. A proxy does not originate or answer calls. A stateful proxy keeps transaction state and can fork a request to several contacts in parallel; it may also insert a Record-Route header so that later requests in the dialog continue to pass through it.

A registrar accepts REGISTER requests and stores bindings between an address of record (AoR) and one or more contact addresses in a location service. Proxies query that location service to find where a user can currently be reached. Many products combine the registrar, location service and proxy in one server, but RFC 3261 treats them as distinct logical roles.

A back-to-back user agent (B2BUA) terminates a call as a UAS on one side and originates a separate call as a UAC on the other. Each side is an independent dialog with its own Call-ID, tags and CSeq numbering. IP-PBXs and session border controllers (SBCs) usually behave as B2BUAs, which lets them hide internal topology, normalise headers between vendors, enforce admission and fraud policy, and anchor or transcode media when the design requires it.

A redirect server is a further role: instead of forwarding a request, it answers with a 3xx response listing alternative contacts that the sender can try itself.

Transport, Addressing and DNS Resolution (RFC 3263)

SIP runs over UDP, TCP, TLS over TCP, SCTP and WebSocket (RFC 7118, used by browser clients). The default port for sip URIs over UDP or TCP is 5060, and the default for TLS is 5061. These defaults apply only when no explicit port is given; any deployment may use other ports.

The transport choice applies to signalling only. Running SIP over TCP or TLS does not move RTP onto TCP; the media still uses the transport described in SDP, which for RTP/AVP and RTP/SAVP is UDP. Likewise, a WebRTC client that signals SIP over a secure WebSocket still sends its media over separate DTLS-SRTP flows, not inside the WebSocket.

UDP is sensitive to message size. RFC 3261 requires a client to use a congestion-controlled transport such as TCP when a request is within 200 bytes of the path MTU, or larger than 1300 bytes when the MTU is unknown. Large INVITEs with long SDP bodies are therefore a real source of IP fragmentation problems on UDP.

SIP Message Syntax and Header Fields

SIP is a text protocol with a syntax modelled on HTTP. Every message has a start-line, a set of header fields, an empty line marking the end of the headers, and an optional body. A request starts with a Request-Line containing the method, the Request-URI and the SIP version; a response starts with a Status-Line containing the SIP version, a three-digit status code and a reason phrase. Lines end with CRLF, header names are case-insensitive, and compact forms exist, such as v for Via and i for Call-ID.

RFC 3261 section 8.1.1 lists the header fields that every request must contain: To, From, CSeq, Call-ID, Max-Forwards and Via. Contact is additionally required in requests that can create a dialog, such as INVITE, and REGISTER uses Contact to carry the bindings being added or removed.

Keep the Request-URI and the To header apart. Proxies retarget the Request-URI as the request moves toward the device that will answer, while To keeps the logical target the caller originally asked for. Media addresses never appear in these SIP headers; they are carried in the c= and m= lines of the SDP body.

SIP Methods and Response Codes

RFC 3261 defines six core methods. INVITE starts a session, or modifies an existing one when sent inside a dialog as a re-INVITE. ACK confirms a final response to INVITE. BYE ends a session. CANCEL asks the server to stop processing a pending request, which in practice means an INVITE that has not been answered. REGISTER adds, refreshes or removes contact bindings. OPTIONS queries capabilities and is widely used as a keepalive or health probe between PBXs, SBCs and providers.

Extensions add further methods. PRACK acknowledges reliable provisional responses (RFC 3262). UPDATE changes session parameters before or after answer without affecting dialog state (RFC 3311). REFER asks the recipient to contact a third party and is the basis of call transfer (RFC 3515). INFO carries application information within a dialog (RFC 6086). SUBSCRIBE and NOTIFY provide event notification (RFC 6665), and MESSAGE carries instant messages (RFC 3428).

Responses are grouped by their first digit: 1xx provisional, 2xx success, 3xx redirection, 4xx request failure, 5xx server failure and 6xx global failure. A response is always interpreted together with the method in its CSeq header. A 200 OK for BYE means the hang-up was accepted; it does not mean that a call was answered.

Transactions, Dialogs and Sessions

Engineers use five related terms. A message is a single request or response. A transaction is one request plus all responses to it, including retransmissions; client and server identify it by the branch parameter of the top Via header, which in RFC 3261 always begins with the magic cookie z9hG4bK, together with the method. A dialog is a peer-to-peer relationship between two user agents that persists for some time, is created by INVITE or SUBSCRIBE, and is identified by the Call-ID, the local tag and the remote tag.

A session is the media exchange described by SDP. A call leg is informal language for one dialog when a B2BUA or SBC splits an end-to-end call into several dialogs.

When a UAS sends a provisional response other than 100 Trying with a To tag, an early dialog exists; a 2xx final response confirms the dialog. Later requests in that dialog, such as re-INVITE, UPDATE or BYE, reuse the Call-ID and tags, but each is a new transaction with a new branch and, from the sending side, a higher CSeq number. Each side keeps its own CSeq space, so the number in a BYE sent by the callee need not continue the numbering used by the caller.

Forking adds a subtlety. When a proxy forks an INVITE to several phones, every phone that responds with its own To tag creates a separate early dialog sharing the same Call-ID. A proxy may cancel still-pending branches after the first 2xx, but several branches can return 2xx before cancellation takes effect, creating multiple confirmed dialogs. The UAC must ACK each 2xx and send BYE within any unwanted dialog.

Registration (REGISTER) and Digest Authentication

REGISTER creates, refreshes or removes contact bindings for an address of record. The requested lifetime is given either in an expires parameter on the Contact or in an Expires header, and the registrar returns the lifetime it actually granted in the 200 OK, which may be shorter than requested. The client must refresh before the granted lifetime ends, and a REGISTER with an expiry of zero removes the binding.

Registration and authentication are separate concerns. Registration answers where a user can currently be reached; authentication answers whether the sender can prove its identity. A binding that expires stops new incoming calls from being routed to that contact, but it does not tear down dialogs that are already established.

Challenging the first request is normal. A registrar that requires credentials answers the first REGISTER with 401 Unauthorized and a WWW-Authenticate header, and the client then sends a new REGISTER containing an Authorization header.

The REGISTER Challenge Sequence

In the example, UA 1001 at 192.0.2.10 sends REGISTER for sip:1001@example.com with CSeq 1 and branch z9hG4bK-reg-1, asking for a 3600-second binding. The registrar replies 401 with CSeq 1 REGISTER and a challenge. The UA then sends a second REGISTER with the same Call-ID and From tag, CSeq 2, a new branch z9hG4bK-reg-2 and an Authorization header. The registrar replies 200 OK with CSeq 2 REGISTER and lists the current contact with its granted expiry.

Because REGISTER is not INVITE, no ACK follows the 401 or the 200. The authenticated retry is an entirely new transaction, which is why both the CSeq number and the branch change.

Annotated Example: One Call Traced Message by Message

This walk-through uses documentation addresses so that every value can be followed. UA 1001 is at 192.0.2.10 and UA 1002 is at 198.51.100.20, both in the domain example.com. To keep it short, the messages go directly between the two user agents; with a record-routing proxy in the path, each request would carry one extra Via entry per hop and Route headers learned from Record-Route.

The call uses Call-ID call-a-1001-1002@example.com. UA 1001 puts tag a1001 in From, UA 1002 adds tag b1002 to To in its responses, and those three values identify the dialog. The INVITE transaction uses branch z9hG4bK-call-a-invite and CSeq 1 INVITE. The ACK for the 200 OK uses a new branch, z9hG4bK-call-a-ack, but keeps CSeq number 1 with the method ACK. The BYE is a new transaction with branch z9hG4bK-call-a-bye and CSeq 2 BYE.

The SDP offer in the INVITE advertises media at 192.0.2.10 port 40000 with payload types 0, 8, 111 and 101. The SDP answer in the 200 OK advertises media at 198.51.100.20 port 41000 and keeps payload types 8 and 101. After the ACK, RTP flows between 192.0.2.10:40000 and 198.51.100.20:41000.

SDP Offer/Answer and Codec Negotiation (RFC 3264, RFC 8866)

SDP is defined in RFC 8866, which obsoletes RFC 4566. SIP uses it with the offer/answer model of RFC 3264: one side sends an offer describing the media it wants to exchange, and the other returns an answer that accepts, adjusts within the permitted rules, or rejects each media stream.

The offer in the example contains v=0; an o= line with the originator, session ID, version and address 192.0.2.10; a session name; c=IN IP4 192.0.2.10; t=0 0; m=audio 40000 RTP/AVP 0 8 111 101; a=rtcp:40001; rtpmap lines mapping 0 to PCMU/8000, 8 to PCMA/8000, 111 to opus/48000/2 and 101 to telephone-event/8000; an fmtp line for 101 with events 0-15; a=ptime:20; and a=sendrecv. The answer uses c=IN IP4 198.51.100.20 and m=audio 41000 RTP/AVP 8 101, selecting PCMA and telephone-event.

Payload types 0 (PCMU, G.711 mu-law) and 8 (PCMA, G.711 A-law) are static assignments from the RTP audio and video profile (RFC 3551). Opus and telephone-event use dynamic payload types in the range 96 to 127 and must be mapped with a=rtpmap in every description. Opus is always described with a 48000 Hz clock and 2 channels in rtpmap, even for mono speech (RFC 7587).

The offer lists formats in order of preference. The answer must contain the same number of m= lines in the same order. For an accepted unicast stream, it must include at least one format from the offer and may also list extra formats not offered; those extras cannot be used to send media until a later offer supports them. It rejects a stream by setting its port to zero. If no acceptable format remains, the UAS typically rejects the INVITE with 488 Not Acceptable Here, or with 606 when the refusal applies everywhere.

Basic Call Flow: Successful Setup and Teardown

A successful call between UA 1001 and UA 1002 proceeds in four stages. First, UA 1001 sends INVITE with an SDP offer and CSeq 1. A 100 Trying may come back to stop INVITE retransmissions over UDP; it is hop by hop and is usually generated by the next proxy or by the UAS. UA 1002 alerts its user and sends 180 Ringing.

Second, when the user answers, UA 1002 sends 200 OK with the SDP answer, and UA 1001 confirms it with ACK. The dialog is now confirmed.

Third, RTP flows in both directions between the addresses and ports taken from SDP: 192.0.2.10 port 40000 and 198.51.100.20 port 41000 in the example. Depending on the design, a PBX or SBC may anchor this media instead of letting it flow directly.

Fourth, either side ends the call by sending BYE within the dialog, here UA 1001 with CSeq 2, and the other side answers 200 OK. The sequence INVITE, 180, 200, ACK, media, BYE, 200 is the baseline against which every other flow is compared.

Ringback in this flow is generated locally by the calling phone when it receives a 180 without SDP. Carrier tones and announcements heard before answer use early media, described in a later section.

Failure and Cancellation Flows: Proxy Challenge, CANCEL and 486 Busy Here

Real deployments see these variants every day, and each still follows the transaction rules: every final response to INVITE is acknowledged, and a new request is always a new transaction.

Cancelling Before Answer with CANCEL

If the caller hangs up while the far end is still ringing, UA 1001 sends CANCEL. The CANCEL copies the Request-URI, Call-ID, From, To and the CSeq number of the INVITE, with the method CANCEL, and uses the same top Via branch, so each hop can match it to the pending INVITE. A UAC must not send CANCEL before it has received a provisional response.

The server answers the CANCEL itself with 200 OK, then ends the INVITE with 487 Request Terminated, and UA 1001 acknowledges the 487 with ACK CSeq 1. This sequence has two final responses: 200 OK for CANCEL and 487 for INVITE. Always check the CSeq method: a 200 for CANCEL is not an answer to the call.

Early Media, 183 Session Progress and PRACK (RFC 3262)

Callers often hear network audio before anyone answers: carrier ringback, an announcement that the number cannot be reached, or an IVR prompt. This is early media, and it is usually signalled with 183 Session Progress carrying SDP, which lets RTP start before the 200 OK.

A 180 Ringing often causes the calling phone to generate local ringback according to its policy. SDP in a provisional response can establish an early-media session, but it does not guarantee that RTP will arrive or command the phone to stop local ringback. Under RFC 3960 the caller should consider actual media arrival and local policy, for example playing far-end audio and stopping local ringback when media arrives. A wrong choice can produce silent or doubled ringback on trunks.

Provisional responses are normally unreliable: over UDP they are not retransmitted, so a lost 183 can mean lost early SDP. RFC 3262 adds reliability. The UAC indicates support with Supported: 100rel in the INVITE. The UAS may then send 183 with Require: 100rel and an RSeq value, for example RSeq 71, retransmitting it until it is acknowledged. The UAC acknowledges it with PRACK, a new request in the early dialog with its own CSeq, CSeq 2 PRACK in the example, carrying RAck: 71 1 INVITE, which means RSeq 71 of CSeq 1 INVITE. The UAS returns 200 OK to the PRACK.

When the call is answered, the 200 OK for CSeq 1 INVITE completes the INVITE transaction and is acknowledged with ACK CSeq 1. If the SDP answer was already delivered in the reliable 183, the offer/answer exchange for the INVITE is complete; any SDP repeated in the 200 OK must be identical, not a new answer. The later BYE uses CSeq 3.

Mid-Dialog Operations: Hold, Transfer and Session Timers

Once a dialog exists, the parties can change it without placing a new call. Three operations matter most on enterprise systems: hold and resume, transfer, and periodic refresh. Each uses a new transaction inside the existing dialog, so the Call-ID and tags stay the same while the branch and CSeq change.

Media Plane: RTP, RTCP, SRTP and DTMF

RTP (RFC 3550) carries encoded media, usually over UDP. Every packet has a payload type that refers to the codec mapping from SDP, a sequence number that lets the receiver detect loss and reordering, a timestamp that drives playout timing and jitter calculation, and an SSRC that identifies the source.

RTCP, also defined in RFC 3550, carries sender and receiver reports with packet counts, cumulative loss, interarrival jitter and the data needed to compute round-trip time. By convention RTP uses an even port and RTCP the next higher odd port, for example 40000 and 40001. SDP can signal a different RTCP port with a=rtcp (RFC 3605), and many modern systems multiplex RTP and RTCP on a single port (RFC 5761).

SRTP (RFC 3711) provides confidentiality, message authentication and replay protection for RTP and RTCP. Its default transforms are AES in counter mode for encryption and HMAC-SHA1 for authentication; AES-GCM was added later in RFC 7714. SRTP keys come from a separate key-management method, commonly SDES crypto attributes inside SDP (RFC 4568), which are only safe when the SIP signalling itself is protected by TLS, or from DTLS-SRTP (RFC 5764), which WebRTC uses.

NAT, Firewalls and the SBC

NAT and stateful firewalls cause more SIP problems than any other network function. SIP and SDP carry IP addresses and ports inside the message: in Via, in Contact, and in the c= and m= lines of SDP. A NAT device rewrites only the outer IP and transport headers, so a phone behind NAT can advertise a private address that the far end cannot reach. Signalling may still work, because responses follow Via, while media fails or flows in one direction only.

Consider a remote extension 1003 with the private address 192.168.1.50 behind a NAT whose public address is 203.0.113.80. Its REGISTER arrives from 203.0.113.80 on a translated port, but its Contact and SDP still say 192.168.1.50. The registrar, PBX or SBC must decide which address to trust at each layer, and the media path must be verified with packet captures rather than inferred from SIP.

In enterprise designs, an SBC at the network border is the usual tool. It acts as a B2BUA, presents its own public addresses in SIP and SDP, anchors media where needed, and hides internal topology. It still has to be configured correctly: an SBC does not by itself guarantee correct routing, codec support or security.

SIP Security: TLS for Signalling and SRTP for Media

Signalling and media are protected separately. SIP over TLS, usually on port 5061, encrypts and integrity-protects signalling hop by hop, between a client and a proxy or between two servers. It protects dialled numbers, identities, Digest challenges and any SRTP keys carried in SDP. The sips URI scheme requests TLS on every hop through to the target resource, including the last hop, under RFC 5630. Current guidance deprecates TLS 1.0 and 1.1 (RFC 8996) and recommends TLS 1.2 or TLS 1.3 (RFC 9325).

TLS does not protect media. Voice is encrypted only when SRTP is negotiated on each media leg, and it is protected end to end only if no B2BUA or SBC in the path decrypts and re-encrypts it. Every TLS connection and every SRTP context therefore has its own termination points, which should be documented in the design.

Because TLS is hop by hop, every proxy or SBC that terminates it can read and alter the SIP messages. Trust in a SIP network is therefore also a question of which elements are trusted, not only of encryption.

SIP Trunking, Microsoft Teams Direct Routing and Voice AI

A SIP trunk connects a PBX to a provider over IP instead of analog lines or ISDN primary rate circuits. Direct inward dialling (DID) numbers are mapped to extensions, and numbers are best normalised to E.164 before routing, for example +66 followed by the national number without its leading zero. Depending on the provider, a trunk authenticates either by registering with Digest credentials or by trusted IP address.

Microsoft Teams Direct Routing connects Teams Phone to a SIP trunk through an SBC that Microsoft has certified for that purpose. The Teams side uses SIP over TLS and SRTP, and the SBC translates between that interface and the trunk or PBX, including header, codec and media handling.

Voice AI platforms, such as automated receptionists and speech analytics, usually attach to a call through a SIP interface or a media fork. The same principles apply: separate the signalling interconnect from the media stream, confirm the codec and DTMF method, and measure latency on the media path, because it directly affects how natural the conversation feels.

SIPPER designs and supports SIP trunk, SBC and Teams Direct Routing interconnections for enterprises; the related SIP trunk guide below covers service selection in more detail.

Troubleshooting SIP Calls Layer by Layer

Start with evidence from the right places: packet captures from the phone side, the PBX, the SBC and the provider interface, correlated by Call-ID and time. On B2BUAs the Call-ID changes between legs, so also record timestamps, numbers and any correlation header the system adds.

The table maps common symptoms to likely causes and the first evidence to collect. Work through the planes in order: connectivity, transactions, dialog and routing, SDP, RTP and RTCP, and finally application behaviour.

References and Standards

The core standards used in this article are listed below. Where an older RFC has been replaced, the current document is given first.

• RFC 3261: SIP, the core protocol.
• RFC 3262: Reliability of provisional responses (100rel and PRACK).
• RFC 3263: Locating SIP servers with NAPTR, SRV and A or AAAA records.
• RFC 3264: The offer/answer model with SDP.
• RFC 8866: SDP, obsoleting RFC 4566.
• RFC 3550: RTP and RTCP; RFC 3551: the audio and video profile with static payload types.
• RFC 3711: SRTP; RFC 7714: AES-GCM for SRTP; RFC 4568 and RFC 5764: SRTP key management.
• RFC 3581: rport; RFC 5626: SIP Outbound; RFC 5923: connection reuse; RFC 4961: symmetric RTP.
• RFC 8445, RFC 8489 and RFC 8656: ICE, STUN and TURN.
• RFC 3311: UPDATE; RFC 3515: REFER; RFC 3891: Replaces; RFC 4028: session timers; RFC 6086: INFO.
• RFC 4733: DTMF telephone-event, obsoleting RFC 2833; RFC 7587: the Opus RTP payload format.
• RFC 3325: P-Asserted-Identity; RFC 3323: Privacy; RFC 5630: SIPS; RFC 8760: SHA-2 Digest for SIP; RFC 8996 and RFC 9325: TLS version guidance.
• RFC 7118: SIP over WebSocket; RFC 6026: corrections to INVITE transaction handling; RFC 6665: SUBSCRIBE and NOTIFY; RFC 3428: MESSAGE; RFC 3966: the tel URI; RFC 3605: the RTCP attribute; RFC 5761: RTP and RTCP multiplexing.