First of all, many thanks for both answers. As for your modified example, I think this situation (UAS receiving an ACK in mortal state, state change caused by BYE received from UAC) is discussed in sec. 3.1.6 of RFC 5407 (with the sole difference that the first ACK is lost, not reordered as in your example). What confused me was that example 3.2.4 is in my opinion clearly written from the perspective of the UAS, specifically describing a case that is contradictory to the base standard. As I try to implement a UA it is important to know whether or not it is expected from the interface to support sending a BYE in Moratorium state at all (since this would necessitate some extra effort in the implementation which I can otherwise save) to avoid possible interoperability problems. But I guess I just stick to the base RFC and avoid this edge case for now :-).
A related question: While sending BYE for the initial INVITE is prohibited by RFC 3261 before an ACK is received, I guess this does not hold for RE-INVITEs since the dialog is already established. Is this correct, as re-invites are not mentioned at all in sec. 15? (In this case, example 3.2.4 would be applicable without problems too, only with re-invite instead of ini-invite) Best regards, Peter On Mon, Apr 11, 2011 at 11:49 PM, Worley, Dale R (Dale) <dwor...@avaya.com>wrote: > > From: Peter Krebs [pkr...@gmail.com] > > > > 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 [br...@broadsoft.com] > > > > 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 Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
