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
