 So, we were actually looking at the SIP reply actually last time and we have looked at that. So, request and response these two things actually technically was actually was covered. But when you actually the abstraction the way it is being defined defined in the SIP RFC, we do not define everything in one single go we define it in form of layers. So, the lowest layer which is being specified is how basically the syntax and encoding of all the request and responses that is the first and foremost thing. So, this is nothing but syntax and encoding of all kind of possible request and all kind of possible responses. So, there is a generic definition and this is can be done through a grammar and this grammar is known as BNF is something very similar to ASN, abstract syntax notation. This is a thing let me write down the proper spelling. So, this is a formal way of a specifying the syntax I will give an example of this we will specify in our own way and most likely that is BNF and once you have this specification at least you know how to form a request and how to form a response for every request. There can be multiple requests there can be multiple responses which are permitted. So, once this abstraction is clear so, at least you know how the message will be from this like how to write a letter there will be DRSR there will be address there will be date then you will write how are you whatever it is then you will write whatever you want to say after all preamble then you will say thank you goodbye your name it is a format it is a syntax you will be using English language or you will be using Urdu or Hindi that is kind of encoding how it will be depicted in text. You might write in Roman for example, to write in actually Roman script, but you are writing Hindi language that is possible ok. So, we do that actually once in a while so, all that is specification is given by this. So, once the letter is being written closed sealed what has to be done with that ok. So, next layer is talks about how it will be transported. So, next layer will be transport so, this is the lowest one so, next on top of it so, layers are like this. So, whatever functionality abstraction or whatever it is provided by it is need not be known by this guy. This guy just passes on the information and this takes care of it ok. Basically this is the way it is going to happen is whatever you are going to generate with this BNF grammar specification the message this will be passed using a transport ok. So, transport layer can be UDP can be TCP can be STTP or can be anything is a basically message being encapsulated and then being transported over to the other person. So, it defines that particular transport and similarly how the responses will be sent back. So, this can be any one of those that this is basically mechanism how the message will be transported. So, this how the message is formed and this is how the message is transferred from one entity to another entity that is a transport layer ok. So, I think I should not call it a lower layer because it is not running on top of it actually because whatever you create that is being transported. So, that becomes an entity for this these two are separate, but that is the way it has been written lowest in transport layer in RFC. Then there is a third layer they do not write bottom most upper layer kind of thing the structure is not used the way it is using a networking. Third is what is known as transaction layer what does it mean? For any kind of signalling I will any signalling will consist of multiple transactions ok maybe I will send you an invite the response will come for the first transaction over based on that I will decide on some some other transaction which need to be done. So, there is time every time there is one transaction which will happen fully and it is possible I do a transaction with you and you give responses that is a transaction running he is now on my behalf is transacting with somebody else ok. So, a client will be transacting with CIP proxy, CIP proxy will be transacting with another CIP proxy ok and each transaction is separate each transaction is independent, but they are initiated by earlier transaction. What is the difference between transaction and message? Transaction there is a finite state machine the message once you transfer see for example how you will ensure reliability I am transporting over UDP UDP has no reliability you send a message you create the lowest layer thing the message through encoding and whatever it is message format you transcend the message over UDP using that transport you have done the transaction now you are waiting for the response message lost what you should do. So there has to be at some transaction machine a finite state machine which has to be implemented which will keep track of the transaction till the transaction is complete or abundant. Stateful proxies if they are implemented between client I can have a transaction with this it is not transparently moved out ok this transaction is only between these this will result in a separate transaction with another proxy. The transaction is point to point messaging is end to end. Not necessary not necessary transaction is point to point transaction is point to point yes it is point to point unless you have a state less proxy in between because any request which you will send through the transport will be transparently transmitted to the next guy it does not maintain any states if it is a transaction then this will maintain the state of that within transaction whenever you are sending messages you are changing your state when you are getting back the message your responses for the transaction you are changing the state. In the stateful proxies there are two transactions server transaction client transaction for one side. For a stateful there is no client and server whatever comes it is simply just transports whatever is coming back simply transferring here is a state less it cannot maintain a state. Stateful there is only one transaction it can result into another transaction which is coming here. There is a server here and there is a client here there is a client here there is a server here. There is one client transaction other one is server transaction client transaction server transaction are actually finite state machines it is not one transaction they with this actually the term which is used here. So transaction layer is what is the third layer and formally transaction is defined as a request which is sent by client transaction transaction is a instance which gets created in the client. It is not a transaction client transaction is an entity running in the client. Similarly there is a server transaction so request is going from client transaction which will cause a state to be changed. So if loss happens it has to be retransmitted after certain time out for example this is going to be taken so reliability is the responsibility of this irrespective of what kind of transport is used. Transport can be anything remember if it is TCP most likely it is reliable UDP it is not reliable remember when I took the Bob and that Alice example it was UDP based transaction which was there in that request response message could have been lost in UDP what we will do in that case. So client transaction will remember that the something was the response has not come within certain time I have to again retransmit the transaction request. So it is a request sent by the client transaction along with all the responses which you receive not one response. You send a client transaction sends a request then the all responses which comes will be included and this whole thing together will form a transaction actually and this is sent using transport layer is a different kind of instructions not exactly the same way. So it takes your reliability but when you implement a client transaction there is a finite state machine which is going to be maintained for that. So the remember if for data link layer we had a finite state machine on two sides which can take care of the reliability of the message transfer. In case a message lost you will time out and you will again retransmit message sequencing can be taken care of. When it sends any server suppose if the schedule process is there it is acting whether the client server is sending the request can make the request or send to other. It will it will it is going to have a transaction user setting inside. So when it is a returning the response you will receive the response how it might be it is a same response of this particular transaction you are saying this in sense when I send a request forwarded process forwarded request and we will receive the response. There is a dialogue and there is a corresponding a remember sequence number for the command. So dialogue will give the basically complete dialogue which is happening for that corresponding that call setup and then command sequence tell this transaction corresponds to which command. For each command there will be one transaction which will be created. Transaction user can issue multiple commands. So the layer on top of it is transaction user. So this will handle all application retransmissions matching of responses to request and application layer timeouts that is what I was telling this will take care of I think this is important thing because otherwise there is no reliability built in because application can actually use UDP. Re-transmission responsibility. Is by this transaction layer. Transaction layer is proxy everywhere. Transaction is between two end points. See it is not between Alice and Bob is between Alice and proxy whatever was that at Atlanta proxy there is a transaction which is going to run between them similarly between this proxy and another proxy there is another transaction between this and Bob there is another transaction which is running. Who will realize they will have to re-transmit Alice will realize for retransmission here this will realize for retransmission of message here this will realize for this section. What is happening is in between this there is something called transaction user TU. So when this guy actually sends a message this will create a transaction before corresponding to. So these are transaction user is a layer which is on top of transaction layer except state full proxy state less proxy all other entities will have a transaction user. So this transaction user has to talk to this transaction user. So for that it will create a transaction layer a transaction will be created. So transaction instance will get created for invite and this will go here and there is going to be what we got this is a client transaction a server transaction will get created which will then send a for example I am still trying 100 and then this will be giving a message to transaction user. Now this server transaction will remain as it is this will not still be dead its transaction is not over transaction user will now know that I am a proxy I have to now forward it to appropriately. So transaction user now will try to find out which is other proxy to whom I need to send the message further. My question is it when the proxy there retransmission is message of done by Alice whether this retransmission message will be further polluted by proxy. No retransmission is only for the reliability between these points see message can be lost here UDP is lost for example this guy never received anything what you will do this will still keep on waiting I have send an invite I will get a response that can happen it is a UDP transmission. See if I do a very simple thing I want UDP I am transmitting transaction user got created you want to make a call it creates a client transaction it sends a invite and there is no client transaction technically you are saying I am directly going to use transport this layer is not there. You form an invite you send it it went through UDP it was lost this guy even is not aware that there was an invite being sent to me then what you will do UDP packets are encrypted on IP packets IP packets can be lost because of congestion then she will keep on waiting for all the time for getting even 100 ok kind of response so there has to be time out you have to again try it but should it be done by transaction user is intention is I want to make a call that is it invite is sent so let this be responsibility of the client transaction for retransmission why proxy will maintain this will maintain a timer now client transaction will maintain a timer there is a time I said there is a finite state machine with each client transaction and each server transaction so when this guy want to send invite it will create a client transaction which will have a finite state machine along with all timers and everything which in turn will send invite request through a transport mechanism encoded as per this Lewis layer and it will maintain a state now it will wait for some time when timer expires it will assume it has not been done it will again send the thing remember command sequence will tell if this has been received correctly here time out has happened even if a duplicate goes it knows that it is a duplicate I have already received this command sequence there is a serial number being assigned and the reasons why serial number has been assigned and this is a traditional number it keeps on incrementing every time you put next command for every command you are going to create a separate client transaction it is possible that you can do even a cancel for example cancel is a special command when you give a cancel it will create another client transaction not the same client transaction which is supposed to be cancelled and this new client transaction will send the cancel command and it will refer to the earlier transaction earlier command which in turn will go here and then this there will be a server transaction which will now clear all the state for corresponding to this will send the appropriate response if it requires or the cancel will send a response back in turn it will tell the transaction user which in turn will clear up the client transaction so cancel is also tricky in this case it is not a state forward it is not control all del in fact no where it is control all del control all del itself is a complicated process if you put it in the shell or a control see if you do in a telnet transaction a very similar things actually almost will happen everywhere sometimes you can abort tcp connections server side time out if you do not get a packet with or a message within certain time see most of the protocols by design use something called soft state they do not have hard state so they remain alive they are active if they keep on getting something what do you call heartbeat messages from the other end the moment that heartbeat pass message does not come for certain time it will assume the other guy is dead or he has forgotten or something has happened you simply reset everything all data structure on the server side client side usually will keep on will time out if the response does not come again try it will do it multiple time it does not happen server must have been dead it aborts and tell the higher layer something has happened same procedure will be followed here but it is done in a different way the naming is different that is the only thing and it is on an application layer because your transport is directly UDP this is only the encoding of the message in the application so this message is technically being routed over this transport but this message is generated by transactions and client transactions and server transactions are created by transaction users only in a state less proxies this is not the transaction user is not there so correspondingly there is no server transaction and there is no correspondingly client transaction so whatever comes you simply change the header what as per the policy and transfer it you do not even worry about it what has happened what has not happened it is the end points which will worry if it is lost or if I have done a wrong translation reverse whatever come you again do the translation pass it back so they actually take handle what we call application take care of application layer retransmission I think I will write it then matching of responses each request will have a separate client transaction being created so when the responses come back they are transferred to appropriate client responses and of course what we call application layer timeouts so any what we call u s e u s e was user agent client and whatever it will do it will be through a series of transactions so u s e is as well as so this is always will be working through series of transactions so now it is important that u s e and state full proxies have transaction layer in fact I should write transaction because TLV use for transport layer most state less proxy no transaction layer and of course all the time this client transaction and server transaction they are always represented by finite state machine finite state machine is where finite states are there and depending on whatever is the input the state will change and there will be corresponding output which will be coming out FSM is that FSM stands for finite state machine and of course the fourth layer as I mentioned is always going to be transaction user is known as T u transaction user is a user which is technically a software running there which creates transaction machines client transactions and server transactions and except all except the state less proxy all SIP entities are transaction users there is no separate all entities itself are transaction users so proxy is a transaction user it is not nothing inside the proxy proxy itself is transaction user user agent client is itself is a transaction user because it creates transactions proxy also does the same thing register also does the same thing so except state less proxies everything else is every other entity is a transaction user so the way it is going to be done is what you will do is it will create a client transaction and for this it will create client transaction instance actually there can be multiple client transaction instance as he has mentioned as a case you want to make multiple calls or multiple invites to be sent you will create for every kind of thing a separate instance I already gave an example you create an invite you create a client transaction instance you want to cancel it you will create another client transaction instance in that case which will then be referring back to this because is a cancel it is a separate transaction but it is going to refer to an earlier transaction so there will be a server transaction correspondingly which will go and do all cancellation thing on the server side and once the confirmation come from that side it will do the cancellation on the client side. So here cancellation is slightly different so you create a transaction which is a invite for example on the server side suddenly you want to cancel it you will do not cancel it directly you will start a separate transaction which goes creates a cancel server transaction it will refer reference will be given to this this goes from that reference this has to be cancelled this will be cleared off the response will come back once the response comes back you will clear this thing you will tell to you and this will clear off this one whether two separate transaction instances which gets created and for creating a transaction instance you require a request you require a destination IP you require a port you require a transport UDP TCP or HTTP whatever it is and once you give this thing based on this is where the request has to be sent this will always lead to creation of client instance client transaction instance and transaction instance will be of the type request and the message will be transported to an entity on this side where server will keep on waiting the moment a request come it will check it will find out there is no server instance for this it will create a server instance it is like forking for example whenever you are doing telnet to a server or SSH to a server there is only one server running there first time the request goes it will figure out there is no instance running so it will actually do a fork fork is creating a copy of yourself and then it that will be made responsible to response to this. So, you will create in client server transaction instance this will be done exactly same way the way it is done in network you will create an instance on the server side also. Cancel thing I have already told and of course this is basically what are the layers which will be used for communication purpose. Now most of this elements we define something called core core is the functionality of course this is only an abstraction this does not tell that software has to be designed only in this way it depends whatever fail you way you feel comfortable you can design your software, but this is an abstraction given in RFC. So, you assume that if somebody else design software in whatever way, but he is following this abstraction you should be able to communicate with him only that thing has to be ensured by you you do not know how the other person other server or other SIP entity have been implemented. So, it you should have to ensure if you are making a client it should be able to work with anybody is proxy which is SIP compliant. If you are designing proxy it should be able to talk with any other proxy built by anybody else or any client register it should be able to talk with any kind of proxy, but internally how you implement it is your it is I think implement this issue. So, that IETF should not govern because that innovation we I think we should live it to the invent I leave it to the inventors you can do lot of innovation by implementing the software itself. So, in fact every entity every SIP element we defined course actually in this case core is the implementation core is technically the implementation and they are they technically represents T U client transaction instance creation mechanism client transaction instance everything put together in software that is core and this will be existing for every entity except the state less proxy. So, that is core and core will depend on whether it is a proxy core or whether it is a user client core or whether it is a user server user US user agent server actually core or it can be register core. So, you can define or you can redirecting server redirection server which is there it can be core for that and remember for every transaction transaction will get completed when you will get a final response it cannot be completed before you get a final response. So, transaction client transaction and server transaction this transaction will get completed then this entity server entity can go away if it requires and this will happen only when the final transaction has happened a final response has been received for a request. So, now if you carefully note when the LIS actually has sent a request there was a invite which was sent final transaction happens final response comes only when the final response is from all others have reached here then only you get an ok an ok is kind of a final response. So, in fact, all response codes which starts with 2 x x 3 x x 4 x x 5 x x 6 x x they are all final responses 1 x x is not a final response it is a kind of a temporary response you call it provisional and it will not terminate that transaction. So, your client transaction have to be maintained if you are getting these provisional responses you cannot terminate that you cannot closer 1 x x series will not close the client transaction only anything related to this will close. Now, these request and responses now can actually can keep on moving from one person to another person and so on. So, there are terms which actually things which can happen which we define. So, one thing which can happen is known as loop. So, this is a shift phone talk to a proxy figures out still transaction is not over this request is sent to another proxy this proxy analyze the invite or whatever request which was sent and this request comes back to this guy and this request again goes back in this direction that is very important then it is known as a loop which is going to happen. So, this is loop something also another interesting thing which can happen is you send a request to a proxy this can send to another proxy this in turn sends it back, but this new request which has come back through some whatever way there can be other proxies also is not going to go in the same way it goes to somebody else. So, this is different than loop actually this can happen because of redirection this can happen because of redirection because you are probably registered with this domain, but then you have moved to some other place. So, you told this guy you tell this person where I am. So, it tells this person that I am here. So, it actually passes all the request to this guy this guy then looks because now that remember that when I do redirection. So, redirection means the source the original destination is moved to converted map to another new destination. So, Bob was at block c dot com and then he has moved to say some x y z at Atlanta dot com. So, that is a redirection. So, Atlanta dot com is back here. So, request comes here for x y z or may be some other guy whom this guy cannot go directly it comes back here which in turn sends a response request here. This kind of thing is known as spiral in this case. This is a legitimate. This is a legitimate is a legitimate loop will be endless or I mean it will come out. It depends loop usually is not desirable, but yes it is possible. Loop is there and loop is estimate yes it is possible, but loops need to be resolved in that case. The probably one example is Bob at block c dot com. His job actually got moved. So, still retained that account he did a redirection. He joined somewhere as say Johnny at Atlanta dot com. So, the call was deducted here and then by the time he also actually has moved this entry is still retained and now is some. So, loop is still valid thing, but this signaling is happening in the loop. So, ideally speaking he should have actually the error here is that he should have now told this guy that whatever is Bob at the block c dot com is same as jojo at block c dot com. So, redirection can happen here itself directly. So, earlier this loop is nothing, but what we call a data which is not required, a configuration which is bad actually. Of course, it is not going to impact the call can still be rooted, but it is not desirable. Mostly it will happen because of redirection because for whatever reasons. This redirection is probably you are moving and then you are even returning your earlier account and redirecting to somebody else like dot forward in email. But dot forward in email for example, from IITK you say it goes to whatever is x y z at gmail.com. There you do a dot forward to go to somebody else here. It come to IITK dot ac dot roman, but different name, but server is still the same, but name is already changed and that dot forward again send it to gmail.com with a different name ID, different mail ID and of course, if you create a loop same mail error it will keep on looping indefinitely. Now, that is invalid thing it will not terminate. Invalid loops are not allowed and how that valid loops will be terminated? Yes, there is a maximum forward limit and that will be terminated it should not happen keep on happening indefinitely. So, loops usually which are invalid loops are taken care of by maximum forward house which are there. And then of course, this is You do not handle it simple. So, if you see see I am telling here it is a loop only way this can be said is if as of now because there is nothing has been received from the end point. The call ID and that the tag of the sender these two pairs actually if you combine and those are registered here you just keep check if there is any other request which is coming a while it is this particular transaction is pending which corresponds to the same particular call ID and same particular this thing and same particular what we call sequence command sequence if that thing comes yet probably is a loop that time you have to decide what has happened then you check this this this then you actually can do that these two can do the pairs can do the check and then user need not even offer you can directly say bob.blogsy.com should be now directly forward to this loop is removed that intelligence can be built in this system. Now, that is left to the programmer RFC does not talk about it. So, if you are smart enough actually you can implement this and then make your proxy better or you can at least inform the user we found a loop for you would you like to correct it and this is a way to correct it at least. Spirals also can exist, but I think spirals are also not desirable if this could have been directly from here it would have been better. Now, this guy can do this job and short circuit directly from here. So, you will actually reduce a lot of load on these machines final loops and spirals. They have to do it, but if these machines are entity they can figure out a call lag what not call lag that is dialogue, but dialogue is not there unless you get the response back. So, only the invite will go in this way, but the response will come pretty fast basically they will always say they will not put what we call that thing via field. So, whenever you are doing redirection do not put a via add entry into that, but the problem is if this is going to send to another proxy then this will not know it is going to go back to this guy and it puts a via add or then it becomes a problem. Now, those complications are there and we have to live with those and these kind of things I think has to be identified by processing see because this will not be cleared remember. So, whenever a new call new invite comes whatever is the current transactions which are pending which are not clear compare with all of them compare with all of them and based on that you decide if something is being duplicated you identify loops or something and then at least talk with those proxy servers directly and resolve the met. So, that intelligence has to be part of the proxy design. So, it is not a trivial thing. So, this is also not an obvious stuff. Now, I talked about that back to back user agent I talked about a state less proxy state full proxy I can now diagramtically actually represent them once I have come with this transaction stuff. So, I talked about this thing B2B user agent. So, this is a special kind of proxying thing, but actually it is not a proxy. Proxy is only for signaling back to back user agent also takes care of media. So, there is a proxy there is a proxy this is a B2B user agent. So, media is going to be transacted on this signaling through this particular path. So, there is one user agent there is another user agent client user agent server media and signaling both will be in transacted here and this can make and the ship trapezoid that is a back to back user agent. If it would have been the proxy the media is always transacted directly between these certain media gateways this can be built it can be of this kind signaling in data signaling in data both or media you call it this will not be called a proxy this is not a proxy this is a back to back user agent. How can you differentiate? Proxy is only for signaling part there is no role for media media is transacted directly between peers, but this is like another peer. So, this guy cannot see this and this guy cannot see this they both have to go through this. So, signaling as well as media this kind of a media gateway if you want to tap the call along with all signaling information here this is the best approach back to back user client is the best approach in that case. So, do not allow the call to be set up between these two entities use between. So, tapping usually will require this because I am now not using mega co here for controlling this particular entity media gateway I am using ship only. So, it is you will actually see your user like is this, but actually it is not this. So, similarly this guy will feel as if this guy is here, but actually he is not and they just back to back connected it splice together in software. But whenever he is given as a address of an IP as a back response we do not know. No, this guy will do the signaling here this will still keep in pending. This B2B user agent will ask this client to actually not talk to this guy with all the information given by him and it will behave as if he is this guy. He is approaching the request to go through this part, but it is not a normal feature. It is not normally it will not be done normally it will not be done, but this kind of specialized entities will also exist. So, I think call a stateful proxies and transaction a stateful proxies also need to be explained. Sir, how is the difference between poking? Poking will also be normal response though. Can we get the best response? We can use the poking also you know poking in this part. Poking is when the proxy on the receiver side gets a message it now signals to many entities not one entity which are registered for the same user. Is a parallel thing and the responses will come all of from all of them and it will intelligently will figure out as per the policy that only one of the message have to be passed back. So, when we do the parallel poking and when we use a sequential poking? Parallel poking for example, if you have set up as a feature with your registrar you want that all three of my phone should ring when a call should come and I can pick up from any one of those. You can say first of all try at my home phone give four rings if I do not pick up then my office phone should ring four rings should be there if again it is not picked up then my mobile should ring that is a serial. Yes you can that is your thing you have to do the everything has to be with registered with the registrar and this will inform get everything from registrar and do as per that. So, policy of polling is again left to the implementer and users RFC does not define that. In fact, there are many set of RFCs other RFCs talk about this thing. So, next is the message format. This I have already mentioned, but I am just formally writing that they should not take much time. So, genetic message will be always look like this I am now writing the grammar of that actually it will always consist of start line, optional headers which will be there CRLF carriage return line feed a gap and then you will have the message body which is optional. I think optional is with this and this is a compulsory thing flexible and start line can be either request line or a status line and even when message body is not there this is an optional thing, but CRLF is compulsory start line is compulsory. This is a variable field actually message header they have to be there message body is optional. So, because I know there will be one line this is a variable number of lines the end of the header will be identified by CRLF which is again compulsory thing you cannot identify the end of this number of header fields unless this is there. So, that is why this always has to be present this is an optional thing that is the BNF grammar actually which I am writing now and request line will look now these are two options request line or response line. So, request line will be a method that is a space I have already mentioned this thing earlier, but I am now writing formally then there will be request URI there will be a space single space character and then of course, sieve version line feed sieve version and sorry CRLF you call it carriage return and line feed you will come back to the first thing. So, that is the request line which will be there then this length of the message and all that will not be there after message body the length of the message. Length of the message will be part of the message header it is part of the message header content length that will define how many bytes will be there in the message body. So, if it is 0 there is no message body. So, the methods which are permitted so far I have not talked about all methods. So, all the methods which are there are these which can go in any SIP request. So, one is a register invite we all know what is invite you also know what is act it is not a response remember it is a method in the request in the request line status line is where the ok will come. So, act is not an response act is a request then there is a cancel by options this is for registering the contact information this is used for setting up of your sessions this is for terminating the sessions this is for querying the servers for their capabilities. So, this is S by RFC 3261 for other RFCs also actually specify other methods, but these are the ones which are required by every implementation other things are nothing, but SIP extensions actually the other methods also very variable length variable number of headers it is not one line there can be multiple lines see that is why CRLF is there. So, you identify you know first line is this line you know the CRLF all lines in between them is message header. So, it can be one line it can be 2 it can be 10 it can be 20 nobody stops one of the field always will be content length which will define what is the message body size ok. There is no CRC in this case. There is no CRC that is taken care of by UDP or IP packet or data link control. So, usually if there is going to be noise DLC will take care of that and will do the retransmission. And this is for setting of sessions. Session management if you do reinvite that is also again invite command only, but you with a different parameters. Modification of parameters also and termination everything here this by is for management or you change the parameters of the media ok. So, I close here and then most more of it actually will discuss tomorrow morning.