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,
>
> Yahui
>
> *发件人:*Harald Alvestrand [mailto:harald@alvestrand.no]
> *发 送时间:*2012年9月24日22:01
> *收件人:*public-webrtc@w3.org
> *主题:*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
>     specificationhttp://dev.w3.org/2011/webrtc/editor/webrtc.html.
>
>     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”RTCPeerConnectionreadiness state
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html> 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!
>