为什么只有对等连接的一端获得远程流

Question

I have a problem where only one side of peer connection gets remote stream.

For both cases I add stream before creating answer/offer.

const peer = new RTCPeerConnection(servers);
if (localStream instanceof MediaStream) {
  localStream.getTracks().map(track =>peer.addTrack(track, localStream));
}

Then depending on offer/answer I perform following steps:

// means we got offer
if (remoteDesc) {
    peer
        .setRemoteDescription(remoteDesc)
        .then(_ => peer.createAnswer())
        .then(desc => peer.setLocalDescription(desc))
        .then(_ => Signaling.sendAnswer(peer.localDescription));
} else {
// means we will create offer
    peer
        .createOffer()
        .then(desc => peer.setLocalDescription(desc))
        .then(_ => Signaling.sendOffer(peer.localDescription));
}

But the peer.ontrack is dispatched only for one side the one creating offer. The other one does not get the remote stream.

Does anyone can thing of a solution ?

UPDATE

answer setting

Signaling.onAnswer(desc => peer.setRemoteDescription(new RTCSessionDescription(desc)));

Signaling is an socket channel dispatching and handling offer, answer, candidates etc...

peer.onicecandidate = onIceCandidate;
onIceCandidate(iceEvent) {
    if (iceEvent.candidate) {
        Signaling.sendCandidate(iceEvent.candidate);
    } else {
        // All ICE candidates have been sent
    }
}

Signaling.onCandidate(candidate => peer. addIceCandidate(new RTCIceCandidate(candidate)));

Offer SDP

{type: "offer", sdp: "v=0
↵o=- 4410298974094571977 2 IN IP4 127.0.0.1
↵s…id:data
↵a=sctpmap:5000 webrtc-datachannel 1024
↵"}
sdp
:
"v=0
↵o=- 4410298974094571977 2 IN IP4 127.0.0.1
↵s=-
↵t=0 0
↵a=group:BUNDLE audio video data
↵a=msid-semantic: WMS 20c109a4-ad79-48a6-9de9-a872a48ddfbc
↵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:KUmY
↵a=ice-pwd:l6szW8mudEAgi6dltLkdIE3S
↵a=fingerprint:sha-256 39:6C:A2:46:59:43:71:CC:8C:04:E8:EB:39:C0:27:FC:38:4B:71:CF:4D:A3:ED:6B:A1:AE:DB:F8:83:90:92:EE
↵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:1689860201 cname:/EesnVK9O+Osiowm
↵a=ssrc:1689860201 msid:20c109a4-ad79-48a6-9de9-a872a48ddfbc ab4a10b2-3047-43a1-b9e9-4864d5c654f8
↵a=ssrc:1689860201 mslabel:20c109a4-ad79-48a6-9de9-a872a48ddfbc
↵a=ssrc:1689860201 label:ab4a10b2-3047-43a1-b9e9-4864d5c654f8
↵m=video 9 UDP/TLS/RTP/SAVPF 96 98 100 102 127 97 99 101 125
↵c=IN IP4 0.0.0.0
↵a=rtcp:9 IN IP4 0.0.0.0
↵a=ice-ufrag:KUmY
↵a=ice-pwd:l6szW8mudEAgi6dltLkdIE3S
↵a=fingerprint:sha-256 39:6C:A2:46:59:43:71:CC:8C:04:E8:EB:39:C0:27:FC:38:4B:71:CF:4D:A3:ED:6B:A1:AE:DB:F8:83:90:92:EE
↵a=setup:actpass
↵a=mid:video
↵a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
↵a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
↵a=extmap:4 urn:3gpp:video-orientation
↵a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
↵a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
↵a=sendrecv
↵a=rtcp-mux
↵a=rtcp-rsize
↵a=rtpmap:96 VP8/90000
↵a=rtcp-fb:96 ccm fir
↵a=rtcp-fb:96 nack
↵a=rtcp-fb:96 nack pli
↵a=rtcp-fb:96 goog-remb
↵a=rtcp-fb:96 transport-cc
↵a=rtpmap:98 VP9/90000
↵a=rtcp-fb:98 ccm fir
↵a=rtcp-fb:98 nack
↵a=rtcp-fb:98 nack pli
↵a=rtcp-fb:98 goog-remb
↵a=rtcp-fb:98 transport-cc
↵a=rtpmap:100 H264/90000
↵a=rtcp-fb:100 ccm fir
↵a=rtcp-fb:100 nack
↵a=rtcp-fb:100 nack pli
↵a=rtcp-fb:100 goog-remb
↵a=rtcp-fb:100 transport-cc
↵a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
↵a=rtpmap:102 red/90000
↵a=rtpmap:127 ulpfec/90000
↵a=rtpmap:97 rtx/90000
↵a=fmtp:97 apt=96
↵a=rtpmap:99 rtx/90000
↵a=fmtp:99 apt=98
↵a=rtpmap:101 rtx/90000
↵a=fmtp:101 apt=100
↵a=rtpmap:125 rtx/90000
↵a=fmtp:125 apt=102
↵a=ssrc-group:FID 2136416857 1566502106
↵a=ssrc:2136416857 cname:/EesnVK9O+Osiowm
↵a=ssrc:2136416857 msid:20c109a4-ad79-48a6-9de9-a872a48ddfbc 3f67ff63-fd06-433c-99a6-22220126b0c7
↵a=ssrc:2136416857 mslabel:20c109a4-ad79-48a6-9de9-a872a48ddfbc
↵a=ssrc:2136416857 label:3f67ff63-fd06-433c-99a6-22220126b0c7
↵a=ssrc:1566502106 cname:/EesnVK9O+Osiowm
↵a=ssrc:1566502106 msid:20c109a4-ad79-48a6-9de9-a872a48ddfbc 3f67ff63-fd06-433c-99a6-22220126b0c7
↵a=ssrc:1566502106 mslabel:20c109a4-ad79-48a6-9de9-a872a48ddfbc
↵a=ssrc:1566502106 label:3f67ff63-fd06-433c-99a6-22220126b0c7
↵m=application 9 DTLS/SCTP 5000
↵c=IN IP4 0.0.0.0
↵a=ice-ufrag:KUmY
↵a=ice-pwd:l6szW8mudEAgi6dltLkdIE3S
↵a=fingerprint:sha-256 39:6C:A2:46:59:43:71:CC:8C:04:E8:EB:39:C0:27:FC:38:4B:71:CF:4D:A3:ED:6B:A1:AE:DB:F8:83:90:92:EE
↵a=setup:actpass
↵a=mid:data
↵a=sctpmap:5000 webrtc-datachannel 1024
↵"
type
:
"offer"

Answer SDP

{type: "answer", sdp: "v=0
↵o=- 7479793843491036982 2 IN IP4 127.0.0.1
↵s…id:data
↵a=sctpmap:5000 webrtc-datachannel 1024
↵"}
sdp
:
"v=0
↵o=- 7479793843491036982 2 IN IP4 127.0.0.1
↵s=-
↵t=0 0
↵a=group:BUNDLE audio video data
↵a=msid-semantic: WMS fa46b87c-d963-4145-8d6f-3f268566bdce
↵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:wQcK
↵a=ice-pwd:HzGicV7dTaHoMxcCugtLmM/X
↵a=fingerprint:sha-256 38:8F:8D:2D:47:FA:1A:03:DB:99:DA:BC:A5:46:16:D6:F4:C4:2C:6E:30:62:DF:43:1E:45:58:79:7F:78:2D:69
↵a=setup:active
↵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:2114419408 cname:5/GCTq5gjAmxzBRY
↵a=ssrc:2114419408 msid:fa46b87c-d963-4145-8d6f-3f268566bdce daa62a3e-c127-44e1-908e-e0e36404ed07
↵a=ssrc:2114419408 mslabel:fa46b87c-d963-4145-8d6f-3f268566bdce
↵a=ssrc:2114419408 label:daa62a3e-c127-44e1-908e-e0e36404ed07
↵m=video 9 UDP/TLS/RTP/SAVPF 96 98 100 102 127 97 99 101 125
↵c=IN IP4 0.0.0.0
↵a=rtcp:9 IN IP4 0.0.0.0
↵a=ice-ufrag:wQcK
↵a=ice-pwd:HzGicV7dTaHoMxcCugtLmM/X
↵a=fingerprint:sha-256 38:8F:8D:2D:47:FA:1A:03:DB:99:DA:BC:A5:46:16:D6:F4:C4:2C:6E:30:62:DF:43:1E:45:58:79:7F:78:2D:69
↵a=setup:active
↵a=mid:video
↵a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
↵a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
↵a=extmap:4 urn:3gpp:video-orientation
↵a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
↵a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
↵a=sendrecv
↵a=rtcp-mux
↵a=rtcp-rsize
↵a=rtpmap:96 VP8/90000
↵a=rtcp-fb:96 ccm fir
↵a=rtcp-fb:96 nack
↵a=rtcp-fb:96 nack pli
↵a=rtcp-fb:96 goog-remb
↵a=rtcp-fb:96 transport-cc
↵a=rtpmap:98 VP9/90000
↵a=rtcp-fb:98 ccm fir
↵a=rtcp-fb:98 nack
↵a=rtcp-fb:98 nack pli
↵a=rtcp-fb:98 goog-remb
↵a=rtcp-fb:98 transport-cc
↵a=rtpmap:100 H264/90000
↵a=rtcp-fb:100 ccm fir
↵a=rtcp-fb:100 nack
↵a=rtcp-fb:100 nack pli
↵a=rtcp-fb:100 goog-remb
↵a=rtcp-fb:100 transport-cc
↵a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
↵a=rtpmap:102 red/90000
↵a=rtpmap:127 ulpfec/90000
↵a=rtpmap:97 rtx/90000
↵a=fmtp:97 apt=96
↵a=rtpmap:99 rtx/90000
↵a=fmtp:99 apt=98
↵a=rtpmap:101 rtx/90000
↵a=fmtp:101 apt=100
↵a=rtpmap:125 rtx/90000
↵a=fmtp:125 apt=102
↵a=ssrc-group:FID 1018133779 1796172851
↵a=ssrc:1018133779 cname:5/GCTq5gjAmxzBRY
↵a=ssrc:1018133779 msid:fa46b87c-d963-4145-8d6f-3f268566bdce b2d00a83-f7e0-4765-aa91-b7a470414a6f
↵a=ssrc:1018133779 mslabel:fa46b87c-d963-4145-8d6f-3f268566bdce
↵a=ssrc:1018133779 label:b2d00a83-f7e0-4765-aa91-b7a470414a6f
↵a=ssrc:1796172851 cname:5/GCTq5gjAmxzBRY
↵a=ssrc:1796172851 msid:fa46b87c-d963-4145-8d6f-3f268566bdce b2d00a83-f7e0-4765-aa91-b7a470414a6f
↵a=ssrc:1796172851 mslabel:fa46b87c-d963-4145-8d6f-3f268566bdce
↵a=ssrc:1796172851 label:b2d00a83-f7e0-4765-aa91-b7a470414a6f
↵m=application 9 DTLS/SCTP 5000
↵c=IN IP4 0.0.0.0
↵b=AS:30
↵a=ice-ufrag:wQcK
↵a=ice-pwd:HzGicV7dTaHoMxcCugtLmM/X
↵a=fingerprint:sha-256 38:8F:8D:2D:47:FA:1A:03:DB:99:DA:BC:A5:46:16:D6:F4:C4:2C:6E:30:62:DF:43:1E:45:58:79:7F:78:2D:69
↵a=setup:active
↵a=mid:data
↵a=sctpmap:5000 webrtc-datachannel 1024
↵"
type
:
"answer"

Answer 1

It seems you are not setting the Remote Answer.
In below scenario b/w A to B:
A -> created offer & sent to B
B -> set the remote offer then created answer and sent back to A
A -> After receiving the answer, what you are doing? (you have set the remote answer using .setRemoteDescription then you will receive the track)

Then you need to handle candidates properly .