Dale, > But when the UAS receives the retransmission of the INVITE, it is > out-of-sequence, since the UAS has already processed the BYE. So it > must reject the INVITE with a 500 response. I believe that the > sequence-check must be done before any semantic processing of the > request, so it can't be argued that a 481 response is acceptable.
Either a 500 or a 481 would be acceptable. If the BYE was received before the reINVITE, there is no reason for the UAS to keep the dialog state around after sending the BYE response. When the reINVITE is already being processed, an implementation could increment a reference count on the dialog state; then the UAS could detect the out-of-sequence as you suggest, and send 500. The reINVITE retransmissions stop when a provisional or final response is received. The UAC should not attempt to "optimize" by aborting the reINVITE transaction when BYE OK is received. What goes wrong in the sketched scenario, is that the UAC is not sending ACK upon receiving the 481 (F5). It MUST send ACK there. ACK for non-2xx is a transaction layer issue, and indepedent of the state of any dialog Regards, Jeroen _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
