SIP TLS connection drops after few seconds

We have an asterisk server configured with SIP TLS. We have a SIP TLS connection established with a client end and after few seconds server sends FIN to end the session and connection resets.
Attached is the wireshark snapshots and [general] configuration from sip.conf. So,

  1. what could be tried or looked (as due to TLS it is not clear what is breaking this).

There is a limitation that, client could not use registration and so need to be an IP based trunk. Also, this IP addresses is not having DNS and instead range of IP addresses so there is no peer definition in sip.conf. 2) Is there a way to define peer based on range of IP address instead of single host IP or DNS ?


You should be using chan_pjsip, which can match on address ranges.

I presume you are relying on allowguest defaulting to to yes. In that case you are open to UDP and TCP traffic from the world.

Where in chan_pjsip, I can use address range.

I have following configured for a peer but if I want to do for a range (ie then which sections would need to be configured with range?

type = aor
contact = sip:

type = identify
endpoint = 192_168_1_28
match =

type = endpoint
context = outbound
disallow = all
allow = alaw
allow = ulaw
direct_media = no
aors = 192_168_1_28

I presume you are relying on allowguest defaulting to to yes. In that case you are open to UDP and TCP traffic from the world.
=> Yes, we have restricted only to IP ranges at firewall so though it is open in asterisk, it is restricted to certain ranges only.

You specify what you have to match to identify the UAC.

Thanks for the suggestion. We configured it with pjsip and It is still giving the issue with below loglines shows up in console. What might be causing this?

: res_pjsip/pjsip_transport_management.c:170 idle_sched_cb: Shutting down transport ‘TLS to xx.xx.xx.xx:32784’ since no request was received in 32 seconds

type = aor

type = identify
endpoint = xx_xx_72_0
match = xx.xx.72.0/24

type = endpoint
context = sipout
disallow = all
allow = alaw
allow = ulaw
aors = xx_xx_72_0

This is not an error, in itself. The message is fairly self explanatory.

It shows the transport is shutdown due to no request(data) received within 30 seconds
Shutting down transport ‘TLS to xx.xx.xx.xx:32784’ since no request was received in 32 seconds
but as can be seen from the capture that some requests comes from remote end to asterisk ( and ACK sent by asterisk. However, soon after this it sends out FIN to end session.
So, what exactly asterisk expecting and why it tears down TLS connection?

Maybe try this in pjsip.conf:


You can see in your trace that the TCP ACK is being retransmitted back to the Asterisk server. Do you have a firewall in the middle there that could be blocking traffic?

thanks for suggesting the setting. I have tried but doesn`t make any difference.

The capture doesn`t show initial 3 way handshake (ie SYN, SYNACK, ACK). That is properly established and then client and server TLS negotiation done properly and TLS connection established.

However, as seen in capture, after around 30 seconds of established connection, remote end sends some packets [probably keep alive but as encrypted packet it can not be confirmed] which is ACK by Asterisk []. However, soon after this, asterisk sends FIN to remote client to end TLS connection. The asterisk is behind NAT and firewall but the issue is not with initial connection but some packet exchange happens at around 30 seconds after connection and need to understand what is causing it and any work around to address it.

Are you 100% sure that the TLS handshake successfully completed earlier in the trace?

A simple way to verify what the problem is would be to set this up using UDP initially. If the call succeeds over UDP but fails over TLS, then the TLS configuration is going to be the problem. If the call exhibits similar behavior over UDP, then the Asterisk endpoint configuration would be to blame.

1 Like

From capture , it looks like so,

It would help if you provided the Asterisk (decrypted) protocol trace for the same time period.

However, I would note that the size of the application data received in the last 30 seconds is far too short to have contained a SIP request or response.

PS apologies for pasting a completely irrelevant URL by mistake, earlier.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.