Re: PeerConnection::close() inconsistencies

On 11/24/2011 01:23 PM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
> Hi,
> There seems to be contradictory information in the current draft
> regarding how a PeerConnection::close() call should be handled:
>
> 1) In section “4.1.2 Methods”, in the documentation for the close()
> method it says that the PeerConnection object should kill the ICE agent
> abruptly and then go directly into CLOSED state.
>
> 2) In section 4, under “During the lifetime of the PeerConnection
> object, the following procedures are followed:” point 8 it says
>
> The close method will cause the system to wait until the sdpStat is
> SDPIDLE then it will send an SDP offer terminating all media and change
> the readyState to CLOSING as well as stop all ICE process and change the
> iceState to ICE_CLOSED. Once an SDP anser to this offer is received, the
> readyState will be changed to CLOSED.
>
>
> Is it the second description that is correct?
I think this is a good question, but that we have not yet sorted this 
out completely yet.

The second description has been added to the document at a later stage. 
I think it may make sense to signal in conjunction with closing (as said 
in 2)) so that the remote browser can tear down its PeerConnection 
object in a controlled fashion, but in practice the signaling will in 
many cases not be transmitted at all since the user could simply close 
the browser/browser tab to end the session.

So the PeerConnection implementation must in any case be able to detect 
(maybe from that no RTP/RTCP/STUN keepalives is received, and that no 
responses are received when trying to re-establish the connection) that 
the connection is closed and that the remote end is gone and then go 
into CLOSED state.

>
> What should happen to the remote streams in either case? The logical
> thing would be that the local streams stays unchanged but the remote
> streams should go into closed state.
>
> If the second description is correct how should the other side react?
> The logical thing would be that it sets its own state to CLOSED when
> receiving the terminating SDP offer.
>
> How should this be interpreted when ROAP is the signaling protocol in
> use? Should we use a ROAP SHUTDOWN/OK message exchange instead of the
> SDP offer/answer?
>
> --
> Tommy Widenflycht, Senior Software Engineer
> Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
> Org. nr. 556656-6880
> And yes, I have to include the above in every outgoing email according
> to EU law.

Received on Tuesday, 29 November 2011 08:06:42 UTC