You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
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.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.