ios - WebRTC 信号状态永远不会在 iOS 上更改为 HaveLocalAnswer

Question

我想知道为什么在 createAnswerWithDelegate 之后 peerConnection 的 signalingState 从未更改为 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)所以我必须手动创建答案并强制发送给他。我做错了什么？

Answer 1

这就是当前 Editor's Draft of the WebRTC specification 中描述“have-remote-pranswer”状态的方式(2015 年 10 月 6 日):

A local description of type "offer" has been successfully applied and a remote description of type "pranswer" has been successfully applied.

“pranswer”定义为:

An RTCSdpType of "pranswer" indicates that a description must be treated as an [SDP] answer, but not a final answer. A description used as an SDP "pranswer" may be applied as a response to a SDP offer, or an update to a previously sent SDP "pranswer".

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

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