Reputation: 397
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,
Upvotes: 1
Views: 5453
Reputation: 42430
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.
Upvotes: 1