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