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

On 09/26/2012 11:50 AM, Wangyahui wrote:
> 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().

I think that modification should be done.

>
> 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:54:29 UTC