Creates a new data channel with the given name, waiting until it opens before continuing.
Send a message or buffer on the connection's data channels.
This can take one or two arguments. If only one is provided, it is used as a message that's sent on all open data channels. If two arguments are provided, the first must be the data channel label, and the message (the second) will be sent only to data channel(s) with that label.
If no matching channels are open, this is a no-op. Use waitForChannel()
to ensure the channels you're expecting are open first if necessary.
Wait for a given duration, in milliseconds
Wait until the remote client has created at least one DataChannel.
Optional channelLabel: stringWait until the remote client next sends media data on a media track.
This waits for new media, ignoring any media already consumed by previous steps.
Wait until the remote client next sends a message to us on any DataChannel.
This looks for new messages, ignoring any messages already consumed by previous steps.
Wait until the remote client sends a message to us on a specific DataChannel.
This looks for new messages, ignoring any messages already consumed by previous steps.
Wait until the remote client has created at least one media track
Immediately close the connection.
This defines a final step, and will then create a mock peer from the full set of steps you've defined, and return it wrapped in a promise. As soon as the promise resolves the peer is ready to use.
Echo all incoming data channel messages until the other peer closes the connection.
This defines a final step, and will then create a mock peer from the full set of steps you've defined, and return it wrapped in a promise. As soon as the promise resolves the peer is ready to use.
Creates a new external connection to the given remote peer connection, matching the existing mocked connection, and then proxies all traffic through to that peer.
This defines a final step, and will then create a mock peer from the full set of steps you've defined, and return it wrapped in a promise. As soon as the promise resolves the peer is ready to use.
Proxy this connection dynamically to the 'real' target peer, whoever that may be.
This assumes that you have an existing external connection already set up and attached to this mock connection.
You can do that either by using hookWebRTCConnection or hookAllWebRTC to hook your connection during normal setup to automatically create an external offer to the real remote peer, or you can do so manually using createExternalOffer or answerExternalOffer and then passing the connection id as here.
This defines a final step, and will then create a mock peer from the full set of steps you've defined, and return it wrapped in a promise. As soon as the promise resolves the peer is ready to use.
Send a message or buffer on the connection's data channels, then close the
connection. This is equivalent to .send() then
.thenClose().
This defines a final step, and will then create a mock peer from the full set of steps you've defined, and return it wrapped in a promise. As soon as the promise resolves the peer is ready to use.
Match RTC connections made from hooked JavaScript running on a given hostname.
This only matches connections with explicit sourceURL metadata, which must be
either added automatically (by using the hookAllWebRTC or hookWebRTCConnection
methods) or manually (by providing metadata: { sourceURL: '...' } options
during mock connection setup).
Match RTC connections made from hooked JavaScript running on a matching URL.
This only matches connections with explicit sourceURL metadata, which must be
either added automatically (by using the hookAllWebRTC or hookWebRTCConnection
methods) or manually (by providing metadata: { sourceURL: '...' } options
during mock connection setup).
Match RTC connections made by hooked JavaScript running within a browser with a matching user agent string.
This only matches connections with explicit userAgent metadata, which must be
either added automatically (by using the hookAllWebRTC or hookWebRTCConnection
methods) or manually (by providing metadata: { userAgent: '...' } options
during mock connection setup).
Match RTC connections whose initial negotiation includes an audio media track
Match RTC connections whose initial negotiation includes a data channel.
Match RTC connections whose initial negotiation includes either an audio or video media track.
Match RTC connections whose initial negotiation includes a video media track
Generated using TypeDoc
Rule builders allow you to combine sets of matchers, progressively building a set of matching conditions, before defining the resulting behaviour that will be applied to matching traffic.