0

我想知道为什么在createAnswerWithDelegatepeerConnection 的信号状态之后永远不会更改为RTCSignalingHaveLocalPrAnswer？调用跟踪是：

if(peerConnection.signalingState == RTCSignalingHaveRemoteOffer) {
            NSLog(@"Setting Remote Offer desc");
            [peerConnection createAnswerWithDelegate:self constraints:_constraints];
        }

然后

-(void)peerConnection:(RTCPeerConnection *)peerConnection didCreateSessionDescription:(RTCSessionDescription *)sdp error:(NSError *)error
{    
    if(error) {
        NSLog(@"Error - %@", error.description);
    }
    else {
        NSLog(@"Setting Local Desc");
        [peerConnection setLocalDescriptionWithDelegate:self sessionDescription:sdp];
    }
}

然后在-(void)peerConnection:(RTCPeerConnection *)peerConnection didSetSessionDescriptionWithError:(NSError *)error触发这种情况if(peerConnection.signalingState == RTCSignalingStable)时，我必须手动创建答案并强制发送他。我究竟做错了什么？

4

1 回答 1

3

这就是当前的 WebRTC 规范编辑草案（2015 年 10 月 6 日）中描述“have-remote-pranswer”状态的方式：

“offer”类型的本地描述已成功应用，“pranswer”类型的远程描述已成功应用。

“pranswer”定义为：

“pranswer”的 RTCSdpType 表示必须将描述视为 [SDP] 答案，而不是最终答案。用作 SDP“pranswer”的描述可以用作对 SDP 提议的响应，或对先前发送的 SDP“pranswer”的更新。

createAnswerWithDelegate创建的答案是“答案”，而不是“pranswer”。因此状态直接进入“稳定”状态。请参阅规范的状态流程图以获得更好的概览。

你没有做错任何事。您可能需要对您所处的状态进行一些手动记账，并相应地创建答案或提议。

于 2015-11-20T20:40:54.773 回答