VoIP Protocols: SIP Call Flow
Vladimír Toncar
In this section, we will describe the the flow of a SIP call and show examples of SIP message exchanges.
Registration
Before we describe the flow of a typical SIP call, let's have a look at how SIP user agents register with a SIP registrar. The example below shows a situation where an SIP softphone (namely, the Ekiga client) registers with an Asterisk PBX. The Asterisk's IP address is 10.10.1.99, while the client is at 10.10.1.13 and wants to register the telephone number 13.
In order to register, the SIP telephone needs the send the REGISTER request:
 |
The registrar server will immediately reply with the provisional response "100 Trying". This indicates that the request has been received (and thus the client does not need to retransmit it) and that it is being processed. While processing the request, the registrar discovers that the user agent needs to authenticate. It therefore responds with "401 Unauthorized". For the user agent, this means that it has to send the REGISTER request once more, this time providing authentication.
Let's have a look at the detail of the messages. This is the text of the register message:
REGISTER sip:10.10.1.99 SIP/2.0
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 10.10.1.13:5060;
branch=z9hG4bK78946131-99e1-de11-8845-080027608325;rport
User-Agent: Ekiga/3.2.5
From: <sip:13@10.10.1.99>
;tag=d60e6131-99e1-de11-8845-080027608325
Call-ID: e4ec6031-99e1-de11-8845-080027608325@vvt-laptop
To: <sip:13@10.10.1.99>
Contact: <sip:13@10.10.1.13>;q=1
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,
INFO,PING
Expires: 3600
Content-Length: 0
Max-Forwards: 70
We probably do not need to show the "100 Trying" response. The text of the "401 Unauthorized" message is as follows:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.10.1.13:5060;
branch=z9hG4bK78946131-99e1-de11-8845-080027608325;
received=10.10.1.13;rport=5060
From: <sip:13@10.10.1.99>;
tag=d60e6131-99e1-de11-8845-080027608325
To: <sip:13@10.10.1.99>;tag=as5489aead
Call-ID: e4ec6031-99e1-de11-8845-080027608325@vvt-laptop
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk",
nonce="343eb793"
Content-Length: 0
In the "401 Unauthorized" response, the important header is WWW-Authenticate:. It instructs the client to authenticate using the digest authentication (RFC2617). The nonce (a short for "number used once") parameter is a "challenge string". The client will combine the challenge string with the user's password and compute the MD5 hash of the resulting string. The server will compute its own hash using the same method and compare it with the MD5 hash provided by the client. The digest authentication is the most frequently used method because the password is never sent over the network in plain text. The "basic" authentication has been deprecated in SIP 2.0 as it is insecure (sending a password in plain text is generally a bad idea).
Once the client computes the MD5 digest, it will re-send the REGISTER request. The message will look like this:
REGISTER sip:10.10.1.99 SIP/2.0
CSeq: 2 REGISTER
Via: SIP/2.0/UDP 10.10.1.13:5060;
branch=z9hG4bK32366531-99e1-de11-8845-080027608325;rport
User-Agent: Ekiga/3.2.5
Authorization: Digest username="test13", realm="asterisk",
nonce="343eb793", uri="sip:10.10.1.99", algorithm=MD5,
response="6c13de87f9cde9c44e95edbb68cbdea9"
From: <sip:13@10.10.1.99>;
tag=d60e6131-99e1-de11-8845-080027608325
Call-ID: e4ec6031-99e1-de11-8845-080027608325@vvt-laptop
To: <sip:13@10.10.1.99>
Contact: <sip:13@10.10.1.13>;q=1
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,
MESSAGE,INFO,PING
Expires: 3600
Content-Length: 0
Max-Forwards: 70
The registrar server will again first respond with "100 Trying" and then compare the two MD5 hashes (the one provided by the client with the one computed by the registrar itself). If the they match, the registrar will respond with "200 OK" and insert the endpoint to the location database. The database is usually shared between the registrar and the proxy server so that the proxy can use it connect calls.
The figure below shows the message exchange:
 |
The response "200 OK" contains one important parameter, Expires. It tells the client that the registration will expire after the given number of seconds and the client will be required to register again.
Call Flow
Let us now have a look at a typical SIP call. We will consider a scenario with a SIP proxy server involved. Suppose a user at the SIP telephone with number 121 dials the number 122. The following will happen:
1. The user agent in telephone 121 does not know the IP address of 122. But it knows the IP address of the SIP proxy (suppose this address is 10.10.1.99). The user agent will compose an INVITE request and send it to the proxy. The To: header of the request contains the SIP URI <sip:122@10.10.1.99>. The body of the INVITE request carries an SDP (Session Description Protocol) message providing the parameters (codec, IP address, port) the called party will need to send its RTP stream to the caller. See the previous section for an example of the INVITE request.
2. The SIP proxy immediately responds with "100 Trying" and then forwards the INVITE request to the target telephone. The proxy server adds one Via: header to the message. As mentioned before, the SIP proxy has access to the location database and thus knows the IP addresses of all registered telephones (the simplest implementation of this is such that the registrar server and the proxy are the same application).
Steps 1 and 2 are shown in Figure A below.
 |
3. The telephone 122 starts ringing and sends the response "180 Ringing" to the proxy server. The proxy will forward the response to the telephone 121.
4. The called user picks up the phone and her telephone sends the response "200 OK". The body of the response contains an SDP message so that the caller knows where to send his RTP stream. The proxy server forwards the response to the caller.
5. The caller (telephone 121) confirms the receipt of "200 OK" with the ACK message. The proxy server forwards the ACK to the telephone 122. At this point, the call has been established and both parties start sending their RTP streams.
The steps 3 through 5 are shown in Figure B.
 |
6. When one of the users hangs up, his/her telephone sends the request BYE and the SIP proxy forwards the message to the other party. The other party responds to the BYE request with "200 OK" (again, the proxy server forwards the response to the other side). Both parties stop sending RTP data and the call is over.
The events in step 6 are shown in Figure C.
 |
In order to understand the SIP call flow better, we now need to have a closer look at the Session Description Protocol. This is the topic of the next section.
Next section: SIP — Session Description Protocol