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!
>