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

Daniel-Constantin Mierla miconda at gmail.com
Wed Apr 8 19:39:56 CEST 2020


On 08.04.20 18:30, Greg Troxel wrote:
> 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.

SIP is designed to deal (pretty well) with packets received not in the
same order as they were sent.

If it is a request with a lower CSeq than a previously received one, it
has to ignore it and send a 500 response.

The responses for the active transaction (matching the cseq of the
request that created the transactions), the response codes have a
priority "rank". 200ok is the highest priority in the way that if a 1xx
or [3456]xx is received after it, just discard it.

The ACK-reINVITE seems to be the one that creates the most of the
troubles, from my experience. A SIP proxy or a server cannot do much
here, because even it can process sequentially, the re-ordering can
still happen on the network (before or after it). The clients have the
mechanisms in the SIP specs to implement it somehow nice, but I haven't
seen it in reality. The receiver of the reINVITE before the ACK can
reject it with a Retry-After header. But I bet that the (most of) sender
will tear down the call if the reINVITE is not getting a 200ok. As I
remember now, I haven't seen it written explicitly in the RFCs (at least
those from the early years of SIP, may be in the new ones that update
some specs), but it is legit to reject a request and ask to be resent
later, without considering it a complete failure.

Cheers,
Daniel


-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda




More information about the sr-users mailing list