 As a successor to the diameter protocol, session initiation protocol is the next and the final standard which has so far been incorporated by the NGN. In this module we are going to look at the protocol, its inherent operation features, how it implements its functionality through messages, and how it can have some kind of abstraction implemented through addressing. So session initiation protocol is actually something that works between the application layer and the transport layer. If you recall, we had two layers in the ISO OSI reference model. We had the presentation layer and the session layer in the ISO OSI model. But TCP IP actually simply reduced the seven layers into five layers. So SIP actually is something that is at the application layer, but it facilitates data, multimedia traffic to be transmitted in real time from the client to the server. Therefore, we can say that SIP is something that is an effort to go back to the seven layers when it started from ISO OSI then back to five layers of TCP IP then once again SIP is there. So it is essentially a protocol which is required for signaling because the client and server or two clients cannot perform signaling with the traditional TCP IP protocol suite. It has been adopted by ITF as a replacement for signaling standard number seven, both for the ISTN users and for the telephony users. ISTN was a very good standard as compared to telephony because it offered some additional services like voice, data, and similar other control services. But essentially, signaling standard seven was adopted for telephony in the landline phones and in the mobile telephony. Now that SIP replaces it, it has to incorporate the same level of reliability and completeness which was the hallmark of SS7. So SIP essentially manages the multimedia connections. It means that it helps the multimedia connections to be established to be maintained and to be terminated between two parties as a unicast or multicast or even broadcasting. So it is now incorporated in IP multimedia subsystem as part of the overall NGN architecture. So it is implemented in the TCP IP stack through the support of TCP, the streaming control transport protocol or the UDP. Since SIP has to be very flexible, so it supports mapping of names from one format to the other as well as for redirection once a certain called party has changed its location. So its updated location has to be shared with the calling party. So this kind of redirection is a requirement which SIP has to support. So the beauty about SIP is that not only it can use the underlying protocols at the transport layer, it can also be integrated as a component with the application layer protocols themselves. All those SIP is an application layer protocol in its own cell. For instance, it can be connected as a component along with the HTTP, the real-time streaming protocol and the session description protocol. SIP actually uses a real-time protocol for the transmission of traffic between the calling and called parties, multi-conference situation, etc. So we see that this RTP can be used between two parties as in voice over IP. Then it can be implemented for a multi-party conference scenario. Then it can also be used for multicasting in IPTV where a particular video podcast is shared between multiple users who have subscribed to that particular service. SIP is based on the client-server architecture which is quite similar to how HTTP works. Here again the request is generated by a client which is a logical entity on the sender side. Then it is sent to the receiving entity which is more like a server. So we have a client-server interaction. It is different from a HTTP in the sense that we have a client that is a client forever and a server that's a server forever. Here it is actually a little different. Any request being initiated is done through a client. So in a typical voice over IP two-party situation, the one who initiates as a calling party is a client and the one who receives is more like a server. So it means that the client and server context here is going to be a little tricky and different. So the server actually takes the requests and processes them and initiates a response. So any single entity, any user equipment or a particular user for that matter can be a client as well as a server. All the functionality of SIP is implemented through the messaging. This messaging is so intelligently designed to keep it very flexible. So first of all the most important thing in the SIP messaging is the caller ID, the call ID. The call ID is essentially the first identifier that is assigned by the calling party or the creator of this particular request and it remains intact and unchanged all along the call session and it is used as a reference by all the participants. So it means that every SIP message is going to contain this call ID as a reference to a particular calling party called party pair. So there are typically six messages, although there are variants to these messages as well, but primarily there is an invite message that is used by the caller to initiate a session. Then there's an acknowledgement, it is an acknowledgement that the caller actually has received the answer to a particular request. Then there is buy which terminates a connection, cancel is actually if a session is already on, it has to be disrupted before actually call transfer can take call establishment can take place. It is cancel. Now there's a very fine difference between buy and cancel. Cancel is more abrupt whereas buy is more graceful way of closing a particular session. Then there is a message known as register. Here the user agent or the user equipment registers its current location that is identified through its IP address or the uniform resource identifier which is more like a URL like structure to which the user actually can associate to. So it means when a user registers itself through an IP address or a URI it means any response would be sent or associated to this particular address. Then there is an option message as well where the caller actually tries to understand the features or the capabilities that it is entitled to and the calling party has a certain feature. So it means this options actually is something which is used by the parties calling or called to understand what are their capabilities and how those capabilities can be initiated. As we said in the beginning that SIP has to be flexible. So the flexibility is achieved through the identification which is based on more generalized form of representation as in web like email address or like a domain name. So you see that we have a URI scheme which is very generalized form like HTTP www.something.com or .whatever. So each element in SIP is actually identified as a logical entity. So it means that a physical device like a user equipment can have a logical ID so it would be referred to on the basis of that logical ID. So what we can conclude from here is that SIP architecture or this whole SIP framework that works along with so many other protocols that we've already mentioned it is more like an overlay. Overlay means it's a logical mapping on a physical network. Now let's look at the typical forms although these are not the only forms of URIs. Let's look at these examples again this illustration is from the handbook on next generation networks by Tony Genewski. So we see here we have different forms of SIP identifiers like we have a user 123 in the first example it has its own authentication password inline at the rate the domain with the port number as tetra 6. Then the other one is we have the SIP user 123 at a particular domain the third one is on the basis of IP address instead of a domain name. The fourth one is a web address or a typical URL or URI representation of a certain server and the last one is again the identifier which does not have any user but it has its own mailbox like 123 up to 9 at example.com is nothing but mailbox where a particular user account is created. So it means that these URIs are some examples of how SIP can manage addressing and naming.