SIP, the Session Initiation Protocol, is the application-layer signalling protocol used to create, modify and end communication sessions between two or more participants. On a voice network it is what sets up a call, reports that the far end is ringing, confirms that somebody answered, changes the call while it is in progress, and tears it down at the end. It does not carry the audio. The voice itself travels in a separate media stream, normally RTP, whose addresses and codecs are negotiated inside the SIP messages.
SIP is defined in RFC 3261, published by the IETF in June 2002, which replaced the earlier RFC 2543. It is a text-based request and response protocol whose message syntax borrows heavily from HTTP, though the specification is explicit that SIP is not an extension of HTTP. It is the signalling layer underneath almost all modern IP telephony: IP PBXs, contact-centre platforms, session border controllers, softphones, carrier interconnects and the SIP trunks that connect them to the public phone network.
Quick facts
| Question | Short answer |
|---|---|
| What does SIP stand for? | Session Initiation Protocol |
| What does it do? | Establishes, modifies and terminates sessions between endpoints |
| What does it not do? | Carry audio, define codecs, guarantee bandwidth, or implement call features |
| Which specification defines it? | RFC 3261, extended and updated by many later RFCs |
| What carries the voice? | RTP, described separately in the media negotiation |
| How is the media negotiated? | SDP (RFC 8866) carried in SIP message bodies, using the offer and answer model in RFC 3264 |
| Which transports does it run over? | UDP, TCP and TLS are the common ones. Default ports are 5060, and 5061 for TLS |
| Is it the same as a SIP trunk? | No. SIP is the protocol. A SIP trunk is a commercial connection between a phone system and a carrier that uses it |
What SIP is responsible for
RFC 3261 describes five things SIP handles when a session is established and torn down:
User location. Working out which endpoint should be contacted for a given address. A person or service may be reachable at several devices, and those devices move.
User availability. Determining whether the called party is willing to take part. A busy signal, a rejection and a redirection are all availability outcomes.
User capabilities. Agreeing what media and parameters will be used, which in practice means agreeing a codec both sides can encode and decode.
Session setup. Ringing at the far end, and establishing the session parameters at both ends.
Session management. Transferring, modifying and ending sessions, and invoking services on top of them.
A useful way to hold this in mind: SIP’s job is to get two endpoints to agree on who is talking to whom and how the media will flow, and then to keep track of that agreement until somebody ends it.
What SIP does not do
This is where most misunderstandings start, so it is worth being blunt about the boundaries.
SIP does not carry voice. The audio is a separate stream. SIP messages contain a session description that says where to send the media and in what format, and nothing more.
SIP does not define codecs. The specification deliberately keeps media detail out of SIP. Codec information sits in the SDP body carried inside SIP messages, in the same way an attachment is carried by an email.
SIP cannot reserve bandwidth. RFC 3261 states plainly that because SIP messages and the sessions they establish can traverse entirely different networks, SIP does not provide any network resource reservation capability. Call quality is a property of the IP path, not of the signalling protocol.
SIP does not implement features. It provides primitives rather than services. Hold, transfer, hunt groups, queues, voicemail and IVR are built by an application on top of SIP primitives. The protocol supplies the building blocks.
This is also why the claim that “SIP reduces latency” is wrong in the direction it is usually made. Signalling choices affect how quickly a call is set up. Once the media is flowing, delay comes from the network path, the codec, the jitter buffer and any transcoding, which is covered in latency, jitter and packet loss.
How a SIP call is set up
A basic call uses a three-way handshake. The caller’s user agent sends an INVITE. The called user agent may send provisional responses such as 100 Trying and 180 Ringing to report progress. When the call is answered it sends 200 OK, and the caller confirms with ACK. At that point a dialog exists between the two endpoints, and the media path is negotiated inside those messages.
The media negotiation runs as an offer and an answer. The INVITE normally carries an SDP offer listing the codecs the caller supports and the address and port where it wants to receive audio. The 200 OK carries the SDP answer selecting from that list and giving the answering side’s address and port. This offer and answer model, defined in RFC 3264, is the mandatory baseline negotiation mechanism for SIP.
Ending the call is simpler. Either side sends BYE and the other answers 200 OK. Notice the asymmetry: ACK exists only for responses to INVITE, because a ringing phone can take a long time to answer and because an INVITE can be forked to several destinations at once. Every other method, BYE included, uses an ordinary request and response with no acknowledgement.
Mid-call changes reuse the same mechanism. A re-INVITE inside an existing dialog carries a new session description, and the other party accepts it with 200 OK or rejects it with an error such as 488 Not Acceptable Here. A rejected re-INVITE does not drop the call. The session simply continues on the previously agreed terms.
Why signalling and media travel separately
SIP signalling is routed. It can pass through one proxy, several, or none, and each proxy can decide whether it wants to stay in the path for the rest of the dialog by inserting a Record-Route header. Media is not routed the same way. Once both ends know each other’s media address from the SDP exchange, RTP normally flows directly between them. The signalling path establishes the call, but the audio does not have to follow it.
Two practical consequences follow from this split.
The first is diagnostic. A call that sets up cleanly and then has no audio is almost never a SIP problem. The signalling worked, which is why the call connected. Something is wrong on the media path, usually a firewall, a NAT device or an address rewritten incorrectly. The most common single cause is a router’s SIP helper, described in SIP ALG: why it breaks SIP calls.
The second is architectural. Because the two flows are independent, they can be secured, routed and monitored independently, and they can also fail independently. A session border controller is often introduced precisely to bring both flows back under one point of control at a network edge.
Details of what the media stream itself carries are covered in what is RTP.
Inside a SIP message
A SIP message is plain UTF-8 text. It has a start line, header fields, a blank line and an optional body. A request start line names the method, the Request URI it is addressed to and the protocol version. A response start line gives the version, a three-digit status code and a reason phrase.
Six header fields are mandatory in every SIP request: To, From, CSeq, Call-ID, Max-Forwards and Via. Between them they handle addressing, response routing, message ordering, loop prevention and transaction identification.
| Header | What it does |
|---|---|
| To | The address the request was originally directed to |
| From | The originator, with a tag identifying this side of the dialog |
| Call-ID | A globally unique identifier for the call |
| CSeq | A sequence number plus a method name, incremented per new request in a dialog |
| Via | Where responses to this request should be sent, plus a branch parameter identifying the transaction |
| Max-Forwards | A hop counter, decremented at each hop, commonly starting at 70 |
| Contact | Where future requests should be sent, as opposed to responses |
Two distinctions inside that table matter more than they look. Via tells other elements where to send the response, while Contact tells them where to send future requests. And the To tag, the From tag and the Call-ID together identify a dialog. Neither the To header nor the Request URI does that on its own.
The message body is where the session description sits, usually SDP with a Content-Type of application/sdp. SIP treats it as an opaque payload.
SIP requests and responses
RFC 3261 defines six methods: REGISTER for publishing contact information, INVITE, ACK and CANCEL for setting up sessions, BYE for ending them, and OPTIONS for asking a server what it supports. Extensions registered with IANA add more, including SUBSCRIBE and NOTIFY for event notification, REFER for transfers, MESSAGE for instant messaging, UPDATE for early session changes, PRACK for reliable provisional responses, and INFO for carrying session-related information mid-call.
Responses are grouped by their first digit, in the same six classes used throughout the protocol:
| Class | Meaning | Common examples |
|---|---|---|
| 1xx | Provisional, request received and being processed | 100 Trying, 180 Ringing, 183 Session Progress |
| 2xx | Success | 200 OK |
| 3xx | Redirection, further action needed | 302 Moved Temporarily |
| 4xx | Request failure at this server | 403 Forbidden, 404 Not Found, 486 Busy Here, 488 Not Acceptable Here |
| 5xx | Server failure on an apparently valid request | 500 Server Internal Error, 503 Service Unavailable |
| 6xx | Global failure, the request will fail anywhere | 600 Busy Everywhere, 603 Decline |
Everything other than a 1xx is a final response. The class boundary that trips people up most is 4xx against 6xx: a 486 means this endpoint is busy and another one might answer, while a 600 means stop trying anywhere. A full breakdown is in SIP response codes explained.
The elements a SIP network is built from
SIP defines logical roles, not boxes. One piece of software can be several of these, and can change role between one transaction and the next.
User agent. An endpoint. It acts as a user agent client when it sends a request and a user agent server when it answers one. A softphone, an IP phone, a PBX and a media gateway are all user agents.
Proxy server. An intermediary that forwards requests towards the target and enforces policy along the way. A stateful proxy tracks transaction state, a stateless proxy does not. A proxy can send an INVITE to several possible locations at once, which is called forking.
Registrar. A server that accepts REGISTER requests and writes the resulting bindings into a location service, so proxies know which contact addresses currently correspond to a given address of record.
Redirect server. A user agent server that answers with a 3xx response telling the client to try a different set of addresses rather than forwarding the request itself.
Back to back user agent. A B2BUA terminates the dialog on one side and originates a new one on the other, acting as a user agent server and a user agent client at the same time. Unlike a proxy it holds dialog state and sits in every request on the dialogs it establishes. Most IP PBXs and session border controllers behave this way, which is why call legs on either side of them can look unrelated in a trace.
One point about registration is worth stating because it is widely misread. Registration exists to route incoming requests to the right place. It plays no part in authorising outgoing requests. Authorisation is handled separately, per request, through a challenge and response exchange or at a lower layer. A device that is registered is reachable, not thereby entitled to place calls.
Transactions and dialogs are not the same thing
These two terms are used loosely in day-to-day conversation and precisely in the specification, and the difference explains a lot of otherwise confusing behaviour.
A transaction is one request plus all the responses to it. It is matched using the branch parameter in the topmost Via header, and it lives for seconds. The INVITE and everything up to the final response is one transaction. The BYE at the end of the call is a different transaction entirely.
A dialog is the peer to peer relationship between two user agents that persists across transactions. It is identified by the Call-ID together with the local and remote tags, and it lives for the duration of the call.
Related distinction: a loop is a request that returns to a proxy unchanged in every way that affects routing, which is an error the protocol detects and rejects. A spiral is a request that returns to the same proxy but targeted somewhere different, typically because of call forwarding, and that is entirely legitimate. Traces that look like loops are frequently spirals.
How SIP finds the other end
When a request has to leave the local network, the sending element resolves the destination domain rather than hard-coding an address. RFC 3263 defines how this works, using NAPTR records to discover which transports a domain supports and SRV records to find the hosts and ports for that transport, before falling back to ordinary address records. The result is an IP address, a port and a transport. The URI in the request is not rewritten.
This matters operationally because it is the mechanism that lets a provider present several servers behind one name, distribute load between them, and fail over to another when one is unreachable. A configuration that points at a single IP address rather than a name gives that up.
SIP compared with the terms it gets confused with
| Term | What it is | Where the confusion comes from |
|---|---|---|
| SIP | The signalling protocol that sets up and ends sessions | Used loosely to mean the whole voice service |
| SIP trunk | A commercial connection between a phone system and a carrier that uses SIP | “We use SIP” describes a technology, “we have a SIP trunk” describes a service |
| VoIP | The broad category of carrying voice over IP networks | SIP is one protocol used within VoIP, not a synonym for it |
| RTP | The protocol that carries the media | SIP negotiates the media, RTP transports it |
| SDP | The format used to describe the session | SDP is carried inside SIP bodies, it is not part of SIP itself |
| SIP URI | An address of the form sip:user@domain |
It identifies a SIP resource, and is not the same thing as a phone number, though a number can be expressed as one |
If you are evaluating a service rather than a protocol, what is SIP trunking covers the commercial and architectural side.
How SIP is secured
Plain SIP over UDP is unauthenticated text on the wire. Three mechanisms are normally layered on top.
Transport security. Running SIP over TLS encrypts the signalling hop by hop. A SIPS URI goes further and requires secure transport from the caller all the way to the callee’s domain, after which the security applied on the final leg depends on that domain’s policy. TLS 1.0 and 1.1 have since been deprecated by RFC 8996, so current deployments should be on TLS 1.2 or later.
Authentication. SIP uses a digest challenge and response scheme borrowed from HTTP. The original scheme in RFC 3261 was tied to MD5. RFC 8760 updated it to allow stronger hash algorithms, which is worth checking when specifying equipment.
Media protection. Encrypting the signalling does nothing for the audio, because the audio is a separate flow. SRTP protects the media, and it has to be negotiated in the SDP exchange rather than inherited from the signalling.
Securing the protocol is only part of the problem. Most real incidents on SIP infrastructure are credential and misconfiguration attacks aimed at generating chargeable traffic, which is covered in VoIP toll fraud and SIP security.
Mistakes that cause most SIP problems
Assuming SIP carries the audio. If the call connects and there is no sound, look at the media path and the devices between the endpoints, not at the signalling.
Letting a router rewrite SIP. SIP helper features in consumer and small business routers modify addresses inside SIP messages and frequently corrupt them. Disable the helper and handle NAT deliberately.
Sending DTMF as audio. Low bit rate codecs cannot be relied on to reproduce tones accurately enough for a machine to recognise them, which is why RFC 4733 defines DTMF as named telephone events carried in RTP. Both ends have to agree to use it. Keypad input that works on one route and fails on another is usually this.
Treating a 4xx as a permanent failure. A 486 or a 480 is one endpoint’s answer, not the network’s. Retrying elsewhere may well succeed. A 6xx is the one that means stop.
Confusing a call with a dialog with a transaction. A single call contains several transactions. Correlating logs on Call-ID rather than on branch parameters saves a lot of time.
Pointing a trunk at an IP address rather than a hostname. This discards the DNS-based failover and load distribution the protocol was designed to use.
Where didlogic fits
didlogic operates the carrier side of a SIP interconnect. The customer’s phone system, contact-centre platform or voice application speaks SIP, and didlogic terminates that signalling, applies routing, and hands calls on to the networks that serve the destination. The SIP trunking service is delivered over SIP itself, which is a native capability of most IP PBXs, session border controllers and gateways.
Outbound trunks can be authenticated in either of the two ways the protocol supports: SIP registration with a username and password, which suits softphones and most IP PBXs, or static IP authentication with no registration, which suits enterprise SBCs and gateways. TLS and TCP transports are supported alongside UDP, as are non-standard ports.
On the inbound side, a virtual phone number can be mapped to a registered SIP device, pointed at a SIP URI including one on an external network, forwarded to an ordinary phone number, or sent to several destinations at once for hunt groups or failover.
What stays with the customer is everything above the signalling layer: extensions, queues, call logic, recording, IVR and any application behaviour. SIP is the interface between the two, which is why the boundary is usually clean and why the same trunk works whether the thing behind it is a PBX, a contact-centre platform or a voice application.
FAQs
Is SIP the same as VoIP?
No. VoIP is the general practice of carrying voice over IP networks. SIP is one specific protocol used within VoIP, and it handles only the signalling. A VoIP system also needs a media protocol, and most use RTP.
Does SIP carry the voice?
No. SIP negotiates where the media should be sent and in what format, then the media flows separately, normally as RTP. This is why signalling can succeed while audio fails.
What port does SIP use?
The defaults defined in RFC 3261 are 5060 for UDP and TCP, and 5061 for TLS. Providers and platforms frequently use non-standard ports, and DNS SRV records can specify a different port for a domain, so the default should never be assumed.
What is the difference between SIP and SIP trunking?
SIP is a protocol defined by the IETF. A SIP trunk is a service: a connection between a phone system and a carrier, sold with capacity, numbers and routing, that happens to use SIP as its signalling protocol.
Why do SIP calls connect but have no audio?
Because the signalling and the media take different paths. The call connecting proves the signalling worked. One-way or absent audio points at NAT handling, a firewall, or a device rewriting addresses inside the SDP.
Is SIP encrypted by default?
No. Plain SIP is readable on the wire. TLS encrypts the signalling and SRTP encrypts the media, and the two are negotiated separately. Encrypting one does not encrypt the other.
How does SIP handle keypad presses?
Usually not as audio. RFC 4733 defines DTMF digits as named events carried in RTP, because low bit rate codecs cannot be guaranteed to reproduce the tones accurately enough for automatic recognition. Both ends have to support and negotiate it.
Is SIP still current, given RFC 3261 is from 2002?
Yes. The core specification has been extended and corrected by a long list of later RFCs covering authentication, transport security, event notification, connection management and transaction handling, but the model described in RFC 3261 remains the one in use.
Continue learning
