mirror of
https://github.com/servo/servo.git
synced 2025-06-27 10:33:39 +01:00
240 lines
10 KiB
Text
240 lines
10 KiB
Text
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
|