1

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?

Logs found here

Thanks!

Gal Goffer
  • 43
  • 4
  • 1
    That is certainly unsual. could you please attach server.log? (Please set JAINSIP and SipServlet log level to DEBUG) – Jaime Casero May 18 '16 at 07:36
  • Thanks for commenting @Jaime . Added the logs to the original post. – Gal Goffer May 18 '16 at 12:17
  • 1
    I can see an INVITE coming with callID:1-14218@172.20.22.20. The invite is rejected with 500(Call blocked due to non-GNF destination number). Is this the scenario you mentioned originally? – Jaime Casero May 19 '16 at 11:59
  • Yes, that's the one. I expected a retransmit of the 500 since no ACK was received. – Gal Goffer May 22 '16 at 11:28

2 Answers2

0

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).

Mike Dirlek
  • 11
  • 1
  • We work in UDP, but it does not seem like that was the actual issue in this case - it turns out we terminated the leg immediately after sending the 500 message so mobicents did not in fact have a session with which to work. – Gal Goffer Jun 19 '16 at 14:14
0

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.

Gal Goffer
  • 43
  • 4