> From: Peter Krebs [[email protected]] > > While perusing the race condition examples in RFC 5407 I noticed what seems > to be an inconsistency in regard to RFC 3261. The example in sec. 3.2.4 > depicts the callee (Bob) sending a BYE request immediately after the 200, > however RFC 3261, sec. 15 clearly states that > > "...the callee’s UA MUST NOT send a BYE on a confirmed dialog until it has > received an ACK for its 2xx response or until the server transaction times > out." > > Do I misunderstand the given example or is this an actual inconsistency? Or > is this intentional and just following the observed behaviour of > implementations out in the field and thus recommended? I would guess the > later, because following the original rule would mean there is no way for > the callee to terminate a dialog until the timeout runs out.
> From: Brett Tate [[email protected]] > > RFC 5407 provides a "Best Current Practice" for potential SIP race > conditions. If there are conflicts with RFC 3261 or other "Standards > Track" RFCs, the normative statements of "Standards Track" RFCs take > precedence. A BCP cannot update a "Standards Track" RFC. RFCs like this are treacherous. In principle, they only provide guidance on how to best use the base, standards-track RFC. But very often, they "clarify" the base RFC, which means, they resolve ambiguities or provide small corrections to the text in the base RFC. So in reality, you have to consider the later RFC as updating the base RFC. > As the title of RFC 5407 section 3.2.4 reflects, the section is > highlighting the potential for receiving ACK while in "Mortal State": > "Callee Receives ACK (Moratorium State) While in the Mortal State". > The section does not update RFC 3261. It provides guidance concerning > how the race condition can be avoided and how the ACK should be > handled if it occurs. The crucial point is: RFC 5407 section 3.2.4 shows a sequence of operations that sets up the system so that the race condition can happen. But Bob's UA is not permitted to perform that sequence of operations, because it is shown sending a BYE before receiving the ACK to the 200 to the INVITE, which as you note is forbidden by RFC 3261 section 15. The question is whether the situation described by section 3.2.4 can be reached at all, that is, can the UAS receive an ACK while in the Mortal state? With a little we see that it can be, if the UAC sends a BYE -- see RFC 5407 figure 2. We can arrange the sequence of events by having the UAC receive the 200 to the INVITE and sending the ACK, followed by sending a BYE, but having the BYE received at the UAS before the ACK arrives: [fixed-width] State Alice Bob State | | | ini-INVITE F1 | |------------------------------->| Pre | 180 F2 | Pre |<-------------------------------| Ear | 200 F3 | Ear |<-------------------------------| Mora | | Mora | ACK F4 | |------------- | Est | BYE \ | |---------------*--------------->| | \ | Mort | \ | | ------------->| *race* Mort | | [fixed-width] The discussion in section 3.2.4 seems to be appopriate for this version of the situation: Bob essentially ignores the ACK because Bob has been informed that the dialog is terminated by the BYE. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
