WebRTC issue on closing peer connection in have-local-offer state

1
votes

The scenario i have been testing is trying to cancel a requested session initiation before an answer from the remote. I am using a setup between two Nexus 7 devices running Android 6.0.

I introduced a session initiation cancel option which is available to the user during the period that a session initiation request has been made and the remote user has not yet answered (e.g., in a user alerting state). The RTC peer connection signaling state on the initiating side is "have-local-offer", when the user requests the session cancel. On initiation of the cancel, i invoke a close on the peer connection and see that a signaling state change occurs on the initiation side as the RTC signaling state goes (as i would expect) to 'close'.

On the side receiving the session initiation request, however, the RTC signaling state goes to the state "have-remote-offer" as expected, but the close event from the initiating side does not appear to propagate to the receiving side, and the receiving side remains in the "have-remote-offer" state.

I have reviewed the standards and it appears that the event should be generated on the receiving side (i.e., the close should be sent when closed in state "have local offer").

Obviously, i can build around this case and generate a terminate over the session server signaling channel - but would like to understand whether i am doing something wrong or mis-interpreting the spec?

thanks,

1
sessionwebrtc
Where exactly in the spec do you find support for an event being generated receiver side? – jib
Good point - i assumed on the processing of the close, reached in any state ('Set the object's RTCPeerConnection signalingState to closed.') that this state was a state of the peer connection and reflected a state on both ends of the connection so that if the state went to closed the corresponding remote also went to closed. If correct, that in the stable state, the close is propagated, would seem from a state machine perspective that some event would happen on the remote - anyway, without getting into actual underlying implementation, can you point to discussion of handling of this? thanks! – SBG

1 Answers

1
votes

You haven't successfully negotiated a connection yet, so RTCPeerConnection's only means of communication to the other side is through the signaling channel you provide.

For it to communicate something on close, that something would have to be surfaced in the API akin to onicecandidate, and no such thing exists.

Remember, your code is on both ends, so you can easily signal this yourself.

One minor mistake in the specification aside (which will hopefully go away soon), a peer connection does not close itself.