Miki, If we did cover this specific aspect before, it is probably in the SIP email archive. But, to save time looking for that, let's look at this closely now. Email below trimmed to specific issue. I re-read the note text in beginning of Section 15 of RFC-3261. It addresses the cleaning up state of the UAS, but does not discuss all possible message sequences from the UAC. What the UAC sends and when is the main issue below.
>-----Original Message----- >From: Miki HASEBE [mailto:[EMAIL PROTECTED] >Sent: Monday, April 04, 2005 7:59 AM >To: Michael Hammer (mhammer) >Cc: Kenneth Ho; Cullen Jennings (fluffy); >[email protected]; Dean Willis; >[email protected]; Gonzalo Camarillo >Subject: Semi Regular Examples draft [snip] >> 2) how you can send a CANCEL then ACK a 200 OK, (seems like >> a retrans of CANCEL or a BYE would do the trick here) > >Considering notes about "hanging up" on chapter 15 of RFC3261, >this is considered to be the recommendation specification that >the software in phones need to maintain state for a short >while in order to clean up properly. > >Therefore, I think UAC should send ACK to the 200 OK. >I think we would like to add the sequence to the draft, that >is sending BYE soon after sending ACK. I still don't like sending the ACK after a CANCEL was sent. This leads to the possibility that the CANCEL is lost (or 200 OK's suppressing further CANCELs but not acted upon) and the ACK is received, leading the UAS to think the dialog is really complete. The only advantage you seem to get is that the UAS can now send a BYE, if the called party hears nothing and decides to hang up. The down side is that the UAC won't send another message since it will get a 200 OK to CANCEL, and the UAS won't timeout, since it got the ACK. So, the called party listens to a mute call until he gets angry and hangs up. Not getting the ACK would give the UAS a clue that something is wrong. Also, once it times out waiting for the ACK, it could then send a BYE. But, if the UAC sends a CANCEL, then receives a 200 OK to INVITE, it knows that the CANCEL was not received in time and will have no effect on the UAS (see Section 9, p. 53, and 9.2, p. 55). Therefore, it needs to immediately send a BYE. (Note: This is not covered in Section 9.1, nor in Section 9.2 that only covers the case of CANCEL received before final response sent). By transitioning from retransmissions of CANCELs to sending and retransmission of BYEs the UAC can be more assured of ending the call. Last, note that Section 9.2 says that a CANCEL is reponded with a 200 OK if it matches an existing transaction, which is the case here. This seems to be true whether it arrives before a final response is sent or after, even though no action will be taken on it. [snip] >> 4) If you receive a CANCEL, accept that and the fact that an >ACK won't be forthcoming to the 200 OK. There is no sense >trying to complete that dialog once both sides know it is >going to fail. > >As you have pointed out, I also think that receiving the >CANCEL may be considered as failure of the dialog establishment. >According to RFC3261, UAC MAY send a BYE in this situation. >But surely UAS knows that the dialog establishment has failed, >so I would like to consider the recommendation of UAS behavior. [snip] My whole goal above is to not send the UAS mixed (contradictory) signals. Let me know what you think. Mike _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
