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
