- From: Wangyahui <yahui.wang@huawei.com>
- Date: Wed, 26 Sep 2012 09:50:51 +0000
- To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Yes, the function of createDataStream() what Harald said is really similar to createDataChannel(). So maybe addStream(data) in the flow charts should be modified to createDataChannel() which has been defined in RTCPeerConnection(). Yahui -----邮件原件----- 发件人: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com] 发送时间: 2012年9月25日 21:17 收件人: public-webrtc@w3.org 主题: Re: 答复: Some comments//Re: New version of editor draft for webrtc On 09/25/2012 02:54 PM, Harald Alvestrand wrote: > 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 Nit: I think it should say "createDataChannel(). //S > 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! >> >
Received on Wednesday, 26 September 2012 09:52:18 UTC