This question should be directed to the SIP implementors list (being a question on protocol usage). > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Romel > Khan > Sent: Monday, August 06, 2001 11:45 AM > To: '[EMAIL PROTECTED]' > Subject: [Sip] Cancel method in SIP bis-04 > > > I have couple of questions/points on procedures related to > Cancel method (I > don't recall whether SIP bis 04 is clear on that): > 1. UAC sends Invite to UAS. UAS sends 200 OK to UAC. > Meanwhile before the > 200 OK is received by the UAC, it for some reason sends a > Cancel to the UAS. > So what should happen in this glare situation? I assume the > UAS will ignore > the Cancel since it has already sent the 200 OK. And the UAC, > upon receiving > the 200 OK, should either send Bye to UAS or let the call > connect sending an > ACK depending on the particular reason the Cancel was sent in > the 1st time. > The Cancel, however, is not retransmitted. > Or is there a different procedure? Which pages in which SIP > RFC might have > talked about this? > >From the sections that describe INVITE and CANCEL processing, a correct sequence would be as follows. UAC UAS | | |-------- INVITE ------->| |<--------- 1xx ---------| |-- CANCEL --><-- 200 ---| |<---- 200 (CANCEL) -----| to complete the transaction (note 1) |----- ACK (INVITE) ---->| to complete the transaction (note 2) |--------- BYE --------->| (UAC wanted out of the call) |<------ 200 (BYE) ------| Note 1: as you say, UAS will ignore the CANCEL since it provided a final response, but it must complete CANCEL transaction. Note 2: UAC must complete INVITE transaction. > 2. UAC sends Invite to UAS. UAS sends a response such as 200 > OK but it is > improperly formatted. How should the sending side behave in > this case? I > notice from SIP implementations that the UAC will send Cancel to UAS. > It will be very helpful to have some kind of 'reason' header > field in the > Cancel request so that the reason why the Cancel is being will be much > clearer. > UAC will re-transmit request until timeout, then clean up state/call. It never gets a final response (that it understands). regards, Bert > Thanks. > > Romel Khan > Net2Phone > Ph: (732)-363-0213, x241 > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
