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

在當前的WebRTC規范編輯草案 （2015年10月6日） 中，以這種方式描述“具有遠程代理”狀態：

類型“ offer”的本地描述已成功應用，類型“ pranswer”的遠程描述已成功應用。

“ pranswer”定義為：

RTCSdpType為“ pranswer”表示必須將描述視為[SDP]答案，而不是最終答案。 可以將用作SDP“ pranswer”的描述用作對SDP報價的響應，或者用作對先前發送的SDP“ pranswer”的更新。

createAnswerWithDelegate創建的答案是“答案”，而不是“ pranswer”。 因此狀態直接進入“穩定”狀態。 請參閱規范的狀態流程圖以獲取更好的概述。

您沒有做錯任何事。 您可能需要對所處的狀態進行一些手動記賬，並相應地創建答案或要約。