The core SIP specification defines six types of SIP requests, each of them with a different purpose. Every SIP request contains a field, called a method, which denotes its purpose. The list shows the six methods.
Range Response Class 100—199 Informational 200—299 Success 300—399 Redirection 400—499 Client error 500—599 Server error 600—699 Global failure
Table 5-1 SIP Response Classes.
100 Trying 413 Request entity too large
180 Ringing 414 Request-URI too large
181 Call is being forwarded 415 Unsupported media type
182 Queued 420 Bad extension
183 Session progress 480 Temporarily not
available
200 OK 481 Call leg/transaction
does not exist
202 Accepted 482 Loop detected
300 Multiple choices 483 Too many hops
301 Moved permanently 484 Address incomplete
302 Moved temporarily 485 Ambiguous
305 Use proxy 486 Busy here
380 Alternative service 487 Request cancelled
400 Bad request 488 Not acceptable here
401 Unauthorized 500 Internal servere error
402 Payment required 501 Not implemented
403 Forbidden 502 Bad gateway
404 Not found 503 Service unavailable
405 Method not allowed 504 Gateway time-out
406 Not acceptable 505 SIP version
not supported 407 Proxy authentication
600 Busy everywhere required
408 Request time-out 603 Decline
409 Conflict 604 Does not exist anywhere
410 Gone 606 Not acceptable
411 Length required
Table 5-2 SIP Response Codes
■ INVITE
■ ACK
■ OPTIONS
■ BYE
■ CANCEL
■ REGISTER
We will see in subsequent chapters how some extensions to the core SIP specification define additional methods.
Both requests and responses can contain SIP bodies. The body of a mes-sage is its payload. SIP bodies usually consist of a session description.
INVITE INVITE requests invite users to participate in a session. The body of INVITE requests contains the description of the session. For instance, when Bob calls Laura, his UA sends an INVITE with a session description to Laura’s UA. Let us assume that Bob’s UA uses Session Description Protocol (SDP) to describe the session. Her UA receives the INVITE with the following session description:
v=0
o=Bob 2890844526 2890842807 IN IP4 131.160.1.112 s=I want to know how you are doing
c=IN IP4 131.160.1.112 t=0 0
m=audio 49170 RTP/AVP 0
The INVITE received by Laura’s UA means that Bob is inviting Laura to join an audio session. From the session description carried in the INVITE, Laura’s UA knows that Bob wants to receive Real-time Transport Protocol (RTP) packets containing Laura’s voice on 131.160.1.112 User Datagram Protocol (UDP) port number 49170. Her UA also knows that Bob can receive Pulse Code Modulation(PCM) encoded voice. (RTP/AVP0 in the m line indicates PCM.)
Laura’s UA begins alerting Laura and returns a “180 Ringing” response to Bob’s UA. When Laura finally accepts the call, her UA will return a “200 OK” response with a session description in it.
v=0
o=Laura 2891234526 2812342807 IN IP4 138.85.27.10 s=I want to know how you are doing
c=IN IP4 138.85.27.10 t=0 0
m=audio 20000 RTP/AVP 0
At this point, Laura accepts the call and informs Bob that she will receive RTP packets on 138.85.27.10 UDP port 20000 (Figure 5-1).
If, when Laura and Bob are in the midst of the session, one of them wishes to modify the session, they just have to issue a new INVITE. This type of INVITE, called a re-INVITE, carries an updated session description.
It might consist of new parameters such as port numbers for the existing media, or it might add new media streams. For instance, Bob and Laura can add a video stream to their voice conversation via a re-INVITE.
Significantly, SIP only handles the invitation to the user and the user’s acceptance of the invitation. All of the session particulars are handled by the session description protocol used (SDP in this case). Thus, with a dif-ferent session description, SIP can invite users to any type of session.
Laura Bob
(1) INVITE (2) 180 Ringing
(3) 200 OK I will call Laura to see
how she is doing.
Figure 5-1 Laura issues a final response (200 OK) for the INVITE she received.
ACK ACK requests are used to acknowledge the reception of a final response to an INVITE. Thus, a client originating an INVITE request issues an ACK request when it receives a final response for the INVITE, providing a three-way handshake: INVITE-final response-ACK (Figure 5-2).
Why Does SIP Use a Three-Way Handshake? INVITE is the only method that uses a three-way handshake as opposed to a two-way hand-shake (METHOD-final response). Certain characteristics set the INVITE method apart from other methods. When a client issues a request other than INVITE, it expects a fast response from the server. However, the response from an INVITE request might take a long time. When Bob calls Laura, she may have to fish her SIP phone out of her coat pocket and press buttons, so the “200 OK” response that will come will be more or less delayed. Sending an ACK from the client to the server when the response is received lets the server know that the client is still there and that the session has been successfully established.
The three-way handshake also enables the implementation of forking proxies. When one of these forks a request, the client who issued the request will obtain several responses from different servers. Sending an ACK to every destination that has responded is essential to ensuring SIP operation over unreliable protocols such as UDP.
Laura Bob
(1) INVITE
(4) ACK (2) 180 Ringing
(3) 200 OK
Conversation Figure 5-2
Three-way handshake:
INVITE-200 OK-ACK.
Besides the speedy session setup and forking, INVITE’s three-way hand-shake also enables us to send an INVITE without a session description, which will be sent later in the ACK. This feature is useful, for example, when SIP interworks with other signalling protocols that use different mes-sage sequencing.
However, the historical motivation for having a three-way handshake can be found in the old SIPv1 draft, in the section about how to provide reli-able delivery of session invitation. The draft introduced the ACK method in order to avoid unsynchronized parties on session establishment, which might occur when a two-way handshake is used over an unreliable trans-port protocol such as UDP. Consider the following case where a two-way handshake is implemented.
Bob would send an INVITE to Laura and retransmit it until it received a final response from Laura. Until this final response is received, Bob can-not know whether Laura received the INVITE or it got lost in the network.
Bob waits for a while and because he gets no answer, he gives up and stops retransmitting the INVITE. Bob believes that no session has been established.
At roughly the same time, Laura accepts Bob’s call and sends back a “200 OK” response. If this response gets lost, Bob will never receive it, so, Bob still believes that no session has been established. Because Laura observes that Bob has stopped retransmitting the INVITE, she assumes that Bob has received her 200 OK. Therefore, Laura thinks that the session has been successfully established (Figure 5-3).
If a three-way handshake were in place for this scenario, Laura would not receive an ACK for her 200 OK response, given that Bob gave up some time ago. Thus, she would (correctly) think that the session was not estab-lished.
CANCEL CANCEL requests cancel pending transactions. If a SIP server has received an INVITE but not yet returned a final response, it will stop processing the INVITE upon receipt of a CANCEL. If, however, it has already returned a final response for the INVITE, the CANCEL request will have no effect on the transaction.
In Figure 5-4, Bob calls Laura and her SIP phone begins ringing, but nobody picks up for a while. Bob decides to hang up. He sends a CANCEL request for his previous INVITE. Upon reception of the CANCEL, Laura’s SIP phone stops ringing. The server sends back a 200 OK response for the CANCEL, indicating that it was processed successfully.
It is important to remark that after the server has responded to the CANCEL request, it responds to the previous INVITE as well. It sends a
“487 Transaction Cancelled” and the client finishes the INVITE three-way handshake by sending an ACK (INVITE-487 Transaction Cancelled-ACK).
Therefore, the INVITE three-way handshake is always performed, even when the transaction is cancelled.
CANCEL requests are useful when forking proxies (proxies that issue more than one INVITE upon reception of just one INVITE) are in the path.
When a forking proxy is performing a parallel search, it tries several loca-tions at once. For example, a forking proxy knows of three possible localoca-tions
Laura Bob
(4) 200 OK (5) 487 Transaction cancelled
(1) INVITE
(3) CANCEL
(6) ACK (2) 180 Ringing Figure 5-4
Bob cancels his INVITE.
where Bob might be reachable: SIP:Bob@131.160.1.112, SIP:Bob.Johnson@
company.com, and SIP:Bob@university.com. When this proxy receives an INVITE from Laura to Bob, it will try these three locations in parallel (at the same time). The forking proxy sends three INVITEs, one to each loca-tion. Bob, who is currently working at 131.160.1.112, answers the call. The forking proxy receives a 200 OK from SIP:Bob@131.160.1.112 and it for-wards this response to Laura’s UA. Because the session is already estab-lished between Laura and Bob, the forking proxy wants to stop the other searches initiated, so it sends two CANCELs, one to each location, to close out the searches (Figure 5-5).
Remember that a CANCEL request does not affect a transaction once a final response has been sent. Therefore, in our example, even if the forking proxy sends a CANCEL to SIP:Bob@131.160.1.112, the session between Bob and Laura would persist. CANCEL cannot terminate an ongoing trans-action. It is ignored by completed transactions.
(14) 487 Cancelled
Laura Bob
(1) INVITE
(4) ACK (2) 180 Ringing
(3) 200 OK
(6) 200 OK (5) BYE Conversation Figure 5-6
Laura sends a BYE when she hangs up.
BYE BYE requests are used to abandon sessions. In two-party sessions, abandonment by one of the parties implies that the session is terminated.
For instance, when Bob sends a BYE to Laura, their session is automati-cally terminated (Figure 5-6). In multicast scenarios, however, a BYE request from one of the participants just means that a particular partici-pant leaves the conference. The session itself is not affected. In fact, it’s common practice in large multicast sessions to not send a BYE when leav-ing the session.
REGISTER Users send REGISTER requests to inform a server (in this case, referred to as a registrar) about their current location. Bob can send a REGISTER to the registrar at company.com directing that all incoming requests for SIP:Bob.Johnson@company.com should be proxied, or redi-rected, to SIP:Bob@131.160.1.112 (Figure 5-7).
SIP servers are usually co-located with SIP registrars. A SIP registrar can send all information received in various REGISTER requests to a sin-gle location server, making it available to any SIP server trying to find a user.
REGISTER messages also contain the times when the registration per-tains. For instance, Bob can register his present location until four o’clock in the afternoon because he knows that’s when he will leave the office. A user can also be registered at several locations at the same time, indicating to the server that it should search for the user at all registered locations until he or she is reached.
OPTIONS OPTIONS requests query a server about its capabilities (Fig-ure 5-8), including which methods and which session description protocols it supports. One SIP server might answer to an OPTIONS request that it supports SDP as session description protocol and five methods: INVITE, ACK, CANCEL, BYE, and OPTIONS. Because the server does not support the REGISTER method, I can deduce that it is not a registrar. The OPTIONS method might not look useful now, but as new extensions add new methods to SIP, the OPTIONS method is a great way to discover which methods a certain server supports.
An OPTIONS method also returns data that specifies which encodings for message bodies the server understands. If a certain server understands, for instance, a certain compression scheme, the client will be able to send the session descriptions compressed and take the opportunity to save some bandwidth.