Keep incoming connection from timing out in Asterisk

Asterisk Asterisk SIP
1

A SIP trunk is configured between Genesys cloud and Asterisk version 20. We manage asterisk and the transport is set to TLS.
Genesys cloud establish a new connection with SIP over TLS and when the call is in progress via UDP the TLS session gets terminated after 120 seconds. (since the SIP invite). During this period there is no SIP requests being sent by Genesys to asterisk and hence the TLS session is consider idle.

As a result when the call complete the transfer is failing as asterisk is unable to send SIP REFER and the original connection used when establishing the invite is closed.

Is it possible to send periodic SIP messages from Asterisk (Invite, notify, info etc) over the TLS session that was established for incoming connection to keep alive?

Is is possible to configure the dial plan transfer to create a new TLS session to Genesys cloud?

Appreciate any pointers
Thank you

2

120 seconds is a bit short for session timers, but still in range, so enable session timers.

However something else is wrong if you cannot establish a connection for the REFER (or that matter, the BYE). They may be sending a bad Contact header (which can include sending one with an IP address, when their certificate gives a domain name. as has been reported in relation to a couple of providers, recently - this only causes problems if you configure to verify the server, which would normally be good practice).

3

Thank you for the reply,
below is the error when Asterisk is attempting to send REFER back. This is only when the call duration is greater than 120 seconds.

– Auto fallthrough, channel ‘’ status is ‘UNKNOWN’

  • ERROR[3242815][C-00000162]: chan_sip.c:4356 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data*

Am I to take it Asterisk by default will be able to send REFER using new TLS session if the session used for receiving the invite is closed?

4

That’s what should happen.

Note that chan_sip is no longer supported, and any bugs in it will not be fixed.

5

We have looked at the packet capture to identify the attempt from asterisk to create a new TLS connection to send REFER, we don’t see any. Is this controlled by some config parameter in sip.conf?

Secondly,

  1. The TLS connection established to send SIP invite has the ip_1 as ‘From’ and the contact header exists but it’s different ip (ip_2).

  2. Asterisk is attempting to send REFER as below

*Reliably Transmitting (NAT) to ip_1:50723:*
*REFER sip:abc@ip_2:6060;did=601.febda8d SIP/2.0*
*Via: SIP/2.0/TLS <source_ip>:5061;branch=z9hG4bK08186aa7;rport*
*Route: <sip:ip_1:5061;r2=on;transport=tls;ftag=yHpoyso;lr>*

Should we expect asterisk to establish the connection using ip_2?

6

The address in the first Route header, given that it is using loose routing, including the port number.

https://www.rfc-editor.org/rfc/rfc3261.html#section-8.1.2

7

Any insights on this?

We have looked at the packet capture to identify the attempt from asterisk to create a new TLS connection to send REFER, we don’t see any. Is this controlled by some config parameter in sip.conf?

8

Knowledge of chan_sip has largely died out here. It may well be a bug, but if so, the fix will be to use chan_pjsip.

I suspect the incoming connection wasn’t closed cleanly, but I don’t think it should be trying to use that in the first place. Very few people use the Transfer application, so you may have an accumulation of unusual factors here.

9

There does seem to be a mechanism for reusing an incoming TLS connection, but it requires special options, and when it is used, the connection should not be be being dropped quickly. One would need to see the incoming INVITE to know if that option was being used. See RFC 5923.

I don’t know if Asterisk supports it. I can’t find anything in the chan_sip source code that suggests it does. There are also no likely hits in chan_pjsip, and a weaker search for pjproject hits doesn’t suggest support.

10

Thank you @david551 for the guidance. As stated, we were not able to identify any options that can be set so that Asterisk can create a new TLS session to send REFER based on the incoming invite.

We worked around this by setting the “session-expires” to a lower value, this forced Asterisk to send periodic SIP INVITE (re-invite) using the same TLS session to Genesys cloud before it gets terminated.