ssl - Asterisk :SIP 调用 120 秒后为 "TLS clean shutdown alert reading data"

Question

我正在使用 Twilio 提供的安全 SIP 中继来实现 IVR。我已经按照 Twilio 的 Asterisk 配置指南实现，将 SRTP 安装到/usr/local/lib，并在 https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial 中实现了配置。 .

问题在于任何超过 2 分钟的调用都无法干净地结束并导致 Asterisk 重新启动。

sip.conf(使用 chan_sip，而不是 pjsip):

[general]
; other configuration lines removed
tlsenable=yes
tlsbindaddr=0.0.0.0
tlscertfile=/etc/pki/tls/private/pbx.pem
tlscafile=/etc/pki/tls/private/gd_bundle-g2-g1.crt
tlscipher=ALL
tlsclientmethod=tlsv1 
tlsdontverifyserver=yes


[twilio-trunk](!)
type=peer
context=from-twilio ;Which dialplan to use for incoming calls
dtmfmode=rfc4733
canreinvite=no
insecure=port,invite
transport=tls
qualify=yes
encryption=yes
media_encryption=sdes

我可以很好地调用和接听电话，并且我已经确认电话已通过 wireshark 和来自 Twilio 自己的支持队列的确认进行了加密。

每次调用恰好 120 秒时，会弹出此调试信息:

[Dec 6 13:14:39] DEBUG[30015]: iostream.c:157 iostream_read: TLS clean shutdown alert reading data
[Dec 6 13:14:39] DEBUG[30015]: chan_sip.c:2905 sip_tcptls_read: SIP TCP/TLS server has shut down

调用继续双向流动，调用者永远不会知道有问题，直到他们在上下文中挂断，即 h,1,Hangup()。然后 Asterisk 重新启动(新的 PID)并且调用者在调用超时之前再挂起 5 分钟，然后快速忙。 Twilio 确认他们看到 BYE 并在挂断点返回 ACK。

我在 13.11 上更新到 15.1.3，结果相同。超过 120 秒的调用会导致调试中出现 TLS 消息并重新启动 Asterisk。

没有 Google 查询结果。 Twilio 并没有真正提供帮助。任何人都可以阐明正在发生的事情以及我接下来需要看的地方吗？

更多日志:

[Dec 8 10:18:48] DEBUG[4993][C-00000001]: channel.c:5551 set_format: Channel SIP/twilio0-00000000 setting write format path: gsm -> ulaw
[Dec 8 10:18:48] DEBUG[4993][C-00000001]: res_rtp_asterisk.c:4017 rtp_raw_write: Difference is 2472, ms is 329
[Dec 8 10:18:48] DEBUG[4993][C-00000001]: channel.c:3192 ast_settimeout_full: Scheduling timer at (50 requested / 50 actual) timer ticks per second
– <SIP/twilio0-00000000> Playing ‘IVR/omnicare_9d_account.gsm’ (language ‘en’)
[Dec 8 10:18:48] DEBUG[4993][C-00000001]: res_rtp_asterisk.c:4928 ast_rtcp_interpret: Got RTCP report of 64 bytes from 34.203.250.7:10475
[Dec 8 10:18:53] DEBUG[4993][C-00000001]: res_rtp_asterisk.c:4928 ast_rtcp_interpret: Got RTCP report of 64 bytes from 34.203.250.7:10475
[Dec 8 10:18:55] DEBUG[4992]: iostream.c:157 iostream_read: TLS clean shutdown alert reading data
[Dec 8 10:18:55] DEBUG[4992]: chan_sip.c:2905 sip_tcptls_read: SIP TCP/TLS server has shut down
[Dec 8 10:18:58] DEBUG[4993][C-00000001]: channel.c:3192 ast_settimeout_full: Scheduling timer at (0 requested / 0 actual) timer ticks per second
[Dec 8 10:18:58] DEBUG[4993][C-00000001]: channel.c:3192 ast_settimeout_full: Scheduling timer at (0 requested / 0 actual) timer ticks per second
[Dec 8 10:18:58] DEBUG[4993][C-00000001]: channel.c:3192 ast_settimeout_full: Scheduling timer at (0 requested / 0 actual) timer ticks per second
[Dec 8 10:18:58] DEBUG[4993][C-00000001]: channel.c:5551 set_format: Channel SIP/twilio0-00000000 setting write format path: ulaw -> ulaw
[Dec 8 10:18:58] DEBUG[4993][C-00000001]: res_rtp_asterisk.c:4928 ast_rtcp_interpret: Got RTCP report of 64 bytes from 34.203.250.7:10475
[Dec 8 10:19:01] DEBUG[4914]: cdr.c:4305 ast_cdr_engine_term: CDR Engine termination request received; waiting on messages…
Asterisk uncleanly ending (0).
Executing last minute cleanups
== Destroying musiconhold processes
[Dec 8 10:19:01] DEBUG[4914]: res_musiconhold.c:1627 moh_class_destructor: Destroying MOH class ‘default’
[Dec 8 10:19:01] DEBUG[4914]: cdr.c:1289 cdr_object_finalize: Finalized CDR for SIP/twilio0-00000000 - start 1512749813.880448 answer 1512749813.881198 end 1512749941.201797 dispo ANSWERED
== Manager unregistered action DBGet
== Manager unregistered action DBPut
== Manager unregistered action DBDel
== Manager unregistered action DBDelTree
[Dec 8 10:19:01] DEBUG[4914]: asterisk.c:2157 really_quit: Asterisk ending (0).

Answer 1

检查您的防火墙日志。我们遇到过 session 被认为 NAT 条目陈旧/陈旧的防火墙拆除的问题。

您还可以尝试使用选项 qualify=yes 将 Asterisk 配置为发送保持事件的数据包。和 nat=yes在该用户/中继的 sip.conf 条目中。或者在 RTP 流中使用 rtpkeepalive=<secs> .我能找到的关于 sip.conf 的最佳文档是 github 上的示例配置.

我挖了the source code对于文本“TLS clean shutdown alert reading data”，它指向我some OpenSSL docs这表明一个干净/正常的关闭(我猜这是由你的防火墙引起的):

The TLS/SSL connection has been closed. If the protocol version is SSL 3.0 or higher, this result code is returned only if a closure alert has occurred in the protocol, i.e. if the connection has been closed cleanly. Note that in this case SSL_ERROR_ZERO_RETURN does not necessarily indicate that the underlying transport has been closed.