为什么呼叫者未触发WebRTC上轨，呼叫者看不到远程视频，被呼叫者仅在SDP中发送a = recvonly

Question

除了教科书方法外，我几乎都有一个报价处理程序，除了一个小小的变化，我等待流创建之后再在被叫方（收件人）端添加曲目。但是，被叫方似乎仅在回答中正向发送a =，这可能会导致未在呼叫方上触发ontrack。这是代码：

  async function handleOffer(msg) {
   
  if(!myPeerConnection ){
    myPeerConnectionPromise = createPeerConnection();
  }

  let desc = new RTCSessionDescription(msg.sdp);
  await myPeerConnection.setRemoteDescription(desc);

  Promise.all([userMediaPromise, myPeerConnectionPromise]).then(async (values) => {
    try {
        localStream = values[0];
        localStream.getTracks().forEach(track => {myPeerConnection.addTrack(track, localStream);});
    } catch (err) {
        handleGetUserMediaError(err);
    }

  await myPeerConnection.setLocalDescription(await myPeerConnection.createAnswer());
  
  signaling.send("answer", { sdp: myPeerConnection.localDescription});

  })
  
}

我已经在该网站上查看了类似的问题，但是找不到答案。与我的问题最接近的问题是，offeroptions的设置不正确，但在我的情况下，呼叫方的Offeroptions是

    {
      offerToReceiveAudio:1,
      offerToReceiveVideo:1
    }

我还尝试查找是否可以通过createAnswer（）传递任何answerOptions，但找不到任何东西。

更新：我注意到在此过程的很早之前添加本地磁道之前，被呼叫方就触发了needingneedneed，并且由于信令状态不是“稳定”而被关闭。发送应答后，在信令状态转换回“稳定”后，不会触发重新协商。这与我的问题有关吗？

已解决：摆脱了需要协商的事件处理程序并手动管理要约-回答过程。该处理程序触发得太早，并在两端添加曲目之前创建了localdescription。