Mike, Thank you for the comment.
> I'll confess I haven't read the draft yet, but the examples below seem to add > to the confusion rather than suppress the confusion. I am also assuming that > this is UDP-based, not TCP-based SIP. I don't understand: Yes, they are the examples on UDP-based SIP. Applications like an IP phone are assumed as a target, but it is not limited only to them. > 1) how you can send a 200 OK to an INVITE and then later send a 4xx response > to that INVITE, I agree that any 4xx must not be transmitted after sending 200 OK as the response to the INVITE. The final response must not be changed, once UAS has transmitted the final response. I would like to clarify for avoiding misunderstandings. What I would like to point out in the crossover sequence of CANCEL and 200 OK (Chapter 2.1) is that the CANCEL is answered by 481(4xx) when the CANCEL arrives after sending 200 OK as a last response to the INVITE. > 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. > 3) Treat a retransmission of an INVITE as a new dialog until you have an ACK > to the 200 OK with To: tag, > (retransmissions must be recognizable and handled as such, i.e. retransmit > the 200 OK) Yes, I agree to your idea that re-transmitted INVITEs must be recognizable as such. There is a comment pointing out that UAS seems not to distinguish between the re-transmitted INVITE after sending 200 OK and the new INVITE. > 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. I think that there were many discussions of the same kind in various places. If you know the discussions relative to this draft, please let me know the pointer. Your cooperation is appreciated. thank you. Miki --------------------------------------------------------- Miki HASEBE Research and Development Center NTT-east Corporation Telephone +81 3 5359 5104 Facsimile +81 3 5359 4768 E-mail: [EMAIL PROTECTED] 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan --------------------------------------------------------- _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
