SIP signaling follows the server-client paradigm as used widely in the Internet by protocols like HTTP or SMTP. The following picture presents a typical exchange of requests and responses. Please note that it is only a typical case and doesn't include all possible cases.
If you unfamiliar with terms like SIP phone or softphone, learn about VoIP phones. Better open it in a new window.
Before understanding the methods, first you should understand the pictorial diagram. User 1 uses his softphone to reach the SIP phone of user2. Server1 and server2 help to setup the session on behalf of the users. This common arrangement of the proxies and the end-users is called "SIP Trapezoid" as depicted by the dotted line. The messages appear vertically in the order they appear i.e. the message on top (INVITE M1) comes first followed by others. The direction of arrows shows the sender and recipient of each message. Each message contains a 3-digit-number followed by a name and each one is labeled by 'M' and a serial number. The 3-digit-number is the numerical code of the associated message comprehended easily by machines. Human users use the name to identify the message.
Figure : SIP session example with SIP trapezoid
The transaction starts with user1 making an INVITE request for user2. But user1 doesn't know the exact location of user2 in the IP network. So it passes the request to server1. Server1 on behalf of user1 forwards an INVITE request for user2 to server2. It sends a TRYING response to user1 informing that it is trying to reach user2. The response could have been different but we will discuss the other types of responses later. If you are wondering how server1 knows that it has to forward the request to server2, just hold on for a moment. We will discuss that while going through the registration process of SIP.
Receiving INVITE M2 from server1, server2 works in a similar fashion as server1. It forwards an INVITE request to user2 (note: Here server2 knows the location of user2. If it didn't know the location, it would have forwarded it to another proxy server. So an INVITE request may travel through several proxies before reaching the recipient). After forwarding INVITE M4 server2 issues a TRYING response to server1.
The SIP phone, on receiving the INVITE request, starts ringing informing user2 that a call request has come. It sends a RINGING response back to server2 which reaches user1 through server1. So user1 gets a feedback that user2 has received the INVITE request.
User2 at this point has a choice to accept or decline the call. Let's assume that he decides to accept it. As soon as he accepts the call, a 200 OK response is sent by the phone to server2. Retracing the route of INVITE, it reaches user1. The softphone of user1 sends an ACK message to confirm the setup of the call. This 3-way-handshaking (INVITE+OK+ACK) is used for reliable call setup. Note that the ACK message is not using the proxies to reach user2 as by now user1 knows the exact location of user2.
Once the connection has been setup, media flows between the two endpoints. Media flow is controlled using protocols different from SIP e.g. RTP.
When one party in the session decides to disconnect, it (user2 in this case) sends a BYE message to the other party. The other party sends a 200 OK message to confirm the termination of the session.
Was that a bit long? Need a break? Go, get it! You deserve a break after going through such a long SIP session -:) When you get back, we will dive inside a SIP request message.