Hi Henning,
I was testing 5.4.2 but I ended up going back as far a May 3.
While trying to reproduce I just noticed that now I see 300-400ms to relay the ACK. (not enough to trigger a re-transmission anymore)
- First INVITE and BYE are relayed in 1ms. - When I rollback the commit the ACK is also relayed in 1ms. - The same problem is found on another gitlab runner test box and the delay seems to be worst.
- No NAPTR resolution should be needed since the RURI is an IP.
``` 2020/10/30 03:02:48.442251 192.0.2.23:5060 -> 192.0.2.24:5060 ACK sip:192.0.2.2:5060 SIP/2.0 Record-Route: sip:192.0.2.23;lr Via: SIP/2.0/UDP 192.0.2.23:5060;branch=z9hG4bKa37.abcde5432ec8393b4ab82cf54fa2d04a.0 Via: SIP/2.0/UDP 192.0.2.7:5777;received=192.0.2.7;rport=5777;branch=z9hG4bKPj0bd8b830-4a10-467a-9984-3a8dceb15141 Max-Forwards: 69 From: sip:4468246@fakecustomer.xyz;tag=5f1e815a-3786-499a-ba48-6b1dfde0544d To: sip:+11234567890@proxy1;tag=778aaba7-ab0e-4a60-9596-65d28d86a43e Call-ID: a7319394-6352-4465-b673-d49ea8de8190 CSeq: 10636 ACK Route: sip:192.0.2.24;lr Content-Length: 0 ```
It seems it is reproducible as it is always adding a significant delay, sometimes triggering a 200 OK re-transmission. Not sure if it may be more complicated to reproduce due to config params. I will not be able to debug to confirm more into details until next Wednesday.