Re: Re: Some comments//Re: New version of editor draft for webrtc

Hi, Harald

Thanks for your  kind help. I now have a deeper understanding of this spec.



发件人: Harald Alvestrand []
发送时间: 2012年9月25日 20:54
收件人: Wangyahui
主题: Re: 答复: Some comments//Re: New version of editor draft for webrtc

On 09/25/2012 02:31 PM, Wangyahui wrote:
Hi, Harald

Thank you very much for your reply. Now it seems clear.
Besides, you said "createDataStream()", does it mean that local peer can generate a data steam from a local file?
createDataStream() creates a data stream. It does not generate content for the data stream.

The JS code can then choose to read data from a local file and send it out over the data stream, if that's what it wants. There's no "from file" argument to createDataStream.

hope that's clearer....

Best Regards,


发件人: Harald Alvestrand []
发 送时间: 2012年9月24日 22:01
主题: Re: Some comments//Re: New version of editor draft for webrtc

On 09/24/2012 03:49 AM, Wangyahui wrote:
Hi, all
I am new to WebRTC, and begin with initial study of WebRTC 1.0 specification

There are some problems I encountered while reading this spec. I would appreciate it if you could reply.

1.“discard” means that codecs can abandon some channels? Or maybe it should be “decode” by mistake?
Location: “4.1 Introduction”, the third paragraph and last sentence. “All of the channels that a codec needs to encode jointly MUST be in the same MediaStreamTrack and the codecs SHOULD be able to encode, or discard, all the channels in the track.”
Sometimes it is permissible to lose information (can't think of a good example; possibly when you're sending audio + video to an audio-only participant?) - I read this as saying it is not permissible to crash because of non-handlable track types. in the stream.

2.I saw (1) and (3) in this specification, but I didn’t find any link or reference. Besides, there is no (2), but many (3) following” RTCPeerConnection readiness state<> is closed”.
This is a leftover. All states should now be enums, so "closed(3)" needs to be changed to just "closed".
Thanks for pointing it out!

Location1: “4.2.2 MediaStreamTrack”, the third paragraph. “A track in a MediaStream , received with a RTCPeerConnection , MUST have its readyState attribute [GETUSERMEDIA] set to muted (1) until media data arrives.”
Location2: “5. Peer-to-peer connections” under”NOTE” step 4. “If the connection’s RTCPeerConnection readiness state is closed (3), abort these steps”
3. Step 12 of “Simple Call Flow” is addStream(data), but as I know the parameter of addStream(MediaStream stream) is for audio/video not data.
I think this should be "createDataStream()" instead. This API hasn't been stable for all that long.

By the way, is it possible to add some descriptions for steps of the flow charts?
Location: “9. Call Flow Browser to Browser”, “10. Call Flow Browser to MCU”

In addition, some revisions for editorial errors are attached for your information. Thank you for checking it.

And thank you very much for your review!

Received on Wednesday, 26 September 2012 09:34:34 UTC