What Is SIP and How Does SIP Calling Work?

SIP, the Session Initiation Protocol, is the signalling protocol that sets up, modifies and ends multimedia sessions such as voice calls over IP networks. It is defined in RFC 3261. SIP tells the other side who is calling, where to send the audio and when the call is over. It does not carry the audio itself. The voice is sent separately in RTP packets. A SIP call therefore involves two parallel flows: SIP messages for control and RTP packets for media.

What does SIP look like?

SIP is a text protocol. A message starts with a request line or a status line, followed by header fields and an optional body. It is deliberately similar to HTTP, so anyone who has read an HTTP request will recognise the shape. A request looks like this:

INVITE sip:2002@pbx.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK156102930c;rport
Max-Forwards: 70
From: "Alice" <sip:1001@pbx.example.com>;tag=71ac9ce7
To: <sip:2002@pbx.example.com>
Call-ID: df22a1f9a716e990@192.168.1.20
CSeq: 1 INVITE
Contact: <sip:1001@192.168.1.20:5060>
Content-Type: application/sdp
Content-Length: 231

The first line names the method (INVITE) and the target SIP URI. The headers identify the caller, the callee, the specific call (Call-ID) and the path the message took (Via). The body, when present, usually contains SDP that describes the media. It follows the headers after a blank line and is left out here.

What are the main SIP methods?

RFC 3261 defines six core request methods. Other RFCs add more, but these six cover a basic call.

• REGISTER tells a server where a user can currently be reached. A softphone sends it at start-up and repeats it before the registration expires. See SIP registration explained.
• INVITE starts a session. It carries an SDP offer describing what media the caller can handle.
• ACK confirms that the caller received the final response to an INVITE. It completes the three-way handshake.
• BYE ends an established session.
• CANCEL aborts an INVITE that has not yet been answered.
• OPTIONS asks a server or device what it supports. PBXs often use it as a keepalive to check if a phone is still reachable.

Responses use three-digit codes. 100 Trying and 180 Ringing are provisional. 200 OK means success. 401 Unauthorized and 407 Proxy Authentication Required ask the client to authenticate. 404 Not Found, 486 Busy Here and 503 Service Unavailable are common errors. The SIP error code lookup lists them in detail.

How does a SIP call flow from start to finish?

Consider Alice at extension 1001 calling Bob at 2002 through a PBX.

1. Alice's softphone sends INVITE to the PBX with an SDP offer listing her IP address, RTP port and supported codecs.
2. The PBX replies 100 Trying so Alice's phone knows the request arrived. If the PBX requires authentication, it first replies 401 or 407 and Alice's phone resends the INVITE with credentials.
3. The PBX looks up where Bob is registered and forwards a new INVITE to Bob's device.
4. Bob's device rings and sends 180 Ringing back. The PBX relays it to Alice, whose phone plays a ringback tone.
5. Bob answers. His device sends 200 OK with an SDP answer naming his chosen codec, IP address and RTP port.
6. Alice's phone sends ACK. The call is now established.
7. Both sides send RTP audio directly to the negotiated addresses, or through the PBX if it stays in the media path.
8. Bob hangs up. His device sends BYE. Alice's phone replies 200 OK and both sides stop sending RTP.

The INVITE and its 200 OK create a dialog, which the ACK confirms. Every later message in that call, such as a re-INVITE to put the call on hold or the final BYE, belongs to the same dialog and shares its Call-ID and tags.

How does SIP negotiate audio?

SIP itself does not know about codecs or ports. It carries an SDP body, defined in RFC 8866, that does. The caller sends an offer listing every codec it can use in order of preference. The callee picks from that list and replies with an answer. RFC 3264 defines the rules for this exchange. The selected codec, the IP addresses and the RTP ports in the answer define the media stream. This is called the offer/answer model.

A minimal SDP offer for an audio call lists a connection address, a media line with the port and payload types, and attribute lines naming each codec. For example m=audio 10000 RTP/AVP 111 0 8, together with an a=rtpmap line that maps the dynamic type 111 to Opus, offers Opus, G.711 ulaw and G.711 alaw on port 10000. See SIP codecs explained for the common choices.

How does a SIP client find the server?

When a softphone has only a domain name and no port, it follows RFC 3263. It looks up NAPTR records to learn which transports the domain supports, then SRV records such as _sip._udp.example.com or _sips._tcp.example.com to find the host and port, and finally A or AAAA records for the IP address. Many softphones, including SIPdia, do a DNS SRV lookup when no port is given and fall back to the default port when no SRV record exists.

Which transports does SIP use?

SIP runs over UDP, TCP or TLS. UDP is the traditional default on port 5060. TCP suits large messages and connections through NAT. TLS adds encryption on port 5061. The choice affects reliability, NAT behaviour and privacy but not the SIP messages themselves. See SIP over UDP, TCP and TLS.

What roles exist in a SIP network?

• User agent (UA). The endpoint, such as a softphone or desk phone. It acts as a client when it sends requests and as a server when it answers them.
• Registrar. Accepts REGISTER requests and stores the current location of each user.
• Proxy. Receives requests and forwards them towards the destination. A PBX typically combines registrar and proxy.
• Back-to-back user agent (B2BUA). Terminates a call on one side and starts a new one on the other. Asterisk works this way, which lets it record, transfer and bridge calls.

Why does SIP sometimes fail behind NAT?

SIP messages carry IP addresses in their headers and SDP body. A device behind a home router writes its private address, such as 192.168.1.20, into the Via and Contact headers and into the SDP. The server on the public internet cannot reach that address. The result is a registration that appears to succeed but never receives calls, or a call that connects with no audio. Solutions include the rport parameter, STUN, ICE and server-side NAT handling. SIP registration explained and Understanding RTP cover the details.

Next steps

See how these concepts appear in a real app on the SIPdia features page. Then read SIP registration explained to understand the first message every softphone sends, and Understanding RTP and audio streams to follow the voice itself.