React本机WebRTC setRemoteDescription错误

Question

第一次尝试webRTC的时候，我有点卡住了。这是在React Native和react-native-webrtc中实现的。我正在测试是否可以一步一步手动在2台安卓手机之间建立p2p连接。因此，我尝试从一部手机发起呼叫，方法是创建一个报价并通过电子邮件将其发送到我的第二部手机。然后，在我的第二部手机中，我会将报价复制并粘贴到我的测试应用程序的文本字段中，然后按下一个按钮来解析报价和setRemoteDescription。这就是我遇到错误的步骤。

下面是我生成和发送报价的代码。

const configuration = {iceServers: [{url: 'stun:stun.l.google.com:19302'}]};
const pc = new RTCPeerConnection(configuration);
pc.addStream(newStream);
pc.createOffer().then((desc) => {
  pc.setLocalDescription(desc).then(() => {
    this.setState({offer: JSON.stringify(desc)});
    this.sendSDP(JSON.stringify(desc));
  });
});

下面是解析offer字符串和setRemoteDescription的代码：

const peer = new RTCPeerConnection(configuration);
const remoteOffer = JSON.parse(this.state.remoteOffer.trim());
peer.setRemoteDescription(new RTCSessionDescription(remoteOffer))
  .then(() => {
    console.log('Success');
  });

下面是错误:可能未处理的Promise Rejection (id: 0)："SessionDescription is NULL。“

这是它生成的smaple SDP：

v=0
o=- 5299598814408802478 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 60bf7681-7bb3-4e23-9c53-d893ee22e887
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 102 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:9UIW
a=ice-pwd:fnnBPehMg0DeaEJUJerme780
a=ice-options:trickle renomination
a=fingerprint:sha-256 
27:C9:67:A0:F9:12:1B:6E:E7:50:D5:AD:C0:02:59:62:0A:68:43:28:03:44:7D:EC:D6:F1:7E:1A:E2:AF:72:77
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
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:102 ILBC/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:670797681 cname:I8LsJZX3n5eJai4a
a=ssrc:670797681 msid:60bf7681-7bb3-4e23-9c53-d893ee22e887 6d561642-6ff6-417a-bbf4-597fc1adeefc
a=ssrc:670797681 mslabel:60bf7681-7bb3-4e23-9c53-d893ee22e887
a=ssrc:670797681 label:6d561642-6ff6-417a-bbf4-597fc1adeefc
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 127 123 125
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:9UIW
a=ice-pwd:fnnBPehMg0DeaEJUJerme780
a=ice-options:trickle renomination
a=fingerprint:sha-256 
27:C9:67:A0:F9:12:1B:6E:E7:50:D5:AD:C0:02:59:62:0A:68:43:28:03:44:7D:EC:D6:F1:7E:1A:E2:AF:72:77
a=setup:actpass
a=mid:video
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 H264/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 red/90000
a=rtpmap:123 rtx/90000
a=fmtp:123 apt=127
a=rtpmap:125 ulpfec/90000
a=ssrc-group:FID 3993542722 2266256606
a=ssrc:3993542722 cname:I8LsJZX3n5eJai4a
a=ssrc:3993542722 msid:60bf7681-7bb3-4e23-9c53-d893ee22e887 7f960b56-02ec-453d-b69b-07311714c8be
a=ssrc:3993542722 mslabel:60bf7681-7bb3-4e23-9c53-d893ee22e887
a=ssrc:3993542722 label:7f960b56-02ec-453d-b69b-07311714c8be
a=ssrc:2266256606 cname:I8LsJZX3n5eJai4a
a=ssrc:2266256606 msid:60bf7681-7bb3-4e23-9c53-d893ee22e887 7f960b56-02ec-453d-b69b-07311714c8be
a=ssrc:2266256606 mslabel:60bf7681-7bb3-4e23-9c53-d893ee22e887
a=ssrc:2266256606 label:7f960b56-02ec-453d-b69b-07311714c8be

我在这里遗漏了什么或做错了什么？

Answer 1

我终于弄明白了这个问题，它是反戏剧性的。问题是，当我通过电子邮件发送报价时，电子邮件会自动在中间的某个位置添加一个换行符，这会导致错误。现在，我使用了文本修复程序网站工具来删除换行符，直到我继续使用正确的信号方法。