1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
<?xml version="1.0" encoding="UTF-8" ?>
<class name="WebRTCPeerConnection" inherits="RefCounted" version="4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../doc/class.xsd">
<brief_description>
Interface to a WebRTC peer connection.
</brief_description>
<description>
A WebRTC connection between the local computer and a remote peer. Provides an interface to connect, maintain and monitor the connection.
Setting up a WebRTC connection between two peers from now on) may not seem a trivial task, but it can be broken down into 3 main steps:
- The peer that wants to initiate the connection ([code]A[/code] from now on) creates an offer and send it to the other peer ([code]B[/code] from now on).
- [code]B[/code] receives the offer, generate and answer, and sends it to [code]A[/code]).
- [code]A[/code] and [code]B[/code] then generates and exchange ICE candidates with each other.
After these steps, the connection should become connected. Keep on reading or look into the tutorial for more information.
</description>
<tutorials>
</tutorials>
<methods>
<method name="add_ice_candidate">
<return type="int" enum="Error" />
<argument index="0" name="media" type="String" />
<argument index="1" name="index" type="int" />
<argument index="2" name="name" type="String" />
<description>
Add an ice candidate generated by a remote peer (and received over the signaling server). See [signal ice_candidate_created].
</description>
</method>
<method name="close">
<return type="void" />
<description>
Close the peer connection and all data channels associated with it.
[b]Note:[/b] You cannot reuse this object for a new connection unless you call [method initialize].
</description>
</method>
<method name="create_data_channel">
<return type="WebRTCDataChannel" />
<argument index="0" name="label" type="String" />
<argument index="1" name="options" type="Dictionary" default="{}" />
<description>
Returns a new [WebRTCDataChannel] (or [code]null[/code] on failure) with given [code]label[/code] and optionally configured via the [code]options[/code] dictionary. This method can only be called when the connection is in state [constant STATE_NEW].
There are two ways to create a working data channel: either call [method create_data_channel] on only one of the peer and listen to [signal data_channel_received] on the other, or call [method create_data_channel] on both peers, with the same values, and the [code]negotiated[/code] option set to [code]true[/code].
Valid [code]options[/code] are:
[codeblock]
{
"negotiated": true, # When set to true (default off), means the channel is negotiated out of band. "id" must be set too. "data_channel_received" will not be called.
"id": 1, # When "negotiated" is true this value must also be set to the same value on both peer.
# Only one of maxRetransmits and maxPacketLifeTime can be specified, not both. They make the channel unreliable (but also better at real time).
"maxRetransmits": 1, # Specify the maximum number of attempt the peer will make to retransmits packets if they are not acknowledged.
"maxPacketLifeTime": 100, # Specify the maximum amount of time before giving up retransmitions of unacknowledged packets (in milliseconds).
"ordered": true, # When in unreliable mode (i.e. either "maxRetransmits" or "maxPacketLifetime" is set), "ordered" (true by default) specify if packet ordering is to be enforced.
"protocol": "my-custom-protocol", # A custom sub-protocol string for this channel.
}
[/codeblock]
[b]Note:[/b] You must keep a reference to channels created this way, or it will be closed.
</description>
</method>
<method name="create_offer">
<return type="int" enum="Error" />
<description>
Creates a new SDP offer to start a WebRTC connection with a remote peer. At least one [WebRTCDataChannel] must have been created before calling this method.
If this functions returns [constant OK], [signal session_description_created] will be called when the session is ready to be sent.
</description>
</method>
<method name="get_connection_state" qualifiers="const">
<return type="int" enum="WebRTCPeerConnection.ConnectionState" />
<description>
Returns the connection state. See [enum ConnectionState].
</description>
</method>
<method name="initialize">
<return type="int" enum="Error" />
<argument index="0" name="configuration" type="Dictionary" default="{}" />
<description>
Re-initialize this peer connection, closing any previously active connection, and going back to state [constant STATE_NEW]. A dictionary of [code]options[/code] can be passed to configure the peer connection.
Valid [code]options[/code] are:
[codeblock]
{
"iceServers": [
{
"urls": [ "stun:stun.example.com:3478" ], # One or more STUN servers.
},
{
"urls": [ "turn:turn.example.com:3478" ], # One or more TURN servers.
"username": "a_username", # Optional username for the TURN server.
"credential": "a_password", # Optional password for the TURN server.
}
]
}
[/codeblock]
</description>
</method>
<method name="poll">
<return type="int" enum="Error" />
<description>
Call this method frequently (e.g. in [method Node._process] or [method Node._physics_process]) to properly receive signals.
</description>
</method>
<method name="set_default_extension" qualifiers="static">
<return type="void" />
<argument index="0" name="extension_class" type="StringName" />
<description>
Sets the [code]extension_class[/code] as the default [WebRTCPeerConnectionExtension] returned when creating a new [WebRTCPeerConnection].
</description>
</method>
<method name="set_local_description">
<return type="int" enum="Error" />
<argument index="0" name="type" type="String" />
<argument index="1" name="sdp" type="String" />
<description>
Sets the SDP description of the local peer. This should be called in response to [signal session_description_created].
After calling this function the peer will start emitting [signal ice_candidate_created] (unless an [enum Error] different from [constant OK] is returned).
</description>
</method>
<method name="set_remote_description">
<return type="int" enum="Error" />
<argument index="0" name="type" type="String" />
<argument index="1" name="sdp" type="String" />
<description>
Sets the SDP description of the remote peer. This should be called with the values generated by a remote peer and received over the signaling server.
If [code]type[/code] is [code]offer[/code] the peer will emit [signal session_description_created] with the appropriate answer.
If [code]type[/code] is [code]answer[/code] the peer will start emitting [signal ice_candidate_created].
</description>
</method>
</methods>
<signals>
<signal name="data_channel_received">
<argument index="0" name="channel" type="WebRTCDataChannel" />
<description>
Emitted when a new in-band channel is received, i.e. when the channel was created with [code]negotiated: false[/code] (default).
The object will be an instance of [WebRTCDataChannel]. You must keep a reference of it or it will be closed automatically. See [method create_data_channel].
</description>
</signal>
<signal name="ice_candidate_created">
<argument index="0" name="media" type="String" />
<argument index="1" name="index" type="int" />
<argument index="2" name="name" type="String" />
<description>
Emitted when a new ICE candidate has been created. The three parameters are meant to be passed to the remote peer over the signaling server.
</description>
</signal>
<signal name="session_description_created">
<argument index="0" name="type" type="String" />
<argument index="1" name="sdp" type="String" />
<description>
Emitted after a successful call to [method create_offer] or [method set_remote_description] (when it generates an answer). The parameters are meant to be passed to [method set_local_description] on this object, and sent to the remote peer over the signaling server.
</description>
</signal>
</signals>
<constants>
<constant name="STATE_NEW" value="0" enum="ConnectionState">
The connection is new, data channels and an offer can be created in this state.
</constant>
<constant name="STATE_CONNECTING" value="1" enum="ConnectionState">
The peer is connecting, ICE is in progress, none of the transports has failed.
</constant>
<constant name="STATE_CONNECTED" value="2" enum="ConnectionState">
The peer is connected, all ICE transports are connected.
</constant>
<constant name="STATE_DISCONNECTED" value="3" enum="ConnectionState">
At least one ICE transport is disconnected.
</constant>
<constant name="STATE_FAILED" value="4" enum="ConnectionState">
One or more of the ICE transports failed.
</constant>
<constant name="STATE_CLOSED" value="5" enum="ConnectionState">
The peer connection is closed (after calling [method close] for example).
</constant>
</constants>
</class>
|