[SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

[Greg Troxel]

Alex Balashov <abalashov at evaristesys.com> writes:

> On Wed, Apr 08, 2020 at 04:54:48PM +0100, David Villasmil wrote:
>
>> I have a question on this, since 180 arrived before the 200, shouldn’t it
>> go out before? I.e.: FIFO? Or is this not happening because there are
>> multiple processes and one may take the 180 and the other the 200 and they
>> are processes independently?
>> 
>> I guess setting the childs to only 1 should prove this theory.
>
> In theory, it should all be FIFO, of course. In practice, there are
> stochastic aspects to OS process scheduling and I/O scheduling which
> make the ingress and egress of messages arriving at Kamailio
> simultaneously or substantially simultaneously somewhat indeterminate.

I don't see this as being about the nature of parallel processing.

Either the protocol specifications have ordering rules (in which case an
implementation which does not follow those is defective), or they do not
have ordering rules (in which case an implementation that is troubled by
lack of ordering is defective).

There is a messy middle ground of course, where significant misordering
is inefficient.  An example is the transport of IP packets.  TCP can
deal with misordered packets, but this ends up not so efficient.  So
there is a notion that a system that causes frequent or gross
misordering is not as good as one that doesn't.  Compare to ATM, where
cells may not be reordered at all -- this is a major burden on
implementers.

I am curious which situation we are discussing here.  Given that SIP can
use UDP, which has no ordering guarantees, it would be surprising if an
endpoint can expect ordering of any messages.