[whatwg] PeerConnection and Stream API feedback

We have made an experimental implementation of PeerConnection and the 
Stream API and would like to provide some feedback that we have 
collected so far.

The TrackList feature seems to be a good way to control the different 
components of a Stream. Although it is said that tracks provide a way to 
temporarily disable a local camera, due to the nature of the 
ExclusiveTrackList it is still not possible to disable video altogether, 
i.e. to 'pull down the curtain' in a video conference. I noticed that 
there is a bug filed on this issue but I do not think the proposed 
solution there is quite right. There is a state in which no tracks are 
selected in an ExclusiveTrackList, when the selected index returned is 
-1. A quick fix would be to allow also setting the active track to -1 in 
order to deselect all the other tracks.

I think a note would be appropriate that although the label on a 
GeneratedStream is guaranteed to be unique for the conceptual stream, 
there are situations where one ends up with multiple Stream objects with 
the same label. For example, if the remote peer adds a stream, then 
removes it, then adds the same stream again, you would end up with two 
Stream objects with the same label if a reference to the removed Stream 
is kept. Also, if the remote peer takes a stream that it receives and 
sends it back you will end up with a Stream object that has the same 
label as a local GeneratedStream object.

We prefer having a StreamRecorder that you have to stop in order get the 
recorded data (like the previous one, but with asynchronous Blob 
retrieval) and we do not understand the use cases for the current 
proposal where recording continues until the recorder is garbage 
collected (or the Stream ends) and you always get the data from the 
beginning of the recording. This also has to be tied to application 
quota in some way. The recording example does not seem correct either, 
it never calls record() and then it calls getRecordedData() directly on 
the GeneratedStream object.

Instead of blob: we would like to use stream: for the Stream URLs so 
that we very early on in the media engine selection can use the protocol 
scheme to determine how the URL will be handled. Blobs are typically 
handled in the same way as other media playback. The definition of 
stream: could be the same as for blob:.

In addStream(), the readyState of the Stream is not checked to see if it 
is ENDED, in which case adding a stream should fail (perhaps throwing a 
TypeError exception like when passing null). When a received Stream is 
removed its readyState is not set to ENDED (and no 'ended' event is 
dispatched).

PeerConnection is an EventTarget but it still uses a callback for the 
signaling messages and this mixture of events and callbacks is a bit 
awkward in my opinion. If you would like to change the function that 
handles signaling messages after calling the constructor you would have 
to wrap a function call inside the callback to the actual signal 
handling function, instead of just (re-)setting an onsignal (or 
whatever) attribute listener (the event could reuse the MessageEvent 
interface).

Perhaps signalingMessage() could be renamed to 
add/handle/process/SignalingMessage() or similar to better indicate that 
it is used to input signaling messages received from the other peer.

There is a potential problem in the exchange of SDPs in that glare 
conditions can occur if both peers add streams simultaneously, in which 
case there will be two different outstanding offers that none of the 
peers are allowed to respond to according to the SDP offer-answer model. 
Instead of using one SDP session for all media as the specification 
suggests, we are handling the offer-answer for each stream separately to 
avoid such conditions.

We recently published a snapshot of our modified WebKitGTK+ library as 
an installable Ubuntu 11.04 package, should anyone wish to experiment 
with the API. (Note that the API entry points are prefixed with the 
'webkit' vendor prefix, e.g. webkitPeerConnnection)
https://labs.ericsson.com/apis/web-real-time-communication/downloads

//Per-Erik

Received on Wednesday, 8 June 2011 00:21:39 UTC