google-chrome - Asterisk 提供 "Strict RTP learning"消息，但Chrome WebRTC没有音频，但可在Firefox中使用

Question

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

然后，我可以通过以下步骤在Firefox中正常运行:

打开在线演示站点https://www.doubango.org/sipml5/call.htm?svn=252

打开专家模式屏幕

选中“禁用视频”复选框。

在“ICE服务器”字段中输入[](因为我位于不涉及NAT的本地局域网中，所以我不需要STUN或TURN，尽管我在Asterisk配置中确实启用了ICE)

输入了wss://asterisk-ci.test:8089/ws的“Websocket服务器URL”值

单击“保存”，然后返回到演示页面。

在演示页面的“注册”部分输入 Asterisk 服务器信息，然后单击“登录”，确认它随后显示为“已连接”状态。

在“调用控制”框中输入扩展名6003，然后单击“调用”。

在Firefox中，这种方法效果很好-声音文件会通过电话回放给我。

在Google Chrome浏览器(最新的v65)中，实际上没有声音播放，但除此之外，一切似乎都应该正常工作。特别是:

sipML5客户端显示“通话中”，并且UI显示通话处于事件状态。

Javascript控制台中没有错误。

“网络”选项卡中Websocket框架中的SIP流量看起来不错，并且似乎与Firefox的行为匹配。

chrome://webrtc-internals页面指示有大量流量进入。特别是，音频 channel 上的数据图显示与此处显示的声音文件一致。

我尝试使用 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

但在Google Chrome上进行连接时，得到的结果却截然不同:

== 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的使用都很有趣，尽管我不确定两者都该如何做。 Google Chrome浏览器是否以与Asterisk混淆的方式隐藏了您的IP地址？

有趣的是，当我使用SIP.js示例尝试相同的操作时，除初始地址为 0.0.0.0:9而不是初始地址外，我在Asterisk中得到的调试结果完全相同(在Firefox上运行，但在Chrome上没有声音) 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为它们两者做正确的事情。同时，由于这个问题我们将不胜感激，因此我将对此悬赏。

Answer 1

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

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


点击清除主机缓存

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

If DNS prefetching is not disabled => you can see tables.

并重新启动chrome。

dns-prefetching