SIP Illustrated 1: Basics

In November 2000, the Session Initiation Protocol (SIP) was accepted by 3GPP as a signaling protocol of the IP Multimedia Subsystem (IMS) network for IP-based streaming multimedia services. Later it was extended for video conferencing, streaming multimedia distribution, instant messaging, presence information, file transfer, etc.



The SIP protocol is easy to understand as it is text-based and practically derived from the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP). SIP is very flexible and well designed for Internet telephony, on the other hand it has also some disadvantages and limitations. If you’re new to IMS signalling or you just need some brief introduction into SIP, I hope you’ll find this post useful.


SIP is standardized in RFC 3261, but there are many other RFCs, which update/complement it (e.g. RFC 5626). SIP can be transported on top of UDP, TCP or SCTP.

SIP Protocol Stack

SIP Protocol Stack

  • As a payload SIP can carry MIME Content, XML, Session Description Protocol (SDP), Binary Content (SMSoIP), etc.
  • For security we can use IPSec or TLS.
  • SIP clients typically use TCP or UDP on port numbers 5060 or 5061.  Port 5060 is commonly used for non-encrypted signaling traffic whereas port 5061 is typically used for traffic encrypted with TLS (sips).


Although SIP is being used to establish peer-to-peer communication, the protocol itself is client-server oriented. In contrast to other protocols, the roles of client or server are not permanent. In one dialog an endpoint can be a client whereas in another can act as a server.

SIP endpoints

SIP endpoints

  • Roles of endpoints can change – they last only for one transaction.
  • Each resource of a SIP network, such as a user agent or a voicemail box, is identified by a Uniform Resource Identifier(URI).
  • In SIP we have two types of messages – Requests and Responses. Client always sends a request, server always responds with a response.

SIP Requests

There are only a few SIP Requests, but their meaning can fundamentally change based on the value of particular SIP headers.

REGISTER Maps a public URI with the current location of the user, is used for authentication of the subscriber.
INVITE  Establishes a session, can carry SDP.
PRACK Acknowledges the reception of a provisional response.
UPDATE Modifies some characteristics of a session.
ACK Acknowledges the establishment of a session – there is no response for this request.
CANCEL Cancels a pending request.
REFER Ask recipient to issue SIP request for the purpose of call transfer.
INFO Send mid-session information that does not modify the session state (e.g. communication with MRF).
BYE Terminates a session.
OPTIONS Queries a server about its capabilities.
PUBLISH Uploads (presence) information to a server.
SUBSCRIBE  Requests to be notified about a particular event.
NOTIFY Notifies the user agent about a particular event.
MESSAGE Carries a message (text, binary, instant, service).

SIP Responses

The response – as in case of HTTP – is just a code. There is also a text description attached, but that has only an informational value. Basically we have two types of responses – Provisional (100 – 199) and Final (200 – 699). Final response (e.g. 200 OK or 603 Decline) terminates a SIP transaction.

Provisional 1xx 
100 Trying
180 Ringing
181 Call Is Being Forwarded
183 Session Progress
Successful 2xx 
200 OK
202 Accepted [RFC3265]
Redirection 3xx
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
Request Failure 4xx 
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
Server Failure 5xx
500 Server Internal Error
501 Not Implemented
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
Global Failures 6xx 
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable


User Agent Client (UAC) and User Agent Server (UAS) can communicate directly. But in practice there is typically some network infrastructure involved. The SIP network elements consist of Proxies (stateless/stateful), Redirect Servers, Registrar, Gateways, Back-to-back User Agents, Session Border Controllers, etc.  When a UAC sends a request, the request goes through number of proxy servers, which forward it towards the UAS. When the UAS generates a response, the response is forwarded back to the UAC.

SIP Proxy

SIP Proxy

  • SIP Proxy provides routing within the network.
  • Can enforce various policies.
  • Can rewrite specific message parts before forwarding it to the next network element.


A special type of a server providing authentication and location service is called Registrar. In IMS network this role is played by S-CSCF.

SIP Registrar

SIP Registrar


Redirect server is not that often to see in the IMS. E.g. it can be implemented by Location Retrieval Function (LRF).

SIP Redirect Server

SIP Redirect Server


Very important for IMS is the role of Back-to-back User Agent B2BUA. In fact B2BUAs are special network elements, which act as ‘double-agents’. They are seen as servers from the client point of view and as clients from the server point of view. So technically they split the SIP communication into two legs. In IMS we use this concept very often, for example all the Application Servers act as B2BUAs. Later we can discuss various types of B2BUAs.



  • B2BUA maintains the complete call state and participates in all call requests.
  • Can change arbitrary part of a message. Note, that this applies also to Call-ID header.
  • B2BUA can also originate or terminate a message from the SIP point of view (e.g. IPSMGW).

Another very important network element without which can’t work any real 4G network is a Session Border Controller (SBC). This network component has to support many different functionalities (as we already discussed). One of the reasons why we have to have the SBC is, that SIP can’t work over NAT. Simply said, SIP contains IP addresses in headers and also in the body of a message. But in the real world we use not only public IP addresses but also private networks with private (therefore not directly addressable) IPs.

Session Border Controller - NAT

Session Border Controller – NAT

  • SIP acts as B2BUA.
  • Provides (among others) NAT, NAT Traversal, IPv4 to IPv6 interworking, Topology Hiding.

We know that SIP provides signalling for a multimedia session. To negotiate the session parameters we have to share the IPs for media session (e.g. RTP, MSRP). The issue is that the Originator and Recipient can be present in different (private) networks. It is the job SBC to overcome this obstacle and to provide correct IP addresses and media routing.

A-SBC Possitioning

A-SBC Possitioning

On these pages we discuss mainly IMS network architecture and functionalities. It is important to mention, that for a mobile device (client application) it is the IMS network (namely the P-CSCF) which is the first point of contact for the SIP communication. IMS components then implement the roles of SIP network elements, sometimes more then one role is supported.




Note: I know there are many much better resources about SIP. This is simply my way how sort out thoughts 🙂

Related posts:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s