Folks, Thank you for many comments.
I will add this description to the draft of exceptional procedure. Any additional examples or comments will be welcomed. Regards, Miki Hasebe Charles Eckel <[EMAIL PROTECTED]> wrote: > Seems like a fine idea to me. > > Cheers, > Charles > > Michael Hammer (mhammer) wrote: > > > Charles, > > > > OK, I give up. I found the requirement in 13.2.2.4 that requires an ACK > > for every 200 OK INVITE sent. So, effectively the sole purpose of the > > ACK is simply 200 OK suppression. > > > > However, I would note that the behavior of a UAC sending a CANCEL, then > > receiving a 200 OK triggering immediately sending a BYE should be > > documented. I can't find it in RFC-3261. The closest it comes is in > > Section 13.2.2.4 last paragraph. But, based on other parts of 3261, the > > UAC could have concluded that it already did release the dialog and > > already be gone. > > > > So the above will be documented in the exception examples draft? > > > > Mike > > > > > > > >>-----Original Message----- > >>From: Charles Eckel (eckelcu) > >>Sent: Tuesday, April 05, 2005 12:07 PM > >>To: Michael Hammer (mhammer) > >>Cc: Malleswara Rao Ankem; [email protected]; > >>[email protected]; Miki HASEBE > >>Subject: Re: [Sipping] RE: Semi Regular Examples draft > >> > >>I agree with the statement about having to send the BYE, > >>except that you need the send the ACK first. More inline. > >> > >>Michael Hammer (mhammer) wrote: > >> > >> > >>>But, this leaves us in a state where: > >>> > >>>UAC: > >>>Sent CANCEL, receives 200 OK INVITE, sent ACK, receives 200 > >> > >>OK CANCEL, > >> > >>>goes away. > >> > >>It can't. It needs to send a BYE after sending the ACK, and > >>needs retrans the ACK if it gets another 200 OK for the > >>INVITE, and needs to retrans the BYE until it gets a 200 for > >>the BYE (or times out trying). > >>It all goes back to the underlying principle of every > >>transaction completing independently. > >> > >> > >>>UAS: > >>>Sent 200 OK INVITE, receives CANCEL ***but doesn't act on > >> > >>it***, sends > >> > >>>200 OK CANCEL, receives ACK, remains in active dialog. > >> > >>Right, that is why the UAC needs to send the BYE. > >> > >>Cheers, > >>Charles > >> > >> > >>>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 > >>> >> > >>> > > >>> > >>>_______________________________________________ > >>>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
