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

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

3 files changed, 582 insertions, 0 deletions

diff --git a/testing/web-platform/tests/webrtc/coverage/RTCDTMFSender.txt b/testing/web-platform/tests/webrtc/coverage/RTCDTMFSender.txt
new file mode 100644
index 0000000000..aa30021323
--- /dev/null
+++ b/testing/web-platform/tests/webrtc/coverage/RTCDTMFSender.txt
@@ -0,0 +1,122 @@
+Coverage is based on the following editor draft:
+https://w3c.github.io/webrtc-pc/archives/20170605/webrtc.html
+
+7.  insertDTMF
+
+    [Trivial]
+    - The tones parameter is treated as a series of characters.
+
+    [RTCDTMFSender-insertDTMF]
+    - The characters 0 through 9, A through D, #, and * generate the associated
+      DTMF tones.
+
+    [RTCDTMFSender-insertDTMF]
+    - The characters a to d MUST be normalized to uppercase on entry and are equivalent
+      to A to D.
+
+    [RTCDTMFSender-insertDTMF]
+    - As noted in [RTCWEB-AUDIO] Section 3, support for the characters 0 through 9,
+      A through D, #, and * are required.
+
+    [RTCDTMFSender-insertDTMF]
+    - The character ',' MUST be supported, and indicates a delay of 2 seconds before
+      processing the next character in the tones parameter.
+
+    [RTCDTMFSender-insertDTMF]
+    - All other characters (and only those other characters) MUST
+      be considered unrecognized.
+
+    [Trivial]
+    - The duration parameter indicates the duration in ms to use for each character passed
+      in the tones parameters.
+
+    [RTCDTMFSender-ontonechange]
+    - The duration cannot be more than 6000 ms or less than 40 ms.
+
+    [RTCDTMFSender-ontonechange]
+    - The default duration is 100 ms for each tone.
+
+    [RTCDTMFSender-ontonechange]
+    - The interToneGap parameter indicates the gap between tones in ms. The user agent
+      clamps it to at least 30 ms. The default value is 70 ms.
+
+    [Untestable]
+    - The browser MAY increase the duration and interToneGap times to cause the times
+      that DTMF start and stop to align with the boundaries of RTP packets but it MUST
+      not increase either of them by more than the duration of a single RTP audio packet.
+
+    [Trivial]
+    When the insertDTMF() method is invoked, the user agent MUST run the following steps:
+
+      [Trivial]
+      1.  let sender be the RTCRtpSender used to send DTMF.
+
+      [Trivial]
+      2.  Let transceiver be the RTCRtpTransceiver object associated with sender.
+
+      [RTCDTMFSender-insertDTMF]
+      3.  If transceiver.stopped is true, throw an InvalidStateError.
+
+      [RTCDTMFSender-insertDTMF]
+      4.  If transceiver.currentDirection is recvonly or inactive, throw an
+          InvalidStateError.
+
+      [Trivial]
+      5.  Let tones be the method's first argument.
+
+      [RTCDTMFSender-insertDTMF]
+      6.  If tones contains any unrecognized characters, throw an InvalidCharacterError.
+
+      [RTCDTMFSender-insertDTMF]
+      7.  Set the object's toneBuffer attribute to tones.
+
+      [RTCDTMFSender-ontonechange]
+      8.  If the value of the duration parameter is less than 40, set it to 40.
+
+          [RTCDTMFSender-ontonechange-long]
+          If, on the other hand, the value is greater than 6000, set it to 6000.
+
+      [RTCDTMFSender-ontonechange]
+      9.  If the value of the interToneGap parameter is less than 30, set it to 30.
+
+      [RTCDTMFSender-ontonechange]
+      10. If toneBuffer is an empty string, abort these steps.
+
+      [RTCDTMFSender-ontonechange]
+      11. If a Playout task is scheduled to be run; abort these steps;
+
+          [RTCDTMFSender-ontonechange]
+          otherwise queue a task that runs the following steps (Playout task):
+
+          [RTCDTMFSender-ontonechange]
+          1.  If transceiver.stopped is true, abort these steps.
+
+          [RTCDTMFSender-ontonechange]
+          2.  If transceiver.currentDirection is recvonly or inactive, abort these steps.
+
+          [RTCDTMFSender-ontonechange]
+          3.  If toneBuffer is an empty string, fire an event named tonechange with an
+              empty string at the RTCDTMFSender object and abort these steps.
+
+          [RTCDTMFSender-ontonechange]
+          4.  Remove the first character from toneBuffer and let that character be tone.
+
+          [Untestable]
+          5.  Start playout of tone for duration ms on the associated RTP media stream,
+              using the appropriate codec.
+
+          [RTCDTMFSender-ontonechange]
+          6.  Queue a task to be executed in duration + interToneGap ms from now that
+              runs the steps labelled Playout task.
+
+          [RTCDTMFSender-ontonechange]
+          7.  Fire an event named tonechange with a string consisting of tone at the
+              RTCDTMFSender object.
+
+Coverage Report
+
+  Tested        31
+  Not Tested     0
+  Untestable     1
+
+  Total         32
diff --git a/testing/web-platform/tests/webrtc/coverage/identity.txt b/testing/web-platform/tests/webrtc/coverage/identity.txt
new file mode 100644
index 0000000000..0d1bcca7ed
--- /dev/null
+++ b/testing/web-platform/tests/webrtc/coverage/identity.txt
@@ -0,0 +1,220 @@
+Coverage is based on the following editor draft:
+https://w3c.github.io/webrtc-pc/archives/20170605/webrtc.html
+
+9.3 Requesting Identity Assertions
+
+  [Trivial]
+  The identity assertion request process is triggered by a call to createOffer,
+  createAnswer, or getIdentityAssertion. When these calls are invoked and an
+  identity provider has been set, the following steps are executed:
+
+    [RTCPeerConnection-getIdentityAssertion]
+    1.  The RTCPeerConnection instantiates an IdP as described in Identity Provider
+        Selection and Registering an IdP Proxy. If the IdP cannot be loaded, instantiated,
+        or the IdP proxy is not registered, this process fails.
+
+    [RTCPeerConnection-getIdentityAssertion]
+    2.  The RTCPeerConnection invokes the generateAssertion method on the
+        RTCIdentityProvider methods registered by the IdP.
+
+        [RTCPeerConnection-getIdentityAssertion]
+        The RTCPeerConnection generates the contents parameter to this method as
+        described in [RTCWEB-SECURITY-ARCH]. The value of contents includes the
+        fingerprint of the certificate that was selected or generated during the
+        construction of the RTCPeerConnection. The origin parameter contains the
+        origin of the script that calls the RTCPeerConnection method that triggers
+        this behavior. The usernameHint value is the same value that is provided
+        to setIdentityProvider, if any such value was provided.
+
+    [RTCPeerConnection-getIdentityAssertion]
+    3.  The IdP proxy returns a Promise to the RTCPeerConnection. The IdP proxy is
+        expected to generate the identity assertion asynchronously.
+
+        [RTCPeerConnection-getIdentityAssertion]
+        If the user has been authenticated by the IdP, and the IdP is able to generate
+        an identity assertion, the IdP resolves the promise with an identity assertion
+        in the form of an RTCIdentityAssertionResult .
+
+        [RTCPeerConnection-getIdentityAssertion]
+        This step depends entirely on the IdP. The methods by which an IdP authenticates
+        users or generates assertions is not specified, though they could involve
+        interacting with the IdP server or other servers.
+
+    [RTCPeerConnection-getIdentityAssertion]
+    4.  If the IdP proxy produces an error or returns a promise that does not resolve
+        to a valid RTCIdentityValidationResult (see 9.5 IdP Error Handling), then
+        identity validation fails.
+
+    [Untestable]
+    5.  The RTCPeerConnection MAY store the identity assertion for use with future
+        offers or answers. If a fresh identity assertion is needed for any reason,
+        applications can create a new RTCPeerConnection.
+
+    [RTCPeerConnection-getIdentityAssertion]
+    6.  If the identity request was triggered by a createOffer() or createAnswer(),
+        then the assertion is converted to a JSON string, base64-encoded and inserted
+        into an a=identity attribute in the session description.
+
+    [RTCPeerConnection-getIdentityAssertion]
+    If assertion generation fails, then the promise for the corresponding function call
+    is rejected with a newly created OperationError.
+
+9.3.1 User Login Procedure
+  [RTCPeerConnection-getIdentityAssertion]
+  An IdP MAY reject an attempt to generate an identity assertion if it is unable to
+  verify that a user is authenticated. This might be due to the IdP not having the
+  necessary authentication information available to it (such as cookies).
+
+  [RTCPeerConnection-getIdentityAssertion]
+  Rejecting the promise returned by generateAssertion will cause the error to propagate
+  to the application. Login errors are indicated by rejecting the promise with an RTCError
+  with errorDetail set to "idp-need-login".
+
+  [RTCPeerConnection-getIdentityAssertion]
+  The URL to login at will be passed to the application in the idpLoginUrl attribute of
+  the RTCPeerConnection.
+
+  [Out of Scope]
+  An application can load the login URL in an IFRAME or popup window; the resulting page
+  then SHOULD provide the user with an opportunity to enter any information necessary to
+  complete the authorization process.
+
+  [Out of Scope]
+  Once the authorization process is complete, the page loaded in the IFRAME or popup sends
+  a message using postMessage [webmessaging] to the page that loaded it (through the
+  window.opener attribute for popups, or through window.parent for pages loaded in an IFRAME).
+  The message MUST consist of the DOMString "LOGINDONE". This message informs the application
+  that another attempt at generating an identity assertion is likely to be successful.
+
+9.4.  Verifying Identity Assertions
+  The identity assertion request process involves the following asynchronous steps:
+
+    [TODO]
+    1.  The RTCPeerConnection awaits any prior identity validation. Only one identity
+        validation can run at a time for an RTCPeerConnection. This can happen because
+        the resolution of setRemoteDescription is not blocked by identity validation
+        unless there is a target peer identity.
+
+    [RTCPeerConnection-peerIdentity]
+    2.  The RTCPeerConnection loads the identity assertion from the session description
+        and decodes the base64 value, then parses the resulting JSON. The idp parameter
+        of the resulting dictionary contains a domain and an optional protocol value
+        that identifies the IdP, as described in [RTCWEB-SECURITY-ARCH].
+
+    [RTCPeerConnection-peerIdentity]
+    3.  The RTCPeerConnection instantiates the identified IdP as described in 9.1.1
+        Identity Provider Selection and 9.2 Registering an IdP Proxy. If the IdP
+        cannot be loaded, instantiated or the IdP proxy is not registered, this
+        process fails.
+
+    [RTCPeerConnection-peerIdentity]
+    4.  The RTCPeerConnection invokes the validateAssertion method registered by the IdP.
+
+        [RTCPeerConnection-peerIdentity]
+        The assertion parameter is taken from the decoded identity assertion. The origin
+        parameter contains the origin of the script that calls the RTCPeerConnection
+        method that triggers this behavior.
+
+    [RTCPeerConnection-peerIdentity]
+    5.  The IdP proxy returns a promise and performs the validation process asynchronously.
+
+        [Out of Scope]
+        The IdP proxy verifies the identity assertion using whatever means necessary.
+        Depending on the authentication protocol this could involve interacting with the
+        IdP server.
+
+    [RTCPeerConnection-peerIdentity]
+    6.  If the IdP proxy produces an error or returns a promise that does not resolve
+        to a valid RTCIdentityValidationResult (see 9.5 IdP Error Handling), then
+        identity validation fails.
+
+    [RTCPeerConnection-peerIdentity]
+    7.  Once the assertion is successfully verified, the IdP proxy resolves the promise
+        with an RTCIdentityValidationResult containing the validated identity and the
+        original contents that are the payload of the assertion.
+
+    [RTCPeerConnection-peerIdentity]
+    8.  The RTCPeerConnection decodes the contents and validates that it contains a
+        fingerprint value for every a=fingerprint attribute in the session description.
+        This ensures that the certificate used by the remote peer for communications
+        is covered by the identity assertion.
+
+    [RTCPeerConnection-peerIdentity]
+    9.  The RTCPeerConnection validates that the domain portion of the identity matches
+        the domain of the IdP as described in [RTCWEB-SECURITY-ARCH]. If this check fails
+        then the identity validation fails.
+
+    [RTCPeerConnection-peerIdentity]
+    10. The RTCPeerConnection resolves the peerIdentity attribute with a new instance
+        of RTCIdentityAssertion that includes the IdP domain and peer identity.
+
+    [Out of Scope]
+    11. The user agent MAY display identity information to a user in its UI. Any user
+        identity information that is displayed in this fashion MUST use a mechanism that
+        cannot be spoofed by content.
+
+  [RTCPeerConnection-peerIdentity]
+  If identity validation fails, the peerIdentity promise is rejected with a newly
+  created OperationError.
+
+  [RTCPeerConnection-peerIdentity]
+  If identity validation fails and there is a target peer identity for the
+  RTCPeerConnection, the promise returned by setRemoteDescription MUST be rejected
+  with the same DOMException.
+
+9.5.  IdP Error Handling
+  [RTCPeerConnection-getIdentityAssertion]
+  - A RTCPeerConnection might be configured with an identity provider, but loading of
+    the IdP URI fails. Any procedure that attempts to invoke such an identity provider
+    and cannot load the URI fails with an RTCError with errorDetail set to
+    "idp-load-failure" and the httpRequestStatusCode attribute of the error set to the
+    HTTP status code of the response.
+
+  [Untestable]
+  - If the IdP loads fails due to the TLS certificate used for the HTTPS connection not
+    being trusted, it fails with an RTCError with errorDetail set to "idp-tls-failure".
+    This typically happens when the IdP uses certificate pinning and an intermediary
+    such as an enterprise firewall has intercepted the TLS connection.
+
+  [RTCPeerConnection-getIdentityAssertion]
+  - If the script loaded from the identity provider is not valid JavaScript or does not
+    implement the correct interfaces, it causes an IdP failure with an RTCError with
+    errorDetail set to "idp-bad-script-failure".
+
+  [TODO]
+  - An apparently valid identity provider might fail in several ways.
+
+    If the IdP token has expired, then the IdP MUST fail with an RTCError with
+    errorDetail set to "idp-token-expired".
+
+    If the IdP token is not valid, then the IdP MUST fail with an RTCError with
+    errorDetail set to "idp-token-invalid".
+
+  [Untestable]
+  - The user agent SHOULD limit the time that it allows for an IdP to 15 seconds.
+    This includes both the loading of the IdP proxy and the identity assertion
+    generation or validation. Failure to do so potentially causes the corresponding
+    operation to take an indefinite amount of time. This timer can be cancelled when
+    the IdP proxy produces a response. Expiration of this timer cases an IdP failure
+    with an RTCError with errorDetail set to "idp-timeout".
+
+  [RTCPeerConnection-getIdentityAssertion]
+  - If the identity provider requires the user to login, the operation will fail
+    RTCError with errorDetail set to "idp-need-login" and the idpLoginUrl attribute
+    of the error set to the URL that can be used to login.
+
+  [RTCPeerConnection-peerIdentity]
+  - Even when the IdP proxy produces a positive result, the procedure that uses this
+    information might still fail. Additional validation of a RTCIdentityValidationResult
+    value is still necessary. The procedure for validation of identity assertions
+    describes additional steps that are required to successfully validate the output
+    of the IdP proxy.
+
+
+Coverage Report
+
+  Tested        29
+  Not Tested     2
+  Untestable     4
+
+  Total         35
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