WebRTC signaling state never change to HaveLocalAnswer on iOS

Question

i'm wondering why after createAnswerWithDelegate peerConnection's signalingState never change to RTCSignalingHaveLocalPrAnswer? The call trace is:

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

then

-(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];
    }
}

and then in -(void)peerConnection:(RTCPeerConnection *)peerConnection didSetSessionDescriptionWithError:(NSError *)error firing this condition if(peerConnection.signalingState == RTCSignalingStable) so I have to manually create answer and force send him. What am I doing wrong?

Answer 1

This is how the "have-remote-pranswer" state is described in the current Editor's Draft of the WebRTC specification (06 October 2015):

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

A "pranswer" is defined as:

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".

The answer created by createAnswerWithDelegate is an "answer", not a "pranswer". Therefore the state goes directly to the "stable" state. See the specification's state flow chart for to get a better overview.

You are not doing anything wrong. You might have to do some manual bookkeeping about the state you are in, and create the answer or offer accordingly.