W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2011

Re: PeerConnection::close() inconsistencies

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 29 Nov 2011 09:06:07 +0100
Message-ID: <4ED4926F.5090900@ericsson.com>
To: public-webrtc@w3.org
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:26 UTC