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.
SIP in VoLTE
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
- 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
- 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 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
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
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.
SIP B2BUA
- 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
- 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
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.
SIP – IMS
Note: I know there are many much better resources about SIP. This is simply my way how sort out thoughts 🙂
Related posts:
Real Time Communication 