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
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
Coverage Report is based on the following editor draft:
https://w3c.github.io/webrtc-pc/archives/20170605/webrtc.html
4.3.1.6 Set the RTCSessionSessionDescription
[Trivial]
1. Let p be a new promise.
[Trivial]
2. In parallel, start the process to apply description as described in [JSEP]
(section 5.5. and section 5.6.).
[Trivial]
1. If the process to apply description fails for any reason, then user agent
MUST queue a task that runs the following steps:
[Untestable]
1. If connection's [[IsClosed]] slot is true, then abort these steps.
[Untestable]
2. If elements of the SDP were modified, then reject p with a newly created
InvalidModificationError and abort these steps.
[RTCPeerConnection-setLocalDescription-answer]
[RTCPeerConnection-setRemoteDescription-offer]
[RTCPeerConnection-setRemoteDescription-answer]
3. If the description's type is invalid for the current signaling state of
connection as described in [JSEP] (section 5.5. and section 5.6.), then
reject p with a newly created InvalidStateError and abort these steps.
[RTCPeerConnection-setRemoteDescription-offer]
4. If the content of description is not valid SDP syntax, then reject p
with an RTCError (with errorDetail set to "sdp-syntax-error" and the
sdpLineNumber attribute set to the line number in the SDP where the
syntax error was detected) and abort these steps.
[Untestable]
5. If the content of description is invalid, then reject p with a newly
created InvalidAccessError and abort these steps.
[Untestable]
6. For all other errors, for example if description cannot be applied at
the media layer, reject p with a newly created OperationError.
[Trivial]
2. If description is applied successfully, the user agent MUST queue a task
that runs the following steps:
[Untestable]
1. If connection's [[isClosed]] slot is true, then abort these steps.
[RTCPeerConnection-setLocalDescription]
2. If description is set as a local description, then run one of the
following steps:
[RTCPeerConnection-setLocalDescription-offer]
- If description is of type "offer", set connection.pendingLocalDescription
to description and signaling state to have-local-offer.
[RTCPeerConnection-setLocalDescription-answer]
- If description is of type "answer", then this completes an offer answer
negotiation.
Set connection's currentLocalDescription to description and
currentRemoteDescription to the value of pendingRemoteDescription.
Set both pendingRemoteDescription and pendingLocalDescription to null.
Finally set connection's signaling state to stable
[RTCPeerConnection-setLocalDescription-rollback]
- If description is of type "rollback", then this is a rollback. Set
connection.pendingLocalDescription to null and signaling state to stable.
[RTCPeerConnection-setLocalDescription-pranswer]
- If description is of type "pranswer", then set
connection.pendingLocalDescription to description and signaling state to
have-local-pranswer.
[RTCPeerConnection-setRemoteDescription]
3. Otherwise, if description is set as a remote description, then run one of the
following steps:
[RTCPeerConnection-setRemoteDescription-offer]
- If description is of type "offer", set connection.pendingRemoteDescription
attribute to description and signaling state to have-remote-offer.
[RTCPeerConnection-setRemoteDescription-answer]
- If description is of type "answer", then this completes an offer answer
negotiation.
Set connection's currentRemoteDescription to description and
currentLocalDescription to the value of pendingLocalDescription.
Set both pendingRemoteDescription and pendingLocalDescription to null.
Finally setconnection's signaling state to stable
[RTCPeerConnection-setRemoteDescription-rollback]
- If description is of type "rollback", then this is a rollback.
Set connection.pendingRemoteDescription to null and signaling state to stable.
[RTCPeerConnection-setRemoteDescription-rollback]
- If description is of type "pranswer", then set
connection.pendingRemoteDescription to description and signaling state
to have-remote-pranswer.
[RTCPeerConnection-setLocalDescription]
[RTCPeerConnection-setRemoteDescription]
4. If connection's signaling state changed above, fire a simple event named
signalingstatechange at connection.
[TODO]
5. If description is of type "answer", and it initiates the closure of an existing
SCTP association, as defined in [SCTP-SDP], Sections 10.3 and 10.4, set the value
of connection's [[sctpTransport]] internal slot to null.
[RTCSctpTransport]
6. If description is of type "answer" or "pranswer", then run the following steps:
[RTCSctpTransport]
1. If description initiates the establishment of a new SCTP association,
as defined in [SCTP-SDP], Sections 10.3 and 10.4, set the value of connection's
[[sctpTransport]] internal slot to a newly created RTCSctpTransport.
[TODO]
2. If description negotiates the DTLS role of the SCTP transport, and there is an
RTCDataChannel with a null id, then generate an ID according to
[RTCWEB-DATA-PROTOCOL].
[Untestable]
If no available ID could be generated, then run the following steps:
[Untestable]
1. Let channel be the RTCDataChannel object for which an ID could not be
generated.
[Untestable]
2. Set channel's readyState attribute to closed.
[Untestable]
3. Fire an event named error with a ResourceInUse exception at channel.
[Untestable]
4. Fire a simple event named close at channel.
[TODO RTCPeerConnection-setDescription-transceiver]
7. If description is set as a local description, then run the following steps for
each media description in description that is not yet associated with an
RTCRtpTransceiver object:
[TODO RTCPeerConnection-setDescription-transceiver]
1. Let transceiver be the RTCRtpTransceiver used to create the media
description.
[TODO RTCPeerConnection-setDescription-transceiver]
2. Set transceiver's mid value to the mid of the corresponding media
description.
[RTCPeerConnection-ontrack]
8. If description is set as a remote description, then run the following steps
for each media description in description:
[TODO RTCPeerConnection-setDescription-transceiver]
1. As described by [JSEP] (section 5.9.), attempt to find an existing
RTCRtpTransceiver object, transceiver, to represent the media description.
[RTCPeerConnection-ontrack]
2. If no suitable transceiver is found (transceiver is unset), run the following
steps:
[RTCPeerConnection-ontrack]
1. Create an RTCRtpSender, sender, from the media description.
[RTCPeerConnection-ontrack]
2. Create an RTCRtpReceiver, receiver, from the media description.
[RTCPeerConnection-ontrack]
3. Create an RTCRtpTransceiver with sender, receiver and direction, and let
transceiver be the result.
[RTCPeerConnection-ontrack]
3. Set transceiver's mid value to the mid of the corresponding media description.
If the media description has no MID, and transceiver's mid is unset, generate
a random value as described in [JSEP] (section 5.9.).
[RTCPeerConnection-ontrack]
4. If the direction of the media description is sendrecv or sendonly, and
transceiver.receiver.track has not yet been fired in a track event, process
the remote track for the media description, given transceiver.
[TODO RTCPeerConnection-setDescription-transceiver]
5. If the media description is rejected, and transceiver is not already stopped,
stop the RTCRtpTransceiver transceiver.
[TODO RTCPeerConnection-setDescription-transceiver]
9. If description is of type "rollback", then run the following steps:
[TODO RTCPeerConnection-setDescription-transceiver]
1. If the mid value of an RTCRtpTransceiver was set to a non-null value by
the RTCSessionDescription that is being rolled back, set the mid value
of that transceiver to null, as described by [JSEP] (section 4.1.8.2.).
[TODO RTCPeerConnection-setDescription-transceiver]
2. If an RTCRtpTransceiver was created by applying the RTCSessionDescription
that is being rolled back, and a track has not been attached to it via
addTrack, remove that transceiver from connection's set of transceivers,
as described by [JSEP] (section 4.1.8.2.).
[TODO RTCPeerConnection-setDescription-transceiver]
3. Restore the value of connection's [[SctpTransport]] internal slot to its
value at the last stable signaling state.
[RTCPeerConnection-onnegotiationneeded]
10. If connection's signaling state is now stable, update the negotiation-needed
flag. If connection's [[NegotiationNeeded]] slot was true both before and after
this update, queue a task that runs the following steps:
[Untestable]
1. If connection's [[IsClosed]] slot is true, abort these steps.
[RTCPeerConnection-onnegotiationneeded]
2. If connection's [[NegotiationNeeded]] slot is false, abort these steps.
[RTCPeerConnection-onnegotiationneeded]
3. Fire a simple event named negotiationneeded at connection.
[Trivial]
11. Resolve p with undefined.
[Trivial]
3. Return p.
Coverage Report
Tested 35
Not Tested 15
Untestable 8
Total 58
|
