 So, we will actually go ahead from where we left yesterday evening. I had actually given you at that time six possible methods which have been defined in RSE 3261 which actually can be used. Out of these two actually can be sent without creation of any session without basically technically creating any dialogue. So, one of them is option other one is invite. So, this I have not told I am telling it for first time. Invite we are already aware of. So, invite can cancel are technically used for setting of the session buys for terminating register is for registering and options is for querying the other entity what are the capabilities with that server actually. So, the request URI which is formed this is universal resource identifier. So, far I have only told about SIP for example, Atlanta dot com kind of thing. So, I have only talked about so far this thing, but as far as RFC is concerned when you make an implementation you need not only use this you can actually us SIP you can us SIP even other kind of URI standards can be followed and you can even implement those URIs. URIs also can be used in the system that is permitted RFC as per that does not say anything specifically. Only the problem is if you implement some other kind of URI scheme then it is the problem of the SIP entity. It has to figure out what has to be done with that whether it has to be mapped on to another SIP URI or it has to be mapped to a non SIP URI another one, but that will be headache of the entity. As a SIP we will not bother, but we require so this is what we call the scheme. So, SIP and SIPS are two schemes you can even use other schemes URI structure has to be there has to be a domain name. From domain name you will find out where the request actually has to go. So, that is the only important thing. So, domain name is important, but scheme actually can change. So, in fact for telephony there has been already a scheme which was built. So, which can be used alternately this is as per RFC 2806 scheme is known as TEL. So, you might have actually seen this thing at lot of places is a telephony thing or maybe whatever is a domain name kind of concept which can be there. So, TEL URI is also there. So, this also can be used this is one example there are many others which people have built over the time, but the translation from this non-SIP URI to SIP URI or non-SIP to non-SIP is a responsibility of the entity which is implementing the protocol, but you can use even non-SIP URI that is one important thing. Usually because when I am been telling people will actually conceive an idea a notion that always SIP URI has to be used no it is not needed you can use something else also. So, now coming to the status line because last time it was the request thing which was actually talked about. So, either there was a request line or oblige status line. So, request line is structure I have defined last time. So, status line so now mostly it is I am just discussing is about the rules which have to be followed. So, status line typically will be written as this should be equal to. So, this should contain a SIP version a single space character status code and a single space character and then of course reason phrase and in the end you have to have CRLF carriage return line feed character which has to be present. So, that is a BNF definition for the status line. So, request line I have already told reason phrase PHA will not come. So, this is basically human readable entity this will not be interpreted by the machine this will be interpreted by the machine this you are going to write. So, that some entity might be actually using a older version of RFC or SIP V1. So, in that case you will behave accordingly or you will reject if it is not as per your this thing. So, you have to specify when SIP V3 for example will come. So, V2 and V3 machines will coexist. So, depending on what kind of response is coming or what kind of request is coming you have to behave in that way. So, usually when you are going to implement a machine or implement a software you will ensure that you will implementation can handle both kind of requests. So, you do not have to implement only one, but you have to implement both kind of RFCs. So, V2 as well as V1 usually that is commercial entities will do that. Open SIP I think does provide both the options if you are going to use open SIP library. So, in fact the complete implementation you can find out as open SIP dot org. So, this is where you can get the library and then this has the complete implementation of this. So, tomorrow if you want to actually build up any application you can use the code from here or you can contribute back. Now, status code here is 3 digit code this I have already mentioned earlier and only the first digit will specify that 3 digits this will specify the classification. So, 101 or 1002, 199 series will correspond to what we call a provisional response code and you can also write it as 1 x x x acceptance going from 00 to 99. Specification does not talk about what will be for 00 will be used what will be for 01, 02 something, but this is going to be provisional, but depending on usage they essentially become norm. So, this is there in other RFC not in this one. So, this typically for example is provisional means that request is received and we are continuing to process the request. I think this I have mentioned earlier sometime back also. Similarly, you will have 2 x x category this corresponds to success. So, action has been or method has been successfully received or action has been successfully received it is understood and it is accepted that is what it means actually. So, 200 is ok for example, 00. There can be other variant also, but most of them will signify it is a success. Then you will have 3 x x code which can come this is usually for redirection. So, this says further action need to be taken in order to complete the request that is what the meaning is. 4 x x is client error client is the one who has sent the request response is sent by server. So, something which has come from the client is malformed there is an error actually in that. So, I am not able to parse and understand what was the request that is the meaning of this 4 x x. So, technically this request will contain either bad syntax or cannot be fulfilled at this server that is what it means. See for example, you are sending a message to register and you send a invite to register. Registrar would not understand it can only understand register request and the response will be success when the registration happens. Now, that is the only thing which can be done nothing else, but so in that case will say it is I cannot fulfill this request. So, whatever you are sending me is invalid thing. So, that is what the 4 x x is reserved for then you will have. Sir in the Alice Bob example, sir 486 and 488 were sent from the server side that is from the Bob side. So, Bob should be the server then sent. What was that 488 for? 486 was sir busy and 488 was not accepted. So, it is actually assuming the client is in error because I am busy he should be aware of that may be that is it is not the server error. Server can still fulfill the request, but as of now I am not possible because it is coming at the wrong time most likely that is the meaning. So, it is a 4 series was given in that. So, there is 5 and 6 also let me just come to that I have not noted it down. I have not noted down 5 x x and 6 x x, but so there is a 5 x x also I think that is a server error if I remember correctly and there is 6 x x I think local global field area. I think I had written it sometime back it must be there on some other sheet same thing gets repeated actually. So, that will be the status code. Now, coming to the header fields so far we have not discussed header fields it is only a samples actually were shown. So, moving to from request line to header fields. So, header fields will contain typically a structure which is going to be a header name and a header value field name and field value technically. So, a structure will usually will be header this will be usually consist of some header name. So, that is a grammar actually header value. So, a star actually shows that there can be variable number of parameters a variable number of values which can exist field value there will be comma. So, this can repeat H colon H colon is this two dots a colon actually H colon is written in the grammar. So, I have just copied that actually it is colon. So, header will usually consist of multiple lines each line usually will contain one field we can actually have multi line fields also are possible and every header field will start from character number 1 in a new line. If in the beginning there is an space then it is not a new field that is nothing but the previous had the header field in the real line has been broken. So, I can split one single long line into multiple lines, but I have to ensure in the beginning the first character should be either at least one white space or one tap. So, that is a condition I will come to this particular example. So, usually header field format is going to be field name. So, I want to actually do away with the space. So, I am going to put a dash in between actually to be more clear and this will be usually a field name and you can have arbitrary amount of white space here before and after the colon that is permitted. So, this is not illegal. So, in case if you write for example, some field which is there is usually white spaces are not there you will note that wherever I am putting I am actually putting a hyphen for joining the words and make it a single word I am not putting a space because the space is taken as a separator is a delimiter actually for the various fields. So, again this is a structure, but that is fine. So, subject I am not writing capital in fact it is case insensitive capital in small does not matter. For example, in email you might have seen that you send an email to me with full capitals you send it to me like this will both the mails reach to me or not they will always reach to me is case insensitive actually case does not matter. So, same is true even for CPURI same is basically it is true for any header field except under special cases which are specified or there is a string under the quotations. If there is a string under the quotations then it is case sensitive thing entity case does matter in that case they are not same. So, I think this again has been taken from. So, if a parameter is under inverted quotes that whatever is there under the quotes has to be case sensitive. So, in fact that is also true for HTTP URLs. So, subject I can actually put no space large number of space and I can write say lunch I am taking same example given in the RFC or I can now put. So, these are all valid whatever I am writing I can write all three are valid actually headers as far as a syntax is subject is I think is not the header field there I have not verified that, but the what is the recommended practices. So, when you write a software or code you have to ensure that you follow the recommended practice, but you should be willing to accept assume that the other guy who is going to send can send you a malformed thing he may not be following the recommendation, but you are supposed to follow. So, it should not be arbitrary. So, other guy who is sending the message may not follow that is fine you will be you should be able to accept all this, but when you send it is recommended you are always going to put no white space here or no space character and there will be exactly one space character and then whatever is the value. So, that is the recommended format and header fields can be split over multiple lines they can be extended that is permitted because every new header field will be starting from first character in a new line. So, that is essentially q is being used for the encoding purpose. So, that you can actually split a same header field over multiple lines. So, again taking an example when this is being constructed for example, you write. So, I am using a standard there is no white space one white space I can put up a string, but if I write something like this. So, I think this is very similar sentence which is there in the text actually these will be all this will whole thing will be one value this is not under inverted quotes, but it is one value because values are separated by comma. I can have multiple values for one field name, but then they will be separated by comma there is this is only one comma. So, this is one field this is another field in this case. So, another value actually field value name is subject. So, before this comma this is the field this is the field a special meaning can be taken off if I put inverted quotes then it is a one single value. I can have an option to split into two lines I can put like this. Now, if I put this invalid actually because I am starting from the first character in the next line this has to be then a header actually field I cannot do that. So, this is basically an identification mechanism so that on the receiver side your software can parse it easily and understand what is the message. So, there has to be at least one space or one tab or more than that any number. So, usually the practice is wherever your first character starts you will that is a recommended it is actually becomes human readable that is the reason actually why you do it this way. So, this is in the earlier version both are same. So, I can have multi line header fields. So, we have done this spacing stuff we have done multi line the sequencing of headers is that important. In the CRLF field will be there. In the format. Because next header has to start only from the new line. So, CRLF has to be there this is only for one header I am actually you are right there has to be CRLF in the end that is true where has to be where has to be a formula if you put it and this is aesthetics inside that what does it exactly signify where after that aesthetics. This one header value means what is header value is this is the field you can have multiple of them I can actually put for example, subject colon you can say lecture. So, that is the one value you can put a comma then you put you can say food that is a another value you can put say school that is another value. So, three values for this particular thing. In fact, this is equal to interestingly this is equal to I will come to that I was coming to the ordering, but let me give this special ordering this is nothing, but equal to actually writing this subject lecture. So, that is actually equal to three header fields header names or header field names can actually repeat that is permitted. And the order does matter order does matter because if I actually for example, move this thing on the top then the structure this and this are not same. So, whatever is the sequence of the values here in same order they should appear that is important. See for example, this the problem is for example, I am deciding a root field root says the message has to go from me to you first and then from there to another guy from there to another guy. So, I am defining even the sequence by this the message should go if I change the sequence I can either define the root header for example, I can say root colon and I define a CIP URI for CIP colon A dot abc dot com I can define another root B at the rate i j k dot com similarly I define third one. So, this actually defines the sequence I cannot disturb the sequence I can write the third entry as. So, this is how the message will be forwarded. So, it has to go one by one it has to first of all go to this from there it will be sent to this guy from there it will be sent to this. I can set up a multicast conference actually through this mechanism. I am just giving a what is the structure what are the rules yeah it is syntax specification. So, I can have C a raise power x y z the equivalent of this as per this. So, as you are propagating you can keep on deleting or removing. So, remember why a header field has to follow a sequence you cannot simply swap, but I can also put them in comma separated form that is permitted. A comma separates a field value not the semicolon I will be also I can also use semicolon a field value can also have parameters. So, a field value semicolon parameter name is equal to parameter value and any number of parameters can be there. So, that is also there in another extension in this. So, root for example, here will be this is equivalent now I have to put a comma remember they are multiple values I say I am now putting it in multiline. So, I should not start from the first character. So, I can start somewhere here I do not want in a multiline I can write in this line itself and of course, you have to use in all your eyes you have to use escaping this I think I have already mentioned earlier. So, all the special characters have to be escaped in that case means if I know which all characters have to be. So, the relative order here does matter, but relative order of fields actually it does not matter unless the names are same when the names are same within them order does matter they can be placed anywhere. So, header field sequence two you can put in the end for example, from you can always put first only first thing has to be request line and after that whatever is the header thing can be in any sequence, but if the names are same within those things the order has to be maintained because that is important they all even can be combined into a one single entry this combination cannot be done only for now there is a recommendation again it is not a rule. So, when you are writing a software. So, other guy can do anything this is from the source when you are sending invite that time you can decide client will give the route it is like source routing see when this is route this these are users I am not worried about proxies I want to signal you. So, I will tell my proxy to find a route to you and then pass the signal on to you after proper authentication when I say after you should now send a message to somebody else. So, I will pass on this whole header to you. So, it will go to you first and then from there it will go to you then from there it will go to you then to the final destination which is two. So, all three guys intermediaries will be informed these are not proxies these are clients. So, this is helpful for example, we are taking up a confidence yes a kind of overlaid multi casting when it has to be created see I do not want to communicate it to every everybody or I want to just in same message has to be broadcasted to five guys. So, it is has to go in this particular sequence. So, recommendation is that this particular fields route record proxy require see does not matter whether I write a small letter capital I have told already it is case insensitive I can write all capitals I can write all smalls it is permitted in this case. So, one capital is small capital is small that is also going to be same. Not necessary see I was at the mistake earlier because that is the way it was written and that makes it more legible and beautiful that is the only thing. So, that is a recommendationary practice, but need not be. So, when you receive something you should be you should prepare yourself for the worst when you are sending follow the recommendation then max forward and proxy authorization these fields are recommended to be always on the top of the message why they have to kept on the top of the message why do not want them to be at the bottom what is the benefit computation will be less computation will still be the same only thing it will take less time to parse because the message may when the message received at a proxy they are going to receive all these header fields first. So, parsing can finish much faster for the proxy. So, when I am sending a message to you all the header fields which I am expecting you to actually parse require should be always kept on the top of the header that way you will be able to parse it much faster because every header field which comes it starts a separate computation process after parsing. So, this parsing can the computation is start much earlier when it comes at the later stage it will be starting much later. So, I can save time in setting up of the calls or managing the calls again this is a recommendation not mandatory thing. First thing will be always request in the status line that you cannot change after that there are headers header fields. So, I am only talking about header fields now not the request in status line and then there is a in the end there is a CRLF and then there is a message body. So, message body also can be of various type it can be a binary object only the content length will be specified. This I have all told multiple field values can be combined into one single field value in this way by using comma separated field values actually list. This combination combining cannot be done for certain kind of headers you can do it for everything else except there are four cases where this cannot be done here you cannot do it for this particular header field name you cannot do it for authorization you cannot do it for proxy authenticate and you cannot do it for proxy authorization. So, why you think it is not permitted in this case you simply I think drop the header fields after looking at it you do not have to reframe them in this case in earlier cases you have to reframe. For example, this when you reach to this particular root this guy you have already reached. So, this will be dropped out of this line only two will be left out your reframing for the reframing is not permitted. I think it is probably because the hash is also must be going to check for the validity of whatever data you are sending in this that is my most likely guess I have not figured out the information because everything has to do either with authentication and authorization. So, whenever you are sending some keyword or something it is a good idea to actually always also send a hash with that hash will be broken the moment you put that thing and hash should be part of that string. So, you are saying about that common semicolon yeah that is now I am coming. So, now field aims also can have parameters field values. So, I think one of the example was tag which we did or branch in case of your invite and response thing. Now, that is addition now remember the field values are still separated by commas. This I found slightly strange because usually whatever is there as one single entity is separated by a semicolon. So, within that I can separate the sub fields by commas that is usually is the practice normally English language, but here it is done the other way around I do not know the reason why this is done this way, but that is it. So, a field value by definition I will not write I will write field name. So, header field will look something like this. This is the header field it will contain a field name colon field value any number a semicolon parameter name is equal to parameter value and any number of parameters can be attached that is why the star is there and this forms one value actually if there is another value then it has to be comma and then the next chain will start. See this whole thing is technically one parameter one value one field value it is only one field value, but the field value has been appended with parameters when the second field value has to be done there has to be comma and the next field value will come which can also be of the same form. So, branch and tag thing which we had earlier was nothing, but parameters they always took the form semicolon whatever was the parameter name is equal to parameter value and one field may have more than one parameter values. They can have more than one parameter value it is permitted you can have more than that is why star is put, but the same parameter name cannot be used more than once a parameter name cannot exist for more than once it cannot be repeated repetition is not permitted. Within this field value I am putting parameter one is equal to parameter value then I cannot put semicolon parameter one is equal to another parameter value now because though both are parameter one. So, what I am saying is if I write a colon b I say pair is equal to x y z I can put semicolon I cannot now this is invalid because this and this are same it is invalid. But if I get separated by comma then we get I can put pair one then it is valid yes if I put this thing comma I am now going to have another value which can be c and for which now I can use the same parameter this is a valid formation. So, basically if you can send this these are basically like parameters the way tag is for example a random string which is generated for every two and from fields there is a branch which is there in the via header field actually which was put. So, those are all parameters actually. So, case sensitivity I think one of the good example is contact I can write now this is not I am not going to put another field I am putting a parameter. So, I have to put a semicolon this both are same or not same they are going to be same because all things are case insensitive. Last example sir we saw that contact header field in that we were resolving to IP address resolving to IP address not. I can put domain name also PC33.Atlanta.com. Yes PC33 that will be the because this will be SIP. Right currently it is given like this I can put PC33.Atlanta.com also fine. I am giving an example contact will expire after this much time. You are telling that you have to connect to me, but I will be probably moving out. So, with after this time I will not be available here unless I actually send you another invite or another update you have to keep on updating. The source see when you are going to send a message to somebody you will add your contact expire also you will add. You are here say for example in next 60 minutes after that settle you will not be here. So, you kind of given lease for this IP address you keep on correcting me only for this much period. After this if I do not send you another lease kind of thing or another inform update you simply assume that I am not there on this address. It is like if you are going to your internet cafe you want to log in you would like to always set whether I work do not work after 15 minutes this system should log out I should be logged out of it actually and all my data should be raised, but if you are going to work for another 15 minutes before the 15 minutes expire you will send another update you will again do the authentication. So, one authentication is valid only for this much period. So, you have to again do another authentication for increase your validity period I think it is for that purpose logical choices this is the way it should have been designed. Now, these header fields which are there they are again are can be categorized some header fields will be existing only in request some will be in responses some will be in both. So, these are categorized as request header fields and response header fields correspondingly. Now, you are writing an engine or software basically or a server you end up in getting a message a request actually has come to you and it gets a header fields which corresponds to a response what you will do with that should you ignore the whole message should you ignore only that header field or should you start making noise the rule is very simple in internet if you do not understand anything simply ignore it. So, ignore that header field whatever you can understand do all the parsing all actions have to be taken as per that that is a rule and there is a thumb rule followed everywhere in the all almost all internet protocols if you understand it is fine if you do not forget it. Now, there is another interesting thing so far I have given you all kind of very long names of header fields SIP also does have something called short forms of this short form of all header field names does exist and you can use that. So, when you write a software your software should actually understand both forms a proxy midway can actually change your header field name from longer to shorter form or shorter to longer form if they are multiple times a field is existing some of them can be short and some of them can be long that is also permitted. So, both are valid entries they, but they both will mean the same thing and why this short form concept was actually invented no there is a maximum transmission unit maximum size of a dp packet you cannot transmit larger than a size. So, if your message itself become too large then what you will do if you say you cannot your things whatever you are trying to transmit cannot be packed into one single UDP start compressing start using shorter form that is the immediate thing if you are using a TCP transport this is a streamed transport that is. So, in that case size can be anything, but in UDP it cannot be anything. So, it is basically for that compression purpose to conserve on the space. So, one is human readable other one is also human readable, but it is a short form acronym kind of thing. Now, coming to there is another important thing that UDP it is fine when you will get the message your first line will always be request line or a status line, but if you are not using UDP you are using TCP I sent an earlier message after that I was silent I sent some white spaces or CRLFs and then I send the next message then your first line will not be a request line after the silence on the stream thing. So, again in your software irrespective whether it is a UDP transport being used or TCP if you receive a message all CRLFs carriage return line feeds which are happening before request line has to be simply discarded this problem will not happen if you are using UDP transport. So, but this has to be explicitly programmed otherwise this will create confusion because CRLF is end of header. What happens is when you are having a streamed transport between two entities. So, you keep on sending bytes and bytes will arrive it is not one packet or a message is being encapsulated into a UDP packet and send. So, you have sent a message after that silent you might send lot of CRLFs or whatever it is and then suddenly you start you got the first request line. So, previous message end finished then you get a request line in between there can be white spaces these have to be simply discarded actually by design. If it is UDP UDP packet will come you will not see any white space things will start with request line, but not with the TCP transport. So, with the streamed transport this particular issue will come. So, that also has to be resolved. But after those are white spaces in TCP since it is condition oriented you still get the request line you will start off from header. You always get the first thing is always request line then header fields and then CRLF and then the body length will be always there is always content length will always be part of your header. You cannot have a header without content length field it will at least be 0. After one message is passed then in TCP because it is condition oriented we get lot of white spaces CRLFs then again we get the message. So, again that message will have request lines. First request line will be there always. So, every message will have a request or response. So, the TCP only request or status sorry the TCP only has to taken white spaces. Yes, see, but when you are building up your transaction user remember you are building up a transaction client or transaction server ok. Client transaction or server transaction which are going to use a transport. So, transport is at the bottom as a transaction user or as a basically client or server transaction you do not bother about the transport transport is somebody else is headache. So, you have to remove all that thing in your client transaction or server transaction actually which I create they actually now receive the message parse it and they invoke the code in transaction user to correspondingly to do whatever is required, but it remains there to maintain the state of the transaction. You mentioned that the coding of these messages I mean when I was speaking or voice telephoning periods of silence or messages are discontinued. No, that is in media this is purely signaling setting up of the call. Once the call has been set up between two end points in this fashion for example, when they talk to each other then I am sending over RTP real time protocol and real time streaming protocol I can use and I can send mp3 for example in both directions for audio. So, mp3 encoding because I do not want to send the packets unnecessarily I can simply keep on if you are speaking then only I will encode and send the packets otherwise you would not only hard bits will you will keep on sending that the connection is a live media connection. And here the playback will happen when out of the media packet is there otherwise just to make sure you do not get annoyed some noise can be played. So, as if you feel as if connection is still alive. So, walkie talkies you do not see either you have a something coming or nothing coming that actually usually is annoying telephone we do not see we consciously actually see something coming from the other side. Even if there is silence you will get some hum. So, this probably can be locally created to conserve on the bandwidth. Skype I do not know how does it do, but Skype does have a silence detection and it cuts of the voice when it is not required. But even if there is a silence and if you are doing differential encoding in the voice you still conserve on the bandwidth because the differential change is very small. So, your voltage levels when they are varying in time. So, these differential changes what are sent. So, if the noise is like this your differential change is very small you have to send a very small amount number of bits every sample interval actually. So, anyway are consuming much less bandwidth in this. So, there is a live compression differential encoding silence detection everything is there actually. There is one more last thing there is in STTP for example, you can send a body there is a message CRLF and then there is a message body where you put the payload part. This payload STTP allows the chunked means you can actually define multiple bodies with each one of them having their own content length type content length basically specification. So, larger message body can be broken into smaller parts and can be transported through STTP. Now, this is not permitted in SIP although it is going to use almost same kind of mime type same content length content type content encoding as STTP, but chunked body transfer is not permitted with SIP. So, I think that was kind of an introduction to SIP we have not this basically giving all the syntax how things will be done and some issues you have tried to understand. So, with that actually I am now closing the all lecture series of EE 629. So, next class I will be just taking up all the questions regarding whatever has been taught in the whole semester. So, discussion about whatever questions you have. So, my request is you please send me all the questions you want me to discuss before and so that I can at least go through the text. Even if you do not do it I will try to give to my best whatever answers I can give in the class. So, next week is on Thursday actually last class. So, it will be all discussion about this thing whatever we have done so far in the whole semester and of course, your feedback sessions because I think we should be open and lot of you are actually practicing engineers I am not one people who work in the field knows actually much more they can also provide their inputs.