Maxim Sobolev wrote: > Greg Burrow wrote: >> RFC 5407 appendix A makes it clear that sending a BYE in the early media >> state is allowed but not recommended. However, what about sending BYE in >> the Confirmed/Moratorium state? >> We are seeing a UAC reject the answer SDP from a received 200 message by >> sending a BYE before sending an ACK to the 200. >> >> RFC 3261 seems clear that the ACK must be sent first (section 13.2.2.4), but >> the vendor argues that since the dialog is confirmed, sending the BYE is >> allowed (section 15). > > I think by generating BYE before generating ACK in the "confirmed" state > the UAC technically violates the section 13.2.2.4, which says: > > The UAC core MUST generate an ACK request for each 2xx received from > the transaction layer. The header fields of the ACK are constructed > > However in practice this should not cause any issues since the UAS > should be prepared to receive BYE before ACK due to natural causes, such > as jitter in message propagation delay and packet loss. That is, even if > UAC sends ACK followed quickly by BYE they might get reversed in transit > (or ACK might get lost) so that the UAS would get the BYE before ACK.
P.S. All this is assuming that your UAC actually generates ACK after BYE. If it doesn't then it's clearly broken. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sa...@sippysoft.com Skype: SippySoft _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
