if(pc.iceGatheringState === "complete"){
const resp = await fetch("REMOTE URL", {
method: "post",
body: JSON.stringify({
offer: btoa(JSON.stringify(pc.localDescription)),
}),
});
const sdp = await resp.text();
pc.setRemoteDescription(
new RTCSessionDescription(JSON.parse(atob(sdp)))
).catch((e) => console.log(e));
}
A remote (GO) server uses a REST API to accept the offer and respond with the answer. The answer is sent only after all the candidates have been gathered on the remote peer. I.e. after the ""
candidate has been received
The remote server has a local RTP stream which is being sent to the host. The host adds a transceiver before it sends the offer
pc.addTransceiver("video", { direction: "recvonly" });
onTrack
event is received, the stream
is added to a variable and ONLY set as srcObject
of the <video>
component when the iceConnectionState
changes to connected
The above setup works perfectly in case of a local network. Both, the host and the peer chose a host
candidate and the video plays perfectly.
When using a remote connection, both, in case of a STUN (srflx) candidate and a TURN(relay) candidate, the video does not play.
chrome://webrtc-internals
clearly shows the the Transport has chosen the right candidates but there is no traffic on the local
candidate chosen.
I can see using the UDP dump on the remote peer that the video stream is being sent perfectly.
srflex
candidate, the nack
and pli
counts are very high compared to a local networkFor approx 15 sec of video
pliCount:
local: 5
remote: 221
nackCount:
local: 7
remote: 2577
That sounds like packet loss to me. There are a few things that could be causing it.
Can you try lowering the bitrate of what you are sending? See if congestion is causing it.
Can you trying lowering the MTU? If you are forwarding packets from FFMPEG try appending pkt_size to the URL like this