Asterisk 为 Chrome WebRTC 提供“严格 RTP 学习”消息并且没有音频，但在 Firefox 中有效

【问题标题】：Asterisk gives "Strict RTP learning" message and no audio for Chrome WebRTC but works in FirefoxAsterisk 为 Chrome WebRTC 提供“严格 RTP 学习”消息并且没有音频，但在 Firefox 中有效
【发布时间】：2018-04-05 22:56:11
【问题描述】：

我一直在与我的计算机在同一 LAN 上使用 Asterisk 服务器 (v13.18) 试验 WebRTC。我将 Asterisk 扩展 6003 配置为在拨号时自动应答并播放某个臭名昭著的声音文件，然后确认这适用于 Ekiga 软电话客户端。

然后我可以通过以下步骤在 Firefox 中正常工作：

  • 开通在线演示站点https://www.doubango.org/sipml5/call.htm?svn=252
  • 打开专家模式屏幕
  • 选中“禁用视频”复选框。
  • 在“ICE 服务器”字段中输入 []（因为我在本地 LAN 上，不涉及 NAT，我不需要 STUN 或 TURN，尽管我在 Asterisk 配置中启用了 ICE）李>
  • 输入了我的“Websocket 服务器 URL”值wss://asterisk-ci.test:8089/ws
  • 点击保存，然后返回演示页面。
  • 在演示页面的“注册”部分输入星号服务器信息并单击“登录”，确认显示状态为“已连接”。
  • 在“呼叫控制”框中输入分机号6003，点击“呼叫”。

在 Firefox 中这很有效 - 声音文件通过通话播放给我。

在 Google Chrome（最新 v65）中，实际上没有声音播放，但除此之外，一切似乎都应该正常工作。特别是：

  • sipML5 客户端显示“通话中”，UI 显示通话处于活动状态。
  • Javascript 控制台中没有错误。
  • “网络”选项卡中的 Websocket 帧中的 SIP 流量看起来不错，似乎与 Firefox 正在执行的操作相匹配。
  • chrome://webrtc-internals 页面表明有大量流量进入。特别是，音频通道上的数据图表与此处显示的声音文件一致。

我尝试使用SIP.js 设置示例应用程序并得到完全相同的结果，确认这不是sipML5 的问题，而是我的Asterisk 配置以及它如何与Google Chrome 交互的问题。

我通过asterisk -vvvvvr 连接到 Asterisk 以查看可能会显示哪些调试消息，并且工作的 Firefox 和不工作的 Chrome 之间似乎确实存在一些显着差异。以下是我在 Firefox 中连接然后拨打电话时看到的内容：

== WebSocket connection from '192.168.99.123:40190' for protocol 'sip' accepted using version '13'
  -- Registered SIP '1061' at 192.168.99.123:40190
== DTLS ECDH initialized (automatic), faster PFS enabled
== Using SIP RTP CoS mark 5
     > 0x7f79f800dba0 -- Strict RTP learning after remote address set to: 192.168.99.123:32807
  -- Executing [6003@users:1] Answer("SIP/1061-00000007", "") in new stack
     > 0x7f79f800dba0 -- Strict RTP learning after ICE completion
     > 0x7f79f800dba0 -- Strict RTP switching to RTP target address 192.168.99.123:32807 as source
  -- Executing [6003@users:2] Playback("SIP/1061-00000007", "auto-playback") in new stack
  -- <SIP/1061-00000007> Playing 'auto-playback.slin' (language 'en')
     > 0x7f79f800dba0 -- Strict RTP learning complete - Locking on source address 192.168.99.123:32807
  -- Executing [6003@users:3] Hangup("SIP/1061-00000006", "") in new stack

但是当我在谷歌浏览器上连接时，我得到了一个非常不同的结果：

== WebSocket connection from '192.168.99.123:52868' for protocol 'sip' accepted using version '13'
  -- Registered SIP '1061' at 192.168.99.123:52868
== DTLS ECDH initialized (automatic), faster PFS enabled
== Using SIP RTP CoS mark 5
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 127.0.0.1:9
  -- Executing [6003@users:1] Answer("SIP/1061-00000008", "") in new stack
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303
  -- Executing [6003@users:2] Playback("SIP/1061-00000008", "auto-playback") in new stack
  -- <SIP/1061-00000008> Playing 'auto-playback.slin' (language 'en')
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303

然后消息0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303 在通话期间无限重复。

除了该消息重复之外，我注意到在 Firefox 上，原始的“严格 RTP 学习”消息具有正确的地址，而在 Google Chrome 上是 127.0.0.1:9。 127.0.0.1 和端口9 的使用都很有趣，尽管我不知道要做什么。谷歌浏览器是否会以与 Asterisk 混淆的方式隐藏您的 IP 地址？

有趣的是，当我使用 SIP.js 示例尝试相同的操作时，我得到完全相同的结果（在 Firefox 上工作，连接但在 Chrome 上没有声音）在 Asterisk 中具有相同的调试输出，除了初始地址是0.0.0.0:9 而不是 127.0.0.1:9。

尽管我不确定下一步要尝试什么，所以我们将不胜感激。

编辑：按照建议，我将发布 SDP 日志。以下是我为正常工作的 Firefox 获得的信息：

Local SDP (Offer)
v=0
o=mozilla...THIS_IS_SDPARTA-59.0.2 7697709853700369104 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 BD:03:D7:1A:FB:F7:A3:BE:D0:F9:22:65:80:7B:FE:78:1C:17:01:17:99:57:A4:40:49:0D:EF:AA:AA:91:63:2C
a=group:BUNDLE sdparta_0
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 52547 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 192.168.99.123
a=candidate:0 1 UDP 2122252543 192.168.99.123 52547 typ host
a=candidate:1 1 TCP 2105524479 192.168.99.123 9 typ host tcptype active
a=candidate:0 2 UDP 2122252542 192.168.99.123 33797 typ host
a=candidate:1 2 TCP 2105524478 192.168.99.123 9 typ host tcptype active
a=sendrecv
a=end-of-candidates
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:63350c71006d1daf78366efc8d05347f
a=ice-ufrag:e92ccf7b
a=mid:sdparta_0
a=msid:{8a0a921d-b591-41b5-94e7-647b9b40cd06} {78e4a3a8-628f-4e09-a05a-fa6edb3022be}
a=rtcp:33797 IN IP4 192.168.99.123
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:actpass
a=ssrc:1153204890 cname:{9de8930f-bf76-48e0-a9c9-4c15f6914409}
Remote SDP (Answer)
v=0
o=root 477460967 477460967 IN IP4 172.30.8.8
s=-
t=0 0
a=sendrecv
m=audio 18666 RTP/SAVPF 0 8 101
c=IN IP4 172.30.8.8
a=candidate:Hac1e0808 1 UDP 2130706431 172.30.8.8 18666 typ host
a=candidate:Hac1e0808 2 UDP 2130706430 172.30.8.8 18667 typ host
a=sendrecv
a=fingerprint:sha-256 75:D2:BE:77:B6:8E:1B:4E:F9:BF:FB:34:54:2D:05:31:F6:97:C5:34:F3:D9:65:BE:FC:C6:E4:5C:1A:5E:11:E7
a=fmtp:101 0-16
a=ice-pwd:1e0f3ac370cce57d7c978ecb57ae23d9
a=ice-ufrag:7189ea580175062f339a9fe84ed6ecae
a=maxptime:150
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:active

这是我从无法工作的 Chrome 中看到的，它看起来也像 SDP，但看起来与我大不相同，例如甚至在任何输出中都看不到我的 IP 地址：

> createOfferOnSuccess
type: offer, sdp: v=0
o=- 3202047122122577027 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:kQT+
a=ice-pwd:6BgMZ48o3m7PMPFXY7AZvfdb
a=ice-options:trickle
a=fingerprint:sha-256 59:9F:B3:53:89:64:3A:3F:03:1B:32:8F:97:9B:6E:A1:33:B8:05:DD:92:87:3C:1C:CA:A3:83:28:8D:2C:98:FE
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:3990625320 cname:R43Nh5Jptx9sDbOE
a=ssrc:3990625320 msid:C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU c42217e8-19c2-4d94-a392-d4166d00eb22
a=ssrc:3990625320 mslabel:C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU
a=ssrc:3990625320 label:c42217e8-19c2-4d94-a392-d4166d00eb22

> setLocalDescription
type: offer, sdp: v=0
o=- 3202047122122577027 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:kQT+
a=ice-pwd:6BgMZ48o3m7PMPFXY7AZvfdb
a=ice-options:trickle
a=fingerprint:sha-256 59:9F:B3:53:89:64:3A:3F:03:1B:32:8F:97:9B:6E:A1:33:B8:05:DD:92:87:3C:1C:CA:A3:83:28:8D:2C:98:FE
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:3990625320 cname:R43Nh5Jptx9sDbOE
a=ssrc:3990625320 msid:C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU c42217e8-19c2-4d94-a392-d4166d00eb22
a=ssrc:3990625320 mslabel:C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU
a=ssrc:3990625320 label:c42217e8-19c2-4d94-a392-d4166d00eb22

> setRemoteDescription
type: answer, sdp: v=0
o=root 2070370846 2070370846 IN IP4 172.30.8.8
s=Asterisk PBX certified/13.18-cert2
c=IN IP4 172.30.8.8
t=0 0
m=audio 13528 RTP/SAVPF 0 8 126
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=maxptime:150
a=ice-ufrag:4c551f814a951c5e6f74e5c225c5e160
a=ice-pwd:7877be1235781d443361467a70b33c12
a=candidate:Hac1e0808 1 UDP 2130706431 172.30.8.8 13528 typ host
a=candidate:Hac1e0808 2 UDP 2130706430 172.30.8.8 13529 typ host
a=connection:new
a=setup:active
a=fingerprint:SHA-256 75:D2:BE:77:B6:8E:1B:4E:F9:BF:FB:34:54:2D:05:31:F6:97:C5:34:F3:D9:65:BE:FC:C6:E4:5C:1A:5E:11:E7
a=rtcp-mux
a=sendrecv

如果有帮助，以下是设置通话和播放时记录的完整事件集：

addStream
createOffer
negotiationneeded
createOfferOnSuccess
setLocalDescription
signalingstatechange
setLocalDescriptionOnSuccess
icegatheringstatechange
icegatheringstatechange
setRemoteDescription
signalingstatechange
iceconnectionstatechange
onAddStream
setRemoteDescriptionOnSuccess

进一步编辑：在查看了一些 SDP docs 并查看了我自己的 SDP 日志之后，我看到的主要不同之处可能是 Firefox 工作的原因，而 Chrome 不是 Firefox 有这条线

c=IN IP4 192.168.99.123

这确实是我的 IP 地址，而 Chrome 有这条线

c=IN IP4 0.0.0.0

我尝试从终端运行 Chrome 以捕获打印到屏幕上的任何调试输出，除了我在 chrome://webrtc-internals 中看到的内容之外，我发现此消息每秒显示多次：

ERROR:dtlstransport.cc(557)] Jingle:DtlsTransport[audio|1|__]: Received non-DTLS packet before DTLS complete.

我已经阅读了许多有关该错误的 Google 搜索结果，但无法提出任何解决方法。但是，它似乎可能相关；如果一个或多个 UDP 数据包发送到错误的位置，那么即使大多数音频数据包被正确发送，它们也永远不会被解码，我们会看到大量数据进入但实际上没有音频被播放。这确实是我所看到的。

我会做更多的挖掘，看看我可以调整哪些设置以使 Chrome 发送与 Firefox 发送的相同类型的信息，或者让 Asterisk 为它们两者做正确的事情。与此同时，我正在就这个问题开一个赏金，因为任何额外的帮助和建议都将不胜感激。

【问题讨论】：

  • 提供 SDP（提议/回答）消息。您可以在 chrome://webrtc-internals 中挖掘更多内容
  • @Ajay：按照建议，我已编辑问题以包含 SDP 消息。工作的 Firefox 和不工作的 Chrome 日志之间存在显着差异，但不幸的是，我对 SDP 的了解不够，无法说出与实际问题相比哪些差异是显着的。
  • 几年前的帖子，不确定是否有帮助3cx.com/community/threads/webrtc-no-audio.40818

标签： google-chrome webrtc asterisk sip


【解决方案1】：

清除您的 Chrome 缓存，特别是 cookie 和缓存文件。

转到chrome://net-internals/#dns

点击清除主机缓存

如检查DNS预取是否禁用chrome://dns

如果未禁用 DNS 预取 => 您可以查看表格。

并重新启动 chrome。

dns-prefetching

【讨论】：

  • 我试过了，很遗憾得到了同样的结果，但感谢您的建议！我也很高兴知道清除 Chrome 的 DNS 缓存的功能，这是我以前不熟悉的。
【解决方案2】：

我观察到的唯一区别是 Strict RTP learning complete 发生在 chrome 上。
并且 chrome Offer 中没有候选人，所以问题可能在ICE Candidates Negotiation。没有网络嗅探器，识别问题有点困难。

在此处阅读 SDP 基础知识：https://webrtchacks.com/sdp-anatomy/

尝试使用 strictrtp 模式。
ice_support=是
rtcp_mux=是

【讨论】：

  • 感谢您的建议。不幸的是，当我运行这些测试并发布结果时，我已经配置了ice_support=yes 和rtcp_mux=yes。我将从您提供的链接开始阅读 SDP，看看它是否能说明正在发生的事情。
【解决方案3】：

可能是 chrome 忽略了您的本地主机，如果您在 ubuntu 中，这应该是 /etc/hosts 文件。

因此您的本地“asterisk-ci.test”域未解析为“192.168.99.123”。

尝试清除 chrome 的主机缓存：

  1. 在 chrome 浏览器中转到 chrome://net-internals/#dns
  2. 按清除主机缓存

要对此进行测试，请尝试“输入 wss://192.168.99.123:8089/ws 的“Websocket 服务器 URL”值”。所以你直接使用本地ip。

参考文献

Localhost not working in Chrome, 127.0.0.1 does work

Why is Chromium bypassing /etc/hosts and dnsmasq

编辑：还可以通过访问 chrome 中的“chrome://net-internals/#sockets”并单击“Flush Socket Pools”来清除套接字池。

how to clear dns cache in chrome

您也可以尝试在 Chrome 的高级偏好设置中关闭“保护您和您的设备免受危险网站的侵害”。(answer at su stackexchange)

【讨论】：

  • 有趣，我不知道 Chrome 会这样做。然而，看起来这不是问题——因为它碰巧我们的公司 DNS 实际上解析了.test 域扩展名，所以这对我来说实际上是一个“有效”域，而不是我刚刚放入我的 /etc/hosts 文件的东西。不过感谢您的提示 - 我肯定刚刚学到了有关 Chrome 的新知识！
  • @EliCourtwright 我不确定这是否有帮助，但这不仅适用于本地主机，也适用于公司 DNS 域。您可以尝试一下并清除主机数据。
  • 感谢您的额外建议，但我尝试了并得到了相同的结果。唉!我们公司有一些人比我更了解 Asterisk，所以希望他们能看一看，看看他们能找到什么。
猜你喜欢
  • 1970-01-01
  • 2014-12-08
  • 1970-01-01
  • 2023-03-12
  • 2021-12-16
  • 2016-04-04
  • 2011-08-11
  • 1970-01-01
  • 2020-09-05
相关资源
最近更新 更多
热门标签
Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode