为什么 Asterisk 17 没有捕捉到来自 PJSIP 客户端的挂断请求？ [解决了]

Question

我希望用 Asterisk 17 替换我的旧 Asterisk 15 VoIP 服务器。目前我有一个应用程序可以通过 ARI（即 Asterisk Rest 接口）+ WS（用于事件）与 Asterisk 一起工作。在我当前的版本中，一切正常，但在将我的应用程序连接到 Asterisk 17 后，它没有及时收到 ChannelHangupRequest 事件和以下事件（即仅在 ~30 秒后）。所以我决定查看 Asterisk 日志，我发现：

1. 问题不是我的应用引起的
2. 如我之前所说，ChannelHangupRequest 事件在大约 30-50 秒后发送。有趣的是它的 cause 等于 1 并且有一个字段 soft 等于 true。您可以在下面看到 JSON 格式的事件。 Official Asterisk 17 documentation does not give an obvious description for it or at least it is not obvious to me: From soft: boolean (optional) - Whether the hangup request was a soft hangup request. Also, official hangup cause mappings表示1映射到AST_CAUSE_UNALLOCATED。在我的旧版本（即 Asterisk 15）上，事件立即触发，case 等于 16 = AST_CAUSE_NORMAL_CLEARING.

<{"cause":1,"soft":true,"type":"ChannelHangupRequest","timestamp":"2021-03-23T17:10:19.817+0000","channel":{"id":"1616519370.38","name":"PJSIP/1000-00000026","state":"Up","caller":{"name":"Cristi","number":"1000"},"connected":{"name":"","number":""},"accountcode":"","dialplan":{"context":"from-internal","exten":"s","priority":1,"app_name":"Stasis","app_data":"my-app"},"creationtime":"2021-03-23T17:09:30.364+0000","language":"en"},"asterisk_id":"02:42:ac:13:00:03","application":"my-app"} < {"type":"StasisEnd","timestamp":"2021-03-23T17:10:19.817+0000","channel":{"id":"1616519370.38","name":"PJSIP/1000-00000026","state":"Up","caller":{"name":"Cristi","number":"1000"},"connected":{"name":"","number":""},"accountcode":"","dialplan":{"context":"from-internal","exten":"s","priority":1,"app_name":"Stasis","app_data":"my-app"},"creationtime":"2021-03-23T17:09:30.364+0000","language":"en"},"asterisk_id":"02:42:ac:13:00:03","application":"my-app"}

3. Asterisk 日志显示频道已断开连接 for lack of audio RTP activity in 49 seconds。它在某种程度上解释了行为，具体来说，它解释了 ChannelHangupRequest 事件的来源（约 50 秒后），但它没有解释为什么它在用户挂断后不能立即正确发送。

13373[2021-03-23 17:09:28] VERBOSE[6273] stasis/app.c: Creating Stasis app 'my-app' 13374[2021-03-23 17:09:28] VERBOSE[6273] res_http_websocket.c: WebSocket connection from '172.19.0.1:54308' for protocol '' accepted using version '13' 13375[2021-03-23 17:09:29] VERBOSE[6276] stasis/app.c: Replacing Stasis app 'my-app' 13376[2021-03-23 17:09:29] VERBOSE[6276] res_http_websocket.c: WebSocket connection from '172.19.0.1:54312' for protocol '' accepted using version '13' 13377[2021-03-23 17:09:30] VERBOSE[6278] stasis/app.c: Replacing Stasis app 'my-app' 13378[2021-03-23 17:09:30] VERBOSE[6278] res_http_websocket.c: WebSocket connection from '172.19.0.1:54322' for protocol '' accepted using version '13' 13379[2021-03-23 17:09:30] VERBOSE[6280] dial.c: Called 1000 13380[2021-03-23 17:09:30] VERBOSE[1601] netsock2.c: Using SIP RTP Audio TOS bits 184 13381[2021-03-23 17:09:30] VERBOSE[1601] netsock2.c: Using SIP RTP Audio TOS bits 184 in TCLASS field. 13382[2021-03-23 17:09:30] VERBOSE[1601] netsock2.c: Using SIP RTP Audio CoS mark 5 13383[2021-03-23 17:09:30] VERBOSE[6280] dial.c: PJSIP/1000-00000026 is ringing 13384[2021-03-23 17:09:30] VERBOSE[6280] dial.c: PJSIP/1000-00000026 is ringing 13385[2021-03-23 17:09:44] VERBOSE[6276] res_http_websocket.c: WebSocket connection from '172.19.0.1:54312' closed 13386[2021-03-23 17:09:45] VERBOSE[6282] stasis/app.c: Replacing Stasis app 'my-app' 13387[2021-03-23 17:09:45] VERBOSE[6282] res_http_websocket.c: WebSocket connection from '172.19.0.1:54334' for protocol '' accepted using version '13' 13388[2021-03-23 17:09:49] VERBOSE[1601] res_rtp_asterisk.c: 0x7f8c1c02bf90 -- Strict RTP learning after remote address set to: 192.168.10.172:10096 13389[2021-03-23 17:09:49] VERBOSE[6280] dial.c: PJSIP/1000-00000026 answered 13390[2021-03-23 17:09:49] WARNING[1601] channel.c: Unable to find a codec translation path: (ulaw) -> (g723) 13391[2021-03-23 17:09:49] WARNING[1601] channel.c: Unable to find a codec translation path: (g723) -> (ulaw) 13392[2021-03-23 17:09:49] VERBOSE[6280] ari/resource_channels.c: Launching Stasis(my-app) on PJSIP/1000-00000026 13393[2021-03-23 17:10:19] NOTICE[1108] res_pjsip_sdp_rtp.c: Disconnecting channel 'PJSIP/1000-00000026' for lack of audio RTP activity in 49 seconds

4. 上述行为仅适用于用户回答然后挂断的情况。如果用户拒绝接听电话，一切正常。

一种解决方案是减少 RTP 不活动超时作为变通方法，但这不是可取的。你有什么建议吗？

Answer 1

已解决。问题出在我的防火墙配置中。测试环境没有正确配置，因此一些数据包在到达 Asterisk 之前就被丢弃了。所以，Asterisk 本身没有问题。