What is the SIP Protocol?
Definition: SIP, or session initiation protocol is a signaling protocol for IP-based telephony applications. A signaling protocol provides the control layer for communications such as the establishment and release of a voice call.
History of SIP
Previous signaling protocol such as SS7 were designed for circuit-switched networks. These networks use dedicated T1 channels for carrying telephony communications and signaling. With dedicated T1 channels, SS7 is able to provide high-quality voice communications, but at high cost due to the requirement of end-to-end dedicated channels. With the advent of IP and packet-based networks, telephony traffic could be routed more efficiently and cheaply. But this required a new packet-based signaling protocol to be developed. SIP was born. Initially designed for voice communications, today it can manage instant messaging, video conferencing, and file transfers.
At its simplest, SIP architecture consists of SIP user agents and servers.
User agents are endpoints for communications. Examples of user agents are a softphones, IP phones, or mobile phones. SIP servers are required to locate other user agents. Additionally, SIP servers can provide other services such as accounting and SIP forwarding.
SIP Protocol Basics
SIP is an application layer protocol that is very similar to text based application layer protocols like HTTP. In fact, it is also uses request and response message transactions and header fields. The following shows the request and response message transactions for a call initiated by User Agent A to User Agent B.
For transport, SIP can run over TCP, UDP, or SCTP transport layer protocols. The following is an example SIP request message.
INVITE sip:firstname.lastname@example.org SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKnp85213694-430aa1de192.168.1.2;rport From: "arik" <sip:email@example.com>;tag=51449dc To: <sip:firstname.lastname@example.org> Call-ID: email@example.com CSeq: 1 INVITE User-Agent: Nero SIPPS IP Phone Version 188.8.131.52 Expires: 120 Accept: application/sdp Content-Type: application/sdp Content-Length: 270 Contact: <sip:firstname.lastname@example.org> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, INFO
For comparison, here is a HTTP request message.
GET /download.html HTTP/1.1 Host: www.ethereal.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://www.ethereal.com/development.html
Right away you can see the similarities to HTTP. SIP starts with the Method line and then follows with several headers and possibly message content.
SIP Request Methods
SIP borrows the Method field from HTTP to likewise determine the type of request. SIP has 14 Method request types. The most commonly used Methods are INVITE, ACK, BYE, and REGISTER which are used during voice calls. The first line of a SIP request message includes the Method type and the request URI which is the current destination of the request.
Table of SIP request methods
|INVITE||Indicates a client is being invited to participate in a call session.|
|ACK||Confirms that the client has received a final response to an INVITE request.|
|CANCEL||Cancels any pending request.|
|OPTIONS||Queries the capabilities of servers.|
|REGISTER||Registers the address listed in the To header field with a SIP server.|
|SUBSCRIBE||Subscribes for an Event of Notification from the Notifier.|
|NOTIFY||Notify the subscriber of a new Event.|
|PUBLISH||Publishes an event to the Server.|
|INFO||Sends mid-session information that does not modify the session state.|
|REFER||Asks recipient to issue SIP request (call transfer.)|
|MESSAGE||Transports instant messages using SIP.|
|UPDATE||Modifies the state of a session without changing the state of the dialog.|
SIP Request Headers
Header fields are used to configure the SIP request message. The following are some common headers for a request message. Many more headers are available.
Common SIP request headers
|Via||Contains an address that is used to route back replies.|
|From||Contains the SIP URI of the caller.|
|To||Contains the SIP URI of the callee.|
|Call-ID||Contains the globally unique identification for this call using the caller's domain.|
|CSeq||Contains the sequence number of this message for this SIP conversation.|
|Contact||Contains the SIP URI to be used for future requests for this caller.|
|Content-Type||Contains the content type for the message body.|
|Content-Length||Contains the byte count length for the message body.|
SIP Addressing & The SIP URI
The SIP URI used in the To, From, and Contact header fields represents a user's SIP number. It is very similar to an email address. It consists of three components
<protocol:user@gateway>. The protocol can be sip or sips where the latter is secured with TLS. The user is a unique user on a SIP gateway or server.
SIP Response Status Codes
Again similar to HTTP, SIP responses provide status codes to indicate the result of a SIP request. The following lists common SIP response status codes.
Common SIP Response Status Codes
|100||The server is trying to reach the callee.|
|180||The callee is ringing.|
|181||The call is being forwarded.|
|200||The request is successful.|
|302||The user has temporarily moved. Try the Contact field SIP URI.|
|404||The user does not exist.|
SIP Message Body Content & SDP
SIP is content agnostic. Although it is well known for voice call signaling, it is also used for establishing sessions for messaging, video conferencing, SMS and more. The SIP message body determines the type of media session being established. The message body is typically included in a SIP Invite request as part of the initial session establishment.
Session Description Protocol (SDP) is a special content type used for VoIP. The content type is specified as application/sdp. In the following SIP Invite message, the SDP specifies the available voice codecs for a VoIP call.
SIP Invite with SDP Message Body
INVITE sip:email@example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKnp85213694-430aa1de192.168.1.2;rport From: "arik" <sip:firstname.lastname@example.org>;tag=51449dc To: <sip:email@example.com> Call-ID: firstname.lastname@example.org CSeq: 1 INVITE User-Agent: Nero SIPPS IP Phone Version 184.108.40.206 Expires: 120 Accept: application/sdp Content-Type: application/sdp Content-Length: 270 Contact: <sip:email@example.com> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, INFO v=0 o=SIPPS 85214742 85214739 IN IP4 192.168.1.2 s=SIP call c=IN IP4 192.168.1.2 t=0 0 m=audio 30000 RTP/AVP 0 8 97 2 3 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:3 GSM/8000 a=fmtp:97 mode=20 a=sendrecv
SIP VoIP Session Call Flow
Now that we have the basics down, let us put it all together for a SIP call flow to establish a VoIP call. There are four basic parts to establish a call: registration, call establishment, the VoIP call, and the call termination.
When a user agent (say a softphone) launches, it needs to register with a SIP server in order to be found by other user agents. The SIP Register request message is used for this. It provides the location bindings through the To and From SIP URIs. Optionally, an additional binding can be provided through the Contact field.
SIP Register Message
REGISTER sip:sip.cybercity.dk SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2;branch=z9hG4bKnp151248737-46ea715e192.168.1.2;rport From: <sip:firstname.lastname@example.org>;tag=903df0a To: <sip:email@example.com> Call-ID: 578222729-4665d775@578222732-4665d772 Contact: <sip:firstname.lastname@example.org:5060;line=9c7d2dbd8822013c>;expires=1200;q=0.500 Expires: 1200 CSeq: 68 REGISTER Content-Length: 0 Max-Forwards: 70 User-Agent: Nero SIPPS IP Phone Version 220.127.116.11
B: Call Establishment
Call establishment is where the magic happens. There are a few steps here, so let's cover them one-by-one in sequence.
- SIP Invite Request - The SIP Invite starts the call establishment attempt. This message contains the callee (SIP URI in the To field). This is sent from the caller to the SIP server where it looks up the callee. In a larger network, the SIP server may need to consult other SIP servers if the callee is not local. Once the callee is located, the Invite is forwarded. For VoIP, the Invite also includes a SDP message body with the parameters for the VoIP call.
- SIP Response 100 (Trying) - This message is sent from the SIP server to the callee to confirm the Invite request.
- SIP Response 180 (Ringing) - This message indicates that the Invite was received by the callee and their user agent is alerting the user.
- SIP Response 200 (OK) - When the user picks up, a 200 response is sent back to confirm the call. Additionally, the callee sends a SDP message body with its VoIP call parameters. As a result of this message and the initial Invite from the caller, an exchange and negotiation of VoIP call parameters has occurred.
- SIP Ack Request - Finally, the caller confirms with an Ack request back to the callee. The callee then initiates the VoIP call to the caller.
C: VoIP Call
The VoIP call itself is transmitted between the user agents using RTP (real-time transport protocol). This protocol is used for delivering audio and video data over IP networks. An additional protocol RTCP (RTP control protocol) is used to provide statistics and control for the RTP transmissions. We will cover RTP and RTCP in an upcoming blog.
D: Call Termination
When a user decides to terminate a call, a SIP Bye request is sent. Either side of the call can terminate. The other user agent then responds with a SIP 200 status code response to confirm the termination.
So there you have it. That's SIP in a nutshell. Want to go deeper? Check out this example dashboard of ExtraHop's SIP monitoring capabilities, then try our online interactive demo.