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