Chan_pjsip + tls/srtp gives unexpected tcp port closure (and/or crash)


I have a local Asterisk 13.9.1 build (using the bundled pjsip-2.4.5 + patches).

Environment is Centos 6.8 (64-bit) + Asterisk-13.9.1 + libsrtp-1.5.2.

Asterisk runs behind a NAT.

It registers with a remote SIP server over TLS using chan_pjsip. All outgoing/incoming pjsip call media is encrypted using SRTP.

Asterisk is also configured to use chan_sip to allow registrations from local sip clients. Local sip clients use TCP/RTP.

I use SIPp to run multiple concurrent loopback calls (calls vary in duration) through Asterisk to echo() running on the same asterisk). i.e. SIPp <-TCP/RTP-> chan_sip <-> chan_pjsip <-TLS/SRTP-> SIP server (+ rtpproxy) <-TLS/SRTP-> chan_pjsip (echo service).

If I run only 1 or 2 concurrent calls through SIPp + Asterisk all appears to work fine and SIPp completes as expected.
Individual calls from other local SIP clients to remote SIP clients work fine.
Individual calls from remote SIP clients to Asterisk echo() or local SIP clients also work fine.

However if I configure SIPp to run more concurrent calls (i.e. i’ve tried 5-20 => up to 40 pjsip channels + 20 sip channels) I usually see 1 of 2 scenarios:

  • Asterisk closes the current pjsip TCP port (Wireshark trace shows Asterisk issuing FIN, ACK) and then reopens another TLS connection (on another TCP port) to the SIP server. It then attempts to send further SIP INVITE’s out through this port. However Asterisk does not reregister with the SIP server before sending the INVITE’s so the SIP Server returns 477 to all future INVITE’s from Asterisk.

  • Asterisk crashes. When Asterisk crashes the last thing I see on the Wireshark trace is Asterisk issuing FIN + ACK on the TLS port to the SIP Server (together with the returned FIN + ACK and outgoing ACK).

n.b. In case it matters I’m currently building with DONT_OPTIMIZE & DEBUG_THREADS enabled.
n.n.b. I’ve tried varying pjsip keep_alive_interval and registration expiration times with no noticeable improvement.

So why might Asterisk be closing the current pjsip TCP port and trying to reopen a new one?

We’d need a console log and backtrace[1] to be able to determine what may be going on.