W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2017

[webrtc-pc] editorial: media api introduction

From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
Date: Wed, 24 May 2017 11:32:04 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-231008709-1495625522-sysbot+gh@w3.org>
fippo has just created a new issue for https://github.com/w3c/webrtc-pc:

== editorial: media api introduction ==
http://w3c.github.io/webrtc-pc/#rtp-media-api

> The RTP media API lets a web application send and receive MediaStreamTracks over a peer-to-peer 
connection.

This is odd. Tracks and streams are an abstraction that is used by this API to describe how media is sent over a p2p connection.

> Tracks, when added to a RTCPeerConnection, result in signaling; when this signaling is forwarded to a remote peer, it causes corresponding tracks to be created on the remote side.

This is even more weird. It is correct but boiled down a bit too much.
If an application adds a track to a peerconnection it signals its intent to transmit media over that connection. This triggers the negotiation process described in 4.7 because we need to negotiate how this media is going to be transmitted over the network in a way that the other peer understands. As part of the negotiation, signaling messages are exchanges between the two applications which make the stream pop up at the remote side. No data is sent until the p2p connection is up though

Shall I try to come up with something along those lines?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1240 using your GitHub account
Received on Wednesday, 24 May 2017 11:32:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:50 UTC