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

PeerConnection::close() inconsistencies

From: ᛏᚮᛘᛘᚤ <tommyw@google.com>
Date: Thu, 24 Nov 2011 13:23:46 +0100
Message-ID: <CALLKCfPG+wwOqN3tMQvD6zMf26F58hQbxFinUC-+iCu6b3F4NQ@mail.gmail.com>
To: public-webrtc@w3.org
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?

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

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 Thursday, 24 November 2011 12:24:21 UTC

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