Question

我在与计算机相同的局域网上使用Asterisk服务器（v13.18）尝试使用WebRTC。我将Asterisk扩展6003配置为在拨打时自动应答并播放某个臭名昭着的声音文件，然后确认这与Ekiga softphone客户端一起使用。

然后我可以通过以下步骤在Firefox中使用它：

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

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

在谷歌浏览器（最新的v65）中，没有声音实际播放，但除此之外，似乎应该有效。特别是：

sipML5客户端显示＆＃34; In Call＆＃34;并且UI显示正在激活的呼叫。
Javascript控制台中没有错误。
“网络”选项卡中Websocket框架中的SIP流量看起来很好，似乎与Firefox正在进行的操作相匹配。
chrome://webrtc-internals页面显示有大量流量进入。特别是，音频频道上的数据图表与此处显示的声音文件一致。

我尝试使用SIP.js设置示例应用，并得到完全相同的结果，确认这不是sipML5的问题，而是我的Asterisk配置及其如何与谷歌浏览器互动。

我通过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上，原始的＆＃34;严格的RTP学习＆＃34;邮件的地址正确，而在Google Chrome上则有127.0.0.1:9。 127.0.0.1和端口9的使用都很有趣，但我不知道该怎么做。 Google Chrome是否会以一种混乱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为这两种信息做正确的事情。与此同时，我在这个问题上打开了赏金，因为我们非常感谢任何额外的帮助和建议。

Answer 1

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

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

点击清除主机缓存

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

如果未禁用DNS预取=＆gt;你可以看到表格。

重新启动chrome。

dns-prefetching

Answer 2

我观察到的差异只是Strict RTP learning complete发生了铬并且chrome Offer中没有候选人，因此问题可能在ICE Candidates Negotiation。没有网络嗅探器，识别问题有点困难。

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

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

Answer 3

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

所以你的本地＆＃34; asterisk-ci.test ＆＃34;域名未解析为＆＃34; 192.168.99.123＆＃34;。

尝试清除chrome的主机缓存：

转到Chrome浏览器的chrome：// net-internals / #dns
按清除主机缓存

要对此进行测试，请尝试输入＆＃34; Websocket Server URL＆＃34;值wss：//192.168.99.123：8089 / ws＆＃34;。所以你直接使用本地ip。

参考

Localhost not working in Chrome, 127.0.0.1 does work

Why is Chromium bypassing /etc/hosts and dnsmasq

编辑：访问＆＃34; chrome：// net-internals / #sockets＆＃34;清除套接字池。在chrome中点击＆＃34; Flush Socket Pools＆＃34;。

how to clear dns cache in chrome

您也可以尝试关闭＆＃34;保护您和您的设备免受危险场所的影响＆＃34;在Chrome的高级偏好设置中。（answer at su stackexchange）

Asterisk提供严格的RTP学习＆＃34; Chrome WebRTC没有消息，也没有音频但在Firefox

3 个答案: