WebRTC 1.0: Real-time Communication Between Browsers

Table of Contents

• 1. Introduction
• 2. Obtaining local multimedia content
  • 2.1 Definition
    • 2.1.1 NavigatorUserMedia
      • 2.1.1.1 Methods
    • 2.1.2 NavigatorUserMediaSuccessCallback
      • 2.1.2.1 Methods
    • 2.1.3 NavigatorUserMediaError and NavigatorUserMediaErrorCallback
      • 2.1.3.1 Attributes
      • 2.1.3.2 Constants
      • 2.1.3.3 Methods
  • 2.2 Examples
• 3. Stream API
  • 3.1 Introduction
  • 3.2 Interface definitions
    • 3.2.1 MediaStream
      • 3.2.1.1 Attributes
      • 3.2.1.2 Methods
      • 3.2.1.3 Constants
    • 3.2.2 LocalMediaStream
      • 3.2.2.1 Methods
    • 3.2.3 MediaStreamTrack
      • 3.2.3.1 Attributes
    • 3.2.4 MediaStreamRecorder
      • 3.2.4.1 Methods
    • 3.2.5 BlobCallback
      • 3.2.5.1 Methods
    • 3.2.6 URL
      • 3.2.6.1 Methods
  • 3.3 Examples
• 4. Peer-to-peer connections
  • 4.1 PeerConnection
    • 4.1.1 Attributes
    • 4.1.2 Methods
    • 4.1.3 Constants
  • 4.2 SignalingCallback
    • 4.2.1 Methods
  • 4.3 Examples
• 5. The data stream
  • 5.1 Security considerations
• 6. Garbage collection
• 7. Event definitions
  • 7.1 MediaStreamEvent
    • 7.1.1 Attributes
    • 7.1.2 Methods
• 8. Event summary
• 9. application/html-peer-connection-data
• A. Acknowledgements
• B. References
  • B.1 Normative references
  • B.2 Informative references

2. Obtaining local multimedia content

[NoInterfaceObject]
interface NavigatorUserMedia {
    void getUserMedia (in DOMString options, in NavigatorUserMediaSuccessCallback? successCallback, in optional NavigatorUserMediaErrorCallback? errorCallback);
};

Navigator implements NavigatorUserMedia;

[Callback=FunctionOnly, NoInterfaceObject]
interface NavigatorUserMediaSuccessCallback {
    void handleEvent (in LocalMediaStream stream);
};

[NoInterfaceObject]
interface NavigatorUserMediaError {
    const unsigned short PERMISSION_DENIED = 1;
    readonly attribute unsigned short code;
};

[Callback=FunctionOnly, NoInterfaceObject]
interface NavigatorUserMediaErrorCallback {
    void handleEvent (in NavigatorUserMediaError error);
};

<script>
 navigator.getUserMedia('audio', gotAudio);
 function gotAudio(stream) {
   // ... use 'stream' ...
 }
</script>

<script>
 function beginCall() {
   navigator.getUserMedia('audio,video user', gotStream);
 }
 function gotStream(stream) {
   // ... use 'stream' ...
 }
</script>

3. Stream API

[Constructor (in MediaStream parentStream)]
interface MediaStream {
    readonly attribute DOMString            label;
    readonly attribute MediaStreamTrackList tracks;
    MediaStreamRecorder record ();
    const unsigned short LIVE = 1;
    const unsigned short ENDED = 2;
    readonly attribute unsigned short       readyState;
             attribute Function?            onended;
};

MediaStream implements EventTarget;

interface LocalMediaStream : MediaStream {
    void stop ();
};

typedef MediaStreamTrack[] MediaStreamTrackList;

interface MediaStreamTrack {
    readonly attribute DOMString kind;
    readonly attribute DOMString label;
             attribute boolean   enabled;
};

interface MediaStreamRecorder {
    voice getRecordedData (in BlobCallback? callback);
};

[Callback=FunctionOnly, NoInterfaceObject]
interface BlobCallback {
    void handleEvent (in Blob blob);
};

interface URL {
    static DOMString createObjectURL (in MediaStream stream);
};

<input type="button" value="Start" onclick="start()" id="startBtn">
<script>
 var startBtn = document.getElementById('startBtn');
 function start() {
   navigator.getUserMedia('audio,video', gotStream);
   startBtn.disabled = true;
 }
 function gotStream(stream) {
   stream.onended = function () {
     startBtn.disabled = false;
   }
 }
</script>

<input type="button" value="⚫" onclick="msgRecord()" id="recBtn">
<input type="button" value="◼" onclick="msgStop()" id="stopBtn" disabled>
<p id="status">To start recording, press the ⚫ button.</p>
<script>
 var recBtn = document.getElementById('recBtn');
 var stopBtn = document.getElementById('stopBtn');
 function report(s) {
   document.getElementById('status').textContent = s;
 }
 function msgRecord() {
   report('Attempting to access microphone...');
   navigator.getUserMedia('audio', gotStream, noStream);
   recBtn.disabled = true;
 }
 var msgStream, msgStreamRecorder;
 function gotStream(stream) {
   report('Recording... To stop, press to ◼ button.');
   msgStream = stream;
   msgStreamRecorder = stream.record();
   stopBtn.disabled = false;
   stream.onended = function () {
     msgStop();     
   }
 }
 function msgStop() {
   report('Creating file...');
   stopBtn.disabled = true;
   msgStream.onended = null;
   msgStream.stop();
   msgStreamRecorder.getRecordedData(msgSave);
 }
 function msgSave(blob) {
   report('Uploading file...');
   var x = new XMLHttpRequest();
   x.open('POST', 'uploadMessage');
   x.send(blob);
   x.onload = function () {
     report('Done! To record a new message, press the ⚫ button.');
     recBtn.disabled = false;
   };
   x.onerror = function () {
     report('Failed to upload message. To try recording a message again, press the ⚫ button.');
     recBtn.disabled = false;
   };
 }
 function noStream() {
   report('Could not obtain access to your microphone. To try again, press the ⚫ button.');
   recBtn.disabled = false;
 }
</script>

<article>
 <style scoped>
  video { transform: scaleX(-1); }
  p { text-align: center; }
 </style>
 <h1>Snapshot Kiosk</h1>
 <section id="splash">
  <p id="errorMessage">Loading...</p>
 </section>
 <section id="app" hidden>
  <p><video id="monitor" autoplay></video> <canvas id="photo"></canvas>
  <p><input type=button value="&#x1F4F7;" onclick="snapshot()">
 </section>
 <script>
  navigator.getUserMedia('video user', gotStream, noStream);
  var video = document.getElementById('monitor');
  var canvas = document.getElementById('photo');
  function gotStream(stream) {
    video.src = URL.getObjectURL(stream);
    video.onerror = function () {
      stream.stop();
    };
    stream.onended = noStream;
    video.onloadedmetadata = function () {
      canvas.width = video.videoWidth;
      canvas.height = video.videoHeight;
      document.getElementById('splash').hidden = true;
      document.getElementById('app').hidden = false;
    };
  }
  function noStream() {
    document.getElementById('errorMessage').textContent = 'No camera available.';
  }
  function snapshot() {
    canvas.getContext('2d').drawImage(video, 0, 0);
  }
 </script>
</article>

4. Peer-to-peer connections

A PeerConnection allows two users to communicate directly, browser-to-browser. Communications are coordinated via a signaling channel provided by script in the page via the server, e.g. using XMLHttpRequest.

Calling "new PeerConnection(configuration, signalingCallback)" creates a PeerConnection object.

The configuration string gives the address of a STUN or TURN server to use to establish the connection. [STUN] [TURN]

The allowed formats for this string are:

"TYPE 203.0.113.2:3478"

Indicates a specific IP address and port for the server.

"TYPE relay.example.net:3478"

Indicates a specific host and port for the server; the user agent will look up the IP address in DNS.

"TYPE example.net"

Indicates a specific domain for the server; the user agent will look up the IP address and port in DNS.

The "TYPE" is one of:

STUN

Indicates a STUN server

STUNS

Indicates a STUN server that is to be contacted using a TLS session.

TURN

Indicates a TURN server

TURNS

Indicates a TURN server that is to be contacted using a TLS session.

The signalingCallback argument is a method that will be invoked when the user agent needs to send a message to the other host over the signaling channel. When the callback is invoked, convey its first argument (a string) to the other peer using whatever method is being used by the Web application to relay signaling messages. (Messages returned from the other peer are provided back to the user agent using the processSignalingMessage() method.)

A PeerConnection object has an associated PeerConnection signaling callback, a PeerConnection ICE Agent, a PeerConnection data UDP media stream, a PeerConnection readiness state and an ICE started flag. These are initialized when the object is created.

When the PeerConnection() constructor is invoked, the user agent must run the following steps. This algorithm has a synchronous section (which is triggered as part of the event loop algorithm). Steps in the synchronous section are marked with ⌛.

1. Let serverConfiguration be the constructor's first argument.

2. Let signalingCallback be the constructor's second argument.

3. Let connection be a newly created PeerConnection object.

4. Create an ICE Agent and let connection's PeerConnection ICE Agent be that ICE Agent. [ICE]

5. If serverConfiguration contains a U+000A LINE FEED (LF) character or a U+000D CARRIAGE RETURN (CR) character (or both), remove all characters from serverConfiguration after the first such character.

6. Split serverConfiguration on spaces to obtain configuration components.

7. If configuration components has two or more components, and the first component is a case-sensitive match for one of the following strings:

   • "STUN"
   • "STUNS"
   • "TURN"
   • "TURNS"

   ...then run the following substeps:

   1. Let server type be STUN if the first component of configuration components is "STUN" or "STUNS", and TURN otherwise (the first component of configuration components is "TURN" or "TURNS").

   2. Let secure be true if the first component of configuration components is "STUNS" or "TURNS", and false otherwise.

   3. Let host be the contents of the second component of configuration components up to the character before the first U+003A COLON character (:), if any, or the entire string otherwise.

   4. Let port be the contents of the second component of configuration components from the character after the first U+003A COLON character (:) up to the end, if any, or the empty string otherwise.

   5. Configure the PeerConnection ICE Agent's STUN or TURN server as follows:

      • If server type is STUN, the server is a STUN server. Otherwise, server type is TURN and the server is a TURN server.
      • If secure is true, the server is to be contacted using TLS-over-TCP, otherwise, it is to be contacted using UDP.
      • The IP address, host name, or domain name of the server is host.
      • The port to use is port. If this is the empty string, then only a domain name is configured (and the ICE Agent will use DNS SRV requests to determine the IP address and port).
      • The long-term username for the STUN or TURN server is the ASCII serialization of the entry script's origin; the long-term password is the empty string.

      If the given IP address, host name, domain name, or port are invalid, then the user agent must act as if no STUN or TURN server is configured.

8. Let the connection's PeerConnection signaling callback be signalingCallback.

9. Set connection's PeerConnection readiness state to NEW (0).

10. Set connection's ICE started flag to false.

11. Let connection's PeerConnection data UDP media stream be a new data UDP media stream.

12. Let connection's localStreams attribute be an empty read-only MediaStream array. [WEBIDL]

13. Let connection's remoteStreams attribute be an empty read-only MediaStream array. [WEBIDL]

14. Return connection, but continue these steps asynchronously.

15. Await a stable state. The synchronous section consists of the remaining steps of this algorithm. (Steps in synchronous sections are marked with ⌛.)

16. ⌛ If connection's ICE started flag is still false, start the PeerConnection ICE Agent and send the initial offer. The initial offer must include a media description for the PeerConnection data UDP media stream, marked as "sendrecv", and for all the streams in localStreams (marked as "sendonly"). [ICE] [SDPOFFERANSWER]

17. ⌛ Let connection's ICE started flag be true.

18. ⌛ If connection's PeerConnection readiness state is still NEW (0), then queue a task that sets it to NEGOTIATING (1) and then fires a simple event named connecting at the PeerConnection object.

When a PeerConnection ICE Agent is required to send SDP offers or answers, the user agent must follow these steps:

1. Let sdp be the SDP offer or answer to be sent. [SDPOFFERANSWER]

2. Let message be the concatenation of the string "SDP", a U+000A LINE FEED (LF) character, and sdp, in that order.

3. Queue a task to invoke that PeerConnection ICE Agent's PeerConnection signaling callback with message as its first argument and the PeerConnection as its second argument.

All streams represented by MediaStream objects must be marked as "sendonly" by the peer that initially adds the stream to the session. The PeerConnection API does not support bidirectional ("sendrecv") audio or video media streams. [SDPOFFERANSWER]

User agents may negotiate any codec and any resolution, bitrate, or other quality metric. User agents are encouraged to initially negotiate for the native resolution of the stream. For streams that are then rendered (using a video element), user agents are encouraged to renegotiate for a resolution that matches the rendered display size.

Starting with the native resolution means that if the Web application notifies its peer of the native resolution as it starts sending data, and the peer prepares its video element accordingly, there will be no need for a renegotiation once the stream is flowing.

All SDP media descriptions for streams represented by MediaStream objects must include a label attribute ("a=label:") whose value is the value of the MediaStream object's label attribute. [SDP] [SDPLABEL]

PeerConnection ICE Agents must not generate any candidates for media streams whose media descriptions do not have a label attribute ("a=label:"). [ICE] [SDP] [SDPLABEL]

When a user agent starts receiving media for a component and a candidate was provided for that component by a PeerConnection ICE Agent, the user agent must follow these steps:

1. Let connection be the PeerConnection whose ICE Agent is expecting this media.

2. If there is already a MediaStream object for the media stream to which this component belongs, then associate the component with that media stream and abort these steps. (Some media streams have multiple components; this API does not expose the role of these individual components in ICE.)

3. Create a MediaStream object to represent the media stream. Set its label attribute to the value of the SDP Label attribute for that component's media stream.

4. Queue a task to run the following substeps:

   1. If the connection's PeerConnection readiness state is CLOSED (3), abort these steps.

   2. Add the newly created MediaStream object to the end of connection's remoteStreams array.

   3. Fire a stream event named addstream with the newly created MediaStream object at the connection object.

When a PeerConnection ICE Agent finds that a stream from the remote peer has been removed (its port has been set to zero in a media description sent on the signaling channel), the user agent must follow these steps:

1. Let connection be the PeerConnection whose PeerConnection ICE Agent has determined that a stream is being removed.

2. Let stream be the MediaStream object that represents the media stream being removed, if any. If there isn't one, then abort these steps.

3. By definition, stream is now finished.

   A task is thus queued to update stream and fire an event.

4. Queue a task to run the following substeps:

   1. If the connection's PeerConnection readiness state is CLOSED (3), abort these steps.

   2. Remove stream from connection's remoteStreams array.

   3. Fire a stream event named removestream with stream at the connection object.

The task source for the tasks listed in this section is the networking task source.

To prevent network sniffing from allowing a fourth party to establish a connection to a peer using the information sent out-of-band to the other peer and thus spoofing the client, the configuration information should always be transmitted using an encrypted connection.

[Constructor (in DOMString configuration, in SignalingCallback signalingCallback)]
interface PeerConnection {
    void processSignalingMessage (in DOMString message);
    const unsigned short NEW = 0;
    const unsigned short NEGOTIATING = 1;
    const unsigned short ACTIVE = 2;
    const unsigned short CLOSED = 3;
    readonly attribute unsigned short readyState;
    void send (in DOMString text);
    void addStream (in MediaStream stream);
    void removeStream (in MediaStream stream);
    readonly attribute MediaStream[]  localStreams;
    readonly attribute MediaStream[]  remoteStreams;
    void close ();
             attribute Function?      onconnecting;
             attribute Function?      onopen;
             attribute Function?      onmessage;
             attribute Function?      onaddstream;
             attribute Function?      onremovestream;
};

PeerConnection implements EventTarget;

[Callback=FunctionOnly, NoInterfaceObject]
interface SignalingCallback {
    void handleEvent (in DOMString message, in PeerConnection source);
};

// the first argument describes the STUN/TURN server configuration
var local = new PeerConnection('TURNS example.net', sendSignalingChannel);
local.signalingChannel(...); // if we have a message from the other side, pass it along here

// (aLocalStream is some LocalMediaStream object)
local.addStream(aLocalStream); // start sending video

function sendSignalingChannel(message) {
  ... // send message to the other side via the signaling channel
}

function receiveSignalingChannel (message) {
  // call this whenever we get a message on the signaling channel
  local.signalingChannel(message);
}

local.onaddstream = function (event) {
  // (videoElement is some <video> element)
  videoElement.src = URL.getObjectURL(event.stream);
};

5. The data stream

All PeerConnection connections include a data UDP media stream, which is used to send data packets peer-to-peer, for instance game control packets. This data channel is unreliable (packets are not guaranteed to be delivered), and packets received out of order are discarded.

SDP media descriptions for data UDP media streams must use the "application" media type, the "udp" transport protocol, and the "application/html-peer-connection-data" media format description. [SDP]

All SDP media descriptions for data UDP media streams must include a label attribute ("a=label:") whose value is the string "data". [SDP] [SDPLABEL]

All SDP media descriptions for data UDP media streams must also include a key field ("k="), with the value being a base64-encoded representation of 16 cryptographically random bytes determined on a per-ICE-Agent basis. [SDP]

PeerConnection ICE Agents must attempt to establish a connection for their PeerConnection data UDP media stream with the initial offer/answer exchange, and must maintain that UDP media stream for the ICE Agents' whole lifetime.

Each PeerConnection data UDP media stream has a sending sequence number, which must initially be set to one (1), and a most recently received sequence number, much must initially be zero (0).

A data UDP media stream is an active data UDP media stream if the PeerConnection ICE Agent has selected a destination for it. A data UDP media stream can change active status many times during the lifetime of its PeerConnection object (e.g. any time the network topology changes and the ICE Agent performs an ICE Restart). [ICE]

Bytes transmitted on a data UDP media stream are masked so as to prevent cross-protocol attacks (data UDP media stream always appear to contain random noise to other protocols). For the purposes of masking, the data UDP media stream masking salt is defined to be the following 16 bytes, described here as hexadecimal numbers: DB 68 B5 FD 17 0E 15 77 56 AF 7A 3A 1A 57 75 02

Bytes transmitted on a data UDP media stream are also hashed so as to prevent forgery attacks (an attacker cannot change the data without knowing the key negotiated via the signaling channel). For the purposes of this hashing, the data UDP media stream hashing salt is defined to be the following 16 bytes, described here as hexadecimal numbers: 4E 2F 96 AB 0A 39 92 A2 56 94 91 F5 7E 58 2E FA

When the user agent is to transmit a data packet to a peer using a data UDP media stream and with a byte string payload raw message, the user agent must run the following steps:

1. Let nonce be 16 cryptographically random bytes.

2. Let ice-key be the 16 bytes given as the encryption key for the data UDP media stream in its media description, as defined above.

3. Let sending sequence number be the current sending sequence number.

4. Increment the sending sequence number by one (1).

5. Let mask-key be the first 16 bytes of the HMAC-SHA1 of the 16 data UDP media stream masking salt bytes keyed with the 16 ice-key bytes. [HMAC] [SHA1]

6. Let typed raw message be the concatenation of the sequence number as a big-endian 64 bit integer, three 0x00 bytes, a 0x01 byte, and raw message.

7. Let masked message be the result of encrypting typed raw message using AES-128-CTR keyed with mask-key and using the 16 nonce bytes as the initial counter value. [AES]

8. Let masked message with nonce be the concatenation of nonce and masked message.

9. Let hash-key be the first 16 bytes of the HMAC-SHA1 of the 16 data UDP media stream hashing salt bytes keyed with the 16 ice-key bytes. [HMAC] [SHA1]

10. Let hash be the first 16 bytes of the HMAC-SHA1 of masked message with nonce keyed with the 16 hash-key bytes. [HMAC] [SHA1]

11. Let hashed masked message with nonce be the concatenation of hash and masked message with nonce.

12. Send hashed masked message with nonce in a UDP packet to the destination that the relevant PeerConnection ICE Agent has selected a destination for the data UDP media stream.

When a packet that is part of a data UDP media stream is received, the user agent must run the following steps:

1. Let hashed masked message with nonce be the UDP packet's data.

2. If hashed masked message with nonce is shorter than 32 bytes, then abort these steps.

3. Let ice-key be the 16 bytes given as the encryption key for the data UDP media stream in the media description for this media stream. [SDP]

4. Let hash-key be the first 16 bytes of the HMAC-SHA1 of the 16 data UDP media stream hashing salt bytes keyed with the 16 ice-key bytes. [HMAC] [SHA1]

5. Let hash be the first 16 bytes of the hashed masked message with nonce.

6. Let masked message with nonce be all but the first 16 bytes of hashed masked message with nonce.

7. If hash does not equal the first 16 bytes of the HMAC-SHA1 of masked message with nonce keyed with the 16 hash-key bytes, abort these steps. [HMAC] [SHA1]

8. Let nonce be the first 16 bytes of the masked message with nonce.

9. Let masked message be all but the first 16 bytes of masked message with nonce.

10. Let mask-key be the first 16 bytes of the HMAC-SHA1 of the 16 data UDP media stream masking salt bytes keyed with the 16 ice-key bytes. [HMAC] [SHA1]

11. Let typed raw message be the result of decrypting masked message using AES-128-CTR keyed with mask-key and using the 16 nonce bytes as the initial counter value. [AES]

12. Let sequence number be the result of interpreting the first eight bytes of typed raw message as a 64 bit big-endian integer.

13. If sequence number is less than the most recently received sequence number then abort these steps.

14. Let the most recently received sequence number be sequence number.

15. If the ninth, tenth, eleventh, and twelfth bytes of typed raw message are not 0x00, 0x00, 0x00, and 0x01 respectively, then abort these steps.

16. Let raw message be the byte string consisting of all but the first twelve bytes of typed raw message.

17. Let message be raw message decoded as UTF-8, with error handling.

18. Create an event that uses the MessageEvent interface, with the name message, which does not bubble, is not cancelable, has no default action, and has a data attribute whose value is message, and queue a task to dispatch the event at the PeerConnection object responsible for this side of the data UDP media stream.

Though described above as being computed for each packet, the ice-key, hash-key, and mask-key values can be precomputed as soon as the PeerConnection ICE Agent is started.

                /'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''.
+--------------+ +---------------+ +-ENCRYPTED------------------------------------------------------------+ :
| 16 byte hash | | 16 byte nonce | | [ 8 bytes of sequence number ] [ 4 bytes of frame type ] [ data... ] | :
+--------------+ +---------------+ +----------------------------------------------------------------------+ :
                \...........................................................................................'

A remotely-initiated data UDP media stream is the first "sendrecv" media stream in the initial offer whose media is "application", whose transport protocol is "udp", whose media format description is "application/html-peer-connection-data", and whose label attribute ("a=label:") has the value "data".

The task source for this task is the networking task source.

6. Garbage collection

A Window object has a strong reference to any PeerConnection objects created from the constructor whose global object is that Window object.

7. Event definitions

The addstream and removestream events use the MediaStreamEvent interface:

interface MediaStreamEvent : Event {
    readonly attribute MediaStream? stream;
    void initMediaStreamEvent (in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in MediaStream? streamArg);
};

9. application/html-peer-connection-data

This registration is for community review and will be submitted to the IESG for review, approval, and registration with IANA.

Type name:

application

Subtype name:

html-peer-connection-data

Required parameters:

No required parameters

Optional parameters:

No optional parameters

Encoding considerations:

This MIME type defines a binary protocol format which uses UTF-8 for text encoding.

Security considerations:

This format is used for encoding UDP packets transmitted by potentially hostile Web page content via a trusted user agent to a destination selected by a potentially hostile remote server. To prevent this mechanism from being abused for cross-protocol attacks, all the data in these packets is masked so as to appear to be random noise. The intent of this masking is to reduce the potential attack scenarios to those already possible previously.

However, this feature still allows random data to be sent to destinations that might not normally have been able to receive them, such as to hosts within the victim's intranet. If a service within such an intranet cannot handle receiving UDP packets containing random noise, it might be vulnerable to attack from this feature.

Interoperability considerations:

Rules for processing both conforming and non-conforming content are defined in this specification.

Published specification:

This document is the relevant specification.

Applications that use this media type:

This type is only intended for use with SDP. [SDP]

Additional information:

Magic number(s):

No sequence of bytes can uniquely identify data in this format, as all data in this format is intentionally masked to avoid cross-protocol attacks.

File extension(s):

This format is not for use with files.

Macintosh file type code(s):

This format is not for use with files.

Person & email address to contact for further information:

Daniel C. Burnett <dburnett@voxeo.com>

Intended usage:

Common

Restrictions on usage:

No restrictions apply.

Author:

Daniel C. Burnett <dburnett@voxeo.com>

Change controller:

W3C

Fragment identifiers cannot be used with application/html-peer-connection-data as URLs cannot be used to identify streams that use this format.