Session Establishment Flows

Referencing RFC3665, there are 11 basic session establishment flows that illustrate the diverse scenarios encountered in SIP communications, ranging from successful session establishments to various unsuccessful attempts due to no answers or busy signals. These flows, including "Successful Session Establishment" and "Session Establishment Through Two Proxies," provide a framework for understanding the best practices in SIP communication setups. Further exploration into call forwarding scenarios and their specifics will be addressed in dedicated chapters.

We'll delve deeper into the technological aspects now. Typically, SIP operates over UDP, but it's important for SIP devices to also support TCP. A SIP message is divided into two main components: 

A header, which acts as an envelope, detailing a request or the outcome of a request (known as a response) through various header fields. 

A possible payload or body, carrying information pertinent to the request or response. 

While the header is always in text format, the payload can be either text or binary. 

To illustrate, consider the breakdown of a standard SIP call. In this example, User A wishes to initiate a call to User B:

All these messages are explained here: 

1. User Agent A sends a SIP request "INVITE" to User Agent B to indicate User A's wish to talk to User B. This request contains the details of the voice streaming protocol. The Session Description Protocol (SDP) is used in the payload for this purpose. The SDP message contains a list of all media codecs supported by User A. (These codecs are using RTP for transport.) 
2. User Agent B reads the request and tells User Agent A it has been received. While the phone rings, User Agent B sends provisional messages (ringing) to User Agent A to notify the other end that the phone is ringing just so it doesn't time out and give up. 
3. Eventually User B decides to accept the call. At this point User Agent B sends an OK response to User Agent A. In the payload of the response, there's another SDP message. It contains a set of media codecs that are supported by both user agents. At this point both parties are officially in the call. All types of SIP requests are accepted using 200-type responses. 
4. User Agent A finally confirms with an ACK message. There are no retries and no response messages for this request type, even if the message is lost. ACK is only used in the case of an INVITE message.   
5. Both user agents are now connected using the method selected in the last SDP message. 
6. At the end of the communication session, one of the users hangs up. At this point this user's user agent sends a new request BYE. This message can be sent by any of the parties. 
7. The other user's user agent accepts the request and replies with an OK message. The call is disconnected.