On 10/31/17 8:44 AM, Liviu Chircu wrote:
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).
One can argue that the proxy is doing nothing wrong and perhaps being
helpful by exposing bugs in handling of reordered UDP messages.
Thanks,
Paul
* 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
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
