This is explained in RFC 3261. INVITE establishes a dialog and so to get both parties to be aware that the other is aware of one's own reaction you need a three way handshake. A send an INVITE to B. When B then send 200 OK he is aware that A want's to have a dialog but he does not yet know if A has received his response. When A receive the 200 OK he knows that B has accepted the dialog but as B does not yet know if A has received the 200 OK B does not know that the dialog has started yet. Thus, A send an ACK to inform B that the dialog started.
When you close the dialog you don't need this three way handshare. You just need to inform the other party that as far as you are concerned the dialog is over. At the moment A or B send a BYE to the other he has already considered the dialog to be more or less dead. I.e. you want to receive and accept requests from the other but as the dialog is dead you don't want to do anything serious with them. Typically just sending some error response or some such. When the other end receive the BYE request he will stop sending such requests and will instead send a response to the BYE message. At this point the dialog is dead for both of them except that he will send the response back to inform the sender that he has received the BYE. A three-way handshare is not needed to get both parties to understand the dialog is dead. When opening a dialog you need the three-way since otherwise A would have receied the 200 OK from INVITE and thus known that the dialog is active but B would not know this since he doesn't yet know if A received the 200 OK or not. For example, if A send an INVITE and B receive it and then send 200 OK. If we assume that it was not a three-way handshare and the line went down immediately after B sending the 200 OK response. Then A would not yet know that the dialog was active since he never received the 200 OK response while B would think the dialog was active since he had already sent 200 OK. If the dialog itself is sent over a different channel (typically media is sent to a different port than the SIP messages) the dialog media may go back and forth even if the SIP message path is broken and you would have an inconsistency. B would think the dialog is operative and start to send media, A would think the dialog is not yet operative since he has not yet received 200 OK (the 200 OK message never made it to A). Thus, a three-way handshare is necessary. B will continue to send the 200 OK message until he receives an ACK from A and at that point both parties knows the dialog is active and media data an go back and forth between them. As such this has nothing to do with the SDP data and offer/answer model but it has to do with the fact tha both parties need to have a consistent view of the state of the dialog. It is rather the fact that since we do need a three-way handshare to establish a dialog, the SDP can either go with offer in INVITE and answer in 200 OK and empty ACK, or alternatively with offer in 200 OK and answer in ACK and as both styles are useful, both are permitted. In contrast, closing the dialog does not need a three-way handshare since the dialog is closed as far as A is concerned the moment he has sent BYE. He will then stop sending and receiving media data (after a timeout) even if he never receive any response from B. For exmaple if B lost connection on the SIP message path so A sending BYE to B but B never receives it, then B will never receive the BYE message but will after a while see that the media connection is closed by A and will then probably try to send BYE on his own to A. If the connection is broken A will never receive that BYE message either and so B iwll also not receive any response from the BYE but again, the dialog is considered closed the moment he has sent a BYE so they both consider the dialog closed - no three-way handshake is needed. Yes, there will be a small window where A consider the dialog closed (when he send out BYE) and media is still received since B has not yet received that BYE message but eventually B will either receive the BYE message or will find that the media stream to A is lost or he receives no media stream from A and so B will either receive the BYE message or he will get information that the media stream to A is lost or he will timeout from no media stream from A for a while. In either case will B then understand that the dialog is over. Hope this is of help. Alf On Wed, 2006-09-27 at 03:31 -0700, varun wrote: > Hi, > Why is there an ACK especially for INvite 200 OK but > not for Bye 200 OK. > Except for the reason that ACK can carry SDP( 200 OK > -ACK Offer Answer). > There must be any other reason too..Please let me > know! > > Thanks > Varun > > > --- "B, Nataraju" <[EMAIL PROTECTED]> wrote: > > > Comments inline... > > > > Thanks, > > Nataraju A B > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > [mailto:sip-implementors- > > > [EMAIL PROTECTED] On Behalf Of Abhit > > Kalsotra > > > Sent: Monday, September 25, 2006 4:46 PM > > > To: [email protected] > > > Subject: [Sip-implementors] Regarding REGSITER > > > > > > Hi > > > > > > I have few queries regarding SIP REGISTER Message > > for IMS. > > > I am new to SIP, so could not gather much in > > details from RFC, drafts > > > and 3gpp. Hope you adroit of SIP would help me... > > > > > > I have query regarding the "Contact" header in > > REGISTER message. > > > In IMS, contact header indicates the > > point-of-presence for the > > > subscriber - the IP address of the UE. This is the > > temporary point of > > > contact for the subscriber that is being > > registered. Can I REGISTER > > > telephone Number with the same REGISTRAR; if yes > > then suppose I want > > to > > > register a telephone number, what's the format I > > should send to > > P-CSCF, > > > and suppose I want to register a mailid what's the > > format in contact > > > header I should send to P-CSCF. > > > > > [ABN] the contact header in REGISTER request > > specifies you point of > > contact for any of the incoming requests. > > I am not very sure you can register a Tel Uri, but > > standard does not put > > any restriction on that. > > > > Probably for tel uri, we can use SIP uri and > > user=phone URI-parameter, > > to mean tel URI > > > > > Kindly tell me > > > > > > Regards > > > Abhi > > > > > > > > > > > > > > > ######################################################### > > > THIS EMAIL MESSAGE IS FOR THE SOLE USE OF THE > > INTENDED > > > RECIPIENT(S) AND MAY CONTAIN CONFIDENTIAL AND > > PRIVILEGED > > > INFORMATION. ANY UNAUTHORIZED REVIEW, USE, > > DISCLOSURE OR > > > DISTRIBUTION IS PROHIBITED.BEFORE OPENING ANY > > ATTACHMENTS > > > PLEASE CHECK FOR VIRUSES AND DEFECTS.IF YOU ARE > > NOT THE > > > INTENDED RECIPIENT, PLEASE NOTIFY US IMMEDIATELY > > BY REPLY > > > E-MAIL AND DELETE THE ORIGINAL MESSAGE. > > > > > > ########################################################## > > > > > > _______________________________________________ > > > Sip-implementors mailing list > > > [email protected] > > > > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
