Hi Alex,

IMO, building logic into the proxy which encourages/mends the proper sequencing of UDP messages does nothing more than to hide the underlying problem, i.e. "UDP does not guarantee message sequencing in the first place" *. There is also a subtle point to be made here: your proxy's loosely coupled/parallelized way of handling the two transactions is effectively breaking the RFC some % of the time, since the proxy's TU is generating a new INVITE while another INVITE transaction is in progress (strictly judging by the network timestamps).

* From this angle, the only sane thing left to do is to have the proxy retry the re-INVITE for UASs who are properly responding with 491 and propagate any other 4xx/5xx error replies back to the UAC (UA B in our case) in the hope that they retry their re-INVITE.

Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 30.10.2017 19:11, Alex Balashov wrote:
Hi,

I've got a scenario like so:

    UA A -----> Proxy P ----> UA B

1. UA A initiates call through Proxy P;

2. Dialog is established and confirmed, with Record-Route;

3. UA B sends reinvite #1 through P to A;

4. UA B sends 2xx reply;

5. UA B sends end-to-end ACK for reinvite #1 and almost
    simultaneously sends reinvite #2. The temporal delta is
    between reinvite #2 and ACK for reinvite #1 on the wire
    is 3 ms.

The issue is that the concurrency characteristics of proxy P are such
that its worker threads are very loosely coupled, and there's no
synchronisation among them for message ordering. Transport is UDP,
naturally.

So, the result — for all kinds of stochastic processing and userspace
scheduling type reasons — is that the reinvite is forwarded first,
before the ACK.  That leads to a 500 / 491 scenario UA A.

Is there any general guidance on what to do with these scenarios? I
looked at RFC 5407 § 3.1.4, which appears to describe a similar, but not
identical scenario involving an initial INVITE and subsequent reinvite.
As far as I can tell, the recommendation in that standard is "space the
messaging out more in time".

Switching to TCP would presumably help, since any given flow would
involve a single connection to a single worker thread and the transport
would guarantee ordering. However, that's not really feasible in this
implementation for a host of reasons.

Any other thoughts welcome!

Cheers,

-- Alex


_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to