On Tue, Oct 31, 2017 at 10:38:00PM -0400, Dale R. Worley wrote: > As others have said, the problem must be solved by the UAs, not the > proxy. Indeed, what with possible network delays and re-sending of > lost packets, there's no way to guarantee end-to-end sequencing of > messages. Even with TCP service, there's no guarantee that none of > the intermediate proxies aren't using multiple TCP connections to > carry messages between themselves.
That's certainly true. But in this case I do control the entire setup topology end-to-end, and implicit in my thesis was the desire to assert control over that over which control can be asserted. :-) > You're correct to look to 5407 (which is important enough to be known as > just "Hasebe") for guidance. And it does look like section 3.1.4 is the > relevant case, or very close to it. > > This scenario illustrates the race condition that occurs when a UAS > in the Moratorium state [having sent 2xx but not received ACK] > receives a re-INVITE sent by a UAC in the Established state. > > And as the text goes on, sending 2xx is recommended, rather than 491, > because all of the state changes within the UA associated with the first > re-INVITE have already been completed. But a 491 response is also > permissible. The reason that I did not think § 3.1.4 was exactly pertinent was due to this formulation: The UAS receives a re-INVITE (with offer2) before receiving an ACK for the ini-INVITE (with offer1). The UAS sends a 200 OK (with answer2) to the re-INVITE (F8) because it has sent a 200 OK (with answer1) to the ini-INVITE (F3, F5) and the dialog has already been established. (Because F5 is a retransmission of F3, SDP negotiation is not performed here.) The scenario described in the foregoing is for a reinvite occuring after an *initial* INVITE cycle but arriving before the ACK for that initial INVITE. The scenario I've got going on is a reinvite following another reinvite. As you suggest, there are few reasons to think that the reasoning should be different, or at any rate substantially different, for a consecutive reinvite vs. a reinvite following an initial INVITE. Nevertheless, that was what motivated the perception that § 3.1.4 may not speak to the fine letter of the exact scenario in play. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
