星号:" TLS清理关机提醒读取数据"在SIP呼叫120s后

时间:2017-12-12 03:34:24

标签: ssl twilio asterisk sip

我正在使用Twilio提供的Secure 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并在Hangup点返回了一个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).

1 个答案:

答案 0 :(得分:0)

检查防火墙日志。我们遇到的问题是防火墙拆除会话,认为NAT条目已过时/过时。

您还可以尝试使用 sip.conf 条目中的用户/主干的qualify=yesnat=yes选项配置Asterisk以发送保持活动数据包。或者在rtpkeepalive=<secs>的RTP流中。我能为sip.conf找到的最好的文档是github上的示例配置。

我在the source code中搜索了文本&#34; TLS清理关闭警报读取数据&#34;,它向我指出some OpenSSL docs表明清洁/正常关闭(我在其中)猜测是由你的防火墙造成的):

  

TLS / SSL连接已关闭。如果协议版本是SSL 3.0或更高版本,则仅当协议中出现关闭警报时才返回此结果代码,即,如果连接已完全关闭。请注意,在这种情况下,SSL_ERROR_ZERO_RETURN不一定表示基础传输已关闭。