If you want to terminate or cancel an INVITE you should send CANCEL and not BYE. BYE is used to close a dialog that is established. CANCEL is used to close a dialog that is in the process of being established but has not yet been established.
Also, since you cannot send CANCEL until after you have received a response from INVITE you shouldn't send anything until you get some response. If that response is 1xx then you should send CANCEL and if it is 2xx you should send ACK and then BYE and if it is any other response you should send ACK and nothing more. (the error ACK is sent in transaction and sent by the transaction layer so UA is not supposed to worry about it). I.e. you have three possible scenario: A ---> INVITE --> B Until you get response from B you can do nothing but retransmit the original INVITE until you time out. If you want to cancel the INVITE you can of course stop sending the retransmissions as you are not interested in establishing any dialog any more anyway. However, if one of those INVITEs you have already sent do reach B and B send a response you must be prepared to handle that response when it arrives. If you receive no response from B then you probaby haven't managed to reach B anyway so there is nothing to cancel or stop. Just stop sending the INVITE retransmits and you are done. When B receive the INVITE and then send you a response you get the three different cases. Case 1 - you receive a 1xx. A <--- 1xx ---- B At this point send a CANCEL. A ---- CANCEL ---> B Now, if B receive the CANCEL before it send a 200 OK, B will stop ringing etc and send a 487 error response to INVITE and send a 200 OK response to CANCEL. I.e. A will receive a 200 OK response to CANCEL and also receive a 487 error response to INVITE. You handle this case as case 3 below (receive error response). It is also possible that B send a 200 OK response to INVITE before it receives the CANCEL you sent. If so you should handle it as case 2 below. I.e. you will receive a response to the CANCEL and also a 200 OK response to INVITE. In this case it is like case 2 below. Case 2 - receive a 2xx response. In this case you have established a dialog. Send first ACK to B and then send BYE to B to close the dialog. A ---- ACK ----> B A ---- BYE ----> B B will then send a response to the BYE and the dialog is closed. Note that due to forking it is possible that you receive several 2xx responses from different parties. If you want to close all of them you have to do this ACK then BYE for each of them. If you want to keep some of them and establish dialog with them and communicate with them you will just send ACK and then wait with BYE until you decide to close the connection. Case 3 - receive an error response 3xx, 4xx, 5xx, 6xx. In this case you have not established any dialog so no need to send BYE. However, you must send ACK but this ACK is typically sent by transaction layer so UA does not have to worry about it. I.e. there is nothing more to be done. Alf On Fri, 2006-09-29 at 21:39 +0900, NTT COMWARE Hidehisa Matsutani wrote: > Hi, > > I have some questions to implement a SIP application. > Please take a look on the sequence below: > > (1) What do you think of the sequence? > Is UAC allowed to send BYE just after it sends INVITE(session timer > refresh)? Or should UAC send after the INVITE transaction? > (In the other words, F2 should be sent after F1 transaction is completed, > shouldn't it?) > > (2) If the sequence is allowed, when should UAC stop the re-transmission > for the INVITE? > I think the re-transmission should be stopped when BYE transaction is > started, -- after F2. > Someone says re-transmission should be stopped after 200(BYE) is > received, -- after F3. > Which is better do you think? > > UAC UAS > | | > The session has been already established > ========================== > | | > | F1 | > |--------------------->| INVITE(Session timer refresh) > | F2 | > |--------------------->| BYE > | F3 | > |<---------------------| 200(BYE) > | F4 | > |--------------------->| INVITE(re-transmit of F1) > | F5 | > |<---------------------| 481(INVITE) > | : | > | : | > | F6 | > |<---------------------| 481(INVITE) re-transmit of F5 > | | > > Best Regards, > > HIDEHISA Matsutani E-mail: [EMAIL PROTECTED] > NTT COMWARE CORPORATION > NWS Headquarters Core-NWS Department NW-OpS-BU IP-Service-Platform PJ > Tel: +81-43-211-2102 Fax: +81-43-211-5123 > > > > > _______________________________________________ > 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
