Alex Balashov <abalas...@evaristesys.com> writes: > 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. :-)
Well, I'd answer "the difference between theory and practice is larger in practice than in theory". If you can get what you want without exerting special control over all of the parts of the system -- a control which SIP is not designed to ensure you can have -- you're a lot more likely to succeed. > 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 > [section] 3.1.4 may not speak to the fine letter of the exact scenario > in play. True... But I wouldn't want to have to build a system that distinguished the two cases. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
