But, this leaves us in a state where: UAC: Sent CANCEL, receives 200 OK INVITE, sent ACK, receives 200 OK CANCEL, goes away.
UAS: Sent 200 OK INVITE, receives CANCEL ***but doesn't act on it***, sends 200 OK CANCEL, receives ACK, remains in active dialog. That can't be right. If it were, it would mean that the ACK has no real meaning and could be omitted. The only part above that is not required by RFC-3261 is the sending of ACK. It is not so clear, but should be that getting a 200 OK INVITE after sending a CANCEL should immediately require a BYE to be sent. Also, in 14.2, it says a UAS that does not get an ACK (e.g. timesout) SHOULD send a BYE to terminate dialog. Mike >-----Original Message----- >From: Malleswara Rao Ankem [mailto:[EMAIL PROTECTED] >Sent: Tuesday, April 05, 2005 12:51 AM >To: Michael Hammer (mhammer) >Cc: Miki HASEBE; [email protected]; [email protected] >Subject: Re: [Sipping] RE: Semi Regular Examples draft > >Hi Michael, >Some thoughts in line > >On Apr 4, 2005 9:08 PM, Michael Hammer (mhammer) ><[EMAIL PROTECTED]> wrote: >> 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. > >a) Instead of sending a ACK the UAC can send a BYE (presuming >that this would stop any retransmissions from the UAS side >which is waiting for a ACK). >b) Moreover, UAS MUST NOT send a BYE before it receives an ACK >for its 200OK. So this is one of the reasons sending an ACK is >not harmful as you say. > >regards >Mallesh >> >> 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 >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP Use >> [email protected] for questions on current sip Use >> [email protected] for new developments of core SIP >> > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
