[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] Reinvite/ACK race
From:       worley () ariadne ! com (Dale R !  Worley)
Date:       2017-11-02 2:20:14
Message-ID: 87po91776p.fsf () hobgoblin ! ariadne ! com
[Download RAW message or body]

Alex Balashov <abalashov@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
[prev in list] [next in list] [prev in thread] [next in thread]