We have a situation where a UAC sends an INVITE to the server, and the server responds with 3xx-6xx. If the UAC does not send an ACK on this response - there is no retransmission.
According to RFC3261 (https://www.ietf.org/rfc/rfc3261.txt) if no ACK was received then the underlying stack should retransmit the response.
Our setup is a Linux workstation with MSS-tomcat (mobicents 8, tomcat 8).
Has anybody encountered this before?
Thanks!
On
Found the source of the issue: It turns out that after the 500 message was dispatched, we terminated the Leg applicatively. This resulted in the sip-stack not having a valid session to return to, and consequently it was unaware of whether or not ACK was received at all.
Note: when we worked with WebSphere sip-stack, the stack would simply disregard the application's request to terminate the leg in this case, and delay it until after an ACK was received or the retransmissions timed-out.
If the sip signaling for the call is over tcp (instead of udp) there will not be any retransmission of the error response since the reliability is handled by the underlying transport.
Note however that this is not true for 200 response to invite since ACK for 2xx isn't hop-by-hop and might take a different path in the network compared to the response (some proxys might have been using udp where the 200 could have gotten lost).