> From: Markus Hofmann > > UAC UAS > | | > | ----------- INVITE ---------> | > | <---------- 200 OK ---------- | > | ------- ACK --> xxx | > | ----------- BYE ------------> | > | <-----------200 OK (?)------ | > | | > > The ACK will be lost but the BYE will be send immediately > after the ACK (for example a CANCEL fails). > > The UAS receives the BYE, what should the UAS do now?
One possibility is that UAS decides to postpone processing the BYE (or ignoring it and letting the UAC retransmit) because the INVITE transaction has not completed. In that case, UAS will eventually retransmit 200 for INVITE, and UAC will respond with ACK. After that, the BYE can be processed normally. Otherwise, section 15.1.2 of RFC 3261 seems to make it clear that the BYE is to be processed like usual. The dialog already exists (from the UAS's point of view), and so it must be terminated, and 200 for BYE must be sent. After processing the BYE, UAS can give up on trying to get an ACK for 200 for INVITE, or it can retransmit 200 for INVITE. If UAC receives a second 200 for INVITE, it must respond with ACK (until the time-out for the INVITE transaction has passed), because it originally responded to 200 for INVITE with ACK. Dale _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
