> It doesn’t appear to have a negative effect on the ongoing call; The SIP channel closed. RTP continues to flow. Therefore, the call itself stays up but you cannot send any SIP messages anymore.
In Asterisk, the channel driver chan_sip and its SIP-over-TLS is used by many folks out there, including me and even big(ger) VoIP/SIP service providers. I would not switch to chan_pjsip, instead I would analyze this issue. If I understand it correctly, your Asterisk is the TLS client, connected to some TLS server not in your control. Correct? Just for your information: That particular message happens on debug level 2, if you like to reduce your console output. However, the best would be a Wireshark log with a filter on 'ssl' and/or 'tcp.port == 5061'. Furthermore, the cause of the problem could be your remote party. Actually, that is very likely. If possible team up with them and capture logs on the TCP layer there as well. Only they are able to see the packets decrypted because it is their server certificate/private key. > From a developer perspective, what Asterisk conditions would cause this error > to trigger? Could be anything, even a firewall or intrusion detection system which is wrongly configured at the remote party. Sorry. If you look for a nudge (beside the tips above), have a look at the SIP traffic on the command-line interface (sip set debug on): Is there any SIP session timer that low, or SIP re-registration that low, or is your Asterisk sending some other SIP message again and again. -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
