LESSON 1: SIP: BASIC CALL FLOW (PEER-TO-PEER)

Alert: If you HATE long posts, stop reading and click here.

The Session Initiation Protocol, a VoIP protocol, used for originating and termination of media sessions like voice, video, IM, presence etc. Before we enter into the more technical details of SIP, let's refresh our basic telecom VoIP skills.

I'd like to insist here that SIP is a signalling protocol, its NOT a media protocol -- which means it is a set of rules use to control the signaling part of a media session. It doesn't have any control on media. So let's not wait to start the basic call flow of SIP.

Key terms:

It is important to familiarize with these terms in order to understand basic SIP call flow. Here are few of them:

Call flow: It's a flow diagram of SIP messages -- shows an ideal way how a media session carried over two endpoints. Its a must know thing and will be useful for your troubleshooting as well.

Endpoint: Any device which is used to originate and terminate a media session. For example SIP phones, SIP clients running on PCs, webRTC running in browsers etc. In terms of SIP, we formally called this endpoint as User Agent. It has two modes:

1. UAC - User Agent Client
2. UAS - User Agent Server

User Agent Client: [UAC] who requests something in a SIP session.

User Agent Server: [UAS] who responds after serving the request from UAC

For example, in a school, students apply a leave request and teachers may approve or may not. Here in SIP, students are UA Clients whereas Teachers are UA Servers. It does not mean Students are always UA-Clients and Teachers are UA-Servers. Depending upon the situation, the user-agent can change the mode from UA-Client to UA-Server.

Note: It is not necessary that you will get approval from teachers for every leave request. At times there will be rejections. The same way in SIP also, you see not only success responses (200 OK), but also failure/error responses (487, 500 error etc).

Request: a message from UAC to UAS

Response: a message from UAS to UAC

Basic SIP Call flow (Peer to Peer)

Explanation:

Lets assume two things here before we go to the explanation.

User-A = UA-A (User Agent-A)

User-B = UA-B (User Agent-B)

• As per the diagram, the UA-A is calling UA-B.
• INVITE is the request from UA-A to UA-B -- which means UA-A initiated a call and inviting UA-B to have a communication session. This INVITE message carries all the related information about UA-A such as information of media-capabilities, which port UA-A can listen etc.
• UA-B responds “100 Trying” message to UA-A. This message states about the progress of session (call) to UA-A
• UA-B also respond with 180 Ringing message to UA-A. This message conveys the ringing status of UA-B to UA-A
• After 180 Ringing, UA-B sends 200 OK to UA-A. This 200 OK message carries all the media-capabilities of UA-B
• Once both the parties know each others capabilities, then they are ready to participate in the communication session. This will be confirmed by UA-A sending an ACK request to UA-B
• Once UA-B receives the ACK request, then the media starts flowing between the UA-A and UA-B
• Whenever any party hangs up to terminate the call, this will be conveyed as BYE request in terms of SIP. So, in our example, we see clearly that BYE request is initiated by UA-A to UA-B.
• This BYE request has to be acknowledged by the other party i.e. UA-B
• This concludes one SIP session (call) between two User Agents.

Note: This call flow here explained when everything is working fine as expected. We can say, its a GOOD CALL between two SIP Endpoints.

Hope this helps!

Thanks,

Raj