asgardius/virtualx-engine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
virtualx-engine/modules/webrtc/doc_classes/WebRTCDataChannel.xml

112 lines
4.3 KiB
XML
Raw Permalink Normal View History

WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<?xml version="1.0" encoding="UTF-8" ?>
Bump version to 3.6-beta
2022-08-05 18:51:38 +02:00
<class name="WebRTCDataChannel" inherits="PacketPeer" version="3.6" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../doc/class.xsd">
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<brief_description>
</brief_description>
<description>
</description>
<tutorials>
</tutorials>
<methods>
<method name="close">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="void" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
Closes this data channel, notifying the other peer.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
Add get_buffered_amount() to WebRTCDataChannel
2021-07-20 18:44:40 +02:00
<method name="get_buffered_amount" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="int" />
Add get_buffered_amount() to WebRTCDataChannel
2021-07-20 18:44:40 +02:00
<description>
Returns the number of bytes currently queued to be sent over this channel.
</description>
</method>
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<method name="get_id" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="int" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
Returns the id assigned to this channel during creation (or auto-assigned during negotiation).
If the channel is not negotiated out-of-band the id will only be available after the connection is established (will return [code]65535[/code] until then).
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
<method name="get_label" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="String" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
Returns the label assigned to this channel during creation.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
<method name="get_max_packet_life_time" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="int" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
doc: Fix formatting, typos and some descriptions in new docstrings
2019-06-15 00:04:55 +02:00
Returns the [code]maxPacketLifeTime[/code] value assigned to this channel during creation.
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
Will be [code]65535[/code] if not specified.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
<method name="get_max_retransmits" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="int" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
doc: Fix formatting, typos and some descriptions in new docstrings
2019-06-15 00:04:55 +02:00
Returns the [code]maxRetransmits[/code] value assigned to this channel during creation.
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
Will be [code]65535[/code] if not specified.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
<method name="get_protocol" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="String" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
doc: Fix formatting, typos and some descriptions in new docstrings
2019-06-15 00:04:55 +02:00
Returns the sub-protocol assigned to this channel during creation. An empty string if not specified.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
<method name="get_ready_state" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="int" enum="WebRTCDataChannel.ChannelState" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
doc: Fix scoped hyperlinks to same-class enums/methods The class name does not need to be specified when it is the current class.
2019-06-27 11:44:37 +02:00
Returns the current state of this channel, see [enum ChannelState].
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
<method name="is_negotiated" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="bool" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
Returns [code]true[/code] if this channel was created with out-of-band configuration.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
<method name="is_ordered" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="bool" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
Returns [code]true[/code] if this channel was created with ordering enabled (default).
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
<method name="poll">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="int" enum="Error" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
Reserved, but not used for now.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
<method name="was_string_packet" qualifiers="const">
doc: Use self-closing tags for `return` and `argument` For the time being we don't support writing a description for those, preferring having all details in the method's description. Using self-closing tags saves half the lines, and prevents contributors from thinking that they should write the argument or return documentation there. (cherry picked from commit 7adf4cc9b5de6701a41e27690a69b9892d5eed85)
2021-07-30 15:28:05 +02:00
<return type="bool" />
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
<description>
doc: Fix formatting, typos and some descriptions in new docstrings
2019-06-15 00:04:55 +02:00
Returns [code]true[/code] if the last received packet was transferred as text. See [member write_mode].
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</description>
</method>
</methods>
<members>
doc: Add default values to all properties Thanks to @bojidar-bg's impressive work in #29380.
2019-06-29 12:38:01 +02:00
<member name="write_mode" type="int" setter="set_write_mode" getter="get_write_mode" enum="WebRTCDataChannel.WriteMode" default="1">
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
The transfer mode to use when sending outgoing packet. Either text or binary.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</member>
</members>
<constants>
<constant name="WRITE_MODE_TEXT" value="0" enum="WriteMode">
doc: Fix formatting, typos and some descriptions in new docstrings
2019-06-15 00:04:55 +02:00
Tells the channel to send data over this channel as text. An external peer (non-Godot) would receive this as a string.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</constant>
<constant name="WRITE_MODE_BINARY" value="1" enum="WriteMode">
doc: Fix formatting, typos and some descriptions in new docstrings
2019-06-15 00:04:55 +02:00
Tells the channel to send data over this channel as binary. An external peer (non-Godot) would receive this as array buffer or blob.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</constant>
<constant name="STATE_CONNECTING" value="0" enum="ChannelState">
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
The channel was created, but it's still trying to connect.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</constant>
<constant name="STATE_OPEN" value="1" enum="ChannelState">
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
The channel is currently open, and data can flow over it.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</constant>
<constant name="STATE_CLOSING" value="2" enum="ChannelState">
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
The channel is being closed, no new messages will be accepted, but those already in queue will be flushed.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</constant>
<constant name="STATE_CLOSED" value="3" enum="ChannelState">
Add documentation for WebRTC classes.
2019-06-03 15:20:15 +02:00
The channel was closed, or connection failed.
WebRTC refactor. Data channels, STUN/TURN support. A big refactor to the WebRTC module. API is now considered quite stable. Highlights: - Renamed `WebRTCPeer` to `WebRTCPeerConnection`. - `WebRTCPeerConnection` no longer act as `PacketPeer`, it only handle the connection itself (a bit like `TCP_Server`) - Added new `WebRTCDataChannel` class which inherits from `PacketPeer` to handle data transfer. - Add `WebRTCPeerConnection.initialize` method to create a new connection with the desired configuration provided as dictionary ([see MDN docs](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#RTCConfiguration_dictionary)). - Add `WebRTCPeerConnection.create_data_channel` method to create a data channel for the given connection. The connection must be in `STATE_NEW` as specified by the standard ([see MDN docs for options](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDataChannel#RTCDataChannelInit_dictionary)). - Add a `data_channel_received` signal to `WebRTCPeerConnection` for in-band (not negotiated) channels. - Renamed `WebRTCPeerConnection` `offer_created` signal to `session_description_created`. - Renamed `WebRTCPeerConnection` `new_ice_candidate` signal to `ice_candidate_created`
2019-05-11 01:46:27 +02:00
</constant>
</constants>
</class>
Reference in a new issue Copy permalink