Adding upstream version 1:115.7.0.upstream/1%115.7.0upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 240 insertions, 0 deletions

diff --git a/testing/web-platform/tests/webrtc/coverage/set-session-description.txt b/testing/web-platform/tests/webrtc/coverage/set-session-description.txt
new file mode 100644
index 0000000000..f2bb422703
--- /dev/null
+++ b/testing/web-platform/tests/webrtc/coverage/set-session-description.txt
@@ -0,0 +1,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