├── resource ├── index.md ├── chapter6 │ ├── 6_点对点数据API.md │ ├── 6_1_1_RTCSctpTransport接口.md │ ├── 6_4_Garbage_Collection.md │ ├── 6_1_1_1_Create_an_instance.md │ ├── 6_1_1_2_Update_max_message_size.md │ ├── 6_1_2_RTCSctpTransportState_Enum.md │ ├── 6_3_RTCDataChannelEvent.md │ ├── 6.1.1.3 连接步骤.md │ ├── 6_1_RTCPeerConnection_Interface_Extensions.md │ └── 6_2_RTCDataChannel.md ├── chapter7 │ ├── 7_Peer-to-peer_DTMF.md │ ├── 7_1_RTCRtpSender_Interface_Extensions.md │ ├── 7_3_canInsertDTMF_algorithm.md │ ├── 7_4_RTCDTMFToneChangeEvent.md │ └── 7_2_RTCDTMFSender.md ├── chapter4 │ ├── 4_5 异常处理.md │ ├── 4_7 会话协商模型.md │ ├── 4_8_1_1 候选属性的语法.md │ ├── 4_4_4 垃圾回收.md │ ├── 4_7_1 设置Negotiation-Needed.md │ ├── 4_1 peer to peer connections-introductionx.md │ ├── 4_4 RTCPeerConnection 接口.md │ ├── 4_7_2 清除Negotiation-Needed.md │ ├── 4_9 优先级和QoS模型.md │ ├── 4_4_1_5 更新 ICE 连接状态.md │ ├── 4_4_1_3 更新连接状态.md │ ├── 4_4_3 旧接口扩展.md │ ├── 4_8_1_2 RTCIceProtocol 枚举.md │ ├── 4_4_1 操作.md │ ├── 4_4_1_4 更新 ICE 收集状态.md │ ├── 4_10_1 RTCCertificateExpiration词典.md │ ├── 4_3_2 RTCIceGatheringState 枚举.md │ ├── 4_8_1_3 RTCIceTcpCandidateType 枚举.md │ ├── 4_2_5 RTCIceTransportPolicy枚举.md │ ├── 4_8_1_4 RTCIceCandidateType 枚举.md │ ├── 4_4_1_2 将操作排入队列.md │ ├── 4_2_6 RTCBundlePolicy 枚举.md │ ├── 4_9_1 RTCPriorityType枚举.md │ ├── 4_2_7 RTCRtcpMuxPolicy 枚举.md │ ├── 4_6_2 RTCSessionDescription 类.md │ ├── 4_6_1 会话描述模型 - RTCSdpType 枚举.md │ ├── 4_2_3 RTCOAuthCredential Dictionary.md │ ├── 4_4_3_2 旧版配置扩展.md │ ├── 4_3_3 RTCPeerConnectionState 枚举.md │ ├── 4_2_8 提供、应答选项.md │ ├── 4_4_1_1 构造函数.md │ ├── 4_2_2 RTCIceCredentialType Enum.md │ ├── 4_3_4 RTCIceConnectionState 枚举.md │ ├── 4_10 证书管理.md │ ├── 4_7_3 更新Negotiation-Needed标志.md │ ├── 4_3_1 状态定义之 RTCSignalingState 枚举.md │ ├── 4_2_4 RTCIceServer Dictionary.md │ ├── 4_8_3 RTCPeerConnectionIceErrorEvent接口.md │ ├── 4_4_1_7 设置配置.md │ ├── 4_2_1 RTCConfiguration Dictionary.md │ ├── 4_8_2 RTCPeerConnectionIceEvent接口.md │ ├── 4_4_3_1 方法扩展.md │ ├── 4_10_2 RTCCertificate接口.md │ ├── 4_8_1 连接建立接口 - RTCIceCandidate 接口.md │ └── 4_4_1_6 设置 RTCSessionDescription.md ├── chapter5 │ ├── 5_2_5 RTCRtpDecodingParameters 词典.md │ ├── 5_2_14RTCRtpHeaderExtensionCapability词典.md │ ├── 5_6_2 RTCIceCandidatePair Dictionary.md │ ├── 5_2_4 RTCRtpCodingParameters 词典.md │ ├── 5_6_1 RTCIceParameters Dictionary.md │ ├── 5_2_9 RTCRtcpParameters 词典.md │ ├── 5_6_5 RTCIceRole Enum.md │ ├── 5_2_7 RTCDtxStatus 枚举.md │ ├── 5_5_1 RTCDtlsFingerprint 字典.md │ ├── 5_2_3 RTCRtpReceiveParameters 词典.md │ ├── 5_2_12RTCRtpCapabilities词典.md │ ├── 5_2_8 RTCDegradationPreference 枚举.md │ ├── 5_6_6 RTCIceComponent Enum.md │ ├── 5_6_3 RTCIceGathererState Enum.md │ ├── 5_4_1_1 Encoding Parameter Examples.md │ ├── 5_2_1 RTCRtpParameters 词典.md │ ├── 5_2_13 RTCRtpCodecCapability词典.md │ ├── 5_2_11RTCRtpCodecParameters词典.md │ ├── 5_2_2 RTCRtpSendParameters 词典.md │ ├── 5_4_1 Simulcast functionality.md │ ├── 5_2_10RTCRtpHeaderExtensionParameters词典.md │ ├── 5_1_1 处理远程 MediaStreamTracks.md │ ├── 5_7 RTCTrackEvent.md │ ├── 5 RTP Media API.md │ ├── 5_2_6 RTCRtpEncodingParameters 词典.md │ ├── 5_4_2 "Hold" functionality.md │ ├── 5_6_4 RTCIceTransportState Enum.md │ ├── 5_5 RTCDtlsTransport接口.md │ ├── 5_2_6 RTCRtpEncodingParameters 词典.md │ ├── 5_3RTCRtpReceiver接口.md │ ├── 5_4 RTCRtpTransceiver 接口.md │ ├── 5_6 RTCIceTransport接口.md │ ├── 5_2 RTCRtpSender 接口.md │ └── 5_1 RTCPeerConnection 接口扩展.md ├── chapter11 │ ├── 11_3_RTCErrorEventInit 字典.md │ ├── 11_2_RTCErrprEvent接口.md │ └── 11_1_RTCError接口.md ├── chapter9 │ ├── 9_2 MediaStream id.md │ ├── 9_3_1MediaTrackSupportedConstraints，MediaTrackCapabilities，MediaTrackConstraints和MediaTrackSettings.md │ ├── 9_3_MediaStreamTrack.md │ └── 9_1网络使用的媒体流API扩展简介.md ├── chapter2 │ └── 2 一致性.md ├── chapter8 │ ├── 8_6_统计选择算法.md │ ├── 8_1统计模型简介.md │ ├── 8_3RTCStatsReport对象.md │ ├── 8_5_RTCStatsEvent.md │ ├── 8_4_RTCStats词典.md │ ├── 8_8GetStats示例.md │ ├── 8_2_RTCPeerConnection接口扩展.md │ └── 8_7强制实施统计数据.md ├── Chapter1 │ └── 1 介绍.md ├── chapter13 │ └── 13_隐私和安全.md ├── chapter3 │ └── 3 Terminology.md └── chapter12 │ └── 12_Event summary.md ├── image ├── index.md ├── 10_6pic.png ├── 5_6_4pic.png ├── peerstates.png ├── proofread.png ├── ladder-2party-simple.png ├── ladder_2party_simple.png └── translation process.png ├── README.md ├── 翻译校对流程.md ├── 翻译排版指南.md └── contributors.md /resource/index.md: -------------------------------------------------------------------------------- 1 | # 目录 2 | -------------------------------------------------------------------------------- /image/index.md: -------------------------------------------------------------------------------- 1 | upload image here 2 | -------------------------------------------------------------------------------- /image/10_6pic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RTC-Developer/WebRTC-Documentation-in-Chinese/HEAD/image/10_6pic.png -------------------------------------------------------------------------------- /image/5_6_4pic.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RTC-Developer/WebRTC-Documentation-in-Chinese/HEAD/image/5_6_4pic.png -------------------------------------------------------------------------------- /image/peerstates.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RTC-Developer/WebRTC-Documentation-in-Chinese/HEAD/image/peerstates.png -------------------------------------------------------------------------------- /image/proofread.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RTC-Developer/WebRTC-Documentation-in-Chinese/HEAD/image/proofread.png -------------------------------------------------------------------------------- /resource/chapter6/6_点对点数据API.md: -------------------------------------------------------------------------------- 1 | # 6 对等数据API 2 | 3 | 对等数据API允许网络应用点对点发送接收通用应用数据。发送接收数据的API模拟`WebSockets`[WEBSOCKETS-API]的行为。 4 | 5 | -------------------------------------------------------------------------------- /image/ladder-2party-simple.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RTC-Developer/WebRTC-Documentation-in-Chinese/HEAD/image/ladder-2party-simple.png -------------------------------------------------------------------------------- /image/ladder_2party_simple.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RTC-Developer/WebRTC-Documentation-in-Chinese/HEAD/image/ladder_2party_simple.png -------------------------------------------------------------------------------- /image/translation process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/RTC-Developer/WebRTC-Documentation-in-Chinese/HEAD/image/translation process.png -------------------------------------------------------------------------------- /resource/chapter6/6_1_1_RTCSctpTransport接口.md: -------------------------------------------------------------------------------- 1 | ### 6.1.1 `RTCSctpTransport`接口 2 | 3 | 4 | 5 | `RTCSctpTransport`接口允许应用获取SCTP绑定到特定SCTP关联的数据通道的信息。 6 | -------------------------------------------------------------------------------- /resource/chapter7/7_Peer-to-peer_DTMF.md: -------------------------------------------------------------------------------- 1 | # 7 点对点DTMF 2 | 3 | 本节介绍`RTCRtpSender`上的一个接口，用于在`RTCPeerConnection`上发送DTMF（电话键盘）值。有关如何将DTMF发送到其他对等方的详细信息，请参见[RTCWEB-AUDIO]。 4 | 5 | -------------------------------------------------------------------------------- /resource/chapter4/4_5 异常处理.md: -------------------------------------------------------------------------------- 1 | ## [4.5 异常处理](http://w3c.github.io/webrtc-pc/#error-handling) 2 | 3 | ### 4.5.1 通用原则 4 | 5 | 所有返回 Promise 的方法都受 Promise 的异常错误处理规则的约束。不返回 Promise 的方法可能会抛出异常来显示错误。 6 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_5 RTCRtpDecodingParameters 词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.5 `RTCRtpDecodingParameters`字典 2 | 3 | ```java 4 | dictionary RTCRtpDecodingParameters : RTCRtpCodingParameters { 5 | }; 6 | ``` 7 | 8 | -------------------------------------------------------------------------------- /resource/chapter4/4_7 会话协商模型.md: -------------------------------------------------------------------------------- 1 | ## [4.7 会话协商模型](http://w3c.github.io/webrtc-pc/#session-negotiation-model) 2 | 3 | 对RTCPeerConnection状态的许多改变将需要通过信令信道与远程侧通信，以便具有期望的效果。通过收听协商需要的事件，可以通知应用程序何时需要进行信令。根据连接的需要协商标志的状态触发这个事件，该标志由[[NegotiationNeeded]]内部插槽表示。 4 | -------------------------------------------------------------------------------- /resource/chapter4/4_8_1_1 候选属性的语法.md: -------------------------------------------------------------------------------- 1 | #### [4.8.1.1 候选属性语法](http://w3c.github.io/webrtc-pc/#candidate-attribute-grammar) 2 | 3 | 候选属性语法用于在RTCIceCandidate() 构造函数中解析candidateInitDict的候选成员。 4 | 5 | 候选属性主要语法在[ICE]的第15.1节中定义。此外，浏览器必须支持ICE TCP的语法扩展，如[RFC6544]第4.5节中所定义。 6 | 7 | 浏览器可以支持其他RFC中定义的候选属性的其他语法扩展。 8 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_4 垃圾回收.md: -------------------------------------------------------------------------------- 1 | ### [4.4.4 垃圾回收](http://w3c.github.io/webrtc-pc/#garbage-collection) 2 | 3 | 只要有任何可能在对象上触发事件处理器的事件存在，RTCPeerConnection对象就不能被垃圾回收。当对象的[[IsClosed]]内部插槽为true时，就没有事件处理器可以被触发了，因此可以安全地执行垃圾回收。 4 | 5 | 连接到RTCPeerConnection的所有RTCDataChannel和MediaStreamTrack对象都具有对RTCPeerConnection对象的强引用。 6 | -------------------------------------------------------------------------------- /resource/chapter4/4_7_1 设置Negotiation-Needed.md: -------------------------------------------------------------------------------- 1 | ### [4.7.1 设置Negotiation-Needed](http://w3c.github.io/webrtc-pc/#setting-negotiation-needed) 2 | 3 | 本节不具有规范性。 4 | 5 | 如果在需要信令的RTCPeerConnection上执行操作，则该连接将被标记为需要协商。这种操作的示例包括添加或停止RTCRtpTransceiver，或添加第一个RTCDataChannel。 6 | 7 | 实现中的内部更改还可能导致连接被标记为需要协商。 8 | 9 | 请注意，更新需要协商的标志的确切过程如下所示。 10 | -------------------------------------------------------------------------------- /resource/chapter6/6_4_Garbage_Collection.md: -------------------------------------------------------------------------------- 1 | ## 6.4垃圾收集 2 | 3 | `RTCDataChannel`对象必须不能被垃圾回收如果它的 4 | 5 | - [ReadyState]插槽为`connecting`并且至少一个事件听众以`open`，`message`，`error`，`close`事件登记。 6 | - [ReadyState]插槽为`open`并且至少一个事件听众以`message`，`error`，`close`事件登记。 7 | - [ReadyState]插槽为`closing`并且至少一个事件听众以`error`，`close`事件登记。 8 | - 底层数据传输被建立，并且数据已经排序准备传输。 9 | -------------------------------------------------------------------------------- /resource/chapter4/4_1 peer to peer connections-introductionx.md: -------------------------------------------------------------------------------- 1 | # 4.点对点连接 2 | 3 | ## [4.1简介](http://w3c.github.io/webrtc-pc/#peer-to-peer-connections) 4 | 5 | RTCPeerConnection实例允许应用程序与另一个浏览器中的另一个RTCPeerConnection实例或另一个实现了所需协议的端点建立对等通信。通过信令信道交换控制消息（称为信令协议）来协调通信，信令信道没有指定的实现方法，通常由页面中的脚本连接服务器提供。例如，使用XMLHttpRequest [XMLHttpRequest]或WebSockets[WEBSOCKETS-API]。 6 | -------------------------------------------------------------------------------- /resource/chapter4/4_4 RTCPeerConnection 接口.md: -------------------------------------------------------------------------------- 1 | ## [4.4 RTCPeerConnection 接口](http://w3c.github.io/webrtc-pc/#rtcpeerconnection-interface) 2 | 3 | [[JSEP](http://w3c.github.io/webrtc-pc/#bib-JSEP)]规范作为一个整体，描述了[`RTCPeerConnection`](http://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection)如何运行的细节。适当时提供对[[JSEP](http://w3c.github.io/webrtc-pc/#bib-JSEP)]特定小节的参考。 4 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_14RTCRtpHeaderExtensionCapability词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.14 `RTCRtpHeaderExtensionCapability`字典 2 | 3 | ```java 4 | dictionary RTCRtpHeaderExtensionCapability { 5 | DOMString uri; 6 | }; 7 | ``` 8 | 9 | **字典`RTCRtpHeaderExtensionCapability`成员** 10 | 11 | **DOMString类型**的`uri`: 12 | 13 | [RFC5285]中定义的RTP标头扩展的URI。 14 | 15 | -------------------------------------------------------------------------------- /resource/chapter11/11_3_RTCErrorEventInit 字典.md: -------------------------------------------------------------------------------- 1 | ## 11.3 `RTCErrorEventInit` 字典 2 | 3 | ```java 4 | dictionary RTCErrorEventInit : EventInit { 5 | required RTCError error; 6 | }; 7 | ``` 8 | 9 | ### 11.3.1 字典RTCErrorEventInit成员 10 | 11 | `RTCError`类型的`error`,默认为`null`: 12 | 13 | 描述与事件(如果存在)关联的错误的`RTCError`。 14 | 15 | 16 | 17 | -------------------------------------------------------------------------------- /resource/chapter5/5_6_2 RTCIceCandidatePair Dictionary.md: -------------------------------------------------------------------------------- 1 | ### 5.6.2 `RTCIceCandidatePair`字典 2 | 3 | ```java 4 | dictionary RTCIceCandidatePair { 5 | RTCIceCandidate local; 6 | RTCIceCandidate remote; 7 | }; 8 | ``` 9 | 10 | **字典`RTCIceCandidatePair`成员** 11 | 12 | `RTCIceCandidate`类型的`local`：本地ICE 候选者。 13 | 14 | `RTCIceCandidate`类型的`remote`：远程ICE 候选者。 15 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_4 RTCRtpCodingParameters 词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.4 `RTCRtpCodingParameters`字典 2 | 3 | ```java 4 | dictionary RTCRtpCodingParameters { 5 | DOMString rid; 6 | }; 7 | ``` 8 | 9 | **字典RTCRtpCodingParameters成员** 10 | 11 | DOMString类型的`rid`: 12 | 13 | 如果设置，RTP编码将与[JSEP] (第5.2.1节)定义的RID头扩展一起发送。RID不能通过`setParameters`修改。它只能在发送端的`addTransceiver`中设置或修改。只读参数。 14 | 15 | -------------------------------------------------------------------------------- /resource/chapter9/9_2 MediaStream id.md: -------------------------------------------------------------------------------- 1 | ## 9.2 媒体流 2 | 3 | ### 9.2.1 id 4 | 5 | `MediaStream`指定的id属性返回了对流唯一的id，这样`RTCPeerConnection API`的远程端就可以识别媒体流。 6 | 7 | 当媒体流被创建用来表示从远程对等体获得的流时，id属性是通过远程源提供的信息初始化的。 8 | 9 | > NOTE:MediaStream对象的id对于流的源是唯一的，但这并不意味着不可能以重复项结束。例如，本地生成的流的轨道可以使用`RTCPeerConnection`从一个用户代理发送到远程对等体，然后以相同的方式发送回原始用户代理，在这种情况下，原始用户代理将得到具有相同id的多条流（本地生成的id和从远程对等体发送的id）。 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /resource/chapter4/4_7_2 清除Negotiation-Needed.md: -------------------------------------------------------------------------------- 1 | ### [4.7.2 清除Negotiation-Needed](http://w3c.github.io/webrtc-pc/#clearing-negotiation-needed) 2 | 3 | 本节不具有规范性。 4 | 5 | 当应用类型为“answer”的RTCSessionDescription时，将清除`negotiation-needed`的标志，并且提供的描述与RTCPeerConnection上当前存在的RTCRtpTransceivers和RTCDataChannel的状态相匹配。具体而言，所有未停止的收发器在本地描述中具有匹配属性的相关部分，并且，如果已经创建了任何数据信道，则本地描述中存在数据部分。 6 | 7 | NOTE：更新Negotiation-Needed的标志的明确过程如下所示。 8 | -------------------------------------------------------------------------------- /resource/chapter5/5_6_1 RTCIceParameters Dictionary.md: -------------------------------------------------------------------------------- 1 | ### 5.6.1 `RTCIceParameters`字典 2 | 3 | ```java 4 | dictionary RTCIceParameters { 5 | DOMString usernameFragment; 6 | DOMString password; 7 | }; 8 | ``` 9 | 10 | **字典`RTCIceParameters`成员** 11 | 12 | `DOMString`类型的`usernameFragment`:在[ICE],章节7.1.2.3中定义的ICE用户名片段。 13 | 14 | `DOMString`类型的`password`:在[ICE],章节7.1.2.3中定义的ICE密码。 15 | 16 | 17 | -------------------------------------------------------------------------------- /resource/chapter4/4_9 优先级和QoS模型.md: -------------------------------------------------------------------------------- 1 | ## [4.9 优先级和QoS模型](http://w3c.github.io/webrtc-pc/#priority-and-qos-model) 2 | 3 | 4 | 5 | 许多应用程序中包含多路相同数据类型的媒体流，并且当中的某些媒体流相比于其他媒体流质量更为重要。WebRTC使用了在[RTCWEB-TRANSPORT]和[TSVWG-RTCWEB-QOS]中描述的优先级和服务质量（QoS）框架，来帮助在某些网络环境中标记特定类型数据包的优先级以及差分服务代码点（DSCP），以此来达到提升服务质量的目的。优先级设定可以用来标识不同媒体流的相对优先级。通过调用优先级设置API可以让JavaScript应用程序更改RTCRtpEncodingParameters对象的中priority属性来告诉浏览器特定媒体流的优先级是高，中，低还是非常低，priority属性可以设置为以下值。 6 | -------------------------------------------------------------------------------- /resource/chapter7/7_1_RTCRtpSender_Interface_Extensions.md: -------------------------------------------------------------------------------- 1 | ## 7.1 RTCRtpSender接口扩展 2 | 3 | 点对点DTMF API对`RTCRtpSender`接口的扩展如下。 4 | 5 | ```java 6 | partial interface RTCRtpSender { 7 | readonly attribute RTCDTMFSender? dtmf; 8 | }; 9 | ``` 10 | 11 | **属性** 12 | 13 | RTCDTMFSender类型的dtmf,只读的，可以为null：当获取时，dtmf属性返回[Dtmf]内部插槽的值，它代表一个可用来发送DTMF的`RTCDTMFSender`,如果未设置，则为null。当RTCRtpSender的[SenderTrack]为“audio”，[Dtmf]内部插槽被设置。 14 | -------------------------------------------------------------------------------- /resource/chapter6/6_1_1_1_Create_an_instance.md: -------------------------------------------------------------------------------- 1 | #### 6.1.1.1创建一个实例 2 | 3 | 为了创建一个可选初始状态的`RTCSctpTransport`，`initialState`，运行下列步骤。 4 | 5 | 1.让transport成为一个新的`RTCSctpTransport`对象。 6 | 7 | 2.让transport具有一个[SctpTransportState]内部插槽，初始化为`initialState`，如果提供，否则为`"new"`。 8 | 9 | 3.让transport具有[MaxMessageSize]内部插槽，运行标记为`update the data max message size`的标签对其初始化。 10 | 11 | 4.让transport具有[MaxChannels]内部插槽初始化为`null`。 12 | 13 | 5.返回transport。 14 | 15 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_9 RTCRtcpParameters 词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.9 `RTCRtpParameters`字典 2 | 3 | ```java 4 | dictionary RTCRtcpParameters { 5 | DOMString cname; 6 | boolean reducedSize; 7 | }; 8 | ``` 9 | 10 | **字典`RTCRtcpParameters`成员** 11 | 12 | DOMString类型的`cname`: 13 | 14 | RTCP使用的规范名称(CNAME) (例如，在SDES消息中)。只读参数。 15 | 16 | boolean类型的`reducedSize`: 17 | 18 | 是否已配置缩小的RTCP[RFC5506] (如果为true)或[RFC3550]中指定的复合RTCP(如果为false)。只读参数。 19 | -------------------------------------------------------------------------------- /resource/chapter5/5_6_5 RTCIceRole Enum.md: -------------------------------------------------------------------------------- 1 | ### 5.6.5 RTCIceRole枚举 2 | 3 | ```java 4 | enum RTCIceRole { 5 | "controlling", 6 | "controlled" 7 | }; 8 | ``` 9 | 10 | | RTCIceRole枚举描述 | | 11 | | ------------------ | ------------------------------------------------ | 12 | | `controlling` | 一个由[ICE]，第三节中定义的`controlling agent`。 | 13 | | `controlled` | 一个由[ICE]，第三节中定义的`controlled agent`。 | 14 | 15 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_7 RTCDtxStatus 枚举.md: -------------------------------------------------------------------------------- 1 | ### 5.2.7 `RTCDtxStatus` 枚举 2 | 3 | ```java 4 | 5 | ``` 6 | 7 | ``` 8 | enum RTCDtxStatus { 9 | "disabled", 10 | "enabled" 11 | }; 12 | ``` 13 | 14 | | RTCDtxStatus枚举描述 | | 15 | | -------------------- | -------------------------------- | 16 | | `disabled` | 不连续传输被禁用。 | 17 | | `enabled` | 如果协商成功，不连续传输被启用。 | 18 | 19 | 20 | 21 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_1_5 更新 ICE 连接状态.md: -------------------------------------------------------------------------------- 1 | #### [4.4.1.5 更新 ICE 连接状态](http://w3c.github.io/webrtc-pc/#update-the-ice-connection-state) 2 | 3 | 要更新RTCPeerConnection实例连接的ICE连接状态，用户代理必须把运行以下步骤的任务加入队列： 4 | 5 | 1. 如果connection的[[IsClosed]]值为true，则中止这些步骤。 6 | 7 | 2. 把 newState 的值设为新状态的值，这些值是 RTCIceConnectionState 中的枚举值。 8 | 9 | 3. 如果connection的ICE连接状态值等于newState的值，则中止这些步骤。 10 | 11 | 4. 将connection的连接状态值设置为newState的值。 12 | 13 | 5. 触发名为iceconnectionstatechange的事件。 14 | 15 | -------------------------------------------------------------------------------- /resource/chapter5/5_5_1 RTCDtlsFingerprint 字典.md: -------------------------------------------------------------------------------- 1 | ### 5.5.1 RTCDtlsFingerprint字典 2 | 3 | `RTCDtlsFingerprint`字典包含[RFC4572]中描述的哈希函数算法和证书指纹。 4 | 5 | ```java 6 | dictionary RTCDtlsFingerprint { 7 | DOMString algorithm; 8 | DOMString value; 9 | }; 10 | ``` 11 | 12 | #### 字典RTCDtlsFingerprint成员 13 | 14 | DOMString类型的`算法`:它是哈希函数文本名称注册表[IANA-HASH-FUNCTION]中定义的一个哈希函数算法。 15 | 16 | DOMString类型的`值`:使用[RFC4572]第五节中“指纹”语法表示的小写十六进制字符串中的指纹证书的值。 17 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_1_3 更新连接状态.md: -------------------------------------------------------------------------------- 1 | #### [4.4.1.3 更新连接状态](http://w3c.github.io/webrtc-pc/#update-the-connection-state) 2 | 3 | RTCPeerConnection 对象具有聚合连接状态。每当RTCDtlsTransport或RTCIceTransport的状态发生变化或[[IsClosed]]值变为true时，用户代理必须通过加入任务到队列来更新连接状态，任务执行以下步骤： 4 | 5 | 1. 让连接成为此RTCPeerConnection对象。 6 | 7 | 2. 把 newState 的值设为新状态的值，这些值是 RTCPeerConnectionState 中的枚举值。 8 | 9 | 3. 如果连接的状态值等于newState的值，则中止这些步骤。 10 | 11 | 4. 把newState的值赋给连接的状态值。 12 | 13 | 5. 触发名为 connectionstatechange 的事件。 14 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_3 旧接口扩展.md: -------------------------------------------------------------------------------- 1 | ### [4.4.3 旧接口扩展](http://w3c.github.io/webrtc-pc/#legacy-interface-extensions) 2 | 3 | NOTE 4 | 出于可读性考虑，本节内容已经过时。在这里考虑部分接口是它们的主要对应物的一部分，因为它们使现有方法重载。 5 | 6 | 本节中支持的方法是可选的。但是，如果支持这些方法，则必须根据此处指定的方法实现。 7 | 8 | NOTE 9 | 10 | 以前存在于RTCPeerConnection上的addStream方法很容易polyfill为： 11 | 12 | ``` 13 | RTCPeerConnection.prototype.addStream = function(stream) { 14 | stream.getTracks().forEach((track) => this.addTrack(track, stream)); 15 | }; 16 | 17 | ``` 18 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_3 RTCRtpReceiveParameters 词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.3 `RTCRtpReceiveParameters`字典 2 | 3 | ```java 4 | dictionary RTCRtpReceiveParameters : RTCRtpParameters { 5 | required sequence encodings; 6 | }; 7 | ``` 8 | 9 | **字典`RTCRtpReceiveParameters`成员** 10 | 11 | 序列类型的encodings： 12 | 13 | 包含入向媒体RTP编码信息的序列。 14 | 15 | > (FEATURE AT RISK) ISSUE 3 16 | > 17 | > 对`RTCRtpReceiveParameters`的`encodings`属性的支持被标记为存在危险的特性，因为实现者没有明确的承诺。 18 | 19 | -------------------------------------------------------------------------------- /resource/chapter2/2 一致性.md: -------------------------------------------------------------------------------- 1 | # [2.一致性](http://w3c.github.io/webrtc-pc/#conformance) 2 | 3 | 如果有章节被标记为与技术规范无关（non-normative）时，这意味着其中的作者指引、图表、示例和注释内容均不属于技术规范。除此以外的其它章节均为技术规范。 4 | 5 | 在 [[RTC2119]](http://w3c.github.io/webrtc-pc/#bib-RFC2119) 中，定义描述了关键词**可能（MAY）**、**必须（MUST）**、**一定不（MUST NOT）**、**将（SHALL）**、**应该（SHOULD）**。 6 | 7 | 以任何形式出现的用于实践的算法、特定步骤，只要结果是正确的，即为符合一致性要求的表述。（注意，本规范说明中定义的算法旨在易用性，而不考虑性能。） 8 | 9 | 本说明规范中使用 ECMAScript 来实现的接口**必须**与 [[WEBIDL-1]](http://w3c.github.io/webrtc-pc/#bib-WEBIDL-1) 中定义的 ECMAScript 约束一致。 10 | -------------------------------------------------------------------------------- /resource/chapter8/8_6_统计选择算法.md: -------------------------------------------------------------------------------- 1 | ## 8.6 统计选择算法 2 | 3 | 统计选择算法如下： 4 | 5 | 1. 设result为空RTCStatsReport。 6 | 2. 如果selector为`null`，则收集整个连接的统计信息，将它们添加到result，返回结果并中止这些步骤。 7 | 3. 如果selector是`RTCRtpSender`，则收集统计信息并将以下对象添加到结果: 8 | - 表示由选择器发送的代表RTP流的所有`RTCOutboundRTPStreamStats`对象。 9 | - 添加了由`RTCOutboundRTPStreamStats`对象直接或间接引用的所有stats对象。 10 | 4. 如果selector是`RTCRtpReceiver`，则收集stats并将以下对象添加到result： 11 | - 表示由选择器接收的代表RTP流的所有`RTCInboundRTPStreamStats`对象。 12 | - 添加了由`RTCInboundRTPStreamStats`直接或间接引用的所有stats对象。 13 | 5. 返回结果。 14 | 15 | -------------------------------------------------------------------------------- /resource/chapter6/6_1_1_2_Update_max_message_size.md: -------------------------------------------------------------------------------- 1 | 2 | #### 6.1.1.2 更新最大信息容量 3 | 4 | 为了更新`RTCSCTPTransport`的数据最大信息容量，运行下列步骤： 5 | 6 | 1.让transport成为用来更新的`RTCSCTPTransport`对象。 7 | 8 | 2.让`remoeteMaxMessageSize`成为从远程描述中获取的"max-message-size"SDP属性的值，如[SCTP-SDP]中所述，或65536如果属性缺失。 9 | 10 | 3.让`canSendSize`成为客户端可发送的字节数(本地发送buffer的大小)，如果可以处理任意大小的信息，则设置为0。 11 | 12 | 4.如果`remoteMaxMessageSize`和`canSendSize`都为0，设置[MaxMessageSize]为正无穷。 13 | 14 | 5.否则，如果`remoteMaxMessageSize`与`canSendSize`有一个为0，设置[MaxMessageSize]为两者较大值。 15 | 16 | 6.否则，设置[MaxMessageSize]为两者较小值。 17 | -------------------------------------------------------------------------------- /resource/chapter9/9_3_1MediaTrackSupportedConstraints，MediaTrackCapabilities，MediaTrackConstraints和MediaTrackSettings.md: -------------------------------------------------------------------------------- 1 | 2 | ### 9.3.1 MediaTrackSupportedConstraints, MediaTrackCapabilities, MediaTrackConstraints 和 MediaTrackSettings 3 | 4 | [GETUSERMEDIA]概述了`MediaTrackSupportedConstraints`，`MediaTrackCapabilites`，`MediaTrackConstraints`和`MediaTrackSettings`的基础知识。然而，由`RTCPeerConnection`提供的`MediaStreamTrack`的`MediaTrackSettings`只会填充成员，以便通过由`setRemoteDescription`和实际RTP数据应用的远程`RTCSessionDescription`提供数据。这意味着某些成员（例如`facingMode`，`echoCancellation`，`latency`，`deviceId`和`groupId`）将始终缺失。 5 | 6 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_12RTCRtpCapabilities词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.12 `RTCRtpCapabilities`字典 2 | 3 | ```java 4 | dictionary RTCRtpCapabilities { 5 | required sequence codecs; 6 | required sequence headerExtensions; 7 | }; 8 | ``` 9 | 10 | **字典`RTCRtpCapabilities`成员** 11 | 12 | 序列``类型的`codecs`： 13 | 14 | 支持的媒体编解码器以及RTX,RED和FEC机制的条目。在`codecs[]`中只有一个条目用于通过RTX重传，并且`sdpFmtpLine`不存在。 15 | 16 | **序列**``类型的`headerExtensions`： 17 | 18 | 支持的RTP标头扩展。 19 | 20 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_8 RTCDegradationPreference 枚举.md: -------------------------------------------------------------------------------- 1 | ### 5.2.8 `RTCDegradationPreference`枚举 2 | 3 | ```java 4 | enum RTCDegradationPreference { 5 | "maintain-framerate", 6 | "maintain-resolution", 7 | "balanced" 8 | }; 9 | ``` 10 | 11 | | RTCDegradationPreference枚举描述 | | 12 | | -------------------------------- | -------------------------------- | 13 | | `maintain-framerate` | 降低分辨率以便维持帧率。 | 14 | | `maintain-resolution` | 降低帧率以便维持分辨率。 | 15 | | `balanced` | 在降低帧率和分辨率之间保持平衡。 | 16 | 17 | -------------------------------------------------------------------------------- /resource/chapter4/4_8_1_2 RTCIceProtocol 枚举.md: -------------------------------------------------------------------------------- 1 | #### [4.8.1.2 RTCIceProtocol枚举](http://w3c.github.io/webrtc-pc/#rtciceprotocol-enum) 2 | 3 | `RTCIceProtocol`表示ICE候选者的协议。 4 | 5 | ``` 6 | enum RTCIceProtocol { 7 | "udp", 8 | "tcp" 9 | }; 10 | ``` 11 | 12 | 13 | 14 | 17 | 18 | 19 | 22 | 25 | 26 | 27 | 30 | 33 | 34 |
15 | 枚举描述 16 |
20 | udp 21 | 23 | 表示一个基于UDP协议的候选人，详细描述参考 [ICE]. 24 |
28 | tcp 29 | 31 | 表示一个基于tcp协议的候选人，详细描述参考 [RFC6544]. 32 |
35 | -------------------------------------------------------------------------------- /resource/chapter5/5_6_6 RTCIceComponent Enum.md: -------------------------------------------------------------------------------- 1 | ### 5.6.6 RTCIceComponent枚举 2 | 3 | ```java 4 | enum RTCIceComponent { 5 | "rtp", 6 | "rtcp" 7 | }; 8 | ``` 9 | 10 | 11 | 12 | | RTCIceComponent枚举描述 | | 13 | | ----------------------- | ------------------------------------------------------------ | 14 | | `rtp` | ICE传输被用到[ICE],4.1.1.1中定义的`RTP`(或`RTCP`复用)。与RTP复用的协议(例如数据通道)共享其组件ID。这表示在候选属性中编码时`component-id`值为1。 | 15 | | `rtcp` | ICE传输用于RTCP，如[ICE]第4.1.1.1节中所定义。这表示在候选属性中编码时的`component-id`值2。 | 16 | 17 | -------------------------------------------------------------------------------- /resource/Chapter1/1 介绍.md: -------------------------------------------------------------------------------- 1 | # [1.介绍](http://w3c.github.io/webrtc-pc/#intro) 2 | 3 | 这部分内容与技术规范无关。 4 | 5 | 这份技术规范中引述了基于 HTML 的视频会议与点对点通信的一系列功能： 6 | 7 | - 利用 NAT 穿透技术连接远程节点，如 ICE、STUN 和 TURN。 8 | 9 | - 发送本地流至远端，或是从远端接收流。 10 | 11 | - 发送任意类型数据至远端。 12 | 13 | 本文档定义了实现以上功能的接口。这份技术规范由 [IETF RTCWEB](https://datatracker.ietf.org/wg/rtcweb/) 小组和 [Media Capture Task Force](https://www.w3.org/wiki/Media_Capture) 协同开发，前者开发贡献了一份协议技术规范，后者开发贡献了一套用于接入本地媒体设备的接口规范。你可以在 [[RTCWEB-OVERVIEW]](http://w3c.github.io/webrtc-pc/#bib-RTCWEB-OVERVIEW) 和 [[RTCWEB-SECURITY]](http://w3c.github.io/webrtc-pc/#bib-RTCWEB-SECURITY) 中找到系统概述。 14 | -------------------------------------------------------------------------------- /resource/chapter7/7_3_canInsertDTMF_algorithm.md: -------------------------------------------------------------------------------- 1 | ## 7.3 canInsertDTMF算法 2 | 3 | 为了确定是否可以为RTCDTMFSender实例dtmfSender发送DTMF,用户代理必须对运行以下步骤的任务排队： 4 | 5 | 1. 让sender成为与dtmfSender关联的`RTCRtpSender`。 6 | 2. 让收发器成为与sender关联的`RTCRtpTransceiver`。 7 | 3. 让connection成为与收发器关联的`RTCPeerConnection`。 8 | 4. 如果connection的`RTCPeerConnectionState`不为`connected`，返回`false`。 9 | 5. 如果sender的[SenderTrack]为`null`，返回`false`。 10 | 6. 如果收发器的[CurrentDirection]既不是`sendrecv`也不是`sendonly`,返回`false`。 11 | 7. 如果发送者的[[SendEncodings]] `[0] .active`为`false`，则返回`false`。 12 | 8. 如果没有协商mimetype“audio / telephone-event”的编解码器与此发件人一起发送，则返回`false`。 13 | 9. 否则，返回`true`。 14 | 15 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_1 操作.md: -------------------------------------------------------------------------------- 1 | ### [4.4.1 操作](http://w3c.github.io/webrtc-pc/#operation) 2 | 3 | 调用new RTCPeerConnection（configuration）会创建RTCPeerConnection对象。 4 | 5 | configuration.servers 包含 ICE 用于查找和访问服务器的信息。应用程序可以提供同种类的服务器的多个实例，并且任何TURN服务器也可以用作STUN服务器，以便收集服务器自反候选者。 6 | 7 | RTCPeerConnection对象具有信令状态，连接状态，ICE收集状态和ICE连接状态。这些状态在创建对象时被初始化。 8 | 9 | RTCPeerConnection的ICE协议实现用 ICE 代理[ICE]表示。某些RTCPeerConnection方法涉及与 ICE 代理 的交互被命名为：addIceCandidate，setConfiguration，setLocalDescription，setRemoteDescription和close。这些交互在本文档和[JSEP]的相关章节中进行了描述。当 RTCIceTransport 的内部表示状态发生变化时，ICE 代理还向用户代理提供指示，如5.6 RTCIceTransport接口中所述。 10 | 11 | 本节中列出的任务的任务源是网络任务源。 12 | -------------------------------------------------------------------------------- /resource/chapter11/11_2_RTCErrprEvent接口.md: -------------------------------------------------------------------------------- 1 | ## 11.2 `RTCErrprEvent`接口 2 | 3 | `RTCErrorEvent`接口是针对将`RTCError`作为事件引发的情况定义的: 4 | 5 | ```java 6 | [ 7 | Exposed=Window, 8 | Constructor (DOMString type, RTCErrorEventInit eventInitDict) 9 | ] interface RTCErrorEvent : Event { 10 | [SameObject] readonly attribute RTCError error; 11 | }; 12 | ``` 13 | 14 | 15 | 16 | ### 11.2.1 构造函数 17 | 18 | `RTCErrorEvent`:[测试：1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/idlharness.https.window.js) 19 | 20 | 构造一个新的`RTCErrorEvent`。 21 | 22 | ### 11.2.2 属性 23 | 24 | `RTCError`类型的error，只读，可以为null： 25 | 26 | 描述触发事件的错误的`RTCError`。 27 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_1_4 更新 ICE 收集状态.md: -------------------------------------------------------------------------------- 1 | #### [4.4.1.4 更新 ICE 收集状态](http://w3c.github.io/webrtc-pc/#update-the-ice-gathering-state) 2 | 3 | 要更新RTCPeerConnection实例连接的ICE收集状态，用户代理必须把运行以下步骤的任务加入队列： 4 | 5 | 1. 如果connection的[[IsClosed]]值为true，则中止这些步骤。 6 | 7 | 2. 把 newState 的值设为新状态的值，这些值是 RTCIceGatheringState 中的枚举值。 8 | 9 | 3. 如果连接的ICE收集状态的值等于newState的值，则中止这些步骤。 10 | 11 | 4. 将连接的 ICE 采集状态值设置为newState的值。 12 | 13 | 5. 触发名为icegatheringstatechange的事件。 14 | 15 | 6. 如果 newState 的值为“completed”，则使用 RTCPeerConnectionIceEvent 接口触发名为 icecandidate 的事件，并在候选连接时将候选属性设置为null。 16 | 17 | 18 | >NOTE 19 | > 20 | >会触发null候选事件以确保旧版兼容性。新代码应监视 RTCIceTransport 和/或 RTCPeerConnection 的收集状态。 21 | -------------------------------------------------------------------------------- /resource/chapter5/5_6_3 RTCIceGathererState Enum.md: -------------------------------------------------------------------------------- 1 | ### 5.6.3 `RTCIceGathererState`枚举 2 | 3 | ```java 4 | enum RTCIceGathererState { 5 | "new", 6 | "gathering", 7 | "complete" 8 | }; 9 | ``` 10 | 11 | | RTCIceGathererState枚举描述 | | 12 | | :-------------------------- | :----------------------------------------------------------- | 13 | | `new` | `RTCIceTransport`刚刚被创建，还未开始收集候选者。 | 14 | | `gathering` | `RTCIceTransport`正在收集候选者。 | 15 | | `complete` | `RTCIceTransport`已经完成收集，并已发送此传输的候选者终止指示。在ICE重启导致它重启之前，它不会再次收集候选者。 | 16 | 17 | -------------------------------------------------------------------------------- /resource/chapter9/9_3_MediaStreamTrack.md: -------------------------------------------------------------------------------- 1 | ## 9.3 媒体流轨道 2 | 3 | `MediaStreamTrack`对象在非本地媒体源案例中对其`MediaStream`的引用（RTP源，每个`RTCRtpReceiver`关联一个`MediaStreamTrack`的情况）总是很强。 4 | 5 | 每当`RTCRtpReceiver`在相应的MediaStreamTrack被静音的RTP源上接收数据，并且包含`RTCRtpReceiver`的`RTCRtpTraceceiver`对象的[[Receptive]]插槽为`true`时，它必须对任务排序以设置相应MediaStreamTrack的静音状态为`false`。 6 | 7 | 当RTCRtpReceiver接收到的RTP源媒体流的SSRC之一由于接收到BYE或超时而被移除时，它必须对任务排序以将相应MediaStreamTrack的静音状态设置为`true`。注意，`setRemoteDescription`还可以将`track`的静音状态设置为值`true`。 8 | 9 | 在[GETUSERMEDIA]中指定了添加track，删除track和设置track静音状态的步骤。 10 | 11 | 当`RTCRtpReceiver`接收器生成的MediaStreamTrack轨道已经结束[GETUSERMEDIA]时（例如通过调用`receiver.track.stop`），用户代理可以选择释放为输入流分配的资源，例如通过关闭接收端解码器。 12 | 13 | 14 | 15 | -------------------------------------------------------------------------------- /resource/chapter4/4_10_1 RTCCertificateExpiration词典.md: -------------------------------------------------------------------------------- 1 | ### [4.10.1 RTCCertificateExpiration词典](http://w3c.github.io/webrtc-pc/#rtccertificateexpiration-dictionary) 2 | 3 | RTCCertificateExpiration用于设置generateCertificate生成的证书的到期日期。 4 | 5 | 6 | ``` 7 | dictionary RTCCertificateExpiration { 8 | [EnforceRange] 9 | DOMTimeStamp expires; 10 | }; 11 | ``` 12 | 13 | expires 14 | 15 | 可选的expires属性可以添加到传递给generateCertificate的算法的定义中。如果此参数存在，则表示RTCCertificate相对于当前时间有效的最长时间。 16 | 17 | 当使用object参数调用generateCertificate时，用户代理会尝试将对象转换为RTCCertificateExpiration。如果这不成功，立即返回一个被新创建的TypeError和中止处理拒绝的promise。 18 | 19 | 用户代理生成的证书的到期日期设置为当前时间加上expires属性的值。返回的RTCCertificate的expires属性设置为证书的到期时间。用户代理可以选择限制expires属性的值。 20 | -------------------------------------------------------------------------------- /resource/chapter8/8_1统计模型简介.md: -------------------------------------------------------------------------------- 1 | # 8 统计模型 2 | 3 | ## 8.1简介 4 | 5 | 基本的统计模型是浏览器以统计对象的形式维护一系列受监控对象的统计信息。 6 | 7 | 选择器可以引用一组相关对象。例如，选择器可以是`MediaStreamTrack`。要使track成为有效的选择器，它必须是由发出统计请求的`RTCPeerConnection`对象发送或接收的`MediaStreamTrack`。调用Web应用程序为getStats（）方法提供选择器，浏览器根据统计信息选择算法发出（在JavaScript中）与选择器相关的一组统计信息。请注意，该算法采用选择器的发送方或接收方。 8 | 9 | stats对象中返回的统计信息的设计方式是重复查询可以由`RTCStats id`字典成员链接。因此，Web应用程序可以通过在该时段的开始和结束请求测量来在给定时间段内进行测量。 10 | 11 | 除少数例外情况外，受监控对象一旦创建，就会在其关联的`RTCPeerConnection`期间存在。这样可以确保getStats（）的结果中的统计信息在关闭的关联对等连接之后可用。 12 | 13 | 只有少数受监控对象的生命周期较短。对于这些对象，它们的生命周期在被算法删除时结束。在删除时，将在包含RTCStatsReport对象的单个`statsended`事件中发出其统计信息的记录，该对象包含同时删除的所有对象的统计信息。后续getStats（）结果中不再提供这些对象的统计信息。 [WEBRTC-STATS]中的对象描述描述了何时删除这些受监视对象。 14 | -------------------------------------------------------------------------------- /resource/chapter6/6_1_2_RTCSctpTransportState_Enum.md: -------------------------------------------------------------------------------- 1 | ### 6.1.2 RTCSctpTransportState枚举 2 | 3 | RTCSctpTransportState表示SCTP传输状态。 4 | 5 | ```java 6 | enum RTCSctpTransportState { 7 | "connecting", 8 | "connected", 9 | "closed" 10 | }; 11 | ``` 12 | 13 | | 枚举描述 | | 14 | | ------------ | ------------------------------------------------------------ | 15 | | `connecting` | `RTCSctpTransport`正在协商一个关联。这是当`RTCSctpTransport`被创建时[SctpTransportState]插槽的初始状态。 | 16 | | `connected` | 当协商完成后，会出现一个更新[SctpTransportState]插槽为`“connected”`的任务。 | 17 | | `closed` | 当接收到SHUTDOWN或者ABORT时，或是SCTP关联被有意关闭，例如通过关闭对等连接或应用拒绝数据，改变SCTP端口的远程描述，[SctpTransportState]插槽的值会被更新为`“closed”`。 | 18 | 19 | -------------------------------------------------------------------------------- /resource/chapter8/8_3RTCStatsReport对象.md: -------------------------------------------------------------------------------- 1 | ## 8.3 `RTCStatsReport`对象 2 | 3 | getStats（）方法以`RTCStatsReport`对象的形式传达成功的结果。 `RTCStatsReport`对象是标识被检查对象（`RTCStats`实例中的`id`属性）的字符串之间的映射，以及它们对应的`RTCStats`派生的字典。 4 | 5 | `RTCStatsReport`可以由几个`RTCStats`派生的字典组成，每个字典报告实现认为与选择器相关的一个底层对象的统计信息。通过对某种类型的所有统计量求和，可以实现选择器的总和;例如，如果`RTCRtpSender`使用多个SSRC通过网络传输其轨迹，则每个SSRC中`RTCStatsReport`可以包含一个`RTCStats`派生的字典（可以通过“ssrc” stats属性的值来区分）。 6 | 7 | ```java 8 | [Exposed=Window] interface RTCStatsReport { 9 | readonly maplike; 10 | }; 11 | ``` 12 | 13 | 这个接口有“entries”，“forEach”，“get”，“has”，“keys”，“values”，@@ iterator方法和`readonly maplike`带来的“size”getter。 14 | 15 | 使用这些来检索此统计报告由`RTCStats`组成的各种词典。支持的属性名称[WEBIDL-1]的集合被定义为为此统计信息报告生成的所有`RTCStats`派生词典的ID。 16 | 17 | -------------------------------------------------------------------------------- /resource/chapter5/5_4_1_1 Encoding Parameter Examples.md: -------------------------------------------------------------------------------- 1 | #### [5.4.1.1 编码参数示例](http://w3c.github.io/webrtc-pc/#rtcrtpencodingspatialsim-example*) 2 | 3 | 本节不具有规范性。 4 | 5 | 使用编码参数实现的联播场景示例： 6 | 7 | ``` 8 | EXAMPLE 4 9 | // Example of 3-layer spatial simulcast with all but the lowest resolution layer disabled 10 | var encodings = [ 11 | {rid: 'f', active: false}, 12 | {rid: 'h', active: false, scaleResolutionDownBy: 2.0}, 13 | {rid: 'q', active: true, scaleResolutionDownBy: 4.0} 14 | ]; 15 | 16 | // Example of 3-layer framerate simulcast with the middle layer disabled 17 | var encodings = [ 18 | {rid: 'f', active: true, maxFramerate: 60}, 19 | {rid: 'h', active: false, maxFramerate: 30}, 20 | {rid: 'q', active: true, maxFramerate: 15} 21 | ]; 22 | ``` 23 | -------------------------------------------------------------------------------- /resource/chapter8/8_5_RTCStatsEvent.md: -------------------------------------------------------------------------------- 1 | ## 8.5 `RTCStatsEvent` 2 | 3 | `statsended`事件使用`RTCStatsEvent`。 4 | 5 | ```java 6 | [ Constructor (DOMString type, RTCStatsEventInit 7 | eventInitDict), Exposed=Window] 8 | interface RTCStatsEvent : Event { 9 | readonly attribute RTCStatsReport report; 10 | }; 11 | ``` 12 | 13 | **构造函数** 14 | 15 | `RTCStatsEvent` 16 | 17 | **属性** 18 | 19 | RTCStatsReport类型的`report`:`report`属性包含RTCStats对象的相应子类的stats对象，给出生命周期结束时受监视对象的统计信息的值。 20 | 21 | ```java 22 | dictionary RTCStatsEventInit : EventInit { 23 | required RTCStatsReport report; 24 | }; 25 | ``` 26 | 27 | **字典RTCStatsEventInit成员** 28 | 29 | RTCStatsReport类型的`report`，必需的: 30 | 31 | 包含`RTCStats`对象，为生命周期结束的对象提供统计信息。 32 | -------------------------------------------------------------------------------- /resource/chapter4/4_3_2 RTCIceGatheringState 枚举.md: -------------------------------------------------------------------------------- 1 | ### [4.3.2 RTCIceGatheringState 枚举](http://w3c.github.io/webrtc-pc/#rtcicegatheringstate-enum) 2 | 3 | ``` 4 | enum RTCIceGatheringState { 5 | "new", 6 | "gathering", 7 | "complete" 8 | }; 9 | ``` 10 | 11 | 12 | 13 | 16 | 17 | 18 | 21 | 24 | 25 | 26 | 29 | 32 | 33 | 34 | 37 | 40 | 41 |
14 | Enumeration description 15 |
19 | new 20 | 22 | 任何 RTCIceTransport 都处于“new”收集状态，并且没有任何传输处于“gathering”状态，或者没有传输。 23 |
27 | gathering 28 | 30 | 任何 RTCIceTransport 都处于“gathering”收集状态。 31 |
35 | complete 36 | 38 | 至少存在一个 RTCIceTransport，并且所有RTCIceTransport都处于“已完成”的收集状态。 39 |
42 | 43 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_1 RTCRtpParameters 词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.1 `RTCRtpParameters`字典 2 | 3 | ```java 4 | dictionary RTCRtpParameters { 5 | required sequence headerExtensions; 6 | required RTCRtcpParameters rtcp; 7 | required sequence codecs; 8 | }; 9 | ``` 10 | 11 | **字典`RTCRtpParameters`成员** 12 | 13 | 序列类型的headerExtensions: 14 | 15 | 包含RTP标头扩展参数的序列。只读参数。 16 | 17 | `RTCRtcpParameters`类型的`rtcp`: 18 | 19 | 用于RTCP的参数。只读参数。 20 | 21 | 序列``类型的`codecs`: 22 | 23 | 包含`RTCRtpSender`将选择的媒体编码器序列，以及RTX，RED和FEC机制的条目。对应于通过RTX进行重新传输的每个媒体编解码器，在`codecs[]`中将有一个条目，其中`mimeType`属性表示通过"audio/rtx"或"video/rtx"重新传输，以及`sdpFmtpLine`属性(提供"apt"和"rtx-time"参数)。只读参数。 24 | 25 | -------------------------------------------------------------------------------- /resource/chapter7/7_4_RTCDTMFToneChangeEvent.md: -------------------------------------------------------------------------------- 1 | ## 7.4`RTCDTMFToneChangeEvent` 2 | 3 | `tonechange`事件使用`RTCDTMFToneChangeEvent`接口。 4 | 5 | ```java 6 | [ Constructor (DOMString type, RTCDTMFToneChangeEventInit eventInitDict), Exposed=Window] 7 | interface RTCDTMFToneChangeEvent : Event { 8 | readonly attribute DOMString tone; 9 | }; 10 | ``` 11 | 12 | **构造函数** 13 | 14 | `RTCDTMFToneChangeEvent` 15 | 16 | **属性** 17 | 18 | DOMString类型的`tone`，只读：:`tone`属性包含刚刚开始播放的音调（包括“，”）的字符（参见`insertDTMF`）。如果该值为空字符串，则表示[[ToneBuffer]]插槽为空字符串，并且前一个音调已完成播放。 19 | 20 | ```java 21 | dictionary RTCDTMFToneChangeEventInit : EventInit { 22 | required DOMString tone; 23 | }; 24 | ``` 25 | 26 | **字典`RTCDTMFToneChangeEventInit`成员** 27 | 28 | DOMString类型的`tone`:`tone`属性包含刚刚开始播放的音调（包括“，”）的字符（参见`insertDTMF`）。如果该值为空字符串，则表示[[ToneBuffer]]插槽为空字符串，并且前一个音调已完成播放。 29 | -------------------------------------------------------------------------------- /resource/chapter4/4_8_1_3 RTCIceTcpCandidateType 枚举.md: -------------------------------------------------------------------------------- 1 | #### [4.8.1.3 RTCIceTcpCandidateType枚举](http://w3c.github.io/webrtc-pc/#rtcicetcpcandidatetype-enum) 2 | 3 | `RTCIceTcpCandidateType`表示ICE TCP候选的类型，如[RFC6544]中所定义。 4 | 5 | ``` 6 | enum RTCIceTcpCandidateType { 7 | "active", 8 | "passive", 9 | "so" 10 | }; 11 | ``` 12 | 13 | 14 | 15 | 18 | 19 | 20 | 23 | 26 | 27 | 28 | 31 | 34 | 35 | 36 | 39 | 42 | 43 |
16 | 枚举描述 17 |
21 | active 22 | 24 | 表示一个`active`状态的TCP候选人，这将会尝试打开一个出站连接，但不会接收传入连接的请求。 25 |
29 | passive 30 | 32 | 表示一个`passive`状态的TCP候选人，这将会接收传入连接的请求，但不会尝试打开一个出站连接。 33 |
37 | so 38 | 40 | 表示一个`so`状态的候选人，这将会尝试与对端同时打开一个连接。 41 |
44 | 45 | NOTE：用户代理通常只收集活动的ICE TCP候选者。 46 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_13 RTCRtpCodecCapability词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.13 `RTCRtpCodecCapability`字典 2 | 3 | ```java 4 | dictionary RTCRtpCodecCapability { 5 | required DOMString mimeType; 6 | required unsigned long clockRate; 7 | unsigned short channels; 8 | DOMString sdpFmtpLine; 9 | }; 10 | ``` 11 | 12 | **字典`RTCRtpCodecCapability`成员** 13 | 14 | `RTCRtpCodecCapability`字典提供有关编解码器功能的信息。仅提供将在生成SDP请求中利用不同有效载荷类型的capability组合。例如： 15 | 16 | 1. 两个H.264/AVC编解码器，分别用于两个支持的分组模式值。 17 | 2. 具有不同始终速率的两个CN编解码器。 18 | 19 | **DOMString类型**的`mimeType`: 20 | 21 | 编解码器MIME媒体类型/子类型。[IANA-RTP-2]中列出了有效的媒体类型和子类型。 22 | 23 | **unsigned long 类型**的`clockRate`: 24 | 25 | 以赫兹为单位的编解码器的时钟速率。 26 | 27 | **unsigned short类型**的`channels`: 28 | 29 | 如果存在，表示最大通道数量(mono=1，stereo=2)。 30 | 31 | **DOMString类型**的`sdpFmtpLine`: 32 | 33 | 来自SDP中与编解码器对应的"a=fmtp"行的"格式特定参数"字段(如果存在)。 34 | 35 | -------------------------------------------------------------------------------- /resource/chapter4/4_2_5 RTCIceTransportPolicy枚举.md: -------------------------------------------------------------------------------- 1 | ### [4.2.5 RTCIceTransportPolicy 枚举](http://w3c.github.io/webrtc-pc/#rtcicetransportpolicy-enum) 2 | 3 | 4 | 5 | 如[JSEP]（第4.1.1节）中所述，如果指定了RTCConfiguration的iceTransportPolicy成员，则它定义了浏览器获取ICE候选地址的策略[JSEP]（第3.5.3节）;只有这些候选地址才会用于连接性检查。 6 | 7 | ``` 8 | enum RTCIceTransportPolicy { 9 | "relay", 10 | "all" 11 | }; 12 | ``` 13 | 14 | 15 | 16 | 19 | 20 | 21 | 24 | 28 | 29 | 30 | 33 | 37 | 38 |
17 | Enumeration description (non-normative) 18 |
22 | relay 23 | 25 | ICE代理仅使用媒体中继候选地址，例如通过TURN服务器的候选地址。 26 | NOTE：这可以用于防止远端了解到用户的IP地址，这可能用于一些特定的情况下。例如，在基于“呼叫”的应用程序中，应用程序可能不希望未知呼叫者知道被呼叫者的IP地址，直到被呼叫者以某种方式同意为止。 27 |
31 | all 32 | 34 | 指定此值时，ICE代理可以使用任何类型的候选地址。 35 | 该实现仍然可以使用其自己的候选过滤策略，以限制暴露IP地址给应用程序，如RTCIceCandidate.address的描述中所述。 36 |
39 | -------------------------------------------------------------------------------- /resource/chapter4/4_8_1_4 RTCIceCandidateType 枚举.md: -------------------------------------------------------------------------------- 1 | #### [4.8.1.4 RTCIceCandidateType枚举](http://w3c.github.io/webrtc-pc/#rtcicecandidatetype-enum) 2 | 3 | RTCIceCandidateType表示ICE候选的类型，如[ICE]第15.1节中所定义。 4 | 5 | ``` 6 | enum RTCIceCandidateType { 7 | "host", 8 | "srflx", 9 | "prflx", 10 | "relay" 11 | }; 12 | ``` 13 | 14 | 15 | 16 | 19 | 20 | 21 | 24 | 27 | 28 | 29 | 32 | 35 | 36 | 37 | 40 | 43 | 44 | 45 | 48 | 51 | 52 |
17 | 枚举描述 18 |
22 | host 23 | 25 | 表示一个主持人候选人, 详细描述参考 4.1.1.1 节 [ICE]. 26 |
30 | srflx 31 | 33 | 表示一个服务端反身候选人, 详细描述参考 4.1.1.2 节 [ICE]. 34 |
38 | prflx 39 | 41 | 表示一个对端反身候选人，详细描述参考 4.1.1.2 节 [ICE]. 42 |
46 | relay 47 | 49 | 表示一个中继候选人, 详细描述参考 7.1.3.2.1 节 [ICE]. 50 |
53 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_11RTCRtpCodecParameters词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.11 `RTCRtpCodecParameters`字典 2 | 3 | ```java 4 | dictionary RTCRtpCodecParameters { 5 | required octet payloadType; 6 | required DOMString mimeType; 7 | required unsigned long clockRate; 8 | unsigned short channels; 9 | DOMString sdpFmtpLine; 10 | }; 11 | ``` 12 | 13 | **字典`RTCRtpCodecParameters`成员** 14 | 15 | **octet**类型的`payloadType`: 16 | 17 | 用于验证编解码器的RTP负载类型。只读参数。 18 | 19 | **DOMString**类型的mimeType： 20 | 21 | 编解码器MIME媒体类型/子类型。有效的媒体类型和子类型都在[IANA-RTP-2]中列出。只读参数。 22 | 23 | **unsigned long**类型的`clockRate`: 24 | 25 | 编解码器的时钟速率，以赫兹为单位。只读参数。 26 | 27 | **unsigned short**类型的`channels`： 28 | 29 | 存在时，表示通道数量(mono=1, stereo=2)。只读参数。 30 | 31 | **DOMString**类型的`sdpFmtpLine`: 32 | 33 | SDP中对应于编解码器的"a=fmtp"行中的"格式特定参数"字段(如果存在)，如[JSEP]所定义(第5.8节)。对于`RTCRtpSender`,这些参数来自远程描述，对于`RTCRtpReceiver`,它们来自本地描述。只读参数。 34 | 35 | -------------------------------------------------------------------------------- /resource/chapter6/6_3_RTCDataChannelEvent.md: -------------------------------------------------------------------------------- 1 | ## 6.3 `RTCDataChannelEvent` 2 | 3 | 使用`RTCDataChannelEvent`接口的`datachannel`事件。[测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCPeerConnection-ondatachannel.html) 4 | 5 | ```java 6 | [ Constructor (DOMString type, RTCDataChannelEventInit eventInitDict), Exposed=Window] 7 | interface RTCDataChannelEvent : Event { 8 | readonly attribute RTCDataChannel channel; 9 | }; 10 | ``` 11 | 12 | **构造函数** 13 | 14 | `RTCDataChannelEvent` 15 | 16 | [测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCDataChannelEvent-constructor.html) 17 | 18 | **属性** 19 | 20 | `RTCDataChannel`类型的channel，只读：channel属性表示与事件关联的`RTCDataChannel`对象。 21 | 22 | ```java 23 | dictionary RTCDataChannelEventInit : EventInit { 24 | required RTCDataChannel channel; 25 | }; 26 | ``` 27 | 28 | **字典`RTCDataChannelEventInit`成员** 29 | 30 | `RTCDataChannel`类型的channel，required：将要被事件宣布的`RTCDataChannel`对象。 31 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_1_2 将操作排入队列.md: -------------------------------------------------------------------------------- 1 | #### [4.4.1.2 将操作排入队列](http://w3c.github.io/webrtc-pc/#enqueue-an-operation) 2 | 3 | RTCPeerConnection对象有一个操作队列[[Operations]]，它确保队列中只有一个异步操作同时执行。如果下一个 promise 请求被调用时之前的 promise 还没返回，则将它们添加到队列中并等到队列前面所有的 promise 执行完毕并返回后再执行。 4 | 5 | 要将操作加入 RTCPeerConnection 对象的操作队列，请运行以下步骤： 6 | 7 | 1. 让连接成为 RTCPeerConnection 对象。 8 | 9 | 2. 如果 connection 的[[IsClosed]] 值为true，用 promise 包装一个新创建的 InvalidStateError 并以reject返回。 10 | 11 | 3. 让操作成为即将入队的那一项。 12 | 13 | 4. 创建新 promise ，名为 p 14 | 15 | 5. 将操作附加到[[操作]]列表中。 16 | 17 | 6. 如果[[操作]]的长度恰好为1，则执行操作。 18 | 19 | 7. promise返回后，如果状态是 fulfillment 或 rejection，请执行以下步骤： 20 | 21 | 1. 如果connection的[[IsClosed]]值为true，则中止这些步骤。 22 | 23 | 2. 如果操作返回的 promise 已完成并有值，则将 p 以 fulfill 的状态返回该值。 24 | 25 | 3. 如果操作返回的 promise 被拒绝并有值，则将 p 以 rejected 的状态返回该值。 26 | 27 | 4. 完成或拒绝p后，执行以下步骤： 28 | 29 | 1. 如果connection的[[IsClosed]]值为true，则中止这些步骤。 30 | 31 | 2. 删除[[操作]]的第一个元素。 32 | 33 | 3. 如果[[操作]]非空，则执行[[操作]]队列中的第一个操作。 34 | 35 | 36 | 8. 返回 p。 37 | -------------------------------------------------------------------------------- /resource/chapter4/4_2_6 RTCBundlePolicy 枚举.md: -------------------------------------------------------------------------------- 1 | ### [4.2.6 RTCBundlePolicy 枚举](http://w3c.github.io/webrtc-pc/#rtcbundlepolicy-enum) 2 | 3 | 如[JSEP]（第4.1.1节）中所述，如果远程端点不支持bundle策略，会影响协商哪些媒体轨道的协商，以及会收集那些 ICE 候选地址。如果远端支持 bundle 策略，则所有媒体轨道和数据通道都捆绑在同一传输路径上。 4 | 5 | ``` 6 | enum RTCBundlePolicy { 7 | "balanced", 8 | "max-compat", 9 | "max-bundle" 10 | }; 11 | ``` 12 | 13 | 14 | 15 | 18 | 19 | 22 | 25 | 26 | 29 | 32 | 33 | 34 | 37 | 40 | 41 |
16 | Enumeration description (non-normative) 17 |
20 | balanced 21 | 23 | 为正在使用的每种媒体类型（音频，视频和数据）收集 ICE 候选地址。如果远程端点不支持 bundle 策略，则在一个传输路径上仅协商一个音频和视频轨道。 24 |
27 | max-compat 28 | 30 | 收集每个媒体轨道的 ICE 候选地址。如果远程端点不支持 bundle，则在一个传输路径上协商所有媒体轨道。 31 |
35 | max-bundle 36 | 38 | 只收集一个媒体轨道的 ICE 候选地址。如果远程端点不支持 bundle 策略，则仅协商一个媒体轨道。 39 |
42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # WebRTC 文档翻译项目 2 | 3 | 中文版 WebRTC 1.0官方文档，由 [RTC 开发者社区](https://rtcdeveloper.com/)及 [WebRTC 中文网](http://webrtc.org.cn/)发起的翻译、校对项目。旨在为 WebRTC 开发者们提供一份标准的 [WebRTC API 文档](https://www.w3.org/TR/webrtc/)，易于大家学习与开发。 4 | 5 | 目前，我们已经通过编写好的脚本程序（稍后开源，供有需要的人使用）完成了文档的初步翻译工作，翻译后的文档正在逐步添加中。欢迎参与校对。 6 | 7 | ## 贡献力量 8 | 9 | 如果希望为 RTC(Real-Time Communication) 社区贡献力量，欢迎： 10 | 11 | - 参与校对 12 | 13 | - 提出修改建议 14 | 15 | - 协助改进术语翻译 16 | 17 | 如果你有兴趣参与进来，请仔细阅读： 18 | 19 | - 为了有利阅读，翻译时请遵循 [翻译排版指南.md](/翻译排版指南.md) 20 | 21 | - 翻译流程，请参照 [翻译校对流程.md](/翻译校对流程.md) 22 | 23 | ## 感谢本项目的贡献者们 24 | 25 | 请见《WebRTC 官方文档-中文版》[贡献榜](/contributors.md) 26 | 27 | ## 参考 28 | 29 | WebRTC 代码可参考[官网](https://webrtc.googlesource.com/src)或[这个地址](https://github.com/ibaoger/webrtc) 30 | 31 | ## 术语表 32 | 33 | | 术语 | 注解 | 34 | | --- | --- | 35 | | STUN | Session Traversal Utilities for NAT，NAT 会话传输应用程序，一种网络协议，它允许位于 NAT（或多重 NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的 NAT 之后以及NAT为某一个本地端口所绑定的 Internet 端端口。这些信息被用来在两个同时处于 NAT 路由器之后的主机之间建立 UDP 通信。详见 [RFC5389](https://tools.ietf.org/html/rfc5389)。| 36 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_2 RTCRtpSendParameters 词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.2 `RTCRtpSendParameters`字典 2 | 3 | ```java 4 | dictionary RTCRtpSendParameters : RTCRtpParameters { 5 | required DOMString transactionId; 6 | required sequence encodings; 7 | RTCDegradationPreference degradationPreference = "balanced"; 8 | RTCPriorityType priority = "low"; 9 | }; 10 | ``` 11 | 12 | **字典`RTCRtpSendParameters`成员** 13 | 14 | DOMString类型的`transactionId`： 15 | 16 | 应用的最后一组参数的唯一标识符。确保只能基于先前的getParameters调用setParameters，并且没有干预更改。只读参数。 17 | 18 | 序列类型的`encodings`： 19 | 20 | 包含媒体RTP编码参数的序列。 21 | 22 | `RTCDegradationPreference`类型的`degradationPreference`,默认为`"balanced":` 23 | 24 | 当带宽受到限制，`RTCRtpSender`需要在降低分辨率和降低帧率之间做出选择，`degradationPreference`指定倾向的选择。 25 | 26 | `RTCPriorityType`类型的`priority`，默认为`"low"`: 27 | 28 | 表示`RTCRtpSender`的优先级，它影响`RTCRtpSender`对象之间的带宽分配。它在[RTCWEB-TRANSPORT]第四节中指定。用户代理可以在`RTCRtpSender`的编码之间自由地分配带宽。 29 | 30 | 31 | 32 | -------------------------------------------------------------------------------- /resource/chapter4/4_9_1 RTCPriorityType枚举.md: -------------------------------------------------------------------------------- 1 | ### [4.9.1 RTCPriorityType枚举类型](http://w3c.github.io/webrtc-pc/#rtcprioritytype-enum) 2 | 3 | ``` 4 | enum RTCPriorityType { 5 | "very-low", 6 | "low", 7 | "medium", 8 | "high" 9 | }; 10 | ``` 11 | 12 | 13 | 14 | 17 | 18 | 19 | 22 | 25 | 26 | 27 | 30 | 33 | 34 | 35 | 38 | 41 | 42 | 43 | 46 | 49 | 50 |
15 | 枚举类型描述 16 |
20 | very-low 21 | 23 | 参看[RTCWEB-TRANSPORT], 第4.1和4.2小节. 等同于定义在[RTCWEB-DATA]中的"below normal". 24 |
28 | low 29 | 31 | 参看[RTCWEB-TRANSPORT], 第4.1和4.2小节. 等同于定义在[RTCWEB-DATA]中的"normal". 32 |
36 | medium 37 | 39 | 参看[RTCWEB-TRANSPORT], 第4.1和4.2小节. 等同于定义在[RTCWEB-DATA]中的"high". 40 |
44 | high 45 | 47 | 参看[RTCWEB-TRANSPORT], 第4.1和4.2小节. 等同于定义在[RTCWEB-DATA]中的"extra high". 48 |
51 | 52 | 当在应用程序中使用该API时，开发者需要意识到更好的整体用户体验通常来自于主动降低某些不重要媒体流的优先级而不是一味地去提高某些重要媒体流的优先级。 53 | -------------------------------------------------------------------------------- /resource/chapter4/4_2_7 RTCRtcpMuxPolicy 枚举.md: -------------------------------------------------------------------------------- 1 | ### [4.2.7 RTCRtcpMuxPolicy 枚举](http://w3c.github.io/webrtc-pc/#rtcrtcpmuxpolicy-enum) 2 | 3 | 如[JSEP]（第4.1.1节）中所述，RtcpMuxPolicy会影响为支持非多路复用而收集哪些ICE候选项。 4 | 5 | ``` 6 | enum RTCRtcpMuxPolicy { 7 | // At risk due to lack of implementers' interest. 8 | "negotiate", 9 | "require" 10 | }; 11 | ``` 12 | 13 | 14 | 15 | 18 | 19 | 20 | 23 | 26 | 27 | 28 | 31 | 34 | 35 |
16 | Enumeration description (non-normative) 17 |
21 | negotiate 22 | 24 | 同时收集RTP和RTCP的ICE候选项。如果远程端点能够复用RTCP，则在RTP候选地址上复用RTCP。如果不是，请分开使用RTP和RTCP候选项。请注意，如[JSEP]（第4.1.1节）中所述，用户代理可能无法实现非多路复用的RTCP，在这种情况下，它将拒绝使用协商策略创建 RTCPeerConnection 实例的尝试。 25 |
29 | require 30 | 32 | 只收集RTC候选地址和在RTP上复用了RTCP的候选地址。如果远程端点不支持rtcp-mux，则会话协商将失败。 33 |
36 | 37 | >FEATURE AT RISK 1 38 | > 39 | 支持非多路复用RTP / RTCP的本规范的各个方面被标记为存在风险的特征，因为实施者没有明确的承诺。这包括： 40 | >1. 对于negotiate值，实施者没有明确承诺与此相关的行为。 41 | >2. 支持RTCRtpSender和RTCRtpReceiver中的rtcpTransport属性。 42 | -------------------------------------------------------------------------------- /resource/chapter5/5_4_1 Simulcast functionality.md: -------------------------------------------------------------------------------- 1 | ### [5.4.1 联播功能](http://w3c.github.io/webrtc-pc/#simulcast-functionality) 2 | 3 | 通过`RTCPeerConnection`对象的`addTransceiver`方法和`RTCRtpSender`对象的`setParameters`方法提供联播功能。 4 | `addTransceiver`方法建立联播信封，其中包括可以发送的最大联播流数量，以及编码的顺序。虽然可以使用`setParameters`方法修改单个联播流的特征，但不能更改联播信封。此模型的一个含义是`addTrack`方法无法提供联播功能，因为它不将`sendEncodings`作为参数，因此无法配置`RTCRtpTransceiver`来发送联播。 5 | 虽然`setParameters`无法修改联播信封，但仍可以控制发送的流的数量和这些流的特征。使用`setParameters`，可以通过将`active`属性设置为`false`来使联播流处于非活动状态，或者可以通过将`active`属性设置为`true`来重新激活联播流。使用`setParameters`，可以通过修改`maxBitrate`和`maxFramerate`等属性来更改流特性。 6 | 7 | 此规范未定义如何配置`createOffer`以接收多个 RTP 编码。但是，当使用能够发送[JSEP]中定义的多个 RTP 编码的相应远程描述调用`setRemoteDescription`时，`RTCRtpReceiver`可以接收多个 RTP 编码，并且通过收发器的`receiver.getParameters（）`检索的参数将反映协商的编码。 8 | >NOTE 9 | > 10 | >在选择性转发单元（SFU）在从用户代理接收的联播流之间切换的情况下，`RTCRtpReceiver`可以接收多个RTP流。如果 SFU 不重写 RTP 报头以便在转发之前将切换流安排到单个 RTP 流中，则 RTCRtpReceiver 将接收来自不同 RTP 流的分组，每个 RTP 流具有其自己的 SSRC 和序列号空间。虽然 SFU 可能仅在任何给定时间转发单个 RTP 流，但是由于重新排序，来自多个 RTP 流的分组可能在接收器处混合。因此，配备用于接收多个 RTP 流的 RTCRtpReceiver 将需要能够正确地对接收的分组进行排序，识别潜在的丢失事件并对它们作出反应。在这种情况下的正确操作是非常重要的，因此对于本规范的实现是可选的。 11 | -------------------------------------------------------------------------------- /resource/chapter8/8_4_RTCStats词典.md: -------------------------------------------------------------------------------- 1 | # 8.4 `RTCStats`字典 2 | 3 | `RTCStats`字典表示通过检查特定受监视对象构造的stats对象。 `RTCStats`字典是一种基本类型，它指定一组默认属性，例如时间戳和类型。通过扩展`RTCStats`字典添加特定的统计信息。 4 | 5 | 请注意，虽然统计信息名称是标准化的，但任何给定的实现都可能使用Web应用程序尚不知道的值或实验值。因此，应用程序必须准备好处理未知的统计数据。 6 | 7 | 统计需要彼此同步才能产生合理的计算值;例如，如果同时报告“bytesSent”和“packetsSent”，则需要在相同的时间间隔内报告它们，这样“平均数据包大小”可以计算为“字节/数据包” - 如果间隔不同，则会产生错误。因此，实现必须返回`RTCStats`派生字典中所有统计信息的同步值。 8 | 9 | ```java 10 | dictionary RTCStats { 11 | required DOMHighResTimeStamp timestamp; 12 | required RTCStatsType type; 13 | required DOMString id; 14 | }; 15 | ``` 16 | 17 | **字典`RTCStats`成员** 18 | 19 | DOMHighResTimeStamp类型的`timestamp`:与此对象关联的DOMHighResTimeStamp [HIGHRES-TIME]类型的时间戳。时间相对于UNIX纪元（1970年1月1日，UTC）。对于来自远程源（例如，来自接收的RTCP数据包）的统计，时间戳表示信息到达本地端点的时间。如果适用，可以在`RTCStats`派生的字典中的附加字段中找到远程时间戳。 20 | 21 | RTCStatsType类型的`type`: 22 | 23 | 此对象的类型。 24 | 25 | `type`属性必须初始化为此`RTCStats`字典所代表的最具体类型的名称。 26 | 27 | DOMString类型的`id`:与检查生成此`RTCStats`对象的对象关联的唯一ID。从两个不同的`RTCStatsReport`对象中提取的两个`RTCStats`对象，如果它们是通过检查相同的底层对象生成的，则必须具有相同的id。用户代理可以自由选择id的任何格式，只要它符合上述要求即可。 28 | 29 | RTBRStatsType的有效值集以及它们指示的RTCStats派生的字典记录在[WEBRTC-STATS]中。 30 | -------------------------------------------------------------------------------- /resource/chapter4/4_6_2 RTCSessionDescription 类.md: -------------------------------------------------------------------------------- 1 | ### [4.6.2 RTCSessionDescription 类](http://w3c.github.io/webrtc-pc/#rtcsessiondescription-class) 2 | 3 | RTCPeerConnection通过RTCSessionDescription类来公开本地和远程会话描述。 4 | 5 | ``` 6 | [Constructor(RTCSessionDescriptionInit descriptionInitDict), 7 | Exposed=Window] 8 | interface RTCSessionDescription { 9 | readonly attribute RTCSdpType type; 10 | readonly attribute DOMString sdp; 11 | [Default] object toJSON(); 12 | }; 13 | 14 | ``` 15 | **构造函数** 16 | 17 | `RTCSessionDescription 类` 18 | 19 | RTCSessionDescription() 构造函数接受一个字典参数`descriptionInitDict`，用于初始化新的`RTCSessionDescription`对象。这个构造函数已废弃，不推荐使用此构造函数;它的存在仅用于历史兼容。 20 | 21 | **属性** 22 | 23 | `type`类型为`RTCSdpType`，只读项 24 | 25 | 这个RTCSessionDescription的类型。 26 | 27 | `sdp`类型为`DOMString`，只读项 28 | 29 | SDP [SDP]的字符串表示形式。 30 | 31 | **方法** 32 | 33 | `toJSON()` 34 | 35 | 调用时，运行[WEBIDL]的默认`toJSON`操作。 36 | 37 | ``` 38 | dictionary RTCSessionDescriptionInit { 39 | required RTCSdpType type; 40 | DOMString sdp = ""; 41 | }; 42 | ``` 43 | 字典RTCSessionDescriptionInit成员 44 | 45 | `type`类型为RTCSdpType，必需项 46 | DOMString sdp 47 | `sdp`类型为`DOMString` 48 | SDP [SDP]的字符串表示形式。如果`type`为`rollback`，则该成员未使用。 -------------------------------------------------------------------------------- /resource/chapter4/4_6_1 会话描述模型 - RTCSdpType 枚举.md: -------------------------------------------------------------------------------- 1 | ## [4.6 会话描述模型](http://w3c.github.io/webrtc-pc/#session-description-model) 2 | 3 | ### 4.6.1 `RTCSdpType` 枚举 4 | 5 | RTCSdpType 枚举描述了RTCSessionDescriptionInit或RTCSessionDescription实例的类型。 6 | 7 | ``` 8 | enum RTCSdpType { 9 | "offer", 10 | "pranswer", 11 | "answer", 12 | "rollback" 13 | }; 14 | ``` 15 | 16 | 17 | 18 | 21 | 22 | 23 | 26 | 29 | 30 | 31 | 34 | 37 | 38 | 39 | 42 | 45 | 46 | 47 | 50 | 53 | 54 |
19 | 枚举描述 20 |
24 | offer 25 | 27 | 一个RTCSdpType的`offer`表示必须将一个描述视为一个[SDP]提供。 28 |
32 | pranswer 33 | 35 | 一个RTCSdpType的`pranswer`表示必须将一个描述视为[SDP]应答，但不是最终应答。一个描述可以作为一个 SDP offer 的应答响应，或对先前发送的 SDP pranswer 的更新。 36 |
40 | answer 41 | 43 | 一个RTCSdpType的`answer`表示必须将一个描述视为[SDP]的最终应答，并且必须认为 offer-answer 交换完成。一个描述可以用于响应 SDP offer 的最终应答或者可作为对先前发送的SDP pranswer的更新。 44 |
48 | rollback 49 | 51 | 一个RTCSdpType的`rollback`表示必须将一个描述视为取消当前SDP协商并回退SDP [SDP]提供和最终应答到它先前的稳定状态下。请注意，如果还没有成功进行 offer - answer 协商，则先前稳定状态的本地或远程SDP的描述可能为空。 52 |
55 | 56 | 57 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_10RTCRtpHeaderExtensionParameters词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.10 `RTCRtpHeaderExtensionParameters`字典 2 | 3 | ```java 4 | dictionary RTCRtpHeaderExtensionParameters { 5 | required DOMString uri; 6 | required unsigned short id; 7 | boolean encrypted = false; 8 | }; 9 | ``` 10 | 11 | **字典`RTCRtpHeaderExtensionParameters`成员** 12 | 13 | DOMString类型的`uri`： 14 | 15 | RTP标头扩展的URI，[RFC5285]中定义。只读参数。 16 | 17 | unsigned short类型的`id`: 18 | 19 | 放入RTP数据包用于验证标头扩展的值。只读参数。 20 | 21 | Boolean类型的`encrypted`: 22 | 23 | 标头是否加密。只读参数。 24 | 25 | > NOTE 26 | > 27 | > `RTCRtpHeaderExtensionParameters`字典启用应用程序来确定是否配置了标头扩展以在`RTCRtpSender`或`RTCRtpReceiver`中使用。对于一个`RTCRtpTransceiver`收发器，应用程序可以在不解析SDP的情况下确定标头扩展的"direction"参数([RFC5285]第五章定义)，如下： 28 | > 29 | > 1. sendonly:标头扩展只能包含在transceiver.sender.getParameters().headerExtensions中。 30 | > 2. recvonly:标头扩展只能包含在transceiver.receiver.getParameters().headerExtensions中。 31 | > 3. sendrecv:标头扩展可以包含在transceiver.sender.getParameters().headerExtensions和transceiver.receiver.getParameters().headerExtensions中。 32 | > 4. inactive:标头扩展既不包含在transceiver.sender.getParameters().headerExtensions中也不包含在transceiver.receiver.getParameters().headerExtensions中。 33 | 34 | 35 | 36 | 37 | 38 | -------------------------------------------------------------------------------- /翻译校对流程.md: -------------------------------------------------------------------------------- 1 | # 翻译校对流程 2 | 3 | ## 翻译流程 4 | 5 | 已经通过 Python 脚本完成文档翻译，官方会按照小章节添加至此，并建立 issue。校对者，在 issue 中认领任务即可。 6 | 7 | ## 校对流程梳理 8 | 9 | ![流程](/image/proofread.png) 10 | 11 | 1. 领取流程：issue 作为文章池。 12 | 2. 临时分支定义：仅仅用来对 master 分支发起 PR，在整个流程结束后（Merge 进 master 分支）将临时分支删除。 13 | 3. 校对完成后，对 repo 增加文件，发起 PR。 14 | 4. 确认校对完成：项目发起者 Merge。 15 | 16 | 17 | 18 | ## 如何发起 Pull Request（不熟悉 Github 的同学请阅读） 19 | 20 | ### Fork 工作流的好处 21 | 22 | Fork 工作流与上述流程不一样，大家操作的并不是本代码仓库。每个人都有一个属于自己的仓库，可以进行任意修改并且对本仓库不会造成影响。Fork 工作流的主要优点在于贡献可以轻易地整合进项目，而不需要每个人都推送到单一的中央仓库。开发者推送到他们自己的服务端仓库，只有项目管理者可以推送到官方仓库。这使得管理者可以接受任何开发者的提交，却不需要给他们中央仓库的权限。 23 | 24 | ### Pull Request 操作说明 25 | 26 | 1. Fork 该仓库到自己的 GitHub 账号。得到一个自己的私有仓库可以任意修改并不会影响本仓库。 27 | 2. Clone 自己的的仓库到本地。 28 | 3. 添加仓库为另一个远程实现与之的同步。 29 | 4. 在本地仓库新建分支完成自己的文章翻译并提交到自己的仓库。 30 | 5. 在自己的仓库中点击 *New pull request* 给仓库发 PR。 31 | 6. 如果需要根据校对意见进行修改，则修改后再走一遍上述 Commit -> PR 就行了。 32 | 7. 因为翻译是个协作流程，所以需要定期同步本仓库的更改，此时依次运行：*git fetch upstream*、*git checkout master* 、*git merge upstream/master* 即可。最好是在自己准备翻译之前同步一次。 33 | 34 | ## Q & A 35 | 36 | ### Q：会不会带来和代码 merge 同样的问题，多分支 merge 造成的冲突？ 37 | 38 | A：不会。因为翻译流程 PR 只对 master 仓库进行 Add 文件操作，所以不会带来多人同时修改一个文件的情况。 39 | 40 | --- 41 | 42 | 注：本规则在实际操作过程中，如遇到问题，请在[ RTC 开发者社区](https://rtcdeveloper.com)发帖提出，我们会再逐步优化。 43 | -------------------------------------------------------------------------------- /resource/chapter4/4_2_3 RTCOAuthCredential Dictionary.md: -------------------------------------------------------------------------------- 1 | ### [4.2.3 RTCOAuthCredential Dictionary](http://w3c.github.io/webrtc-pc/#rtcoauthcredential-dictionary) 2 | 3 | RTCOAuthCredential字典用于描述OAuth auth凭证信息，STUN / TURN 客户端（在 ICE 代理内部）使用该信息对 STUN / TURN 务器进行身份验证，如[RFC7635]中所述。请注意，kid参数不在此字典中，而是在RTCIceServer的成员变量 username 中。 4 | 5 | ``` 6 | dictionary RTCOAuthCredential { 7 | required DOMString macKey; 8 | required DOMString accessToken; 9 | }; 10 | ``` 11 | 12 | 字典RTCOAuthCredential成员 13 | 14 | DOMString类型的`macKey`，需要： 15 | 16 | `mac_key`，如[RFC7635]第 6.2 节中所述，采用 base64-url 编码格式。它用于 STUN 消息完整性哈希计算（因为密码用于基于密码的身份验证）。请注意，OAuth 响应“key”参数是 JSON Web Key（JWK）或使用 JWE 格式加密的 JWK 。另请注意，这是唯一不直接使用其值的OAuth参数，但必须从JWK的“k”参数值中提取，该参数值包含所需的base64编码的“mac_key”。 17 | 18 | DOMString类型的`accessToken`，需要： 19 | 20 | `access_token`，如[RFC7635]第6.2节中所述，采用 base64 编码格式。这是一个加密的自包含令牌，对应用程序不透明。认证加密用于消息加密和完整性保护。访问令牌包含非加密的nonce值，授权服务器使用该值来生成唯一的mac_key。令牌的第二部分受认证加密保护。它包含 mac_key ，时间戳和生命周期。时间戳与生命周期相结合提供了到期信息;此信息描述了令牌凭证有效并能被TURN服务器接受的时间窗口。 21 | 22 | 23 | RTCOAuthCredential字典的一个示例是： 24 | 25 | ``` 26 | 27 | { 28 | macKey: 'WmtzanB3ZW9peFhtdm42NzUzNG0=', 29 | accessToken: 'AAwg3kPHWPfvk9bDFL936wYvkoctMADzQ5VhNDgeMR3+ZlZ35byg972fW8QjpEl7bx91YLBPFsIhsxloWcXPhA==' 30 | } 31 | 32 | ``` 33 | -------------------------------------------------------------------------------- /resource/chapter8/8_8GetStats示例.md: -------------------------------------------------------------------------------- 1 | ## 8.8 GetStats示例 2 | 3 | 考虑用户遇到不良声音并且应用程序想要确定其原因是否是丢包的情形。可能使用以下示例代码： 4 | 5 | ```javascript 6 | async function gatherStats() { 7 | try { 8 | const sender = pc.getSenders()[0]; 9 | const baselineReport = await sender.getStats(); 10 | await new Promise((resolve) => setTimeout(resolve, aBit)); // ... wait a bit 11 | const currentReport = await sender.getStats(); 12 | 13 | // compare the elements from the current report with the baseline 14 | for (let now of currentReport.values()) { 15 | if (now.type != 'outbound-rtp') continue; 16 | 17 | // get the corresponding stats from the baseline report 18 | const base = baselineReport.get(now.id); 19 | 20 | if (base) { 21 | const remoteNow = currentReport.get(now.remoteId); 22 | const remoteBase = baselineReport.get(base.remoteId); 23 | 24 | const packetsSent = now.packetsSent - base.packetsSent; 25 | const packetsReceived = remoteNow.packetsReceived - remoteBase.packetsReceived; 26 | 27 | const fractionLost = (packetsSent - packetsReceived) / packetsSent; 28 | if (fractionLost > 0.3) { 29 | // if fractionLost is > 0.3, we have probably found the culprit 30 | } 31 | } 32 | } 33 | } catch (err) { 34 | console.error(err); 35 | } 36 | } 37 | ``` 38 | 39 | -------------------------------------------------------------------------------- /resource/chapter8/8_2_RTCPeerConnection接口扩展.md: -------------------------------------------------------------------------------- 1 | ## 8.2 RTCPeerConnection接口扩展 2 | 3 | 统计API对RTCPeerConnection接口的扩展如下。 4 | 5 | ```java 6 | partial interface RTCPeerConnection { 7 | Promise getStats (optional MediaStreamTrack? selector = null); 8 | attribute EventHandler onstatsended; 9 | }; 10 | ``` 11 | 12 | **属性** 13 | 14 | 事件处理程序类型的`onstatsended`: 15 | 16 | 此事件处理程序的事件类型是`statsended`。 17 | 18 | 为了删除与一个`RTCPeerConnection`，connection相关联的一系列被监控对象的统计信息，用户代理必须并行运行以下步骤： 19 | 20 | 1. 收集将要删除的一系列被监控对象的统计信息。这些信息必须代表删除时的最终值。这些信息不能出现在接下来对getStats()的调用中。 21 | 2. 对运行以下步骤的任务进行排队： 22 | 1. 让report成为新的`RTCStatsReport`对象。 23 | 2. 对于每个受监视对象，使用上面针对该受监视对象收集的统计信息创建新的相关统计信息对象对象，并将其添加到报告中。 24 | 3. 使用`RTCStatsEvent`接口发起一个名为`statsended`的事件，在connection将`report`属性设置为report。 25 | 26 | **方法** 27 | 28 | `getStats` 29 | 30 | 收集给定选择器的统计信息并异步报告结果。 31 | 32 | 当调用`getStats（）`方法时，用户代理必须运行以下步骤： 33 | 34 | 1. 让selectorArg成为方法的第一个参数。 35 | 2. 让connection成为调用方法的`RTCPeerConnection`对象。 36 | 3. 如果selectorArg为`null`，则让selector为`null`。 37 | 4. 如果selectorArg是MediaStreamTrack，让选择器成为connection上的`RTCRtpSender`或`RTCRtpReceiver`，并且connection的`track`成员匹配selectorArg。如果不存在此类发件人或收件人，或者如果多个发件人或收件人符合此条件，则返回承诺，拒绝条件是新创建`InvalidAccessError`。 38 | 5. 让p成为新的承诺。 39 | 6. 并行运行以下步骤： 40 | 1. 根据统计选择算法收集选择器指示的统计数据。 41 | 2. 使用生成的`RTCStatsReport`对象解析p，其中包含收集的统计信息。 42 | 7. 返回p。 43 | 44 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_3_2 旧版配置扩展.md: -------------------------------------------------------------------------------- 1 | #### [4.4.3.2 旧版配置扩展](http://w3c.github.io/webrtc-pc/#legacy-configuration-extensions) 2 | 3 | 除了添加到RTCPeerConnection的媒体之外，本节还介绍了一组可用于影响 offer 创建方式的旧版扩展。鼓励开发人员使用 RTCRtpTransceiver API。 4 | 5 | 使用本节中指定的任何旧版选项调用 createOffer 时，请运行以下步骤而不是常规 createOffer 步骤： 6 | 7 | 1. 让 options 成为方法的第一个参数。 8 | 9 | 2. 让connection成为当前的RTCPeerConnection对象。 10 | 11 | 3. 对于 options 中的每个"offerToReceive"成员，以及它的类别 kind ，执行以下步骤： 12 | 13 | 1. 如果字典成员的值为false， 14 | 15 | 1. 对每个未停止的"sendrecv"类的收发器 transceiver ，把 transceiver 中的[Direction] 设置为"sendonly"。 16 | 17 | 2. 对每个未停止的"recvonly"类别的收发器 transceiver ，把 transceiver 中的[Direction]值 设置为"inactive"。 如果有下一选项，继续此步骤 18 | 19 | 继续下一个选项（如果有）。 20 | 21 | 2. 如果连接具有任何不停止的“sendrecv”或“recvonly”类型的 transceiver，则继续下一个选项（如果有）。 22 | 23 | 3. 让调用connection.addTransceiver（kind）的结果赋值给 transceiver，除了这个操作绝不能更新需要协商的标志。 24 | 25 | 4. 如果由于先前的操作引发错误而未设置收发器，则中止这些步骤。 26 | 27 | 5. 将transceiver的[[Direction]]值设置为“recvonly”。 28 | 29 | 4. 运行 createOffer 指定的步骤以创建 offer。 30 | 31 | ``` 32 | partial dictionary RTCOfferOptions { 33 | boolean offerToReceiveAudio; 34 | boolean offerToReceiveVideo; 35 | }; 36 | ``` 37 | 38 | Attributes zh:属性 39 | 40 | offerToReceiveAudio 类型为 boolean 41 | 42 | 此设置提供对音频方向性的额外控制。例如，无论是否发送音频，它都可用于确保接收音频。 43 | 44 | offerToReceive 类型为 boolean 45 | 46 | 此设置提供对视频方向性的额外控制。例如，无论是否发送视频，它都可用于确保接收视频。 47 | -------------------------------------------------------------------------------- /resource/chapter4/4_3_3 RTCPeerConnectionState 枚举.md: -------------------------------------------------------------------------------- 1 | ### [4.3.3 RTCPeerConnectionState 枚举](http://w3c.github.io/webrtc-pc/#rtcpeerconnectionstate-enum) 2 | 3 | ``` 4 | enum RTCPeerConnectionState { 5 | "closed", 6 | "failed", 7 | "disconnected", 8 | "new", 9 | "connecting", 10 | "connected" 11 | }; 12 | ``` 13 | 14 | 15 | 16 | 19 | 20 | 21 | 24 | 27 | 28 | 29 | 32 | 35 | 36 | 37 | 40 | 43 | 44 | 45 | 48 | 51 | 52 | 53 | 56 | 59 | 60 | 61 | 64 | 67 | 68 |
17 | Enumeration description 18 |
22 | closed 23 | 25 | RTCPeerConnection对象的[[IsClosed]]值为true。 26 |
30 | failed 31 | 33 | 之前的状态不适用，任何RTCIceTransports或RTCDtlsTransports都处于“failed”状态。 34 |
38 | disconnected 39 | 41 | 之前的状态不适用，任何RTCIceTransports或RTCDtlsTransports都处于“disconnected”状态。 42 |
46 | new 47 | 49 | 以前的状态都不适用，并且所有RTCIceTransports或RTCDtlsTransport都处于“new”或“closed”状态，或者当前没有传输。 50 |
54 | connecting 55 | 57 | 以前的状态都不适用，并且所有RTCIceTransports或RTCDtlsTransport都处于“new”，“connecting”或”checking”状态。 58 |
62 | connected 63 | 65 | 以前的状态均不适用，并且所有RTCIceTransports和RTCDtlsTransports都处于“connected”，“completed”或“closed”状态。 66 |
69 | -------------------------------------------------------------------------------- /resource/chapter9/9_1网络使用的媒体流API扩展简介.md: -------------------------------------------------------------------------------- 1 | # 9 网络用途的媒体流API扩展 2 | 3 | ## 9.1 简介 4 | 5 | `MediaStreamTrack`接口（如[GETUSERMEDIA]规范中所定义）通常表示音频或视频的数据流。可以在`MediaStream`中收集一个或多个`MediaStreamTracks`（严格来说，[GETUSERMEDIA]中定义的`MediaStream`可能包含零个或多个`MediaStreamTrack`对象）。 6 | 7 | 可以扩展`MediaStreamTrack`以表示来自或被发送到远程对等体（例如，不仅仅是本地相机）的媒体流。此部分将介绍在`MediaStreamTrack`对象上启用此功能所需的扩展。在[RTCWEB-RTP]，[RTCWEB-AUDIO]和[RTCWEB-TRANSPORT]中描述了如何将媒体传输到对等体。 8 | 9 | 发送给另一个对等方的`MediaStreamTrack`将作为一个且唯一一个MediaStreamTrack向收件人显示。对等体被定义为支持该规范的用户代理。此外，发送方应用程序可以指示`MediaStreamTrack`所属的`MediaStream`对象。接收端相应的`MediaStream`对象将会被创建(如果不是已经存在)并且对应补充。 10 | 11 | 正如本文档之前所述，应用程序可以使用对象`RTCRtpSender`和`RTCRtpReceiver`来对`MediaStreamTracks`的传输和接收进行更细粒度的控制。 12 | 13 | 通道是`MediaStream`规范中考虑的最小单位。信道旨在被编码在一起以便传输，例如，RTP有效载荷类型。编解码器需要联合编码的所有通道必须位于同一个`MediaStreamTrack`中，编解码器应该能够编码或丢弃轨道中的所有通道。 14 | 15 | 对于给定`MediaStreamTrack`的输入和输出的概念也适用于通过网络传输的`MediaStreamTrack`对象。由`RTCPeerConnection`对象创建的MediaStreamTrack（如本文档前面所述）将把从远程对等方接收的数据作为输入。类似地，来自本地源的`MediaStreamTrack`（例如通过[GETUSERMEDIA]的摄像机）将具有输出，如果该对象与RTCPeerConnection对象一起使用,该输出表示传输到远程对等端的内容。 16 | 17 | [GETUSERMEDIA]中描述的复制`MediaStream`和`MediaStreamTrack`对象的概念也适用于此处。例如，该功能可用于视频会议场景中，以便在本地监视器中显示来自用户摄像头和麦克风的本地视频，同时仅将音频发送到远程对等端（例如，响应用户使用“视频静音“功能”。在某些情况下，将不同的`MediaStreamTrack`对象组合到新的`MediaStream`对象中非常有用。 18 | 19 | > NOTE:在本文档中，我们仅指定与`RTCPeerConnection`一起使用时相关的以下对象的各个方面。有关使用`MediaStream`和`MediaStreamTrack`的一般信息，请参阅[GETUSERMEDIA]文档中对象的原始定义。 20 | 21 | -------------------------------------------------------------------------------- /resource/chapter4/4_2_8 提供、应答选项.md: -------------------------------------------------------------------------------- 1 | ### [4.2.8 Offer/answer option 提供、应答选项](http://w3c.github.io/webrtc-pc/#offer-answer-options) 2 | 3 | 这些词典描述了可用于控制 offer/answer 创建过程的选项。 4 | 5 | ``` 6 | dictionary RTCOfferAnswerOptions { 7 | boolean voiceActivityDetection = true; 8 | }; 9 | ``` 10 | 11 | 字典 `RTCOfferAnswerOptions` 的成员 12 | 13 | `voiceActivityDetection` 类型为 boolean，默认为 `true` 14 | 15 | 许多编解码器和系统能够通过诸如不传输任何媒体的这类方式来检测“静音”并改变它们的行为。在许多情况下，例如当处理紧急呼叫或除了口述语音之外的声音时，希望能够关闭这种行为。此选项允许应用程序提供有关是否希望启用或禁用此类处理的信息。 16 | 17 | ``` 18 | dictionary RTCOfferOptions : RTCOfferAnswerOptions { 19 | boolean iceRestart = false; 20 | }; 21 | ``` 22 | 23 | 字典 `RTCOfferOptions` 的成员 24 | 25 | iceRestart 的类型为 boolean ，默认为 false 26 | 27 | 当此词典成员的值为 true 时，生成的 description 将具有与当前凭据不同的 ICE 凭证（在localDescription属性的SDP中可见）。应用生成的描述将重新启动ICE，如[ICE]的9.1.1.1节所述。当此词典成员的值为false且localDescription属性具有有效的 ICE 凭据时，生成的 description 将具有与 localDescription 属性中的当前值相同的 ICE 凭据。 28 | 29 | 当此词典成员的值为 true 时，生成的 description 将具有与当前凭据不同的 ICE 凭证（在 localDescription 属性的 SDP 中可见）。应用生成的描述将重新启动 ICE，如[ICE]的9.1.1.1节所述。 30 | 31 | >NOTE 32 | > 33 | 34 | >当`iceConnectionState`转换为“failed”时，建议执行 ICE 重启。应用程序可另外选择侦听`iceConnectionState`转换为“disconnected”，然后使用其他信息源（例如使用`getStats`来测量在接下来的几秒内发送或接收的字节数是否增加）以确定是否应该重新启动 ICE。 35 | 36 | `RTCAnswerOptions`字典描述特定于类型为answer的会话描述的选项（在此版本的规范中没有）。 37 | 38 | ``` 39 | dictionary RTCAnswerOptions : RTCOfferAnswerOptions { 40 | }; 41 | ``` 42 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_1_1 构造函数.md: -------------------------------------------------------------------------------- 1 | #### [4.4.1.1 构造函数](http://w3c.github.io/webrtc-pc/#constructor) 2 | 3 | 当调用`RTCPeerConnection()`构造函数时，用户代理必须运行以下步骤： 4 | 5 | 1. 如果由于此处未指定的原因而导致下面列举的任何步骤失败，则抛出UnknownError并将“message”字段设置为适当的描述。 6 | 7 | 2. 让connection成为新创建的RTCPeerConnection对象。 8 | 9 | 3. 如果配置中的证书集为非空，请对证书集中的每个证书运行以下步骤： 10 | 1. 如果证书expires属性的值不在将来，则抛出InvalidAccessError。 11 | 12 | 2. 如果证书[[Origin]]值与当前证书的[[Origin]]不同，则抛出InvalidAccessError。 13 | 14 | 3. 存储证书。 15 | 16 | 4. 然后，使用此 RTCPeerConnection 实例生成一个或多个新的 RTCCertificate 实例并存储它们。这可能是异步发生的，所以后续步骤的证书值可能仍未定义。如[RTCWEB-SECURITY]第4.3.2.3节所述，WebRTC使用自签名而不是公钥基础结构（PKI）证书，因此到期检查是为了确保密钥不会无限期使用，并且不需要额外的证书检查。 17 | 18 | 5. 初始化连接的ICE代理。 19 | 20 | 6. 让连接有[[Configuration]]内部值。设置 configuration 参数指定的配置。 21 | 22 | 7. 让连接有一个[[IsClosed]]内部值，初始化为 false。 23 | 24 | 8. 让连接有一个[[NegotiationNeeded]]内部值，初始化为 false。 25 | 26 | 9. 让连接有一个[[SctpTransport]]内部值，初始化为 null。 27 | 28 | 10. 让连接具有[[Operations]]内部值，表示操作队列，初始化为空列表。 29 | 30 | 11. 让连接有一个[[LastOffer]]内部值，初始化为“”。 31 | 32 | 12. 让连接有一个[[LastAnswer]]内部值，初始化为“”。 33 | 34 | 13. 将连接的信令状态设置为“stable”。 35 | 36 | 14. 将连接的ICE连接状态设置为“new”。 37 | 38 | 15. 将连接的ICE收集状态设置为“new”。 39 | 40 | 16. 将连接的连接状态设置为“new”。 41 | 42 | 17. 让连接有一个[[PendingLocalDescription]]内部值，初始化为null。 43 | 44 | 18. 让连接有一个[[CurrentLocalDescription]]内部值，初始化为null。 45 | 46 | 19. 让连接有一个[[PendingRemoteDescription]]内部值，初始化为null。 47 | 48 | 20. 让连接有一个[[CurrentRemoteDescription]]内部值，初始化为null。 49 | 50 | 21. 返回连接。 51 | -------------------------------------------------------------------------------- /resource/chapter4/4_2_2 RTCIceCredentialType Enum.md: -------------------------------------------------------------------------------- 1 | ### [4.2.2 RTCIceCredentialType Enum](http://w3c.github.io/webrtc-pc/#rtcicecredentialtype-enum) 2 | 3 | ``` 4 | enum RTCIceCredentialType { 5 | "password", 6 | "oauth" 7 | }; 8 | ``` 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 42 | 43 |
Enumeration description
passwordThe credential is a long-term authentication username and password, as described in [RFC5389], Section 10.2.
oauth 21 | 22 | 基于OAuth 2.0的身份验证方法，如[RFC7635]中所述。 23 |
24 |
25 | 对于OAuth身份验证，ICE代理需要三个凭据信息。凭证由用于 kid，macKey 和 accessToken 组成。其中kid用于 RTCIceServer 成员变量，macKey 和 accessToken放置在RTCOAuthCredential字典中的。 26 |
27 |
28 | 此规范未定义应用程序（充当OAuth客户端）如何从授权服务器获取accessToken，kid和macKey，因为WebRTC仅处理ICE代理和TURN服务器之间的交互。例如，应用程序可以使用OAuth 2.0 Implicit Grant类型和PoP（Proof-of-Possession）令牌类型，如[RFC6749]和[OAUTH-POP-KEY-DISTRIBUTION]中所述; [RFC7635]附录B中提供了这方面的一个例子。 29 |
30 |
31 | NOTE：作为OAuth客户端的应用程序负责在accessToken到期之前刷新凭据信息并使用新的凭据更新ICE代理。 OAuth客户端可以使用 RTCPeerConnection 的 setConfiguration 方法定期刷新 TURN 凭据。 32 |
33 |
34 | HMAC密钥的长度（RTCOAuthCredential.macKey）可以是大于 20（160位）的任何整数字节数。 35 |
36 |
37 | NOTE：根据[RFC7635]第 4.1 节，HMAC密钥必须是对称密钥，因为非对称密钥会导致大的访问令牌，这可能不适合单个 STUN 消息。 38 |
39 |
40 | NOTE：目前，STUN / TURN 协议仅使用SHA-1和SHA-2系列哈希算法进行消息完整性保护，如[RFC5389]第15.4节和[STUN-BIS]第14.6节中所定义。 41 |
44 | -------------------------------------------------------------------------------- /resource/chapter5/5_1_1 处理远程 MediaStreamTracks.md: -------------------------------------------------------------------------------- 1 | ### [5.1.1 处理远程 MediaStreamTracks](http://w3c.github.io/webrtc-pc/#processing-remote-mediastreamtracks) 2 | 3 | 应用程序可以通过调用RTCRtpTransceiver.stop()停止收发direction来拒绝传入的媒体描述，或者将收发器的direction设置为“sendonly”以仅拒绝对端接入。 4 | 5 | 要在给定RTCRtpTransceiver收发器和trackEventInits的情况下为传入媒体描述[JSEP]（第5.10节）添加remote track，用户代理必须执行以下步骤： 6 | 7 | 1. 让receiver成为收发器的[[receiver]]。 8 | 9 | 2. 让track成为receiver的[[ReceiverTrack]]。 10 | 11 | 3. 让streams成为receiver的[[AssociatedRemoteMediaStreams]]。 12 | 13 | 4. 创建一个新的RTCTrackEventInit字典，其中包含receiver，track，streams和收发器作为成员，并将其添加到trackEventInits。 14 | 15 | 16 | 要在给定RTCRtpTransceiver收发器和muteTracks的情况下处理传入媒体描述[JSEP]（第5.10节）的remote track，用户代理必须执行以下步骤： 17 | 18 | 1. 让receiver成为收发器的[[Receiver]]。 19 | 20 | 2. 让track成为receiver的[[ReceiverTrack]]。 21 | 22 | 3. 如果track.muted为false，则将track添加到muteTracks。 23 | 24 | 要在给定RTCRtpReceiver类型的receiver，msids，addList和removeList的情况下设置关联的remote streams，用户代理必须执行以下步骤： 25 | 26 | 1. 让connection成为与receiver关联的RTCPeerConnection对象。 27 | 28 | 2. 对于msids中的每个MSID都创建MediaStream对象，除非先前已使用该连接的id创建了MediaStream对象。 29 | 30 | 3. 让stream成为上一步创建的MediaStream对象的列表。 31 | 32 | 4. 让track成为receiver的[[ReceiverTrack]]。 33 | 34 | 5. 对于streams中不存在于receiver的[[AssociatedRemoteMediaStreams]]中的每个stream，将其和track作为一对添加到removeList中。 35 | 36 | 6. 对于streams中不存在于receiver的[[AssociatedRemoteMediaStreams]]中的每个stream，将其和track作为一对添加到addList。 37 | 38 | 7. 将receiver的[[AssociatedRemoteMediaStreams]]值设置为streams。 39 | -------------------------------------------------------------------------------- /resource/chapter6/6.1.1.3 连接步骤.md: -------------------------------------------------------------------------------- 1 | ### 6.1.1.3 连接步骤 2 | 3 | `一旦SCTP传输建立连接`，这意味着`RTCSctpTransport`的SCTP关联已经被建立，运行下列步骤： 4 | 5 | 1.让transport成为`RTCSCTPTransport`对象。 6 | 7 | 2.让connection成为与transport关联的`RTCPeerConnection`对象。 8 | 9 | 3.设置[MaxChannels]为协商好的输入输出SCTP流的最小值。 10 | 11 | 4.在transport发起一个名为`statechange`的事件。 12 | 13 | 5.对于connection的每一个`RTCDataChannel`: 14 | 15 | 1. 让channel成为RTCDataChannel对象。 16 | 2. 如果channel的[DataChannelId]插槽大于等于transport的[MaxChannels]插槽，由于失败关闭channel。否则，声明channel为open。 17 | 18 | ```java 19 | [Exposed=Window] interface RTCSctpTransport : EventTarget { 20 | readonly attribute RTCDtlsTransport transport; 21 | readonly attribute RTCSctpTransportState state; 22 | readonly attribute unrestricted double maxMessageSize; 23 | readonly attribute unsigned short? maxChannels; 24 | attribute EventHandler onstatechange; 25 | }; 26 | ``` 27 | 28 | **属性** 29 | 30 | `RTCDtlsTransport`类型的`transport`，只读：数据通道的所有SCTP数据包通过此传输发送和接收。[测试2](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCIceTransport.html) 31 | 32 | `RTCSctpTransportState`类型的`state`，只读：SCTP传输的目前状态。当获取时，此属性必须返回[SctpTransportState]插槽的值。 33 | 34 | 无限制double类型的`maxMessageSize`，只读：可以被传入`RTCDataChannel`的`send()`方法的最大数据量。此属性，返回[MaxMessageSize]插槽的值。 35 | 36 | 无符号short类型的`maxChannels`,只读，可以为null：可以被同时使用的`RTCDataChannel`的最大量。此属性必须返回[MaxChannels]插槽的值。 37 | 38 | > NOTE:此属性的值将会为null，直到SCTP传输进入connected状态。 39 | 40 | EventHadnler类型的`onstatechange`:此event handler的事件类型是`statechange`。 41 | -------------------------------------------------------------------------------- /resource/chapter4/4_3_4 RTCIceConnectionState 枚举.md: -------------------------------------------------------------------------------- 1 | ### [4.3.4 RTCIceConnectionState 枚举](http://w3c.github.io/webrtc-pc/#rtciceconnectionstate-enum) 2 | 3 | ``` 4 | enum RTCIceConnectionState { 5 | "closed", 6 | "failed", 7 | "disconnected", 8 | "new", 9 | "checking", 10 | "completed", 11 | "connected" 12 | }; 13 | ``` 14 | 15 | 16 | 17 | 20 | 21 | 22 | 25 | 28 | 29 | 30 | 33 | 36 | 37 | 38 | 41 | 44 | 45 | 46 | 49 | 52 | 53 | 54 | 57 | 60 | 61 | 62 | 65 | 68 | 69 | 70 | 73 | 76 | 77 |
18 | Enumeration description 19 |
23 | closed 24 | 26 | RTCPeerConnection对象的[[IsClosed]]值为true。 27 |
31 | failed 32 | 34 | 之前的状态不适用，并且任何RTCIceTransport都处于“failed”状态。 35 |
39 | disconnected 40 | 42 | 以前的状态都不适用，并且任何RTCIceTransport都处于“disconnected”状态。 43 |
47 | new 48 | 50 | 以前的状态都不适用，并且所有RTCIceTransport都处于“new”或“closed”状态，或者没有传输。 51 |
55 | checking 56 | 58 | 以前的状态都不适用，并且任何RTCIceTransport都处于new”或“checking”状态。 59 |
63 | completed 64 | 66 | 以前的状态均不适用，并且所有RTCIceTransport都处于“completed”或“closed”状态。 67 |
71 | connected 72 | 74 | 以前的状态均不适用，并且所有RTCIceTransport都处于“connected”，“completed”或“closed”状态。 75 |
78 | 79 | 注意，如果由于信令（例如，RTCP多路复用或捆绑）而丢弃RTCIceTransport，或者由于信令（例如，添加新媒体描述）而创建RTCIceTransport，则状态可以直接从一个状态前进到另一个状态。 80 | 81 | 82 | 83 | -------------------------------------------------------------------------------- /resource/chapter5/5_7 RTCTrackEvent.md: -------------------------------------------------------------------------------- 1 | ## 5.7 `RTCTrackEvent` 2 | 3 | `track`事件使用`RTCTrackEvent`接口。 4 | 5 | ```java 6 | [ Constructor (DOMString type, RTCTrackEventInit eventInitDict), Exposed=Window] 7 | interface RTCTrackEvent : Event { 8 | readonly attribute RTCRtpReceiver receiver; 9 | readonly attribute MediaStreamTrack track; 10 | [SameObject] 11 | readonly attribute FrozenArray streams; 12 | readonly attribute RTCRtpTransceiver transceiver; 13 | }; 14 | ``` 15 | 16 | **构造函数** 17 | 18 | `RTCTrackEvent`(https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCTrackEvent-constructor.html) 19 | 20 | **属性** 21 | 22 | `RTCRtpReceiver`类型的`receiver`，只读：`receiver`属性表示与事件关联的`RTCRtpReceiver`对象。 23 | 24 | `MediaStreamTrack`类型的track，只读：`track`属性表示与`RTCRtpReceiver`关联的由`receiver`验证的`MediaStreamTrack`对象。 25 | 26 | `FrozenArray`类型的streams,只读：`streams`属性返回`MediaStream`对象的数组，表示此事件的track是`MediaStreams`的一部分。 27 | 28 | `RTCRtpTransceiver`类型的`transceiver`，只读：`transceiver`属性表示与此事件关联的`RTCRtpTransceiver`对象。 29 | 30 | ```java 31 | dictionary RTCTrackEventInit : EventInit { 32 | required RTCRtpReceiver receiver; 33 | required MediaStreamTrack track; 34 | sequence streams = []; 35 | required RTCRtpTransceiver transceiver; 36 | }; 37 | ``` 38 | 39 | **字典`RTCTrackEventInit`成员** 40 | 41 | `RTCRtpReceiver`类型的`receiver` 42 | 43 | `MediaStreamTrack`类型的`track` 44 | 45 | `sequence`类型的`streams` 46 | 47 | `RTCRtpTransceiver`类型的`transceiver` 48 | -------------------------------------------------------------------------------- /resource/chapter5/5 RTP Media API.md: -------------------------------------------------------------------------------- 1 | # [5. RTP Media API](http://w3c.github.io/webrtc-pc/#rtp-media-api) 2 | 3 | 4 | RTP媒体API允许Web应用程序通过p2p连接发送和接收MediaStreamTracks。当(音视频)轨道添加到RTCPeerConnection时会产生信令消息;当该消息 5 | 被转发到远程对端时，会在远端创建相应的(音视频)轨道。 6 | 7 | NOTE: 8 | 9 | 一个RTCPeerConnection发送的轨道与另一个RTCPeerConnection接收的轨道之间没有确切的1：1对应关系。例如，发送的轨道的ID没有映射到接>收的轨道ID。此外，replaceTrack更改RTCRtpSender发送的轨道，而不会在接收方创建新的轨道;相应的RTCRtpReceiver只有一个轨道，可能代表缝>合在一起的多个媒体源。 addTransceiver和replaceTrack接口都可以用于使用相同的轨道多次发送，这将在接收器侧被观察为多个接收器，每个接>收器具有其自己的独立轨道。因此，考虑发送侧的RTCRtpSender与接受侧的RTCRtpReceiver的轨道之间的1：1关系更为准确，如果需要，使用RTCRtpTransceiver的mid匹配发送者和接收者。 10 | 11 | 12 | 发送媒体时，发送方可能需要对媒体数据进行缩放或重采样处理，以满足包括SDP协商在内的各种要求。 13 | 14 | 遵循[JSEP]（第3.6节）中的规则，可以缩小视频尺寸以适应SDP约束。媒体数据不得通过拉伸来创建未在输入源中出现的伪数据;除非为满足像素 15 | 计数约束，否则不得裁剪媒体，并且不能更改视频宽高比。 16 | 17 | NOTE: 18 | 19 | WebRTC工作组正在寻求关于需求和时间表的实施反馈，以便更全面地处理这种情况。 GitHub issue 1283中讨论了一些可能的设计。 20 | 21 | 22 | 当视频被重新缩放时，例如对于宽度或高度的某些组合以及根据scaleResolutionDownBy数值的缩放，可能出现所得宽度或高度不是整数的情况。 23 | 在这种情况下，用户代理必须使用结果的整数部分。如果缩放宽度或高度的整数部分为零，传输行为则可依据特定实现。 24 | 25 | 26 | MediaStreamTracks的实际编码和传输是通过名为RTCRtpSenders的对象来管理的。同样，MediaStreamTracks的接收和解码通过称为RTCRtpReceivers的对象进行管理。每个RTCRtpSender与至多一个轨道相关联，并且要接收的每个轨道仅与一个RTCRtpReceiver相关联。 27 | 28 | 29 | 应该对每个MediaStreamTrack进行编码和传输，使其特性（视频轨道的宽度，高度和帧率;音频轨道的音量，采样大小，采样率和声道数）与在远 30 | 端创建的轨道保持合理的程度。在某些情况下，如果不适用，可能会在端上或网络中出现资源限制，或者可能会应用RTCRtpSender设置来指示实施采 31 | 取不同的行动。 32 | 33 | RTCPeerConnection对象包含一组RTCRtpTransceivers，表示配对的发送者和接收者具有某种共享状态。创建RTCPeerConnection对象时，此集初 34 | 始化为空集。 RTCRtpSenders和RTCRtpReceivers始终与RTCRtpTransceiver同时创建，它们将在其生命周期内保持连接状态。当应用程序通过addTrack方法将MediaStreamTrack附加到RTCPeerConnection时，或者在应用程序使用addTransceiver方法时显式地创建RTCRtpTransceivers。当远端SDP中 35 | 加入新的媒体描述时，也会创建它们。此外，当远端SDP指示端上有要发送的媒体时，相关的MediaStreamTrack和RTCRtpReceiver会通过(音视频)轨道的事件添加到应用程序。 36 | -------------------------------------------------------------------------------- /resource/chapter4/4_10 证书管理.md: -------------------------------------------------------------------------------- 1 | ## [4.10证书管理](http://w3c.github.io/webrtc-pc/#sec.cert-mgmt) 2 | 3 | RTCPeerConnection实例用于与对等方进行身份验证的证书使用RTCCertificate接口。这些对象可以由使用generateCertificate方法的应用程序显式生成，并且可以在构造新的RTCPeerConnection实例时在RTCConfiguration中提供。 4 | 5 | 此处提供的显式证书管理功能是可选的。如果应用程序在构造RTCPeerConnection时未提供证书配置选项，则必须由用户代理生成一组新证书。该集必须包括一个ECDSA证书，在P-256曲线上有一个私钥，一个签名带有SHA-256哈希。 6 | 7 | ``` 8 | partial interface RTCPeerConnection { 9 | static Promise generateCertificate(AlgorithmIdentifier keygenAlgorithm); 10 | }; 11 | ``` 12 | 13 | **方法** 14 | 15 | generateCertificate, static 16 | 17 | generateCertificate函数使用户代理创建并存储X.509证书[X509V3](http://w3c.github.io/webrtc-pc/#bib-x509v3)和相应的私钥。以RTCCertificate接口的形式提供信息句柄。返回的RTCCertificate可用于控制由RTCPeerConnection建立的DTLS会话中提供的证书。 18 | 19 | keygenAlgorithm参数用于控制如何生成与证书关联的私钥。 keygenAlgorithm参数使用WebCrypto [WebCryptoAPI](http://w3c.github.io/webrtc-pc/#bib-webcryptoapi) AlgorithmIdentifier类型。 keygenAlgorithm值必须是window.crypto.subtle.generateKey的有效参数;也就是说，当根据WebCrypto算法规范化过程[WebCryptoAPI]进行规范化时，该值必须产生非错误结果，其中操作名称为generateKey，并且[[supportedAlgorithms]]值特定于RTCPeerConnection的证书生成。如果算法规范化过程产生错误，则必须拒绝对generateCertificate的调用。 20 | 21 | 生成的密钥生成的签名用于验证DTLS连接。所识别的算法（由标准化AlgorithmIdentifier的名称标识）必须是可用于产生签名的非对称算法。 22 | 23 | 此过程生成的证书还包含签名。此签名的有效性仅与兼容性原因相关。 RTCPeerConnection仅使用公钥和生成的证书指纹，但如果证书格式正确，则更有可能接受证书。浏览器选择用于签署证书的算法;如果需要哈希算法，浏览器应该选择SHA-256 [FIPS-180-4](http://w3c.github.io/webrtc-pc/#bib-fips-180-4)。 24 | 25 | 生成的证书不得包含可链接到用户或用户代理的信息。应该使用可分辨名称和序列号的随机值。 26 | 27 | 如果keygenAlgorithm参数标识用户代理不能或不会用于为RTCPeerConnection生成证书的算法，则用户代理必须拒绝使用类型为NotSupportedError的DOMException调用generateCertificate（）。 28 | 29 | 用户代理必须支持以下值：{name：“RSASSA-PKCS1-v1_5”，modulusLength：2048，publicExponent：new Uint8Array（[1,0,1]），hash：“SHA-256”}，以及{name：“ECDSA”，namedCurve：“P-256”}。 30 | 31 | NOTE 32 | 33 | 预计用户代理将具有它将接受的小的或甚至固定的值集。 34 | -------------------------------------------------------------------------------- /resource/chapter4/4_7_3 更新Negotiation-Needed标志.md: -------------------------------------------------------------------------------- 1 | ### [4.7.3 更新Negotiation-Needed标志](http://w3c.github.io/webrtc-pc/#updating-the-negotiation-needed-flag) 2 | 3 | 以下的过程在本文档的其他地方引用。它也可能由于实施中影响谈判的内部变化而发生。如果发生此类更改，则用户代理必须对任务进行排队以更新协商需要的标志。 4 | 5 | 要更新连接协商需要的标志，请运行以下步骤： 6 | 7 | 1. 如果connection的[[IsClosed]]插槽为true，则中止这些步骤。 8 | 2. 如果连接的信令状态不是“stable”，则中止这些步骤。 9 | 10 | NOTE：一旦状态转换为“稳定”，将更新协商需要的标志，作为设置RTCSessionDescription的步骤的一部分。 11 | 12 | 3. 如果检查是否需要协商的结果为false，则通过将connection的[[NegotiationNeeded]]槽设置为false来清除需要协商的标志，并中止这些步骤。 13 | 14 | 4. 如果连接的[[NegotiationNeeded]]插槽已经为真，则中止这些步骤。 15 | 16 | 5. 将连接的[[NegotiationNeeded]]插槽设置为true。 17 | 18 | 6. 对运行以下步骤的任务进行排队： 19 | 1. 如果connection的[[IsClosed]]插槽为true，则中止这些步骤。 20 | 2. 如果连接的[[NegotiationNeeded]]插槽为false，则中止这些步骤。 21 | 3. 在连接时触发名为`negotiationneeded`的事件。 22 | 23 | NOTE：这种排队可防止在一次性对连接进行多次修改的常见情况下过早触发协商。 24 | 25 | 要检查连接是否需要协商，请执行以下检查： 26 | 27 | 1. 如果需要任何特定于实现的协商，如本节开头所述，则应返回true。 28 | 29 | 2. 让描述成为连接。[[CurrentLocalDescription]]。 30 | 31 | 3. 如果连接已创建任何RTCDataChannel，并且尚未为数据协商描述中的`m= section`，则返回true。 32 | 33 | 4. 对于连接的一组收发器中的每个收发器，执行以下检查： 34 | 35 | 1. 如果收发器未停止且尚未与描述中的`m= section`关联，则返回true。 36 | 37 | 2. 如果收发器没有停止并且与描述中的`m= section`相关联，则执行以下检查： 38 | 1. 如果收发器。[[Direction]]是“sendrecv”或“sendonly”，并且描述中关联的m =部分不包含单个“a = msid”行，或者来自“a = msid”的MSID数量“此m =节中的行或MSID值本身与transceiver.sender中的行不同。[[AssociatedMediaStreamIds]]，返回true。 39 | 40 | 2. 如果描述的类型为`offer`，并且关联`m= section`的方向在两个连接中都没有。[[CurrentLocalDescription]]也没有连接。[[CurrentRemoteDescription]]匹配收发器。[[Direction]]，返回true。 41 | 42 | 3. 如果描述的类型为`answer`，并且描述中关联的`m= section`的方向与收发器不匹配。[[Direction]]与提供的方向相交（如[JSEP]（第5.3.1节）中所述） ），返回true。 43 | 44 | 3. 如果收发器已停止且与`m= section`相关联，但关联的`m= section`尚未在连接中被拒绝[[CurrentLocalDescription]]或连接。[[CurrentRemoteDescription]]，则返回true。 45 | 46 | 5. 如果执行了所有前面的检查并且未返回true，则无需进行任何协商;则返回false。 47 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_6 RTCRtpEncodingParameters 词典.md: -------------------------------------------------------------------------------- 1 | ### 5.2.6 `RTCRtpEncodingParameters`字典 2 | 3 | ```java 4 | dictionary RTCRtpEncodingParameters : RTCRtpCodingParameters { 5 | octet codecPayloadType; 6 | RTCDtxStatus dtx; 7 | boolean active = true; 8 | unsigned long ptime; 9 | unsigned long maxBitrate; 10 | double maxFramerate; 11 | double scaleResolutionDownBy; 12 | }; 13 | ``` 14 | 15 | **字典`RTCRtpEncodingParamters`成员** 16 | 17 | octet类型的`codecPayloadType`: 18 | 19 | 从`RTCRtpParameters`的编解码器成员引用有效内容类型。只读参数。 20 | 21 | `RTCDtxStatus`类型的`dtx`: 22 | 23 | 仅当发送方类型为"audio"时才使用此成员。它表示是否使用不连续传输。将它设置为禁用会导致关闭不连续传输。将它设置为启用会导致在协商完成情况下打开不连续传输(通过制定编码器参数或通过CN编码器协商)。如果没有协商(例如当设置`voiceActivityDetection`为`false`时)，则无论`dtx`的值为多少，都会关闭不连续操作,当侦测到silence后，媒体将会被发送。 24 | 25 | boolean类型的`active`，默认为`true`： 26 | 27 | 表明此编码正在被发送。设置它为`false`导致编码不再被发送。设置为`true`导致它被发送。由于设置值为`false`不会导致SSRC被移除，所以不会发送RTCP BYE。 28 | 29 | unsigned long 类型的`ptime`: 30 | 31 | 如果存在，则表示此编码的数据包所代表的媒体的首选持续时间(以毫秒为单位)。通常，这仅与音频编码有关。用户代理必须使用此持续时间，否则使用最接近的可用持续时间。该值必须优先于远程描述的任何"ptime"属性，其处理在[JSEP] (第5.10节)中描述。请注意，用户代理仍必须遵守任何"maxptime"属性所施加的限制，如[RFC4566]第六节中所定义。 32 | 33 | unsigned long类型的`maxBitrate`: 34 | 35 | 存在时，表示可用于发送此编码的最大比特率。只要不超过`maxBitrate`值，用户代理就可以在编码之间自由分配带宽。编码还可能受到低于此处指定的最大值的其它限制(例如maxFramerate或每传输每会话带宽限制)。maxBitrate的计算方法与[RFC3890]第6.2.2节中定义的传输独立应用程序特定最大值(TIAS)带宽的计算方式相同，它是不计数IP或其它传输层例如TCP或UDP时所需的最大带宽。 36 | 37 | double类型的`maxFrameate`: 38 | 39 | 存在时，表示可用于发送此编码的最大帧率，以每秒帧数为单位。只要不超过`maxFramerate`值，用户代理就可以在编码之间自由分配带宽。 40 | 41 | 如果使用`setParameters`更改，新的帧率在当前图片完成后生效。设置最大帧率为零，则会具有在下一帧冻结视频的效果。 42 | 43 | double类型的`scaleResolutionDownBy` : 44 | 45 | 此会员仅在发件人的类型为"`video`"时才会出现。在发送之前，视频的分辨率将按给定值按比例缩小。例如，如果值为2.0，则视频将在每个维度中按比例缩小2倍，从而发送大小为四分之一的视频。如果值为1.0，则视频不会受到影响。该值必须大于等于1.0，默认情况下，发件人不会应用任何缩放(即`scaleResolutionDownBy`将为1.0)。 46 | 47 | 48 | 49 | -------------------------------------------------------------------------------- /resource/chapter8/8_7强制实施统计数据.md: -------------------------------------------------------------------------------- 1 | ## 8.7 强制实施物理数据 2 | 3 | [WEBRTC-STATS]中列出的统计数据被用来涵盖广泛的用例。并非所有WebRTC实现都必须实现它们。 4 | 5 | 当PeerConnection上存在相应的对象时，实现必须支持生成以下类型的统计信息，并使用所列的对该对象有效时的属性： 6 | 7 | - RTCRTPStreamStats，具有ssrc，kind，transportId，codecId，nackCount属性 8 | - RTCReceivedRTPStreamStats，包含继承的字典中的所有必需属性，还包括packetsReceived，packetsLost，jitter，packetsDiscarded属性 9 | - RTCInboundRTPStreamStats，包含继承的字典中的所有必需属性，还包括bytesReceived，trackId，receiverId，remoteId，framesDecoded属性 10 | - RTCRemoteInboundRTPStreamStats，包含继承词典的所有必需属性，以及属性localId，roundTripTime 11 | - RTCSentRTPStreamStats，包含继承的字典中的所有必需属性，以及属性packetsSent，bytesSent 12 | - RTCOutboundRTPStreamStats，包含继承词典的所有必需属性，还包括trackId，senderId，remoteId，framesEncoded属性 13 | - RTCRemoteOutboundRTPStreamStats，包含继承的字典中的所有必需属性，以及localId，remoteTimestamp属性 14 | - RTCPeerConnectionStats，具有dataChannelsOpened，dataChannelsClosed属性 15 | - RTCDataChannelStats，带有属性标签，协议，dataChannelIdentifier，state，messagesSent，bytesSent，messagesReceived，bytesReceived 16 | - RTCMediaStreamStats，具有属性streamIdentifer，trackIds 17 | - RTCMediaStreamTrackStats，属性detached 18 | - RTCMediaHandlerStats具有属性trackIdentifier，remoteSource，ended 19 | - 带有属性audioLevel的RTCAudioHandlerStats 20 | - RTCVideoHandlerStats具有属性frameWidth，frameHeight，framesPerSecond 21 | - 带有属性framesSent的RTCVideoSenderStats 22 | - 带有属性framesReceived，framesDecoded，framesDropped，framesCorrupted的RTCVideoReceiverStats 23 | - RTCCodecStats，具有属性payloadType，codec，clockRate，channels，sdpFmtpLine 24 | - RTCTransportStats，具有bytesSent，bytesReceived，rtcpTransportStatsId，selectedCandidatePairId，localCertificateId，remoteCertificateId属性 25 | - RTCIceCandidatePairStats，具有属性transportId，localCandidateId，remoteCandidateId，state，priority，nominated，bytesSent，bytesReceived，totalRoundTripTime，currentRoundTripTime 26 | - RTCIceCandidateStats，具有属性地址，端口，协议，候选类型，URL 27 | - RTCCertificateStats，具有属性fingerprint，fingerprintAlgorithm，base64Certificate，issuerCertificateId 28 | 29 | 实现可以支持生成[WEBRTC-STATS]中定义的任何其他统计信息，并且可以生成未记录的统计信息。 30 | -------------------------------------------------------------------------------- /resource/chapter4/4_3_1 状态定义之 RTCSignalingState 枚举.md: -------------------------------------------------------------------------------- 1 | ## [4.3 状态定义](http://w3c.github.io/webrtc-pc/#state-definitions) 2 | 3 | ### [4.3.1 RTCSignalingState 枚举](http://w3c.github.io/webrtc-pc/#rtcsignalingstate-enum) 4 | 5 | ``` 6 | enum RTCSignalingState { 7 | "stable", 8 | "have-local-offer", 9 | "have-remote-offer", 10 | "have-local-pranswer", 11 | "have-remote-pranswer", 12 | "closed" 13 | }; 14 | ``` 15 | 16 | 17 | 18 | 21 | 22 | 23 | 26 | 30 | 31 | 32 | 35 | 38 | 39 | 40 | 43 | 46 | 47 | 48 | 51 | 54 | 55 | 56 | 59 | 62 | 63 | 64 | 67 | 70 | 71 |
19 | Enumeration description 20 |
24 | stable 25 | 27 | 28 | 没有 offer/answer 交换正在进行。这也是初始状态，在这种情况下，本地和远程描述为空。 29 |
33 | have-local-offer 34 | 36 | 成功使用“offer”类型的本地描述。 37 |
41 | have-remote-offer 42 | 44 | 成功使用“offer”类型的远程描述。 45 |
49 | have-local-pranswer 50 | 52 | zh：已成功应用“offer”类型的远程描述，并已成功应用“pranswer”类型的本地描述。 53 |
57 | have-remote-pranswer 58 | 60 | 已成功应用“offer”类型的本地描述，并且已成功应用“pranswer”类型的远程描述。 61 |
65 | closed 66 | 68 | `RTCPeerConnection`已关闭;它的[[IsClosed]]值是 true 的。 69 |
72 | 73 | ![](/image/peerstates.png) 74 | *Figure 1 Non-normative signalling state transitions diagram. Method calls abbreviated.* 75 | 76 | An example set of transitions might be: 77 | 78 | 一组状态转换示例： 79 | 80 | 呼叫者状态转换： 81 | 82 | - new RTCPeerConnection(): stable 83 | - setLocalDescription(offer): have-local-offer 84 | - setRemoteDescription(pranswer): have-remote-pranswer 85 | - setRemoteDescription(answer): stable 86 | 87 | 88 | 89 | 被呼叫者状态转换： 90 | 91 | - new RTCPeerConnection(): stable 92 | - setRemoteDescription(offer): have-remote-offer 93 | - setLocalDescription(pranswer): have-local-pranswer 94 | - setLocalDescription(answer): stable 95 | 96 | 97 | -------------------------------------------------------------------------------- /resource/chapter4/4_2_4 RTCIceServer Dictionary.md: -------------------------------------------------------------------------------- 1 | ### [4.2.4 RTCIceServer字典](http://w3c.github.io/webrtc-pc/#rtciceserver-dictionary) 2 | 3 | RTCIceServer 字典用于描述可以被 ICE 代理用于与对等方建立连接的STUN和TURN服务器。 4 | 5 | ``` 6 | dictionary RTCIceServer { 7 | required (DOMString or sequence) urls; 8 | DOMString username; 9 | (DOMString or RTCOAuthCredential) credential; 10 | RTCIceCredentialType credentialType = "password"; 11 | }; 12 | ``` 13 | 14 | 字典[RTCIceServer](http://w3c.github.io/webrtc-pc/#dom-rtciceserver)成员 15 | 16 | `URL`的类型是 DOMString或序列，必填 17 | 18 | zh: [RFC7064]和[RFC7065]或其他URI类型中定义的STUN或TURN URI。 19 | 20 | `username`的类型是 DOMString 21 | 22 | 如果此 RTCIceServer 对象表示 TURN 服务器，并且 credentialType 为 “password”，则此属性指定用于该TURN服务器的用户名。 23 | 24 | 如果此RTCIceServer对象表示TURN服务器，并且credentialType为“oauth”，则此属性指定共享对称密钥的密钥ID（kid），该密钥在TURN服务器和授权服务器之间共享，如[RFC7635]中所述。它是一个短暂而唯一的密钥标识符。密钥ID（kid）允许TURN服务器选择适当的密钥材料来解密Access-Token，因此这个密钥ID（kid）识别的密钥被用于“access_token”的加密。 kid值与OAuth响应“kid”参数相同，如[RFC7515]第4.1.4节中所定义。 25 | 26 | `credential`的类型是 DOMString 或 RTCOAuthCredential 27 | 28 | 如果此 RTCIceServer 对象表示 TURN 服务器，则此属性是要与该 TURN 服务器一起使用的证书。 29 | 30 | 如果credentialType是“password”，则证书是DOMString类型，并表示长期验证密码，如[RFC5389]第10.2节中所述。 31 | 32 | 如果credentialType是“oauth”，则证书是RTCOAuthCredential类型，其中包含OAuth访问令牌和MAC密钥。 33 | 34 | `credentialType`的类型是 RTCIceCredentialType，默认为“password” 35 | 36 | 如果此RTCIceServer对象表示TURN服务器，则此属性指定如何在该 TURN 服务器请求授权时使用证书。 37 | 38 | An example array of RTCIceServer objects is: 39 | 40 | 一个 RTCIceServer 数组的例子： 41 | 42 | ``` 43 | 44 | [ 45 | {urls: 'stun:stun1.example.net'}, 46 | {urls: ['turns:turn.example.org', 'turn:turn.example.net'], 47 | username: 'user', 48 | credential: 'myPassword', 49 | credentialType: 'password'}, 50 | {urls: 'turns:turn2.example.net', 51 | username: '22BIjxU93h/IgwEb', 52 | credential: { 53 | macKey: 'WmtzanB3ZW9peFhtdm42NzUzNG0=', 54 | accessToken: 'AAwg3kPHWPfvk9bDFL936wYvkoctMADzQ5VhNDgeMR3+ZlZ35byg972fW8QjpEl7bx91YLBPFsIhsxloWcXPhA==' 55 | }, 56 | credentialType: 'oauth'} 57 | ]; 58 | 59 | ``` 60 | -------------------------------------------------------------------------------- /resource/chapter4/4_8_3 RTCPeerConnectionIceErrorEvent接口.md: -------------------------------------------------------------------------------- 1 | ### [4.8.3 RTCPeerConnectionIceErrorEvent接口](http://w3c.github.io/webrtc-pc/#rtcpeerconnectioniceerrorevent) 2 | 3 | `RTCPeerConnection` 的 `icecandidateerror` 事件使用 `RTCPeerConnectionIceErrorEvent` 接口。 4 | 5 | ``` 6 | [Constructor(DOMString type, RTCPeerConnectionIceErrorEventInit eventInitDict), 7 | Exposed=Window] 8 | interface RTCPeerConnectionIceErrorEvent : Event { 9 | readonly attribute DOMString hostCandidate; 10 | readonly attribute DOMString url; 11 | readonly attribute unsigned short errorCode; 12 | readonly attribute USVString errorText; 13 | }; 14 | ``` 15 | ##### 构造函数 16 | 17 | `RTCPeerConnectionIceErrorEvent` 18 | 19 | ##### 属性 20 | 21 | `hostCandidate`的类型为`DOMString`, 只读项: 22 | 23 | `hostCandidate`属性是用于与STUN或TURN服务器通信的本地IP地址和端口。 24 | 25 | 在多宿主系统上，可以使用多个接口来联系服务器，该属性允许应用程序确定故障发生在哪一个上。 26 | 27 | 如果出于隐私原因禁止使用多个接口，则此属性将根据需要设置为0.0.0.0:0或[::]：0。 28 | 29 | `url`的类型为`DOMString`, 只读项: 30 | 31 | `url`属性是 STUN 或 TURN URL ，用于标识发生故障的STUN或TURN服务器。 32 | 33 | `errorCode`的类型为`unsigned short`，只读项: 34 | 35 | `errorCode`属性是 STUN 或 TURN 服务器 [STUN-PARAMETERS] 返回的数字 STUN 错误代码。 36 | 37 | 如果没有主机候选者可以到达服务器，则 `errorCode` 将被设置为超出 STUN 错误代码范围的值701。在“收集”的`RTCIceGatheringState`中，每个服务器 URL 仅触发一次此错误。 38 | 39 | `errorText`的类型为`USVString`, 只读项: 40 | 41 | `errorText`属性是 STUN 或 TURN 服务器 [STUN-PARAMETERS] 返回的 STUN 原因文本。 42 | 43 | 如果无法访问服务器，则`errorText`将设置为特定于实现的值，提供有关错误的详细信息。 44 | 45 | ``` 46 | dictionary RTCPeerConnectionIceErrorEventInit : EventInit { 47 | DOMString hostCandidate; 48 | DOMString url; 49 | required unsigned short errorCode; 50 | USVString statusText; 51 | }; 52 | ``` 53 | ##### 字典RTCPeerConnectionIceErrorEventInit的成员 54 | 55 | `hostCandidate`的类型为`DOMString` 56 | 57 | 用于与 STUN 或 TURN 服务器通信的本地地址和端口。 58 | 59 | `url`的类型为`DOMString`: 60 | 61 | STUN 或 TURN URL ，用于标识发生故障的STUN或TURN服务器。 62 | 63 | `errorCode`的类型为unsigned short，必需项： 64 | 65 | STUN 或 TURN 服务器返回的数字 STUN 错误代码。 66 | 67 | `statusText`的类型为`USVString`: 68 | 69 | STUN 或 TURN 服务器返回的 STUN 原因文本。 70 | 71 | 72 | -------------------------------------------------------------------------------- /resource/chapter13/13_隐私和安全.md: -------------------------------------------------------------------------------- 1 | # 13 隐私安全考虑 2 | 3 | 此章节不具有规范性。 4 | 5 | 本章不具有规范性；它没有介绍新的行为，但是总结了规范的其它部分已经存在的信息。[RTCWEB-SECURITY-ARCH]中描述了对于一般在WebRTC中使用的API和协议的安全性考虑。 6 | 7 | ## 13.1 同源政策的影响 8 | 9 | 本文档扩展了Web平台，能够在浏览器和其它设备之间(包括其它浏览器)建立实时，直接的通信。 10 | 11 | 这意味着数据和媒体可以在运行在不同的浏览器中的应用程序之间共享，也可以在运行在同一浏览器中的应用程序和不是浏览器的应用程序之间共享。 12 | 13 | WebRTC规范对于通信不提供用户提示或Chrome指示。它假设一旦允许网页访问媒体，就可以自由的与其它实体共享该媒体。因此可以在没有任何用户明确同意或参与的情况下进行数据查看WebRTC数据通道的对等交换，类似于以服务器为媒介的交换(例如，通过Web Sockets)可以在没有用户参与情况下发生。 14 | 15 | peeridentity机制从充当身份提供者的第三方服务器加载运行JavaScript代码。该代码在单独的JS领域中运行，不会影响同一原始策略提供的保护。 16 | 17 | ## 13.2 揭示IP地址 18 | 19 | 即使没有WebRTC，提供Web应用程序的Web服务器也会知道应用程序交付的公共IP地址。设置通讯向Web应用公开关于浏览器网络环境的额外信息，并且可能包括浏览器可用于WebRTC的一组IP地址(可能是私有的)。必须将其中一些信息传递给相应方，以便建立通信会话。 20 | 21 | 揭示IP地址可能会泄露位置和连接方式；这是敏感的。根据网络环境，这还会增加增加指纹表面并创建持久的跨源状态，用户无法轻易清除。 22 | 23 | 连接将始终显示建议用于与对等方通信的IP地址。应用程序可以通过选择不使用某些地址，这些地址使用`RTCIceTransportPolicy`字典公开的设置，以及使用中继(例如，TURN服务器)而不是参与者之间的直接连接，来限制这种暴露。通常会假设TURN服务器的IP地址不是敏感信息。例如，这些选择可以由应用程序基于用户是否已经同意开始与另一方媒体连接来作出。 24 | 25 | 减少将IP地址暴露给应用程序本身需要限制可以使用的IP地址，这会影响端点之间的最直接路径上进行通信的能力。浏览器被鼓励基于用户所需的安全性提供适当的控制来决定哪些IP地址可供应用程序使用。选择公开哪个地址是由本地策略控制的(有关详细信息，请参阅[RTCWEB-IP-HANDLING])。 26 | 27 | 28 | 29 | ## 13.3 对本地网络的影响 30 | 31 | 由于浏览器是在受信任的网络环境(防火墙内)执行的活动平台，因此限制浏览器可以对本地网络中的其它元素造成的损害非常重要，保护数据免受拦截，操纵非常重要，和被不受信任的参与者更改。 32 | 33 | 措施如下： 34 | 35 | - 用户代理将始终请求相应的用户代理的许可使用ICE进行通信。这确保用户代理只能向具有共享证书的合作方发送数据。 36 | - 用户代理将始终使用ICE continued consent持续请求许可，以继续发送数据，这确保接受者可以撤回同意接收的操作。 37 | - 用户代理将始终使用强大的per-session密钥(DTLS-SRTP)对数据加密。 38 | - 用户代理将始终使用拥塞控制。这可以确保WebRTC不能被用于堵塞网络。 39 | 40 | 这些方法在相关IETF文件中详细列出。 41 | 42 | ## 13.4 通信的保密性 43 | 44 | 通信正在发生的事实不能从可以观察网络的对手那里隐藏，因此必须将其视为公共信息。 45 | 46 | 一种叫peerIdentity的机制，为JavaScript提供了请求相同JS无法访问的媒体的选择，但只能发送给其它特定实体。 47 | 48 | ## 13.5 WebRTC公开的持久信息 49 | 50 | 如上所述，WebRTC API公开的IP地址列表可以用作持久的跨源状态。 51 | 52 | 除IP地址以外，WebRTC API通过`RTCRtpSender.getCapabilities`和`RTCRtpReceiver.getCapabilities`方法公开有关底层媒体系统的信息，包括系统可以生成和使用的编解码器的详细和有序信息。该信息的一部分可能在会话协商期间生成，公开和传输的SDP会话描述中表示。该信息大多数情况下，跨时间和跨源是持久的，并且增加了给定设备的指纹表面。 53 | 54 | 如果设置，由`RTCPeerConnection`实例上的`getDefaultIceServers`公开的配置的默认ICE服务器也提供跨时间跨源信息，这增加了给定浏览器的指纹表面。 55 | 56 | 建立DTLS连接时，WebRTC API可以生成可由应用程序持久保存的证书(例如在IndexedDB中)。这些证书不是跨源共享的，当该源的持久存储被清除时，它同时被清除。 57 | 58 | -------------------------------------------------------------------------------- /resource/chapter5/5_4_2 "Hold" functionality.md: -------------------------------------------------------------------------------- 1 | ### [5.4.2 "待机" 功能](http://w3c.github.io/webrtc-pc/#hold-functionality) 2 | 3 | `direction`属性和`replaceTrack`方法一起使开发人员能够实现“待机”方案。 4 | 5 | 要将音乐发送给对等方并停止呈现接收的音频（音乐待机）： 6 | 7 | ``` 8 | EXAMPLE 5 9 | async function playMusicOnHold() { 10 | try { 11 | // Assume we have an audio transceiver and a music track named musicTrack 12 | await audio.sender.replaceTrack(musicTrack); 13 | // Mute received audio 14 | audio.receiver.track.enabled = false; 15 | // Set the direction to send-only (requires negotiation) 16 | audio.direction = 'sendonly'; 17 | } catch (err) { 18 | console.error(err); 19 | } 20 | } 21 | ``` 22 | 23 | 24 | 要响应远程对等方的“sendonly” 提议： 25 | 26 | ``` 27 | EXAMPLE 6 28 | async function handleSendonlyOffer() { 29 | try { 30 | // Apply the sendonly offer first, 31 | // to ensure the receiver is ready for ICE candidates. 32 | await pc.setRemoteDescription(sendonlyOffer); 33 | // Stop sending audio 34 | await audio.sender.replaceTrack(null); 35 | // Align our direction to avoid further negotiation 36 | audio.direction = 'recvonly'; 37 | // Call createAnswer and send a recvonly answer 38 | await doAnswer(); 39 | } catch (err) { 40 | // handle signaling error 41 | } 42 | } 43 | ``` 44 | 45 | 46 | 停止发送音乐并发送从麦克风捕获的音频，以及呈现接收到的音频： 47 | 48 | ``` 49 | EXAMPLE 7 50 | async function stopOnHoldMusic() { 51 | // Assume we have an audio transceiver and a microphone track named micTrack 52 | await audio.sender.replaceTrack(micTrack); 53 | // Unmute received audio 54 | audio.receiver.track.enabled = true; 55 | // Set the direction to sendrecv (requires negotiation) 56 | audio.direction = 'sendrecv'; 57 | } 58 | ``` 59 | 60 | 61 | 响应被远程对等方取消待机： 62 | 63 | ``` 64 | EXAMPLE 8 65 | async function onOffHold() { 66 | try { 67 | // Apply the sendrecv offer first, to ensure receiver is ready for ICE candidates. 68 | await pc.setRemoteDescription(sendrecvOffer); 69 | // Start sending audio 70 | await audio.sender.replaceTrack(micTrack); 71 | // Set the direction sendrecv (just in time for the answer) 72 | audio.direction = 'sendrecv'; 73 | // Call createAnswer and send a sendrecv answer 74 | await doAnswer(); 75 | } catch (err) { 76 | // handle signaling error 77 | } 78 | } 79 | ``` 80 | -------------------------------------------------------------------------------- /resource/chapter5/5_6_4 RTCIceTransportState Enum.md: -------------------------------------------------------------------------------- 1 | ### 5.6.4 RTCIceTransportState枚举 2 | 3 | ```java 4 | enum RTCIceTransportState { 5 | "new", 6 | "checking", 7 | "connected", 8 | "completed", 9 | "disconnected", 10 | "failed", 11 | "closed" 12 | }; 13 | ``` 14 | 15 | | `RTCIceTransportState`枚举描述 | | 16 | | ------------------------------ | ------------------------------------------------------------ | 17 | | `new` | `RTCIceTransport`正在收集候选者并/或等待被提供远程候选者，并且还未开始校验。 | 18 | | `checking` | `RTCIceTransport`已经接收至少一个远程候选者并且正在校验候选者对，或是未发现连接，或是对之前成功的候选者对的校验已经失败。除此之外，它还可能继续收集。 | 19 | | `connected` | `RTCIceTransport`已经发现一个可用的连接，但是仍在校验其它候选者对试图找到一个更好的连接。它还可能继续收集并且/或等待另外的远程候选者。如果对正在使用的连接的consent check[RFC7675]失败，并且不存在其它成功的候选者对，那么状态转变为"checking"(如果还存在需要校验的候选者对)，或"disconnected"(如果没有候选者对需要校验，但是对等体仍在收集并且/或等待其它的远程候选者)。 | 20 | | `completed` | `RTCIceTransport`已经完成收集，接收到 没有更多远程候选者的指示，完成校验所有候选者对，并且已经发现一个连接。如果对于所有成功的候选者对的consent checks[RFC7675]接连失败，状态转变为"`failed`". | 21 | | `disconnected` | ICE代理已经确定当前`RTCIceTransport`的连接丢失。这是一个暂态，在片段网络中可能会间歇触发。确定状态的方式与实现方式相关。例如:丢失正在使用的连接的网络接口，或是接收对STUN请求的响应反复失败。另外，`RTCIceTransport`已经完成校验所有现存候选者对，还没有发现一个连接，但是它仍在收集或等待额外的远程候选者。 | 22 | | `failed` | RTCIceTransport已经完成收集，接收了没有更多远程候选者的指示，完成了对所有候选者对的校验，这是最终状态。 | 23 | | `closed` | RTCIceTransport已经断开，不再对STUN请求响应。 | 24 | 25 | ICE重启导致候选收集和连接检查重新开始，如果在`completed`状态下开始，则转换为`connected`。如果在暂态`disconnected`开始，则会导致转变为`checking`，从而有效的忘记之前丢失的连接。 26 | 27 | `failed`和`completed`状态需要一个不再有额外远程候选者的指示。这可以通过调用`addIceCandidate`来实现，其中候选者值的`candidate`属性被设置为空字符串或者通过`canTrickleIceCandidates`被设置为`false`。 28 | 29 | 一些状态转变的例子包括： 30 | 31 | - (`RTCIceTransport`首次创建，作为`setLocalDescription`或`setRemoteDescription`的结果)：`new` 32 | - (`new`,接收远程候选者)：`checking` 33 | - (`checking`，发现可用连接)：`connected` 34 | - (`checking`,校验失败，仍在收集过程)：`disconnected` 35 | - (`checking`,放弃)：`failed` 36 | - (`disconnected`,新的本地候选者)：`checking` 37 | - (`connected`,完成所有校验)：`completed` 38 | - (`completed`,丢失连接)：`disconnected` 39 | - (`disconnected`或`failed`，出现ICE重启)：`checking` 40 | - (`completed`,出现ICE重启)：`connected` 41 | - `RTCPeerConnection.close()`:`closed` 42 | 43 | ![](/image/5_6_4pic.png) 44 | 45 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_1_7 设置配置.md: -------------------------------------------------------------------------------- 1 | #### [4.4.1.7 设置配置](http://w3c.github.io/webrtc-pc/#set-the-configuration) 2 | 3 | 要设置配置，请运行以下步骤： 4 | 5 | 1. 让配置成为要处理的 RTCConfiguration 字典。 6 | 7 | 2. 让connection 成为目标 RTCPeerConnection 对象。 8 | 9 | 3. 如果设置了 configuration.peerIdentity 且其值与目标的 peer identity 不同，则抛出 InvalidModificationError。 10 | 11 | 4. 如果设置了 configuration.certificates 且证书集与构造连接时使用的证书集不同，则抛出 InvalidModificationError。 12 | 13 | 5. 如果设置了 configuration.bundlePolicy 的值且其值与连接的捆绑策略不同，则抛出 InvalidModificationError。 14 | 15 | 6. 如果设置了 configuration.rtcpMuxPolicy 的值且其值与连接的 rtcpMux 策略不同，则抛出 InvalidModificationError。如果值为“negotiate”且用户代理未实现非复用的 RTCP，则抛出 NotSupportedError。 16 | 17 | 7. 如果设置了 configuration.iceCandidatePoolSize 的值并且其值与连接的先前设置的 iceCandidatePoolSize 不同，并且已经调用了 setLocalDescription，则抛出 InvalidModificationError。 18 | 19 | 8. 将 ICE 代理的 ICE 传输设置设置为 configuration.iceTransportPolicy 的值。如[JSEP]（第4.1.16节）中所定义，如果新的 ICE 传输设置更改了现有设置，则在下一个收集阶段之前不会采取任何操作。如果脚本希望立即发生这种情况，则应该重新启动 ICE。 20 | 21 | 9. 将[JSEP]（第3.5.4节和第4.1.1节中）中定义的 ICE 代理的预取ICE候选池大小设置为 configuration.iceCandidatePoolSize 的值。如果新的 ICE 候选池大小改变了现有设置，则可能导致立即收集新候选池里的候选者，或丢弃现有的池里的候选者，如[JSEP]（第4.1.16节）中所定义。 22 | 23 | 10. 让 validatedServers 为空列表。 24 | 25 | 11. 如果定义了 configuration.iceServers，则对每个元素运行以下步骤： 26 | 27 | 1. 让 server 成为当前的列表元素。 28 | 29 | 2. 让 urls 为 server.urls。 30 | 31 | 3. 如果 url 是一个字符串，请将 url 设置为仅包含该字符串的列表。 32 | 33 | 4. 如果 url 为空，则抛出一个 SyntaxError。 34 | 35 | 5. 对于 urls 中的每个 url，请执行以下步骤： 36 | 37 | 1. 使用[RFC3986]中定义的通用 URI 语法解析 URL 并获取方案名称。如果基于[RFC3986]中定义的语法的解析失败，则抛出一个 SyntaxError。如果浏览器未实现方案名称，则抛出 NotSupportedError。如果方案名称是 turn 或 turns，并且使用[RFC7064]中定义的语法解析 URL 失败，则抛出一个 SyntaxError。如果方案名称是 stun 或 stuns，并且使用[RFC7065]中定义的语法解析url失败，则抛出一个 SyntaxError。 38 | 39 | 2. 如果方案名称是 turn 或 turns ，并且省略了 server.username 或 server.credential，则抛出 InvalidAccessError。 40 | 41 | 3. 如果方案名称是turn或turn，并且 server.credentialType 是“password”，而 server.credential 不是 DOMString，则抛出 InvalidAccessError。 42 | 43 | 4. 如果方案名称是 turn 或 turns ，server.credentialType 是 “oauth”，而 server.credential 不是 RTCOAuthCredential，则抛出 InvalidAccessError。 44 | 45 | 6. 将 server 附加到validatedServers。 46 | 47 | 让 validatedServers 成为 ICE 代理的 ICE服务器列表。 48 | 49 | 如[JSEP]（第4.1.16节）中所定义，如果新的服务器列表替换ICE代理的现有ICE服务器列表，则在下一个收集阶段之前不会采取任何操作。如果脚本希望立即发生这种情况，则应该重新启动ICE。但是，如果ICE候选池具有非零大小，则将丢弃任何现有池化候选者，并且将从新服务器收集新候选者。 50 | 51 | 12. 将配置存储在[[Configuration]]值中。 52 | 53 | -------------------------------------------------------------------------------- /resource/chapter4/4_2_1 RTCConfiguration Dictionary.md: -------------------------------------------------------------------------------- 1 | ## 4.2配置 2 | ### [4.2.1 RTCConfiguration字典](http://w3c.github.io/webrtc-pc/#rtcconfiguration-dictionary) 3 | 4 | RTCConfiguration定义了一组参数，用于配置 RTCPeerConnection 如何建立或重新建立点对点通信。 5 | 6 | ``` 7 | dictionary RTCConfiguration { 8 | sequence iceServers; 9 | RTCIceTransportPolicy iceTransportPolicy = "all"; 10 | RTCBundlePolicy bundlePolicy = "balanced"; 11 | RTCRtcpMuxPolicy rtcpMuxPolicy = "require"; 12 | DOMString peerIdentity; 13 | sequence certificates; 14 | [EnforceRange] 15 | octet iceCandidatePoolSize = 0; 16 | }; 17 | 18 | ``` 19 | 字典RTCConfiguration成员 20 | 21 | iceServers of type sequence: 22 | zh:类的`iceServers` 23 | 24 | 一组可供ICE使用的服务器的描述，例如 STUN 和 TURN 服务器。 25 | 26 | 一组可供ICE使用的服务器的描述，例如 STUN 和 TURN 服务器。 27 | 28 | iceTransportPolicy of type RTCIceTransportPolicy, defaulting to "all": 29 | zh:RTCIceTransportPolicy 类型的 iceTransportPolicy，默认为“all” 30 | 31 | 指示允许ICE代理使用哪些候选者。 32 | 33 | 指示允许ICE代理使用哪些候选者。 34 | 35 | bundlePolicy of type RTCBundlePolicy, defaulting to "balanced": 36 | zh:类型为 RTCBundlePolicy 的 bundlePolicy ，默认为“balanced” 37 | 38 | 指示在收集ICE候选项时要使用的媒体捆绑策略。 39 | 40 | 指示在收集ICE候选项时要使用的媒体捆绑策略。 41 | 42 | rtcpMuxPolicy of type RTCRtcpMuxPolicy, defaulting to "require": 43 | zh:RTCPtcpMuxPolicy类型的rtcpMuxPolicy，默认为“require” 44 | 45 | 指示收集ICE候选项时要使用的 rtcp-mux 策略。 46 | 47 | 指示收集ICE候选项时要使用的 rtcp-mux 策略。 48 | 49 | peerIdentity of type DOMString: 50 | zh:DOMString类型的peerIdentity 51 | 52 | 设置 RTCPeerConnection 目标对端的标识。 RTCPeerConnection 不会与对端建立连接，除非对端提供名称并用该名称成功验证身份。 53 | 54 | 设置 RTCPeerConnection 目标对端的标识。 RTCPeerConnection 不会与对端建立连接，除非对端提供名称并用该名称成功验证身份。 55 | 56 | certificates of type sequence: 57 | 序列号的证书。 58 | 59 | RTCPeerConnection 用于进行身份验证的一组证书。 60 | 61 | 通过调用 generateCertificate 函数创建此参数的有效值 62 | 63 | 虽然任何给定的 DTLS 连接仅使用一个证书，但此属性允许调用者提供支持不同算法的多个证书。将根据 DTLS 握手允许哪些证书，来选择最终证书。 RTCPeerConnection 实现选择将哪个证书用于给定连接;如何选择证书超出了本规范的范围。 64 | 65 | 如果此值不存在，则为每个 RTCPeerConnection 实例生成一组默认证书。 66 | 67 | 此选项允许应用程序建立密钥连续性。 RTCCertificate 可以保存在 [INDEXEDDB] 中并重复使用。持久性和重用也避免了密钥生成的成本。 68 | 69 | 最初选择此值后，此配置选项的值不能更改 70 | 71 | octet类型的iceCandidatePoolSize，默认为0 72 | 73 | Size of the prefetched ICE pool as defined in [JSEP] (section 3.5.4. and section 4.1.1.). 74 | zh: [JSEP]（第3.5.4节和第4.1.1节）中定义的预取ICE池的大小。 75 | 76 | Size of the prefetched ICE pool as defined in [JSEP] (section 3.5.4. and section 4.1.1.). 77 | 78 | [JSEP]（第3.5.4节和第4.1.1节）中定义的预取ICE池的大小。 79 | -------------------------------------------------------------------------------- /翻译排版指南.md: -------------------------------------------------------------------------------- 1 | # 翻译排版指南 2 | 3 | ## 目录 4 | 5 | - [空格](#关于空格) 6 | * [中英文之间需要增加空格](#中英文之间需要增加空格) 7 | * [中文与数字之间需要增加空格](#中文与数字之间需要增加空格) 8 | * [数字与单位之间需要增加空格](#数字与单位之间需要增加空格) 9 | * [行内链接和文字之间需要增加空格](#行内链接和文字之间需要增加空格) 10 | * [中文标点与其他字符之间加空格](#中文标点与其他字符之间加空格) 11 | - [代码](#代码) 12 | * [接口名使用引号](#接口名使用引号) 13 | * [代码段引用](#代码段引用) 14 | - [全角和半角](#全角和半角) 15 | * [使用全角中文标点](#使用全角中文标点) 16 | * [数字使用半角字符](#数字使用半角字符) 17 | * [遇到完整的英文整句、特殊名词，使用半角标点](#遇到完整的英文整句、特殊名词，使用半角标点) 18 | - [名词](#名词) 19 | * [专有名词使用正确的大小写](#专有名词使用正确的大小写) 20 | * [不要使用不地道的缩写或简写](#不要使用不地道的缩写或简写) 21 | 22 | 23 | ## 关于空格 24 | 25 | ### 中英文之间需要加空格 26 | 中英文之间需要加入空格。如果英文之后是标点符号，那么英文与标点之间不需要加空格。 27 | ✅ 28 | > 欢迎访问 WebRTC 中文网 29 | 30 | ❌ 31 | > 欢迎访问WebRTC中文网 32 | 33 | > 欢迎访问 WebRTC中文网 34 | 35 | > 欢迎访问WebRTC 中文网 36 | 37 | 38 | ### 中文与数字之间需要加空格 39 | 40 | ✅ 41 | > 需要调用 1 个接口 42 | 43 | ❌ 44 | > 需要调用1个接口 45 | 46 | > 需要调用 1个接口 47 | 48 | > 需要调用1 个接口 49 | 50 | ### 数字与单位之间需要增加空格 51 | 52 | ✅ 53 | > 比特率为 320 kbps 54 | 55 | ❌ 56 | > 比特率为 320kbps 57 | 58 | 59 | 60 | ### 行内链接和文字之间需要增加空格 61 | 62 | 63 | 64 | ✅ 65 | > 更多信息请访问 [我们的网站](http://webrtc.org.cn/) 66 | 67 | ❌ 68 | > 更多信息请访问[我们的网站](http://webrtc.org.cn/) 69 | 70 | ### 中文标点与其他字符之间加空格 71 | 72 | ✅ 73 | > 我的 GitHub 帐号是 @abc。 74 | 75 | ❌ 76 | > 我的 GitHub 帐号是@abc。 77 | 78 | ## 代码 79 | 80 | ### 接口名使用引号 81 | 82 | 一段文字中，如果出现接口名、类名，需要使用``来引用 83 | 84 | ✅ 85 | > 使用 `getUserMedia` 获得流 86 | 87 | ❌ 88 | > 使用`getUserMedia`获得流 89 | 90 | ### 代码段引用 91 | 92 | 如果有代码，需要引用。 93 | 94 | ✅ 95 | 96 | ``` 97 | dictionary RTCRtpCodingParameters { 98 | DOMString rid; 99 | }; 100 | 101 | ``` 102 | 103 | ❌ 104 | 105 | 106 | dictionary RTCRtpCodingParameters { 107 | DOMString rid; 108 | }; 109 | 110 | 111 | 112 | ## 全角和半角 113 | 114 | ### 使用全角中文标点 115 | 116 | 译文使用全角中文标点符号 （`，`、`。`、`、`、`“”`、`（）`） 117 | 118 | ✅ 119 | > 啊！你调试通了？ 120 | 121 | ❌ 122 | > 啊!你调试通了? 123 | 124 | 125 | ### 数字使用半角字符 126 | 127 | ✅ 128 | > 代码共有 100 行 129 | 130 | ❌ 131 | > 代码共有１００行 132 | 133 | 134 | ## 名词 135 | 136 | ### 专有名词使用正确的大小写 137 | 138 | ✅ 139 | > 使用 GitHub 登录 140 | 141 | > 我们的客户有 GitHub、Google、Facebook 等 142 | 143 | ❌ 144 | > 使用 github 登录 145 | 146 | > 使用 Github 登录 147 | 148 | > 使用 gitHub 登录 149 | 150 | > 使用 GITHUB 登录 151 | 152 | > 我们的客户有 github、google、facebook 等 153 | 154 | > 我们的客户有 GITHUB、GOOGLE、FACEBOOK 等 155 | 156 | > 我们的客户有 Github、Google、FaceBook 等 157 | 158 | ### 不要使用不地道的缩写或简写 159 | 如涉及到专有名词，请使用全称，并注意大小写 160 | 161 | ✅ 162 | > 我们需要一位熟悉 JavaScript 和 HTML5 的前端开发者。 163 | 164 | > 它采用的是 H.264 165 | 166 | ❌ 167 | > 我们需要一位熟悉 Js 和 h5 的 FED。 168 | 169 | > 它采用的是 H264 170 | 171 | > 它采用的是 264 172 | 173 | ## 索引 174 | 175 | ### 使用 [^1] 进行脚注标记 176 | 177 | ✅ 178 | > 原文出处[^1] 179 | 180 | > --- 181 | 182 | > ^1: http://zh.wikipedia.org/wiki/%E5%85%A8%E5%BD%A2%E5%92%8C%E5%8D%8A%E5%BD%A2 183 | -------------------------------------------------------------------------------- /resource/chapter6/6_1_RTCPeerConnection_Interface_Extensions.md: -------------------------------------------------------------------------------- 1 | ## 6.1 RTCPeerConnection 接口扩展 2 | 3 | 对等数据API对RTCPeerConnection接口的扩展如下。 4 | 5 | ```java 6 | partial interface RTCPeerConnection { 7 | readonly attribute RTCSctpTransport? sctp; 8 | RTCDataChannel createDataChannel (USVString label, optional RTCDataChannelInit dataChannelDict); 9 | attribute EventHandler ondatachannel; 10 | }; 11 | ``` 12 | 13 | **属性** 14 | 15 | `RTCSctpTransport`类型的`sctp`，只读，可以为null,[测试](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCIceTransport.html)：SCTP数据通过SCTP传输发送和接收。如果SCTP还未经过协商，值为null。此属性必须返回存储在[SctpTransport]内部插槽的`RTCSctpTransport`对象。 16 | 17 | `EventHandler`类型的`ondatachannel`,[测试](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCPeerConnection-ondatachannel.html)：此event handler的事件类型是`datachannel`。 18 | 19 | 20 | 21 | **方法** 22 | 23 | `createDataChannel` 24 | 25 | 以给定标签创建一个新的`RTCDataChannel`对象。`RTCDataChannelInit`字典可以被用来配置底层通道属性，例如数据可靠性。 26 | 27 | 当`createDataChannel`方法被调用时，用户代理必须运行下列步骤。 28 | 29 | 1.让`connection`成为用来调用方法的`RTCPeerConnection`对象。 30 | 31 | 2.如果`connection`的[IsClosed]插槽为`true`，抛出一个`InvalidStateError`。[测试](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCPeerConnection-createDataChannel.html) 32 | 33 | 3.创建一个`RTCDataChannel`,channel。 34 | 35 | 4.初始化channel的[DataChannelLable]插槽为第一个参数的值。 36 | 37 | 5.如果[DataChannelLabel]长度大于65535bytes,抛出`TypeError`。 38 | 39 | 6.让options成为第二个参数。 40 | 41 | 7.初始化channels的[MaxPacketLifeTime]插槽为option的`maxPacketLifeTime`成员，如果存在，否则为`null`。 42 | 43 | 8.初始化channel的[MaxRetransmits]插槽为option的`maxRetransmits`成员，如果存在，否则为`null`。 44 | 45 | 9.初始化channel的[Ordered]插槽为option的`ordered`成员。 46 | 47 | 10.初始化channel的[DataChannelProtocol]插槽为option的`protocol`成员。 48 | 49 | 11.如果[DataChannelProtocol]长度大于65535bytes，抛出`TypeError`。 50 | 51 | 12.初始化channel的[Negotiated]插槽为option的`negotiated`成员。 52 | 53 | 13.初始化channel的[DataChannelId]插槽为option的`id`成员的值，如果存在并且[Negotiated]为`true`，否则为`null`。 54 | 55 | > NOTE:这意味着如果数据通道在带内协商，id成员将会被忽略。这是有意的。数据通道带内协商应该基于DTLS角色选择ID，如[RTCWEB-DATA-PROTOCOL]中所述。 56 | 57 | 14.如果[Negotiated]为`true`，并且[DataChannelId]为`null`，抛出`TypeError`。 58 | 59 | 15.初始化channel的[DATAChannelPriority]插槽为option的`priority`成员。 60 | 61 | 16.如果[MaxPacketLifeTime]和[MaxRetransmits]属性都被设置(不为null)，抛出`TypeError`。 62 | 63 | 17.如果一个设置，或是[MaxPacketLifeTime],或是[MaxRetransmits]已经被设置用来表示不可靠模式，并且它的值超过了用户代理支持的最大值，此数值必须被设置为用户代理最大值。 64 | 65 | 18.如果[DataChannelId]等于65535，比最大允许ID65534长，但是仍然是无符号short值，抛出`TypeError`。 66 | 67 | 19.如果[DataChannelId]插槽为`null`（由于没有ID被传入`createDataChannel`，或者[Negotiated]为false)，并且SCTP传输DTLS角色已经协商，则初始化[DataChannelId]为用户代理生成的值，根据[RTCWEB-DATA-PROTOCOL]，并且跳过下列步骤。如果不能生成可用ID，或者[DataChannelId]插槽的值被现存`RTCDataChannel`使用，抛出`OperationError`异常。 68 | 69 | > NOTE:如果在此步骤之后[DataChannelId]插槽为`null`，则在设置`RTCSessionDescription`的过程中确定DTLS角色后，将填充该插槽。 70 | 71 | 20.让transport成为connection的[SctpTransport]插槽。如果[DataChannelId]插槽为`null`，transport处于`connected`状态，并且[DataChannelId]大于等于transport的[MaxChannels]插槽，抛出`OperationError`。 72 | 73 | 21.如果channel是在connection上创建的第一个`RTCDataChannel`，更新negotiation-needed标记。 74 | 75 | 22.返回channel并且继续并行执行下列步骤。 76 | 77 | 23.创建channel的关联底层数据传输，并且根据相关channel属性配置。 78 | 79 | -------------------------------------------------------------------------------- /resource/chapter7/7_2_RTCDTMFSender.md: -------------------------------------------------------------------------------- 1 | ## 7.2 RTCDTMFSender 2 | 3 | 为了创建RTCDTMFSender，用户代理必须运行以下步骤： 4 | 5 | 1. 让dtmf成为最新创建的`RTCDTMFSender`对象。 6 | 2. 让dtmf具有[Duration]内部插槽。 7 | 3. 让dtmf具有[InterToneGap]内部插槽。 8 | 4. 让dtmf具有[ToneBuffer]内部插槽。 9 | 10 | ```java 11 | [Exposed=Window] interface RTCDTMFSender : EventTarget { 12 | void insertDTMF (DOMString tones, optional unsigned long duration = 100, optional unsigned long interToneGap = 70); 13 | attribute EventHandler ontonechange; 14 | readonly attribute boolean canInsertDTMF; 15 | readonly attribute DOMString toneBuffer; 16 | }; 17 | ``` 18 | 19 | **属性** 20 | 21 | 事件处理程序类型的`ontonechange`:此事件处理程序的事件类型时候tonechange。[测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCDTMFSender-ontonechange-long.https.html) 22 | 23 | boolean类型的`canInsertDTMF`,只读：不管`RTCDTMFSender` dtmfSender是否能发送DTMF。当获取时，用户代理必须返回结果，确定是否可以为dtmfSender发送DTMF。 24 | 25 | DOMString类型的`toneBuffer`，只读：`toneBuffer`属性必须返回剩余需要播放的tone列表。关于此列表的语法，内容，解释，查看`insertDTMF`。 26 | 27 | **方法** 28 | 29 | `insertDTMF`：`RTCDTMFSender`对象的`insertDTMF`方法用于发送DTMF音调。 30 | 31 | tone参数被视为一系列字符。字符0到9，A到D，`#`和`*`生成相关的DTMF音调。字符a到d必须在输入时标准化为大写，并且等同于A到D.如[RTCWEB-AUDIO]第3节所述，需要支持字符0到9，A到D，＃和*。必须支持字符'，'，并指示在处理tone参数中的下一个字符之前的2秒延迟。所有其他字符（以及仅其他字符）必须被视为无法识别。[测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCDTMFSender-insertDTMF.https.html) 32 | 33 | 持续时间参数指示用于在音调参数中传递的每个字符的持续时间（以毫秒为单位）。持续时间不能超过6000毫秒或小于40毫秒。每种音调的默认持续时间为100 ms。 34 | 35 | interToneGap参数表示以ms为单位的音调间隙。用户代理将其钳位至少30毫秒，最多6000毫秒。默认值为70毫秒。 36 | 37 | 浏览器可以增加持续时间和interToneGap时间，以使DTMF开始和停止的时间与RTP数据包的边界对齐，但它不能增加它们中的任何一个超过单个RTP音频数据包的持续时间。 38 | 39 | 当调用`insertDTMF（)`方法时，用户代理必须运行以下步骤： 40 | 41 | 1. 让sender成为用来发送DTMF的`RTCRtpSender`。 42 | 2. 让transceiver成为与sender关联的`RTCRtpTransceiver`对象。 43 | 3. 如果transceiver的[Stopped]插槽为`true`，抛出`InvalidStateError`。 44 | 4. 如果transceiver的[CurrentDirection]插槽为`recvonly`或者`inactive`，抛出`InvalidStateError`。 45 | 5. 让dtmf成为与sender关联的`RTCDTMFSender`对象。 46 | 6. 如果决定是否可以为drmf发送DTMF返回`false`，抛出`InvalidStateError`。 47 | 7. 让tones成为方法的第一个参数。 48 | 8. 如果tones包含任意未识别的字符，抛出`InvalidCharacterError`。 49 | 9. 设置对象的[ToneBuffer]插槽为tones。 50 | 10. 设置dtmf的[Duration]插槽为`duration`参数的值。 51 | 11. 设置dtmf的[InterToneGap]插槽为`interToneGap`参数的值。 52 | 12. 如果`duration`参数的值小于40毫秒，设置dtmf的[Duration]插槽为40毫秒。 53 | 13. 如果`duration`参数的值大于6000 ms，请将dtmf的[[Duration]]插槽设置为6000 ms。 54 | 14. 如果`interToneGap`参数的值小于30 ms，则将dtmf的[[InterToneGap]]插槽设置为30 ms。 55 | 15. 如果`interToneGap`参数的值大于6000 ms，请将dtmf的[[InterToneGap]]插槽设置为6000 ms。 56 | 16. 如果[[ToneBuffer]]插槽为空字符串，则中止这些步骤。 57 | 17. 如果计划运行Playout任务，则中止这些步骤;否则运行以下步骤的任务排队（播出任务）： 58 | 1. 如果收发器的[[Stopped]]插槽为真，则中止这些步骤。 59 | 2. 如果收发器的[[CurrentDirection]]插槽是`recvonly`或`inactive`，则中止这些步骤。 60 | 3. 如果[[ToneBuffer]]槽包含空字符串，则使用RTCDTMFToneChangeEvent接口触发名为`tonechange`的事件，并将`tone`属性设置为RTCDTMFSender对象的空字符串并中止这些步骤。 61 | 4. 从[[ToneBuffer]]插槽中删除第一个字符，然后让该字符变为tone。 62 | 5. 如果音调是“，”延迟在相关的RTP媒体流上发送tones 2000毫秒，并为2000毫秒后开始执行的任务排队，此任务运行标记为播出任务的步骤。 63 | 6. 如果音调不是“，”使用适当的编解码器在相关的RTP媒体流上开始播放[[持续时间]] ms的音调，然后将要在[[持续时间]] + [[InterToneGap]] ms中执行的任务排队，此任务运行标记为播出任务的步骤。 64 | 7. 使用`RTCDTMFToneChangeEvent`接口触发名为`tonechange`的事件，并将`tone`属性设置为`RTCDTMFSender`对象的tone。 65 | 66 | 由于`insertDTMF`替换了音调缓冲区，为了添加正在播放的DTMF音调，必须使用包含剩余音调（存储在[[ToneBuffer]]插槽中）和附加在一起的新音调的字符串调用`insertDTMF`。使用空音调参数调用`insertDTMF`可用于取消在当前播放音调之后排队等待播放的所有音调。 67 | -------------------------------------------------------------------------------- /resource/chapter5/5_5 RTCDtlsTransport接口.md: -------------------------------------------------------------------------------- 1 | ## [5.5 RTCDtlsTransport接口](http://w3c.github.io/webrtc-pc/#rtcdtlstransport-interface) 2 | 3 | `RTCDtlsTransport`接口允许应用程序获取数据报传输层安全性协议(DTLS)传输的信息，通过此协议，RTP与RTCP数据包被`RTCRtpSender`和`RTCRtpReceiver`对象发送和接收，还有数据通道发送和接收的其它数据，例如STCP数据包。特别是DTLS为底层传输添加了安全性，并且`RTCDtlsTransport`接口允许获取底层传输和安全性的信息。因为需要调用`setLocalDescription()`和`setRemoteDescription()`函数，`RTCDtlsTransport`对象被创建。每个`RTCDtlsTransport`对象代表一个特定的`RTCRtpTransceiver`的RTP或RTCP组件的DTLS传输层，或是一组已经通过BUNDLE协商好的`RTCRtpTransceivers`。 4 | 5 | > NOTE:现存RTCRtpTransceiver的一个新DTLS关联将会由一个现存RTCDtlsTransport对象代表，它的状态将会对应更新，而不是换做一个新的对象来表示。 6 | 7 | 一个`RTCDtlsTransport`有一个被初始化为`new`的[[DtlsTransportState]]内部插槽，和一个被初始化为空列表的[[RemoteCertificates]]的插槽。 8 | 9 | 当底层DTLS传输产生错误时，例如证书失效，或错误警报，用户代理必须对运行下列步骤的任务排序： 10 | 11 | 1. 让transport成为`RTCDtlsTransport`对象，用来接收状态更新和错误提示。 12 | 2. 如果transport的状态已经为failed，中断这些步骤。 13 | 3. 设置transport的[[DtlsTransportState]]插槽为`failed`。 14 | 4. 使用RTCErrorEvent接口和它的或者为dtlsfailure，或者为fingerprint-failure的errorDetail属性，发起一个名为error的事件，并且其它fields都按照RTCErrorDetailType枚举的那样恰当设置，在transport。 15 | 5. 在transport发起一个名为statechange的事件。 16 | 17 | 当底层DTLS传输由于任何其它原因需要更新相应RTCDtlsTransport对象的状态时，用户代理必须对运行下列步骤的任务排序： 18 | 19 | 1. 让transport成为RTCDtlsTransport对象来接收状态更新。 20 | 2. 让newState成为新状态。 21 | 3. 设置transport的[[DtlsTransportState]]插槽为newState。 22 | 4. 如果newState连接，那么让newRemoteCertificates成为远端使用的证书链，每个证书都使用二进制可辨别编码规则(DER)[X690]进行编码，饼设置transport的[[RemoteCertificates]]插槽为newRemoteCertificates。 23 | 5. 在transport发起一个名为statechange的事件。 24 | 25 | ```java 26 | [Exposed=Window] interface RTCDtlsTransport : EventTarget { 27 | [SameObject] 28 | readonly attribute RTCIceTransport iceTransport; 29 | readonly attribute RTCDtlsTransportState state; 30 | sequence getRemoteCertificates (); 31 | attribute EventHandler onstatechange; 32 | attribute EventHandler onerror; 33 | }; 34 | ``` 35 | 36 | **属性** 37 | 38 | `iceTransport` of type `RTCIceTransport`, readonly: 39 | iceTransport属性是用来发送接收数据包的底层传输。底层传输在多个活跃的RTCDtlsTransport对象间可能不会被共享。 40 | 41 | `state` of type `RTCDtlsTransportState`, readonly: 42 | 当需要state属性时，它必须返回[[DtlsTransportState]]插槽的值。 43 | 44 | `onstatechange` of type `EventHandler`: 45 | 此eventhandler的事件类型是statechange。 46 | 47 | `onerror` of type `EventHandler`: 48 | 此eventhandler的事件类型是error。 49 | 50 | **方法** 51 | 52 | `getRemoteCertificates`返回[[RemoteCertificates]]的值。 53 | 54 | `RTCDtlsTransportState` 枚举 55 | 56 | ```java 57 | enum RTCDtlsTransportState { 58 | "new", 59 | "connecting", 60 | "connected", 61 | "closed", 62 | "failed" 63 | }; 64 | ``` 65 | 66 | 67 | 68 | | 枚举描述 | | 69 | | ------------------------------------------------------------ | ------------------------------------------------------------ | 70 | | `new` | DTLS还没有开始协商。 | 71 | | `connecing` | DTLS正在协商一个安全连接，并验证远端指纹。 | 72 | | `connected`[测试：1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCDtlsTransport-state.html) | DTLS已经完成安全连接的协商，并已经确认远端指纹。 | 73 | | `closed`[测试：1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCDtlsTransport-state.html) | transport已经关闭，由于收到close_notify警报，或调用close()。 | 74 | | `failed` | 由于产生了错误，transport已经失败(例如接收到错误警报或未能验证远端指纹)。 | 75 | -------------------------------------------------------------------------------- /resource/chapter4/4_8_2 RTCPeerConnectionIceEvent接口.md: -------------------------------------------------------------------------------- 1 | ### [4.8.2 RTCPeerConnectionIceEvent接口](http://w3c.github.io/webrtc-pc/#rtcpeerconnectioniceevent) 2 | 3 | `RTCPeerConnection` 的 `icecandidate` 事件使用 `RTCPeerConnectionIceEvent` 接口。 4 | 5 | 当触发包含 `RTCIceCandidate` 对象的 `RTCPeerConnectionIceEvent` 事件时，它必须包含`sdpMid`和`sdpMLineIndex`的值。如果RTCIceCandidate的类型为srflx或类型为relay，则事件的url属性必须设置为从中获取候选者的ICE服务器的URL。 6 | 7 | NOTE 8 | 9 | The icecandidate event is used for three different types of indications: 10 | zh:icecandidate事件用于三种不同类型的指示： 11 | 12 | * A candidate has been gathered. The candidate member of the event will be populated normally. It should be signaled to the remote peer and passed into addIceCandidate. 13 | zh: 候选人已经聚集。该活动的候选成员将正常填充。它应该发信号通知远程对等体并传递给addIceCandidate。 14 | * An RTCIceTransport has finished gathering a generation of candidates, and is providing an end-of-candidates indication as defined by Section 8.2 of [TRICKLE-ICE]. This is indicated by candidate.candidate being set to an empty string. The candidate object should be signaled to the remote peer and passed into addIceCandidate like a typical ICE candidate, in order to provide the end-of-candidates indication to the remote peer. 15 | zh: RTCIceTransport已完成收集一代候选者，并提供[TRICKLE-ICE]第8.2节定义的候选终结指示。这由candidate.candidate设置为空字符串表示。候选对象应该被发信号通知远程对等体并像典型的ICE候选者一样被传递到addIceCandidate，以便向远程对等体提供候选终止指示。 16 | * All RTCIceTransports have finished gathering candidates, and the RTCPeerConnection's RTCIceGatheringState has transitioned to "complete". This is indicated by the candidate member of the event being set to null. This only exists for backwards compatibility, and this event does not need to be signaled to the remote peer. It's equivalent to an "icegatheringstatechange" event with the "complete" state. 17 | zh: 所有RTCIceTransports都已完成收集候选者，RTCPeerConnection的RTCIceGatheringState已转换为“完成”。这由事件的候选成员设置为null来指示。这仅用于向后兼容，并且不需要向远程对等方发信号通知此事件。它相当于具有“完整”状态的“icegatheringstatechange”事件。 18 | 19 | ``` 20 | [Constructor(DOMString type, optional RTCPeerConnectionIceEventInit eventInitDict), 21 | Exposed=Window] 22 | interface RTCPeerConnectionIceEvent : Event { 23 | readonly attribute RTCIceCandidate? candidate; 24 | readonly attribute DOMString? url; 25 | }; 26 | ``` 27 | 28 | ##### Constructors zh:构造函数 29 | 30 | `RTCPeerConnectionIceEvent` 31 | 32 | ##### Attributes zh:属性 33 | 34 | candidate of type RTCIceCandidate, readonly, nullable: 35 | zh:RTCIceCandidate类型的候选者，只读，可以为空 36 | 37 | The candidate attribute is the RTCIceCandidate object with the new ICE candidate that caused the event. 38 | 39 | zh:候选属性是RTCIceCandidate对象，其中包含导致该事件的新ICE候选对象。 40 | 41 | This attribute is set to null when an event is generated to indicate the end of candidate gathering. 42 | 43 | zh:生成事件以指示候选收集结束时，此属性设置为null。 44 | 45 | NOTE 46 | Even where there are multiple media components, only one event containing a null candidate is fired. 47 | 48 | zh:即使存在多个媒体组件，也只会触发一个包含空候选的事件。 49 | 50 | url of type DOMString, readonly, nullable: 51 | zh:DOMString类型的url，只读，可以为空 52 | 53 | The url attribute is the STUN or TURN URL that identifies the STUN or TURN server used to gather this candidate. If the candidate was not gathered from a STUN or TURN server, this parameter will be set to null. 54 | 55 | zh:url属性是STUN或TURN URL，用于标识用于收集此候选项的STUN或TURN服务器。如果未从STUN或TURN服务器收集候选项，则此参数将设置为null。 56 | 57 | ``` 58 | dictionary RTCPeerConnectionIceEventInit : EventInit { 59 | RTCIceCandidate? candidate; 60 | DOMString? url; 61 | }; 62 | ``` 63 | 64 | ##### Dictionary RTCPeerConnectionIceEventInit Members zh:字典RTCPeerConnectionIceEventInit成员 65 | 66 | candidate of type RTCIceCandidate, nullable: 67 | zh:RTCIceCandidate类型的候选者，可以为空 68 | 69 | See the candidate attribute of the RTCPeerConnectionIceEvent interface. 70 | 71 | zh:请参阅RTCPeerConnectionIceEvent接口的候选属性。 72 | 73 | url of type DOMString, nullable: 74 | zh:DOMString类型的url，可以为空 75 | 76 | The url attribute is the STUN or TURN URL that identifies the STUN or TURN server used to gather this candidate. 77 | 78 | zh:url属性是STUN或TURN URL，用于标识用于收集此候选项的STUN或TURN服务器。 79 | 80 | -------------------------------------------------------------------------------- /resource/chapter3/3 Terminology.md: -------------------------------------------------------------------------------- 1 | 3. Terminology zh:[3.术语](http://w3c.github.io/webrtc-pc/#terminology) 2 | 3 | The EventHandler interface, representing a callback used for event handlers, and the ErrorEvent interface are defined in [HTML51]. 4 | 5 | zh:事件处理器接口，代表用于响应事件的回调函数，错误事件的接口定义可以在[HTML51]中找到。 6 | 7 | The concepts queue a task and networking task source are defined in [HTML51]. 8 | 9 | zh:队列任务与网络任务源的概念可以在[HTML51]中找到定义。 10 | 11 | The concept fire an event is defined in [DOM]. 12 | 13 | zh:事件触发的概念可以在[DOM]中找到定义。 14 | 15 | The terms event, event handlers and event handler event types are defined in [HTML51]. 16 | 17 | zh:术语"事件"、"事件处理器"和"事件类型"可以在[HTML51]中找到定义。 18 | 19 | performance.timeOrigin and performance.now() are defined in [HIGHRES-TIME]. 20 | 21 | zh:performance.timeOrigin 和 performance.now() 分别可以在[HIGHRES-TIME]中找到定义。 22 | 23 | The terms serializable objects, serialization steps, and deserialization steps are defined in [HTML]. 24 | 25 | zh:术语"可序列化对象"，"序列化步骤"和"反序列化步骤"可以在[HTML]中找到定义。 26 | 27 | The terms MediaStream, MediaStreamTrack, and MediaStreamConstraints are defined in [GETUSERMEDIA]. Note that MediaStream is extended in the MediaStream section in this document while MediaStreamTrack is extended in the MediaStreamTrack section in this document. 28 | 29 | zh:术语"MediaStream"，"MediaStreamTrack" 和 "MediaStreamConstraints" 可以在[GETUSERMEDIA]中找到定义。请注意，MediaStream 在本文档的 MediaStream 部分中进行了扩展，而 MediaStreamTrack 在本文档的 MediaStreamTrack 部分中进行了扩展。 30 | 31 | The term Blob is defined in [FILEAPI]. 32 | 33 | zh:术语"Blob"可以在[FILEAPI]中找到定义。 34 | 35 | The term media description is defined in [RFC4566]. 36 | 37 | zh:术语"媒体描述"可以在[RFC4566]中找到定义。 38 | 39 | The term media transport is defined in [RFC7656]. 40 | 41 | zh:术语"媒体传输"可以在[RFC7656]中找到定义。 42 | 43 | The term generation is defined in [TRICKLE-ICE] Section 2. 44 | 45 | zh:术语"生成"可以在[TRICKLE-ICE]第2节中找到定义。 46 | 47 | The terms RTCStatsType, stats object and monitored object are defined in [WEBRTC-STATS]. 48 | 49 | zh:术语"RTCStatsType"，"stats对象"和"被监控对象"可以在[WEBRTC-STATS]中找到定义。 50 | 51 | When referring to exceptions, the terms throw and create are defined in [WEBIDL-1]. 52 | 53 | zh:在讨论异常时，术语 "throw" 和 "create" 可以在[WEBIDL-1]中找到定义。 54 | 55 | The term "throw" is used as specified in [INFRA]: it terminates the current processing steps. 56 | 57 | zh:术语 "throw" 按[INFRA]中的规定使用：它会即时终止当前的处理步骤。 58 | 59 | The terms fulfilled, rejected, resolved, pending and settled used in the context of Promises are defined in [ECMASCRIPT-6.0]. 60 | 61 | zh:在Promises的上下文中使用的满足，拒绝，解决，待决和结算的术语可以在[ECMASCRIPT-6.0]中找到定义。 62 | 63 | The terms bundle, bundle-only and bundle-policy are defined in [JSEP]. 64 | 65 | zh:术语"bundle"，"bundle-only"和"bundle-policy"可以在[JSEP]中找到定义。 66 | 67 | The OAuth Client and Authorization Server roles are defined in [RFC6749] Section 1.1. 68 | 69 | zh:OAuth客户端和授权服务器角色可以在[RFC6749]第1.1节中找到定义。 70 | 71 | The terms isolated stream, peeridentity, request an identity assertion and validate the identity are defined in [WEBRTC-IDENTITY]. 72 | 73 | zh: 术语"隔离流"，"同等性"，"请求身份断言"和"验证身份"可以在[WEBRTC-IDENTITY]中找到定义。 74 | 75 | The general principles for Javascript APIs apply, including the principle of run-to-completion and no-data-races as defined in [API-DESIGN-PRINCIPLES]. That is, while a task is running, external events do not influence what's visible to the Javascript application. For example, the amount of data buffered on a data channel will increase due to "send" calls while Javascript is executing, and the decrease due to packets being sent will be visible after a task checkpoint. It is the responsibility of the user agent to make sure the set of values presented to the application is consistent - for instance that getContributingSources() (which is synchronous) returns values for all sources measured at the same time. 76 | 77 | zh: 本文档遵循基本的 Javascript 接口原则，包括[API-DESIGN-PRINCIPLES]中定义的 run-to-completion 和 no-data-race 的原则。也就是说，在任务运行时，外部事件不会影响 Javascript 应用程序可见的内容。例如，在执行 JavaScript 应用时，数据通道上缓冲的数据量将因为"发送"的调用增加，而由于数据发送成功导致的数据通道上缓冲数据量的减少，只有在这个任务的检查点之后才能观察到。用户端需要确保在这一刻展现给应用的数值是恒定不变的 - 例如同一时间内 getContributingSources（）（同步调用）返回的值。 78 | -------------------------------------------------------------------------------- /resource/chapter12/12_Event summary.md: -------------------------------------------------------------------------------- 1 | # 12 事件总结 2 | 3 | 本章节不具有规范性。 4 | 5 | 下列事件触发`RTCDataChannel`对象： 6 | 7 | | 事件名称 | 接口 | 触发当... | 8 | | ------------------- | -------------------------- | ------------------------------------------------------------ | 9 | | `open` | Event | `RTCDataChannel`对象的底层数据传输已经建立(或重新建立)。 | 10 | | `message` | MessageEvent[webmessaging] | 成功接收到一条信息。 | 11 | | `bufferedamountlow` | Event | `RTCDataChannel`对象的`bufferedAmount`从它的`bufferedAmountLowThreshold`阈值降低到小于等于它的`bufferedAmountLowThreshold`阈值。 | 12 | | `error` | `RTCErrorEvent` | 数据通道上产生了错误。 | 13 | | `close` | Event | `RTCDataChannel`对象的底层数据传输已经关闭。 | 14 | 15 | 16 | 17 | 下列事件触发`RTCPeerConnection`对象： 18 | 19 | | 事件名称 | 接口 | 触发当... | 20 | | -------------------------- | -------------------------------- | ------------------------------------------------------------ | 21 | | `track` | `RTCTrackEvent` | 新进入媒体已经协商好具体的`RTCRtpReceiver`，接收方的track已经被添加到任何相关联的远程媒体流中。 | 22 | | `negotiationneeded` | Event | 浏览器希望通知应用程序需要协商(换句话说，createOffer调用后继续调用setLocalDescription)。 | 23 | | `signalingstatechange` | Event | 发信状态已经改变。这是由于触发了`setLocalDescription`或者`setRemoteDescription`。 | 24 | | `iceconnectionstatechange` | Event | `RTCPeerConnection`的ICE连接状态已经改变。 | 25 | | `icegatheringstatechange` | Event | `RTCPeerConnection`的ICE收集状态已经改变。 | 26 | | `icecandidate` | `RTCPeerConnectionIceEvent` | 一个新的`RTCIceCandidate`对脚本可用。 | 27 | | `connectionstatechange` | Event | `RTCPeerConnection`连接状态已经改变。 | 28 | | `icecandidateerror` | `RTCPeerConnectionIceErrorEvent` | 收集ICE候选者时出现了失败。 | 29 | | `datachannel` | `RTCDataChannelEvent` | 新的`RTCDataChannel`被分配给脚本，作为其它对等体创建通道的回应。 | 30 | | `isolationchange` | Event | 当`MediaStreamTrack`上的isolated属性改变，新的事件被分配给脚本。 | 31 | | `statsended` | `RTCStatsEvent` | 新的`RTCStatsEvent`被分配给脚本，作为同时删除一个或多个受控对象的回应。 | 32 | 33 | 下列事件触发`RTCDTMFSender`对象： 34 | 35 | | 事件名称 | 接口 | 触发当... | 36 | | ------------ | ------------------------ | ------------------------------------------------------------ | 37 | | `tonechange` | `RTCDTMFToneChangeEvent` | `RTCDTMFSender`对象或是刚刚开始播放tone(作为tone属性返回)，或是刚刚结束对`toneBuffer`中的tone的播放(在`tone`属性中作为空值返回)。 | 38 | 39 | 下列事件触发`RTCIceTransport`对象： 40 | 41 | | 事件名称 | 接口 | 触发当... | 42 | | ----------------------------- | ----- | ----------------------------------------- | 43 | | `statechange` | Event | `RTCIceTransport`状态改变。 | 44 | | `gatheringstatechange` | Event | `RTCIceTransport`收集状态改变。 | 45 | | `selectedcandidatepairchange` | Event | `RTCIceTransport`选定的候选者对发生改变。 | 46 | 47 | 下列事件触发`RTCDtlsTransport`对象： 48 | 49 | | 事件名称 | 接口 | 触发当... | 50 | | ------------- | --------------- | ------------------------------------------------------------ | 51 | | `statechange` | Event | `RTCDtlsTransport`状态改变。 | 52 | | `error` | `RTCErrorEvent` | `RTCDtlsTransport`上发生了一个错误(dtls-error或是fingerprint-failure)。 | 53 | 54 | 下列事件触发`RTCSctpTransport`对象： 55 | 56 | | 事件名称 | 接口 | 触发当... | 57 | | ------------- | ----- | ---------------------------- | 58 | | `statechange` | Event | `RTCSctpTransport`状态改变。 | 59 | 60 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_3_1 方法扩展.md: -------------------------------------------------------------------------------- 1 | #### [4.4.3.1方法扩展](http://w3c.github.io/webrtc-pc/#method-extensions) 2 | 3 | ``` 4 | partial interface RTCPeerConnection { 5 | Promise createOffer(RTCSessionDescriptionCallback successCallback, 6 | RTCPeerConnectionErrorCallback failureCallback, 7 | optional RTCOfferOptions options); 8 | Promise setLocalDescription(RTCSessionDescriptionInit description, 9 | VoidFunction successCallback, 10 | RTCPeerConnectionErrorCallback failureCallback); 11 | Promise createAnswer(RTCSessionDescriptionCallback successCallback, 12 | RTCPeerConnectionErrorCallback failureCallback); 13 | Promise setRemoteDescription(RTCSessionDescriptionInit description, 14 | VoidFunction successCallback, 15 | RTCPeerConnectionErrorCallback failureCallback); 16 | Promise addIceCandidate(RTCIceCandidateInit candidate, 17 | VoidFunction successCallback, 18 | RTCPeerConnectionErrorCallback failureCallback); 19 | }; 20 | 21 | ``` 22 | 23 | **方法** 24 | 25 | `createOffer` 26 | 27 | 调用createOffer方法时，用户代理必须执行以下步骤： 28 | 29 | 1. 让successCallback成为方法的第一个参数。 30 | 31 | 2. 让failureCallback成为方法第二个参数指示的回调。 32 | 33 | 3. 让options成为方法第三个参数指示的回调。 34 | 35 | 4. 运行RTCPeerConnection的createOffer（）方法指定的步骤，将options作为唯一参数，并将p作为生成的promise。 36 | 37 | 5. 当p完成并返回 offer 时，以 offer 作为参数调用 successCallback。 38 | 39 | 6. 当p被拒绝并返回原因 r 时，以 r 作为参数调用 failureCallback。 40 | 41 | 7. 返回使用 undefined 作为 resolved 的 promise。 42 | 43 | 44 | `setLocalDescription` 45 | 46 | zh:调用 setLocalDescription 方法时，用户代理必须运行以下步骤： 47 | 48 | 1. 让 description 成为方法的第一个参数。 49 | 50 | 2. 让 successCallback 成为方法第二个参数指示的回调。 51 | 52 | 3. 让 failureCallback 成为方法第三个参数指示的回调。 53 | 54 | 4. 运行 RTCPeerConnection 的 setLocalDescription 方法指定的步骤，将 description 作为唯一参数，并将p作为生成的promise。 55 | 56 | 5. 完成p后，使用undefined作为参数调用 successCallback。 57 | 58 | 6. 当p被拒绝并返回原因 r 时，以r作为参数调用 failureCallback。 59 | 60 | 7. 返回使用 undefined 作为 resolved 的 promise。 61 | 62 | 63 | `createAnswer` 64 | 65 | NOTE 66 | 旧版 createAnswer 方法不接受 RTCAnswerOptions 参数，因为没有任何已知的旧版 createAnswer 实现支持它。 67 | 68 | 调用createAnswer方法时，用户代理必须运行以下步骤： 69 | 70 | 1. 让successCallback成为方法的第一个参数。 71 | 72 | 2. 让failureCallback成为方法第二个参数指示的回调。 73 | 74 | 3. 运行RTCPeerConnection的createAnswer（）方法指定的步骤，不带参数，让p为结果的promise。 75 | 76 | 4. 当p完成并返回 answer 时，调用 successCallback 并将 answer 作为参数。 77 | 78 | 5. 当p被拒绝并返回原因 r 时时，以 r 作为参数调用 failureCallback。 79 | 80 | 6. 返回使用 undefined 作为 resolved 的 promise。 81 | 82 | `setRemoteDescription` 83 | 84 | 调用setRemoteDescription方法时，用户代理必须执行以下步骤： 85 | 86 | 1. 让描述成为方法的第一个参数。 87 | 88 | 2. 让 successCallback 成为方法第二个参数指示的回调。 89 | 90 | 3. 让 failureCallback 成为方法第三个参数指示的回调。 91 | 92 | 4. 运行 RTCPeerConnection 的 setRemoteDescription 方法指定的步骤，将 description 作为唯一参数，并将 p 作为生成的 promise。 93 | 94 | 5. 完成 p 后，使用 undefined 作为参数调用 successCallback。 95 | 96 | 6. 当 p 被拒绝并返回原因 r 时，以 r 作为参数调用failureCallback。 97 | 98 | 7. 返回使用 undefined 作为 resolved 的 promise。 99 | 100 | `addIceCandidate` 101 | 102 | 调用 addIceCandidate 方法时，用户代理必须执行以下步骤： 103 | 104 | 1. 让候选人成为方法的第一个参数。 105 | 106 | 2. 让 successCallback 成为方法第二个参数指示的回调。 107 | 108 | 3. 让 failureCallback 成为方法第三个参数指示的回调。 109 | 110 | 4. 运行 RTCPeerConnection 的 addIceCandidate（）方法指定的步骤，候选者作为唯一参数，让 p 为结果承诺。 111 | 112 | 5. 完成 p 后，使用 undefined 作为参数调用 successCallback。 113 | 114 | 6. 当 p 被拒绝并返回原因 r 时时，以 r 作为参数调用 failureCallback。 115 | 116 | 7. 返回使用 undefined 作为 resolved 的 promise。 117 | 118 | 119 | Callback Definitions 120 | 121 | 这些回调仅用于旧版API。 122 | 123 | **`RTCPeerConnectionErrorCallback`** 124 | 125 | ``` 126 | callback RTCPeerConnectionErrorCallback = void (DOMException error); 127 | ``` 128 | Callback RTCPeerConnectionErrorCallback Parameters 129 | 130 | error of type DOMException 131 | An error object encapsulating information about what went wrong. 132 | 133 | **`RTCSessionDescriptionCallback`** 134 | 135 | ``` 136 | callback RTCSessionDescriptionCallback = void (RTCSessionDescriptionInit description); 137 | ``` 138 | 139 | Callback RTCSessionDescriptionCallback Parameters 140 | description of type RTCSessionDescriptionInit 141 | The object containing the SDP [SDP]. 142 | 143 | -------------------------------------------------------------------------------- /resource/chapter5/5_2_6 RTCRtpEncodingParameters 词典.md: -------------------------------------------------------------------------------- 1 | ### [5.2.6 RTCRtpEncodingParameters Dictionary](http://w3c.github.io/webrtc-pc/#rtcrtpencodingparameters) 2 | 3 | ``` 4 | dictionary RTCRtpEncodingParameters : RTCRtpCodingParameters { 5 | octet codecPayloadType; 6 | RTCDtxStatus dtx; 7 | boolean active = true; 8 | unsigned long ptime; 9 | unsigned long maxBitrate; 10 | double maxFramerate; 11 | double scaleResolutionDownBy; 12 | }; 13 | ``` 14 | 15 | **Dictionary RTCRtpEncodingParameters Members** 16 | 17 | *codecPayloadType* of type octet: 18 | zh:octet类型的codecPayloadType 19 | 20 | References a payload type from the codecs member of RTCRtpParameters. Read-only parameter. 21 | 22 | zh:从RTCRtpParameters的编解码器成员引用有效内容类型。只读参数。 23 | 24 | *dtx* of type RTCDtxStatus: 25 | zh:RTCDtxStatus类型的dtx 26 | 27 | This member is only used if the sender's kind is "audio". It indicates whether discontinuous transmission will be used. Setting it to disabled causes discontinuous transmission to be turned off. Setting it to enabled causes discontinuous transmission to be turned on if it was negotiated (either via a codec-specific parameter or via negotiation of the CN codec); if it was not negotiated (such as when setting voiceActivityDetection to false), then discontinuous operation will be turned off regardless of the value of dtx, and media will be sent even when silence is detected. 28 | 29 | zh:仅当发件人的类型为“音频”时才使用此成员。它表示是否使用不连续传输。将其设置为禁用会导致关闭不连续传输。将其设置为启用会导致在协商时（通过特定于编解码器的参数或通过协商CN编解码器）打开不连续传输;如果没有协商（例如将voiceActivityDetection设置为false），则无论dtx的值如何，都将关闭不连续操作，即使检测到静音也会发送媒体。 30 | 31 | *active* of type boolean, defaulting to true: 32 | zh:boolean类型的活动，默认为true 33 | 34 | Indicates that this encoding is actively being sent. Setting it to false causes this encoding to no longer be sent. Setting it to true causes this encoding to be sent. 35 | 36 | zh:表示正在积极发送此编码。将其设置为false会导致不再发送此编码。将其设置为true会导致发送此编码。 37 | 38 | *ptime* of type unsigned long: 39 | zh:类型为unsigned long的ptime 40 | 41 | When present, indicates the preferred duration of media represented by a packet in milliseconds for this encoding. Typically, this is only relevant for audio encoding. The user agent MUST use this duration if possible, and otherwise use the closest available duration. This value MUST take precedence over any "ptime" attribute in the remote description, whose processing is described in [JSEP] (section 5.10.). Note that the user agent MUST still respect the limit imposed by any "maxptime" attribute, as defined in [RFC4566], Section 6. 42 | 43 | zh:如果存在，则表示此编码的数据包所代表的媒体的首选持续时间（以毫秒为单位）。通常，这仅与音频编码有关。如果可能，用户代理必须使用此持续时间，否则使用最接近的可用持续时间。该值必须优先于远程描述中的任何“ptime”属性，其处理在[JSEP]（第5.10节）中描述。请注意，用户代理必须仍然遵守任何“maxptime”属性所施加的限制，如[RFC4566]第6节中所定义。 44 | 45 | *maxBitrate* of type unsigned long: 46 | zh:maxBitrate类型为unsigned long 47 | 48 | When present, indicates the maximum bitrate that can be used to send this encoding. The encoding may also be further constrained by other limits (such as maxFramerate or per-transport or per-session bandwidth limits) below the maximum specified here. maxBitrate is computed the same way as the Transport Independent Application Specific Maximum (TIAS) bandwidth defined in [RFC3890] Section 6.2.2, which is the maximum bandwidth needed without counting IP or other transport layers like TCP or UDP. 49 | 50 | zh:存在时，表示可用于发送此编码的最大比特率。编码还可能受到低于此处指定的最大值的其他限制（例如maxFramerate或每传输或每会话带宽限制）的限制。 maxBitrate的计算方法与[RFC3890]第6.2.2节中定义的传输独立应用程序特定最大值（TIAS）带宽相同，后者是不计算IP或TCP或UDP等其他传输层所需的最大带宽。 51 | 52 | *maxFramerate* of type double: 53 | zh:double类型的maxFramerate 54 | 55 | When present, indicates the maximum framerate that can be used to send this encoding, in frames per second. 56 | 57 | zh:存在时，表示可用于发送此编码的最大帧速率，以每秒帧数为单位。 58 | 59 | If changed with setParameters, the new framerate takes effect after the current picture is completed; setting the max framerate to zero thus has the effect of freezing the video on the next frame. 60 | 61 | zh: 如果使用setParameters更改，则新帧速率在当前图片完成后生效;将最大帧速率设置为零因此具有在下一帧上冻结视频的效果。 62 | 63 | *scaleResolutionDownBy* of type double: 64 | zh:scaleResolutionDown类型为double 65 | 66 | This member is only present if the sender's kind is "video". The video's resolution will be scaled down in each dimension by the given value before sending. For example, if the value is 2.0, the video will be scaled down by a factor of 2 in each dimension, resulting in sending a video of one quarter the size. If the value is 1.0, the video will not be affected. The value must be greater than or equal to 1.0. By default, the sender will not apply any scaling, (i.e., scaleResolutionDownBy will be 1.0). 67 | 68 | zh:此会员仅在发件人的类型为“视频”时才会出现。在发送之前，视频的分辨率将按给定值按比例缩小。例如，如果值为2.0，则视频将在每个维度中按比例缩小2倍，从而发送大小为四分之一的视频。如果值为1.0，则视频不会受到影响。该值必须大于或等于1.0。默认情况下，发件人不会应用任何缩放（即scaleResolutionDownBy将为1.0）。 69 | -------------------------------------------------------------------------------- /resource/chapter5/5_3RTCRtpReceiver接口.md: -------------------------------------------------------------------------------- 1 | ## [5.3 RTCRtpReceiver 接口](http://w3c.github.io/webrtc-pc/#rtcrtpreceiver-interface) 2 | 3 | `RTCRtpReceiver`接口允许应用程序检查`MediaStreamTrack`的接收。 4 | 5 | 要使用字符串`kind`来创建`RTCRtpReceiver`，请运行以下步骤： 6 | 7 | 1. 让接收器成为新的`RTCRtpReceiver`对象。 8 | 2. 让`track`成为一个新的MediaStreamTrack对象[GETUSERMEDIA]。轨道源是接收器提供的远程源。请注意，`track.id`由用户代理生成，不会映射到远程端的任何轨道ID。 9 | 3. 将`track.kind`初始化为`kind`。 10 | 4. 将`track.label`初始化为将字符串“remote”与`kind`连接的结果。 11 | 5. 将`track.readyState`初始化为`live`。 12 | 6. 将`track.muted`初始化为`true`。请参阅`MediaStreamTrack`部分，了解在`MediaStreamTrack`接收媒体数据或者没有接收的情况下，静音属性如何反映。 13 | 7. 让接收器将[[ReceiverTrack]]内部插槽初始化为`track`。 14 | 8. 让接收器将[[ReceiverTransport]]内部插槽初始化为`null`。 15 | 9. 让接收器将[[ReceiverRtcpTransport]]内部插槽初始化为`null`。 16 | 10. 让接收器具有[[AssociatedRemoteMediaStreams]]内部槽，表示与该接收器的`MediaStreamTrack`对象相关联的`MediaStream`对象的列表，并初始化为空列表。 17 | 11. 让接收器有一个[[ReceiveCodecs]]内部插槽，表示`RTCRtpCodecParameters`字典列表，并初始化为空列表。 18 | 12. 返回接收器。 19 | 20 | ``` 21 | [Exposed=Window] interface RTCRtpReceiver { 22 | readonly attribute MediaStreamTrack track; 23 | readonly attribute RTCDtlsTransport? transport; 24 | readonly attribute RTCDtlsTransport? rtcpTransport; 25 | static RTCRtpCapabilities? getCapabilities (DOMString kind); 26 | RTCRtpReceiveParameters getParameters (); 27 | sequence getContributingSources (); 28 | sequence getSynchronizationSources (); 29 | Promise getStats(); 30 | }; 31 | ``` 32 | 33 | **属性** 34 | *track* 类型`MediaStreamTrack`，只读 35 | `track`属性是与此`RTCRtpReceiver`对象接收器关联的轨道。 36 | 37 | 请注意，`track.stop（）`是最终的，尽管克隆不受影响。由于`receiver.track.stop（）`不会隐式停止接收器，因此继续发送`Receiver Reports`。获取时，属性必须返回[[ReceiverTrack]]槽的值。 38 | 39 | *transport* `RTCDtlsTransport`类型的传输，只读，可空 40 | 41 | 传输属性是以RTP分组的形式接收接收者的轨道的媒体的传输。在构造`RTCDtlsTransport`对象之前，transport属性将为null。使用捆绑时，多个`RTCRtpReceiver`对象将共享一个传输，并将通过同一传输接收 RTP 和 RTCP。 42 | 43 | 获取时，属性必须返回[[ReceiverTransport]]槽的值。 44 | 45 | `rtcpTransport`类型为`RTCDtlsTransport`，只读，可空 46 | 47 | `rtcpTransport`属性是发送和接收 RTCP 的传输。在构造`RTCDtlsTransport`对象之前，`rtcpTransport`属性将为`null`。当使用 RTCP mux（或捆绑，强制执行 RTCP mux）时，`rtcpTransport`将为`null`，并且 RTP 和 RTCP 流量都将通过传输流动。 48 | 49 | 获取时，属性必须返回[[ReceiverRtcpTransport]]槽的值。 50 | 51 | **方法** 52 | `getCapabilities`，静态 53 | `getCapabilities（）`方法返回系统功能的最乐观视图，用于接收给定类型的媒体。它不保留任何资源，端口或其他状态，但旨在提供一种方法来发现浏览器的功能类型，包括可能支持的编解码器。用户代理必须支持“音频”和“视频”的类型值。如果系统没有与`kind`参数的值相对应的功能，则`getCapabilities`返回`null`。 54 | 55 | 这些功能通常在设备上提供持久的跨源信息，从而增加了应用程序的指纹表面。在隐私敏感的上下文中，浏览器可以考虑缓解，例如仅报告功能的公共子集。 56 | 57 | `getParameters` 58 | `getParameters（）`方法返回`RTCRtpReceiver`对象的当前参数，用于解码轨道的方式。 59 | 调用`getParameters`时，`RTCRtpReceiveParameters`字典构造如下： 60 | 根据当前远程描述中存在的 RID 填充编码。 61 | 62 | * `headerExtensions`序列基于接收器当前准备接收的头扩展来填充。 63 | * 编解码器序列基于接收器当前准备接收的编解码器来填充。 64 | 注意本地和远程描述可能会影响此编解码器列表。例如，如果提供了三个编解码器，接收器将准备好接收它们中的每一个，并将从`getParameters`返回它们。但是如果远程端点只回答两个，则`getParameters`将不再返回缺少的编解码器，因为接收器不再需要准备接收它。 65 | * 如果接收器当前准备接收缩小的RTCP数据包，则`rtcp.reducedSize`设置为true，否则设置为`false`。 `rtcp.cname`被省略了。 66 | 67 | `getContributingSources` 68 | 返回此RTCRtpReceiver在过去10秒内收到的每个唯一CSRC标识符的RTCRtpContributingSource。 69 | 70 | `getSynchronizationSources` 71 | 返回此`RTCRtpReceiver`在过去10秒内收到的每个唯一 SSRC 标识符的`RTCRtpContributingSource` 72 | 73 | `getStats` 74 | 仅收集此接收器的统计信息并异步报告结果。 75 | 当调用`getStats（）`方法时，用户代理必须运行以下步骤： 76 | 77 | 1. 让`selector`成为调用该方法的`RTCRtpReceiver`对象。 78 | 79 | 2. 让`p`成为新的承诺，并行执行以下步骤： 80 | 1. 根据统计选择算法收集选择器指示的统计数据。 81 | 2. 使用生成的RTCStatsReport对象解析p，其中包含收集的统计信息。 82 | 3. 返回p。 83 | 84 | `RTCRtpContributingSource`和`RTCRtpSynchronizationSource`字典分别包含有关给定贡献源（CSRC）或同步源（SSRC）的信息，包括源所贡献的数据包的最近时间。浏览器必须保留前 10 秒内收到的 RTP 数据包的信息。当包含在 RTP 数据包中的第一个音频或视频帧被传送到`RTCRtpReceiver`的`MediaStreamTrack`进行播出时，用户代理必须排队任务，以根据数据包的内容更新`RTCRtpContributingSource`和`RTCRtpSynchronizationSource`字典的相关信息。每次更新与 SSRC 标识符对应的`RTCRtpSynchronizationSource`字典相关的信息，并且如果 RTP 分组包含 CSRC 标识符，则还更新与那些 CSRC 标识符对应的`RTCRtpContributingSource`字典相关的信息。 85 | 86 | NOTE 87 | 如一致性部分所述，只要最终结果是等效的，可以以任何方式实现作为算法的要求。因此，实现不需要为每个数据包逐字排队任务，只要最终结果是在单个事件循环任务执行中，所有返回的特定`RTCRtpReceiver`的`RTCRtpSynchronizationSource`和`RTCRtpContributingSource`字典都包含来自 RTP 流中单个点的信息。 88 | 89 | ``` 90 | dictionary RTCRtpContributingSource { 91 | required DOMHighResTimeStamp timestamp; 92 | required unsigned long source; 93 | double audioLevel; 94 | }; 95 | ``` 96 | 97 | #### 字典 RTCRtpContributingSource 成员 98 | 99 | *timestamp* 类型为DOMHighResTimeStamp， 必需 100 | DOMHighResTimeStamp [HIGHRES-TIME]类型的时间戳，指示到达源自此源的RTP数据包的媒体播放的最近时间。时间戳在播出时定义为`performance.timeOrigin + performance.now（）`。 101 | 102 | *source* 类型为unsigned，必需 103 | 贡献或同步源的 CSRC 或 SSRC 标识符。 104 | 105 | *audioLevel* 类型为double 106 | 仅适用于音频接收器。这是 0..1（线性）之间的值，其中 1.0 表示 0 dBov，0 表示静音，0.5 表示声压级从 0 dBov变化约 6 dBSPL。 107 | 对于 CSRC，如果存在 RFC 6465 标头扩展，则必须从[RFC6465]中定义的级别值转换，否则该成员必须不存在。 108 | 对于 SSRC，如果存在 RFC 6464 标头扩展，则必须从[RFC6464]中定义的级别值转换，否则用户代理必须从音频数据计算值（音频接收器不得缺少该成员）。 109 | 两个 RFC 将级别定义为 0 到 127 的整数值，表示相对于系统可能编码的最大信号的负分贝的音频电平。因此，0 代表系统可能编码的最响亮信号，127 代表静音。 110 | 要将这些值转换为线性 0..1 范围，将值 127 转换为 0，并使用以下公式转换所有其他值：`10 ^（ - rfc_level / 20）`。 111 | 112 | ``` 113 | dictionary RTCRtpSynchronizationSource : RTCRtpContributingSource { 114 | boolean voiceActivityFlag; 115 | }; 116 | ``` 117 | 118 | **字典 RTCRtpSynchronizationSource 成员** 119 | 120 | *voiceActivityFlag* boolean类型 121 | 仅适用于音频接收器。从该源播放的最后一个RTP数据包是否包含语音活动（true）或不包含语音活动（false）。如果 RFC 6464 扩展头不存在，或者对等体通过将“vad”扩展属性设置为“off”来表示它没有使用 V bit，如[RFC6464]第 4 节中所述，则`voiceActivityFlag`将是缺席。 122 | -------------------------------------------------------------------------------- /resource/chapter4/4_10_2 RTCCertificate接口.md: -------------------------------------------------------------------------------- 1 | ### [4.10.2 RTCCertificate Interface zh:4.10.2 RTCCertificate接口](http://w3c.github.io/webrtc-pc/#rtccertificate-interface) 2 | 3 | The RTCCertificate interface represents a certificate used to authenticate WebRTC communications. In addition to the visible properties, internal slots contain a handle to the generated private keying materal ([[KeyingMaterial]]), a certificate ([[Certificate]]) that RTCPeerConnection uses to authenticate with a peer, and the origin ([[Origin]]) that created the object. 4 | 5 | zh:RTCCertificate接口表示用于验证WebRTC通信的证书。除了可见属性之外，内部插槽还包含生成的私有密钥子集（[[KeyingMaterial]]）的句柄，RTCPeerConnection用于与对等体进行身份验证的证书（[[Certificate]]）和原点（[[[[Certificate]]） Origin]]）创建了对象。 6 | 7 | 8 | ``` 9 | [Exposed=Window, 10 | Serializable] 11 | interface RTCCertificate { 12 | readonly attribute DOMTimeStamp expires; 13 | static sequence getSupportedAlgorithms(); 14 | sequence getFingerprints(); 15 | }; 16 | ``` 17 | 18 | **Attributes zh:属性** 19 | 20 | expires of type DOMTimeStamp, readonly 21 | 22 | 23 | he expires attribute indicates the date and time in milliseconds relative to 1970-01-01T00:00:00Z after which the certificate will be considered invalid by the browser. After this time, attempts to construct an RTCPeerConnection using this certificate fail. 24 | 25 | zh:expires属性指示相对于1970-01-01T00：00：00Z的日期和时间（以毫秒为单位），之后浏览器将认为证书无效。在此之后，尝试使用此证书构造RTCPeerConnection失败。 26 | 27 | Note that this value might not be reflected in a notAfter parameter in the certificate itself. 28 | 29 | zh:请注意，此值可能不会反映在证书本身的notAfter参数中。 30 | 31 | **Methods zh:方法** 32 | 33 | getSupportedAlgorithms 34 | 35 | Returns a sequence providing a representative set of supported certificate algorithms. At least one algorithm MUST be returned. 36 | 37 | zh:返回提供一组有代表性的支持证书算法的序列。必须返回至少一个算法。 38 | 39 | For example, the "RSASSA-PKCS1-v1_5" algorithm dictionary, RsaHashedKeyGenParams, contains fields for the modulus length, public exponent, and hash algorithm. Implementations are likely to support a wide range of modulus lengths and exponents, but a finite number of hash algorithms. So in this case, it would be reasonable for the implementation to return one AlgorithmIdentifier for each supported hash algorithm that can be used with RSA, using default/recommended values for modulusLength and publicExponent (such as 1024 and 65537, respectively). 40 | 41 | zh:例如，“RSASSA-PKCS1-v1_5”算法字典RsaHashedKeyGenParams包含模数长度，公共指数和散列算法的字段。实现可能支持各种模数长度和指数，但是有限数量的散列算法。因此，在这种情况下，对于每个支持的可与RSA一起使用的哈希算法，使用modulusLength和publicExponent的默认/推荐值（分别为1024和65537），为实现返回一个AlgorithmIdentifier是合理的。 42 | 43 | getFingerprints 44 | 45 | Returns the list of certificate fingerprints, one of which is computed with the digest algorithm used in the certificate signature. 46 | 47 | zh:返回证书指纹列表，其中一个是使用证书签名中使用的摘要算法计算的。 48 | 49 | For the purposes of this API, the [[Certificate]] slot contains unstructured binary data. No mechanism is provided for applications to access the [[KeyingMaterial]] internal slot. Implementations MUST support applications storing and retrieving RTCCertificate objects from persistent storage. In implementations where an RTCCertificate might not directly hold private keying material (it might be stored in a secure module), a reference to the private key can be held in the [[KeyingMaterial]] internal slot, allowing the private key to be stored and used. 50 | 51 | zh:出于此API的目的，[[Certificate]]插槽包含非结构化二进制数据。没有为应用程序提供访问[[KeyingMaterial]]内部插槽的机制。实现必须支持从持久存储中存储和检索RTCCertificate对象的应用程序。在RTCCertificate可能不直接保存私人密钥资料（可能存储在安全模块中）的实现中，私钥的引用可以保存在[[KeyingMaterial]]内部插槽中，允许私钥存储和用过的。 52 | 53 | RTCCertificate objects are serializable objects [HTML]. Their serialization steps, given value and serialized, are: 54 | 55 | zh:RTCCertificate对象是可序列化的对象[HTML]。它们的序列化步骤，给定值和序列化，是： 56 | 57 | 1. Set serialized.[[Expires]] to the value of value's expires attribute. 58 | zh:将序列化。[[Expires]]设置为value的expires属性的值。 59 | 60 | 2. Set serialized.[[Certificate]] to a copy of the unstructured binary data in value's [[Certificate]] slot. 61 | zh:将序列化。[[Certificate]]设置为值[[Certificate]]插槽中非结构化二进制数据的副本。 62 | 63 | 3. Set serialized.[[Origin]] to a copy of the unstructured binary data in value's [[Origin]] 64 | slot. 65 | zh:将序列化。[[Origin]]设置为值[[Origin]]插槽中非结构化二进制数据的副本。 66 | 67 | 4. Set serialized.[[KeyingMaterial]] to a serialization of the private keying material represented by value's [[KeyingMaterial]] slot. 68 | zh:将序列化。[[KeyingMaterial]]设置为由值[[KeyingMaterial]]槽表示的私有密钥材料的序列化。 69 | 70 | Their deserialization steps, given serialized and value, are: 71 | 72 | zh:根据序列化和价值，他们的反序列化步骤是： 73 | 74 | 1. Initialize value's expires attribute to contain serialized.[[Expires]]. 75 | zh:初始化value的expires属性以包含serialized。[[Expires]]。 76 | 77 | 2. Set value's [[Certificate]] slot to a copy of serialized.[[Certificate]]. 78 | zh:将值的[[Certificate]]插槽设置为序列化的副本。[[Certificate]]。 79 | 80 | 3. Set value's [[Origin]] slot to a copy of serialized.[[Origin]]. 81 | zh:将值的[[Origin]]插槽设置为序列化的副本。[[Origin]]。 82 | 83 | 4. Set value's [[KeyingMaterial]] slot to the private key material resulting from deserializing serialized.[[KeyingMaterial]] 84 | zh:将值的[[KeyingMaterial]]槽设置为序列化反序列化产生的私钥材料。[[KeyingMaterial]] 85 | 86 | Supporting structured cloning in this manner allows RTCCertificate instances to be persisted to stores. It also allows instances to be passed to other origins using APIs like postMessage [webmessaging]. However, the object cannot be used by any other origin than the one that originally created it. 87 | 88 | zh:以这种方式支持结构化克隆允许将RTCCertificate实例持久化到商店。它还允许使用postMessage [webmessaging]等API将实例传递给其他来源。但是，该对象不能由最初创建它的任何其他来源使用。 89 | -------------------------------------------------------------------------------- /resource/chapter5/5_4 RTCRtpTransceiver 接口.md: -------------------------------------------------------------------------------- 1 | ## [5.4 RTCRtpTransceiver 接口](http://w3c.github.io/webrtc-pc/#rtcrtptransceiver-interface) 2 | 3 | `RTCRtpTransceiver`接口表示共享公共mid的`RTCRtpSender`和`RTCRtpReceiver`的组合。如[JSEP]（第3.4.1节）中所定义的，如果`RTCRtpTransceiver`的 `mid` 属性为非`null`，则称其与媒体描述相关联;否则据说是不相关的。从概念上讲，相关联的收发器是在最后应用的会话描述中表示的收发器。 4 | `RTCRtpTransceiver`的收发器类型由关联的`RTCRtpReceiver`的`MediaStreamTrack`对象的类型定义。 5 | 要使用`RTCRtpReceiver`对象，接收方，`RTCRtpSender`对象，发送方和`RTCRtpTransceiverDirection`值，方向创建`RTCRtpTransceiver`，请运行以下步骤： 6 | 1. 让收发器成为新的`RTCRtpTransceiver`对象。 7 | 2. 让收发器有一个[[Sender]]内部插槽，初始化为发送方。 8 | 3. 让收发器有一个[[Receiver]]内部插槽，初始化为接收器。 9 | 4. 让收发器有一个[[Stopped]]内部插槽，初始化为`false`。 10 | 5. 让收发器有一个[[Direction]]内部插槽，初始化为方向。 11 | 6. 让收发器有一个[[Receptive]]内部插槽，初始化为`false`。 12 | 7. 让收发器具有[[CurrentDirection]]内部插槽，初始化为`null`。 13 | 8. 让收发器有一个[[FiredDirection]]内部插槽，初始化为`null`。 14 | 9. 让收发器具有[[PreferredCodecs]]内部插槽，初始化为空列表。 15 | 10. 返回收发器。 16 | 17 | >NOTE 18 | > 19 | >创建收发器不会创建基于`RTCDtlsTransport`和`RTCIceTransport`的对象。这只会在设置`RTCSessionDescription`的过程中发生。 20 | 21 | 22 | ``` 23 | [Exposed=Window] interface RTCRtpTransceiver { 24 | readonly attribute DOMString? mid; 25 | [SameObject] 26 | readonly attribute RTCRtpSender sender; 27 | [SameObject] 28 | readonly attribute RTCRtpReceiver receiver; 29 | readonly attribute boolean stopped; 30 | attribute RTCRtpTransceiverDirection direction; 31 | readonly attribute RTCRtpTransceiverDirection? currentDirection; 32 | void stop (); 33 | void setCodecPreferences (sequence codecs); 34 | }; 35 | 36 | ``` 37 | 38 | **属性** 39 | 40 | *mid* DOMString类型，只读，可以为空 41 | `mid`属性是中间协商的，并且存在于[JSEP]（第 5.2.1 节和第 5.3.1 节）中定义的本地和远程描述中。在协商完成之前，中间值可能为空。回滚后，该值可能会从非`null`值更改为`null`。 42 | 43 | *sender* RTCRtpSender类型，只读 44 | `sender`属性公开了可能以`mid = mid`发送的 RTP 媒体相对应的`RTCRtpSender`。获取时，属性必须返回[[Sender]]槽的值。 45 | 46 | *receiver* RTCRtpReceiver类型，只读 47 | 接收器属性是对应于可以用`mid = mid`接收的RTP媒体的`RTCRtpReceiver`。获取属性时必须返回[[Receiver]]插槽的值。 48 | 49 | *stopped* 类型boolean，只读 50 | `stopped`属性表示此收发器的发送方将不再发送，接收方将不再接收。如果已调用`stop`或设置本地或远程描述导致`RTCRtpTransceiver`停止，则为`true`。获取时，此属性必须返回[[Stopped]]插槽的值。 51 | 52 | *direction* RTCRtpTransceiverDirection类型 53 | 如[JSEP]（第 4.2.4 节）中所定义，`direction`属性指示此收发器的首选方向，该方向将用于调用`createOffer和createAnswer`。方向性更新不会立即生效。相反，将来调用`createOffer`和`createAnswer`会将相应的媒体描述标记为`sendSearchv`，`sendonly`，`recvonly`或`inactive`，如[JSEP]中所定义（第 5.2.2 节和第 5.3.2 节）。 54 | 获取时，此属性必须返回[[Direction]]插槽的值。 55 | 在设置时，用户代理必须执行以下步骤： 56 | 1. 让收发器成为调用设置者的`RTCRtpTransceiver`对象。 57 | 2. 让连接成为与收发器关联的`RTCPeerConnection`对象。 58 | 3. 如果连接的[[IsClosed]]槽为`true`，则抛出`InvalidStateError`。 59 | 4. 如果收发器的[[Stopped]]插槽为`true`，则抛出`InvalidStateError`。 60 | 5. 让`newDirection`成为设置者的参数。 61 | 6. 如果`newDirection`等于收发器的[[Direction]]插槽，则中止这些步骤。 62 | 7. 将收发器的[[Direction]]插槽设置为`newDirection`。 63 | 8.  更新连接所需的协商标志。 64 | 65 | *currentDirection* 类型为RTCRtpTransceiverDirection，只读，可为空 66 | 如[JSEP]（第4.2.5节）中所定义，`currentDirection`属性指示为此收发器协商的当前方向。 `currentDirection`的值独立于`RTCRtpEncodingParameters.active`的值，因为无法从另一个推导出。如果此收发器从未在提供/应答交换中表示，或者收发器已停止，则该值为空。获取时，该属性必须返回[[CurrentDirection]]槽的值。 67 | 68 | **方法** 69 | 70 | `stop` 71 | 不可逆转地停止`RTCRtpTransceiver`。此收发器的发送器将不再发送，接收器将不再接收。调用`stop（）`会更新`RTCRtpTransceiver`关联的RTCPeerConnection的需要协商标志。 72 | 停止收发器将导致将来调用`createOffer`或`createAnswer`以在相应收发器的媒体描述中生成零端口，如[JSEP]（第 4.2.1 节）中所定义。 73 | 74 | >NOTE 75 | > 76 | >如果在应用远程报价和创建答案之间调用此方法，并且收发器与[BUNDLE]中定义的“提供者标记”媒体描述相关联，则这将导致捆绑组中的所有其他收发器停止为好。为避免这种情况，当`signalingState`为“稳定”并执行后续的提议/应答交换时，可以只停止当前收发器。 77 | 78 | 当调用stop方法时，用户代理必须运行以下步骤： 79 | 1. 让收发器成为调用该方法的`RTCRtpTransceiver`对象。 80 | 2. 让连接成为与收发器关联的`RTCPeerConnection`对象。 81 | 3. 如果连接的[[IsClosed]]槽为`true`，则抛出`InvalidStateError`。 82 | 4. 如果收发器的[[已停止]]插槽为`true`，则中止这些步骤。 83 | 5. 停止收发器指定的`RTCRtpTransceiver`。 84 | 6. 更新连接所需的协商标志。 85 | 86 | 给定收发器的`RTCRtpTransceiver`停止算法如下： 87 | 1. 让发送者成为收发器的[[发件人]]。 88 | 2. 让接收器成为收发器的[[接收器]]。 89 | 3. 停止向发件人发送媒体。 90 | 4. 按照[RFC3550]中的规定，为发送方发送的每个 RTP 流发送 RTCP BYE。 91 | 5. 停止使用接收器接收媒体。 92 | 6. 执行接收方[[ReceiverTrack]]的结束步骤。 93 | 7. 将收发器的[[Stopped]]插槽设置为`true`。 94 | 8. 将收发器的[[Receptive]]插槽设置为`false`。 95 | 9. 将收发器的[[CurrentDirection]]插槽设置为空。 96 | 97 | `setCodecPreferences` 98 | `setCodecPreferences`方法会覆盖用户代理使用的默认编解码器首选项。当使用`createOffer`或`createAnswer`生成会话描述时，用户代理必须按照编解码参数中指定的顺序使用指示的编解码器，用于与此`RTCRtpTransceiver`对应的媒体部分。 99 | 此方法允许应用程序禁用特定编解码器的协商。它还允许应用程序使远程对等方优先选择列表中首先出现的编解码器。 100 | 对于包含此`RTCRtpTransceiver`的`createOffer`和`createAnswer`的所有调用，编解码器首选项仍然有效，直到再次调用此方法。将编解码器设置为空序列会将编解码器首选项重置为任何默认值。 101 | 传递给`setCodecPreferences`的编解码器序列只能包含由`RTCRtpSender.getCapabilities（kind）`或`RTCRtpReceiver.getCapabilities（kind）`返回的编解码器，其中`kind`是调用该方法的`RTCRtpTransceiver`的类型。此外，不能修改`RTCRtpCodecCapability`字典成员。如果编解码器不满足这些要求，则用户代理必须抛出`InvalidAccessError`。 102 | 103 | >NOTE 104 | > 105 | >由于[SDP]中的建议，对`createAnswer`的调用应该只使用编解码器首选项的公共子集和商品中出现的编解码器。例如，如果编解码器首选项是“C，B，A”，但仅提供编解码器“A，B”，则答案应仅包含编解码器“B，A”。但是，[JSEP]（第 5.3.1 节）允许添加不在商品中的编解码器，因此实现的行为可能不同。 106 | 107 | 当调用`setCodecPreferences（）`时，用户代理必须运行以下步骤： 108 | 1. 让收发器成为调用此方法的`RTCRtpTransceiver`对象。 109 | 2. 让编解码器成为第一个参数。 110 | 3. 如果编解码器是空列表，请将收发器的[[PreferredCodecs]]插槽设置为编解码器并中止这些步骤。 111 | 4. 删除编解码器中的任何重复值。从列表的后面开始，以保持编解码器的优先级;列表中第一次出现编解码器的索引在此步骤之前和之后是相同的。 112 | 5. 让我们成为收发器的收发器类型。 113 | 6. 如果编解码器和`RTCRtpSender.getCapabilities（kind）.codecs`之间的交集或编解码器与`RTCRtpReceiver.getCapabilities（kind）.codecs`之间的交集是一个空集，则抛出`InvalidModificationError`。这确保了无论收发器方向如何，我们总能提供一些东西。 114 | 7. 让`codecCapabilities`成为`RTCRtpSender.getCapabilities（kind）.codecs`和`RTCRtpReceiver.getCapabilities（kind）.codecs`的联合。 115 | 8. 对于编解码器中的每个编解码器， 116 | 1. 如果编解码器不在`codecCapabilities`中，则抛出`InvalidModificationError`。 117 | 9. 将收发器的[[PreferredCodecs]]插槽设置为编解码器。 118 | -------------------------------------------------------------------------------- /resource/chapter4/4_8_1 连接建立接口 - RTCIceCandidate 接口.md: -------------------------------------------------------------------------------- 1 | ## [4.8 连接建立接口](http://w3c.github.io/webrtc-pc/#interfaces-for-connectivity-establishment) 2 | ### 4.8.1 RTCIceCandidate接口 3 | 4 | 该接口描述了ICE候选人，在[ICE]第2节中描述。除了`candidate`，`sdpMid`，`sdpMLineIndex`和`usernameFragment`之外，其余属性解析来自于`candidateInitDict`中的`candidate`成员，如果它是格式良好的。 5 | 6 | ``` 7 | [Constructor(optional RTCIceCandidateInit candidateInitDict), 8 | Exposed=Window] 9 | interface RTCIceCandidate { 10 | readonly attribute DOMString candidate; 11 | readonly attribute DOMString? sdpMid; 12 | readonly attribute unsigned short? sdpMLineIndex; 13 | readonly attribute DOMString? foundation; 14 | readonly attribute RTCIceComponent? component; 15 | readonly attribute unsigned long? priority; 16 | readonly attribute DOMString? address; 17 | readonly attribute RTCIceProtocol? protocol; 18 | readonly attribute unsigned short? port; 19 | readonly attribute RTCIceCandidateType? type; 20 | readonly attribute RTCIceTcpCandidateType? tcpType; 21 | readonly attribute DOMString? relatedAddress; 22 | readonly attribute unsigned short? relatedPort; 23 | readonly attribute DOMString? usernameFragment; 24 | RTCIceCandidateInit toJSON(); 25 | }; 26 | ``` 27 | 28 | **构造函数** 29 | 30 | `RTCIceCandidate`接口 31 | 32 | RTCIceCandidate() 构造函数接受一个字典参数candidateInitDict，该参数用于初始化新的RTCIceCandidate对象。 33 | 34 | 调用时，请执行以下步骤： 35 | 36 | 1. 如果 `candidateInitDict` 中的 `sdpMid` 和 `sdpMLineIndex` 字典成员都为 `null`，则抛出 TypeError 。 37 | 38 | 2. 让 `iceCandidate` 成为新创建的`RTCIceCandidate` 对象。 39 | 40 | 3. 将 `iceCandidate` 的以下属性初始化为`null`: `foundation`, `component`, `priority`, `address`, `protocol`, `port`, `type`, `tcpType`, `relatedAddress和relatedPort`。 41 | 42 | 4. Set the candidate, sdpMid, sdpMLineIndex, usernameFragment attributes of iceCandidate with the corresponding dictionary member values of candidateInitDict. 43 | zh:使用candidateInitDict的相应字典成员值设置iceCandidate的候选者，sdpMid，sdpMLineIndex，usernameFragment属性。 44 | 45 | 5. 将候选人设置为 `candidateInitDict`的`candidate`成员。如果设置的候选者不是空字符串，请运行以下步骤： 46 | 47 | 1. 使用候选属性语法解析候选者。 48 | 49 | 2. 如果候选属性语法解析失败，则中止这些步骤。 50 | 51 | 3. 如果解析结果中的任何字段表示iceCandidate中相应属性的无效值，则中止这些步骤。 52 | 53 | 4. 将 `iceCandidate` 中的相应属性设置为已解析结果的字段值。 54 | 55 | 6. 返回`iceCandidate`。 56 | 57 | 58 | NOTE：`RTCIceCandidate`的构造函数仅对 `candidateInitDict` 中的字典成员进行基本解析和类型检查。在将RTCIceCandidate对象传递给 addIceCandidate() 时，会完成 `candidate`, `sdpMid`, `sdpMLineIndex`, `usernameFragment` 以及相应会话描述的良构性的详细验证。 59 | 60 | 属性 61 | 62 | 以下大多数属性在[ICE]的第15.1节中定义。 63 | 64 | `candidate` 的类型为 `DOMString` 只读项 65 | 66 | `candidate-attribute`在[ICE]第15.1节中有详细说明。如果此`RTCIceCandidate表示候选者结束指示，则候选者是空字符串。 67 | 68 | `sdpMid` 的类型为 `DOMString` 只读项，可为空 69 | 70 | 如果不为`null`，则其包含[RFC5888]中定义的媒体流“标识标签”，用于与该候选者相关联的媒体组件。 71 | 72 | `sdpMLineIndex` 的类型为 `unsigned short` 只读项，可为空 73 | 74 | 如果不为空，则这指示该候选与之关联的SDP中的媒体描述的索引（从零开始）。 75 | 76 | `foundation` 的类型为 `DOMString` 只读项，可为空 77 | zh:DOMString类型的基础，只读，可空 78 | 79 | 一个唯一标识符，允许ICE关联出现在多个 RTCIceTransports 上的候选项。 80 | 81 | `component`的类型为 `RTCIceComponent` 只读，可为空 82 | 83 | 候选人指定的网络组件（rtp或rtcp）。这对应于 `candidate-attribute` 中的 `component-id` 字段，解码为 `RTCIceComponent` 中定义的字符串表示。 84 | 85 | `priority`的类型为 `unsigned long` 只读，可为空 86 | 87 | 候选人指定的优先顺序。 88 | 89 | `address`的类型为 `DOMString` 只读，可为空 90 | 91 | 候选的地址，允许IPv4地址，IPv6地址和完全限定的域名（FQDN）。这对应于候选属性中的连接地址字段。 92 | 93 | >NOTE：通过ICE收集并在RTCIceCandidate实例中对应用程序进行访问的候选者中公开的地址可以揭示有关设备和用户的更多信息（例如，位置，本地网络拓扑），而不是用户在非WebRTC启用的浏览器中可能预期的信息。 94 | > 95 | > 这些地址始终暴露给应用程序，并且可能暴露给通信方，并且可以在没有任何特定用户同意的情况下暴露（例如，用于与数据信道一起使用的对等连接，或仅用于接收媒体）。 96 | > 97 | > 98 | >这些地址也可以用作临时或持久的跨源状态，因此有助于设备的指纹表面。 99 | > 100 | > 101 | >应用程序可以通过强制ICE代理仅通过RTCConfiguration的iceTransportPolicy成员报告中继候选者来避免暂时或永久地向通信方公开地址。 102 | > 103 | 104 | > 105 | >为了限制暴露给应用程序本身的地址，浏览器可以为其用户提供有关共享本地地址的不同策略，如[RTCWEB-IP-HANDLING]中所定义。 106 | 107 | `protocol` 的类型为 `RTCIceProtocol`，只读项，可为空 108 | 109 | 候选协议可以为udp和tcp。对应于候选属性中的传输字段。 110 | 111 | `port`的类型为 `unsigned short`，只读项，可为空 112 | 113 | 候选人的端口。 114 | 115 | `type`的类型为 `RTCIceCandidateType`，只读项，可为空 116 | 117 | 候选人的类型。对应于候选属性中的传输字段。 118 | 119 | `tcpType`的类型为 `RTCIceTcpCandidateType` ，只读项，可为空 120 | 121 | 如果 protocol 是 tcp ，则 tcpType 表示 TCP 候选的类型。否则，tcpType为null。这对应于candidate-attribute中的tcp-type字段。 122 | 123 | `relatedAddress` 的类型为`DOMString`，只读项，可为空 124 | 125 | 对于从另一个派生的候选者（例如中继或自反候选者），relatedAddress是从其派生的候选者的IP地址。对于主机候选者，relatedAddress为空。这对应于 candidate-attribute 中的 rel-address 字段。 126 | 127 | `relatedPort`的类型为`unsigned short`，只读项，可为空 128 | 129 | 对于从另一个派生的候选者（例如中继或反身候选者），`relatedPort` 是从其派生的候选者的端口。对于候选主机， `relatedPort` 为空。这对应于candidate-attribute中的rel-port字段。 130 | 131 | `usernameFragment` 的类型为`DOMString`，只读项，可为空 132 | 详细描述参照[ICE]第15.4节中定义的ufrag。 133 | 134 | **方法** 135 | 136 | `toJSON()` 137 | toJSON() 138 | 139 | 140 | 141 | 1. 把json成为一个新的RTCIceCandidateInit字典。 142 | 143 | 2. 要调用RTCIceCandidate接口的toJSON()操作，请运行以下步骤：让json成为新的RTCIceCandidateInit字典。对于«“候选者”，“sdpMid”，“sdpMLineIndex”，“usernameFragment”中的每个属性标识符attr»: 144 | 145 | 1. 在给定此RTCIceCandidate对象的情况下，将value设置为获取由attr标识的属性的基础值的结果。 146 | 147 | 2. 将json [attr]设置为value。 148 | 149 | 3. 返回json。 150 | 151 | ``` 152 | dictionary RTCIceCandidateInit { 153 | DOMString candidate = ""; 154 | DOMString? sdpMid = null; 155 | unsigned short? sdpMLineIndex = null; 156 | DOMString usernameFragment; 157 | }; 158 | ``` 159 | 160 | **字典RTCIceCandidateInit成员** 161 | 162 | `candidate` of type DOMString, defaulting to "": 163 | 详细描述参照[ICE]第15.1节中定义的候选属性。如果这表示`candidate`结束指示，则`candidate`是空字符串。 164 | 165 | `sdpMid` 的类型为 `DOMString`, 可为空，默认为null 166 | 如果不为空，则其包含[RFC5888]中定义的媒体流“标识标签”，用于与该`candidate`相关联的媒体组件。 167 | 168 | `sdpMLineIndex` 的类型为 `unsigned short`, 可为空，默认为空 169 | 如果不为空，则这指示该候选与之关联的SDP中的媒体描述的索引（从零开始）。 170 | 171 | `usernameFragment` 的类型为 `DOMString` 只读，可为空 172 | 详细描述参照[ICE]第15.4节中有`ufrag`的定义。 173 | 174 | -------------------------------------------------------------------------------- /resource/chapter11/11_1_RTCError接口.md: -------------------------------------------------------------------------------- 1 | # 11 错误处理 2 | 3 | 某些操作抛出或引起`RTCError`。这是`DOMException`的扩展，包含了额外的WebRTC信息。 4 | 5 | ## 11.1 `RTCError`接口 6 | 7 | ```java 8 | [ 9 | Exposed=Window, 10 | Constructor(RTCErrorInit init, optional DOMString message = "") 11 | ] interface RTCError /*: DOMException*/ { 12 | readonly attribute RTCErrorDetailType errorDetail; 13 | readonly attribute long? sdpLineNumber; 14 | readonly attribute long? httpRequestStatusCode; 15 | readonly attribute long? sctpCauseCode; 16 | readonly attribute unsigned long? receivedAlert; 17 | readonly attribute unsigned long? sentAlert; 18 | }; 19 | ``` 20 | 21 | ### 11.1.1 构造函数 22 | 23 | `RTCError` 24 | 25 | 运行下列步骤： 26 | 27 | 1. 让init成为构造函数的第一个参数。 28 | 29 | 2. 让message成为构造函数的第二个参数。 30 | 31 | 3. 让e成为新的`RTCError`对象。 32 | 33 | 4. 将`message`参数设置为message，`name`参数设置为`“RTCError”`，触发e的`DOMException`构造函数。 34 | 35 | > NOTE:这个name不具有对legacy的映射，因此e的`code`属性返回0。 36 | 37 | 5. 设置e的所有`RTCError`属性为init中的对应属性的值，如果存在，否则设置为`null`。[测试：1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCError.html) 38 | 39 | 6. 返回e。 40 | 41 | ### 11.1.2 属性 42 | 43 | RTCErrorDetailType类型的`errorDetail`，只读：针对出现错误类型的WebRTC特定错误代码。 44 | 45 | [测试：2](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCPeerConnection-setRemoteDescription-offer.html) 46 | 47 | [测试：2](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCError.html) 48 | 49 | long类型的`sdpLineNumber`,只读，可以为null：如果`errorDetail`为`“sdp-syntax-error”`,这是错误被检测到的行号(第一行行号为1)。 50 | 51 | long类型的`httpRequestStatusCode`,只读，可以为null：如果`errorDetail`为`“idp-load-failure”`，这是IdP URI回应的HTTP状态码。 52 | 53 | long类型的`sctpCauseCode`,只读，可以为null：如果`errorDetail`是`“actp-failure”`，这是SCTP协商失败的SCTP原因代码。 54 | 55 | unsigned long类型的`receiveAlert`,只读，可以为null：如果`errorDetail`是`“dtls-failure”，并且接收到致命的DTLS警报，这是接收到的DTLS警报的值。` 56 | 57 | unsigned long类型的`sentAlert`，只读，可以为null：如果`errorDetail`是`"dtls-failure"，并且发送了`致命的DTLS警报，这是发送的DTLS警报值。 58 | 59 | **RTCErrorInit字典** 60 | 61 | ```java 62 | dictionary RTCErrorInit { 63 | required RTCErrorDetailType errorDetail; 64 | long sdpLineNumber; 65 | long httpRequestStatusCode; 66 | long sctpCauseCode; 67 | unsigned long receivedAlert; 68 | unsigned long sentAlert; 69 | }; 70 | ``` 71 | 72 | `RTCErrorInit`的`errorDetail`,`sdpLineNumber`,`httpRequestStatusCode`,`sctpCauseCode`,`receivedAlert`和`sentAlert`成员与`RTCError`的同名属性具有相同的定义。 73 | 74 | ### 11.1.3 字典`RTCError`成员 75 | 76 | RTCErrorDetailType类型的`errorDetail`，必需的：查看`RTCError`的`errorDetail`。 77 | 78 | long类型的`sdpLineNumber`:查看`RTCError`的`sdpLineNumber`。 79 | 80 | long类型的`httpRequestStatusCode`:查看`RTCError`的`httpRequestStatusCode`。 81 | 82 | long类型的`sctpCauseCode`:查看`RTCError`的`sctpCauseCode`。 83 | 84 | unsigned long类型的`receivedAlert`:查看`RTCError`的`receivedAlert`。 85 | 86 | unsigned long类型的`sentAlert`：查看`RTCError`的`sentAlert`。 87 | 88 | ### 11.1.4 `RTCErrorDetailType`枚举 89 | 90 | ```java 91 | enum RTCErrorDetailType { 92 | "data-channel-failure", 93 | "dtls-failure", 94 | "fingerprint-failure", 95 | "idp-bad-script-failure", 96 | "idp-execution-failure", 97 | "idp-load-failure", 98 | "idp-need-login", 99 | "idp-timeout", 100 | "idp-tls-failure", 101 | "idp-token-expired", 102 | "idp-token-invalid", 103 | "sctp-failure", 104 | "sdp-syntax-error", 105 | "hardware-encoder-not-available", 106 | "hardware-encoder-error" 107 | }; 108 | ``` 109 | 110 | 名称以“idp”为前缀的错误详细信息类型由[WEBRTC-IDENTIFY]规范使用。这里描述了它们，因为WebIDL枚举必须只能在一个地方描述。 111 | 112 | | 枚举描述 | | 113 | | ------------------------------------------------------------ | ------------------------------------------------------------ | 114 | | `data-channel-failure` | 数据通道已经失败。 | 115 | | `dtls-failure` | DTLS协商已经失败，或者连接由于致命错误被中断。`message`包含关于error的信息。如果接收到致命DTLS警报，`receivedAlert`属性被设置为接收到的DTLS警报。如果发送了致命TLS警报，`sentAlert`属性被设置为发送的DTLS警报的值。 | 116 | | `fingerprint-failure` | `RTCDtlsTransport`的远程证书与SDP提供的指纹不匹配。如果远程对等体不能将本地证书与提供的指纹匹配，则不会生成此错误。可能会从远程对等体接收到一个"bad-certificate" DTLS警报，这会导致“dtls-failure”。 | 117 | | `idp-bad-script-failure` | 从身份提供方加载的脚本不是有效的JavaScript或没有实现正确的接口。 | 118 | | `idp-execution-failure` | 身份提供方抛出异常或返回了rejected的承诺。 | 119 | | `idp-load-failure` | Idp URI的加载已经失败。`httpRequestStatusCode`属性被设置为回应的HTTP状态码。 | 120 | | `idp-need-login` | 身份提供方需要用户登录。`idpLoginUrl`属性被设置为可以被用来登录的URL。 | 121 | | `idp-timeout` | Idp timer已经失效。 | 122 | | `idp-tls-failure` | 用户Idp HTTPS连接的TLS证书不受信任。 | 123 | | `idp-token-expired` | Idp token已经失效。 | 124 | | `idp-token-invalid` | Idp token是无效的。 | 125 | | `sctp-failure` | SCTP协商已经失败，或者连接由于致命错误而被终止。`sctpCauseCode`属性被设置为SCTP原因码。 | 126 | | `sdp-syntax-error`[测试:1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCPeerConnection-setRemoteDescription-offer.html) | SDP语法无效。`sdpLineNumber`属性被设置为SDP中检测到语法错误的行号。 | 127 | | `hardware-encoder-not-available` | 请求的操作所需的硬件编码器资源不可用。 | 128 | | `hardware-encoder-error` | 硬件编码器不支持提供的参数。 | 129 | 130 | -------------------------------------------------------------------------------- /resource/chapter5/5_6 RTCIceTransport接口.md: -------------------------------------------------------------------------------- 1 | ## [5.6 `RTCIceTransport`接口](http://w3c.github.io/webrtc-pc/#rtcicetransport) 2 | 3 | `RTCIceTransport`接口允许应用程序获取有关用来发送接收数据包的ICE传输的信息。特别的，ICE管理对等连接，它牵涉到应用程序可能获取的状态。由于需要调用`setLocalDescription()`和`setRemoteDescription()`,`RTCIceTransport`对象被创建。底层ICE状态由ICE代理管理，所以当ICE代理向用户代理提供指示时，`RTCIceTransport`的状态就会改变。每个`RTCIceTransport`对象代表一个特定`RTCRtpTransceiver`的RTP或RTCP组件的ICE传输层，或者是一组已经通过[BUNDLE]协商的`RTCRtpTransceiver`。 4 | 5 | > NOTE:现存`RTCRtpTranceiver`的ICE重启将会由现存`RTCIceTransport`对象表示，它的状态将会被对应更新，而不是由新对象表示。 6 | 7 | 当ICE代理表示它将为一个`RTCIceTransport`收集一系列的候选者时，用户代理必须对运行以下步骤的任务进行排序: 8 | 9 | 1. 让connection成为与这个ICE代理关联的`RTCPeerConnection`对象。 10 | 2. 如果connection的[[IsClosed]]插槽为`true`，中断这些步骤。 11 | 3. 让transport成为RTCIceTransport。 12 | 4. 设置transport的[[IceGathererState]]插槽为`gathering`。 13 | 5. 在transport发起一个名为`gatheringstatechange`的事件。 14 | 6. 更新connection的ICE收集状态。 15 | 16 | 当ICE代理表示它已经成功收集了一个`RTCIceTransport`的一系列候选者时，用户代理必须对运行以下步骤的任务进行排序： 17 | 18 | 1. 让connection成为与ICE代理关联的`RTCPeerConnection`对象。 19 | 20 | 2. 如果connection的[[IsClosed]]插槽为`true`，中断这些步骤。 21 | 22 | 3. 让transport成为`RTCIceTransport`。 23 | 24 | 4. 让`newCandidate`成为创建一个RTCIceCandidate的结果，伴随一个新字典，它的`sdpMid`和`sdpMLineIndex`都被设置为与此`RTCIceTransport`相关联的值，`usernameFrangment`被设置为收集完成的candidates的用户名片段，`candidate`被设置为空字符串。 25 | 26 | 5. 使用`RTCPeerConnectionIceEvent`接口发起一个名为`icecandidate`的事件，并且candidate属性在connection被设置为`newCandidate`。 27 | 28 | 6. 如果另一代candidates还在被收集，中断这些步骤。 29 | 30 | > NOTE:这可能会出现，如果在ICE代理还在收集上一代的candidates时，开始ICE重启，可能会发生这种情况。 31 | 32 | 7. 设置transport的[[IceGathererState]]插槽为complete。 33 | 34 | 8. 在transport发起一个名为`gatheringstatechange`的事件。 35 | 36 | 9. 更新connection的ICE收集状态。 37 | 38 | 当用户代理表示新的ICE candidate可用于`RTCIceTransport`，或者从ICE候选者池中选择一个，或者从头开始收集它，用户代理必须对运行以下步骤的任务进行排序： 39 | 40 | 1. 让`candidate`成为可用的ICE候选者。 41 | 2. 让connection成为与这个ICE代理相关联的`RTCPeerConnection`对象。 42 | 3. 如果connection的[[IsClosed]]插槽为`true`，中断这些步骤。 43 | 4. 让transport成为可供候选者使用的`RTCIceTransport`。 44 | 5. 如果connection.[[PendingLocalDescription]]不是`null`，并且表示收集候选者的ICE generation，向connection.[[PendingLocalDesciption]].sdp中添加候选者。 45 | 6. 如果connection.[[CurrentLocalDescription]]不是`null`，并且表示收集候选者的ICE generation，向connection.[[CurrentLocalDescription]].sdp中添加候选者。 46 | 7. 让`newCandidate`成为创建一个RTCIceCandidate的结果，伴随一个新字典，它的`sdpMid`和`sdpMLineIndex`都被设置为与此`RTCIceTransport`相关联的值，`usernameFrangment`被设置为候选者的用户名片段，并且`candidate`被设置为使用`candidate-attribute`语法编码的字符串来代表`candidate`。 47 | 8. 将`newCandidate`添加到transport的本地候选者集合中。 48 | 9. 使用`RTCPeerConnectionIceEvent`接口发起一个名为`icecandidate`的事件，并且候选者属性在`connection`被设置为`newCandidate`。 49 | 50 | 当ICE代理表示`RTCIceTransport`的`RTCIceTransportState`已经改变时，用户代理必须对运行以下步骤的任务进行排序: 51 | 52 | 1. 让`connection`成为与这个ICE代理相关联的`RTCPeerConnection`对象。 53 | 2. 如果`connection`的[[IsClosed]]插槽为`true`，中断这些步骤。 54 | 3. 让`transport`成为状态正在改变的`RTCIceTransport`。 55 | 4. 让`newState`成为新的被指示的`RTCIceTransportState`。 56 | 5. 设置`transport`的[[IceTransportState]]插槽为`newState`。 57 | 6. 在`transport`发起一个名为`statechange`的事件。 58 | 7. 更新`connection`的ICE连接状态。 59 | 8. 更新`connection`的连接状态。 60 | 61 | 当ICE代理表示选定的一对`RTCIceTransport`候选者已经改变时，用户代理必须对运行以下步骤的任务进行排序： 62 | 63 | 1. 让`connection`成为与这个ICE代理相关联的`RTCPeerConnection`对象。 64 | 2. 如果`connection`的[[IsClosed]]插槽为`true`，中断这些步骤。 65 | 3. 让`transport`成为选定候选者对正在改变的`RTCIceTransport`。 66 | 4. 让`newCandidatePair`成为新常见的`RTCIceCandidatePair`，如果选定了一个，表示选择正确，否则为null。 67 | 5. 设置`transport`的[[SelectedCandidatePair]]插槽为`newCandidatePair`。 68 | 6. 在`transport`发起一个名为`selectedcandidatepairchange`的事件。 69 | 70 | 一个`RTCIceTransport`对象具有下列内部插槽： 71 | 72 | - [[IceTransportState]]初始化为`new` 73 | - [[IceGathererState]]初始化为`new` 74 | - [[SelectedCandidatePair]]初始化为`null` 75 | 76 | ```java 77 | [Exposed=Window] interface RTCIceTransport : EventTarget { 78 | readonly attribute RTCIceRole role; 79 | readonly attribute RTCIceComponent component; 80 | readonly attribute RTCIceTransportState state; 81 | readonly attribute RTCIceGathererState gatheringState; 82 | sequence getLocalCandidates (); 83 | sequence getRemoteCandidates (); 84 | RTCIceCandidatePair? getSelectedCandidatePair (); 85 | RTCIceParameters? getLocalParameters (); 86 | RTCIceParameters? getRemoteParameters (); 87 | attribute EventHandler onstatechange; 88 | attribute EventHandler ongatheringstatechange; 89 | attribute EventHandler onselectedcandidatepairchange; 90 | }; 91 | ``` 92 | 93 | 94 | 95 | **属性** 96 | 97 | `RTCIceRole`类型的`role`，只读：`role`属性必须返回transport的ICE role。 98 | 99 | `RTCIceComponent`类型的`component`，只读：`component`属性必须返回`transport`的ICE组件。当RTCP mux被使用时，单一的`RTCIceTransport`同时传输RTP和RTCP，并且`component`被设置为`RTP`。 100 | 101 | `RTCIceTransportState`类型的`state`，只读：当需要获得`state`属性时，它必须返回[[IceTransportState]]插槽的值。 102 | 103 | `RTCIceGathererState`类型的`gatheringState`，只读：当获取`gathering state`属性时，它必须返回[[IceGathererState]]插槽的值。 104 | 105 | `EventHandler`类型的`onstatechange`:此event handler，当`RTCIceTransportstate`类型改变时，必须启动。 106 | 107 | `EventHandler`类型的`ongatheringstatechange`：此event handler，当`RTCIceTransportgatheringstate`改变时，必须启动。 108 | 109 | `EventHandler`类型的`onselectedcandidatepairchange`：此event handler，当`RTCIceTransport`选定的候选者对改变时，必须启动。 110 | 111 | **方法** 112 | 113 | `getLocalCandidates`:返回一个序列，描述为`RTCIceTransport`收集并在`onicecandidate`中发送的本地候选者。 114 | 115 | `getRemoteCandidates`:返回一个序列，描述通过`addIceCandidate()`，由`RTCIceTransport`接收的ICE候选者。 116 | 117 | > NOTE:`getRemoteCandidates`不会暴露peer reflexive candidates，因为它们不是通过`addIceCandidate()`接收的。 118 | 119 | `getSelectedCandidatePair`:返回用来发送数据包的选定候选者对。此方法必须返回[[SelectedCandidatePair]]插槽的值。 120 | 121 | `getLocalParameters`:返回通过`setLocalDescription`由`RTCIceTransport`接收的本地ICE参数，如果参数未被接收，则为`null`。 122 | 123 | `getRemoteParameters`:返回通过`setRemoteDescription`，由`RTCIceTransport`接收的ICE远程参数，如果参数未被接收，则为`null`。 124 | -------------------------------------------------------------------------------- /contributors.md: -------------------------------------------------------------------------------- 1 | # 《WebRTC 官方文档-中文版》贡献历史 2 | 3 | 4 | | 章节 | 贡献者 | 进度 | 5 | |------|------|------| 6 | |1 介绍| [plutoless](https://github.com/plutoless)|已完成| 7 | |2 一致性|[plutoless](https://github.com/plutoless)|已完成| 8 | |3 术语 | [plutoless](https://github.com/plutoless)|已完成| 9 | |4.1 点对点连接| yusicheng|已完成| 10 | |4.2.1 RTCConfiguration字典 | yusicheng|已完成| 11 | |4.2.2 RTCIceCredentialType 枚举 | yusicheng|已完成| 12 | |4.2.3 RTCOAuthCredential Dictionary| yusicheng|已完成| 13 | |4.2.4 RTCIceServer字典| yusicheng|已完成| 14 | |4.2.5 RTCIceTransportPolicy 枚举| yusicheng|已完成| 15 | |4.2.6 RTCBundlePolicy 枚举| yusicheng|已完成| 16 | |4.2.7 RTCRtcpMuxPolicy 枚举| yusicheng|已完成| 17 | |4.2.8 Offer/answer option 提供、应答选项| yusicheng|已完成| 18 | |4.3.1 RTCSignalingState 枚举| yusicheng|已完成| 19 | |4.3.2 RTCIceGatheringState 枚举| yusicheng|已完成| 20 | |4.3.3 RTCPeerConnectionState 枚举| yusicheng|已完成| 21 | |4.3.4 RTCIceConnectionState 枚举| yusicheng|已完成| 22 | |4.4 RTCPeerConnection 接口| yusicheng|已完成| 23 | |4.4.1 操作| yusicheng|已完成| 24 | |4.4.1.1 构造函数| yusicheng|已完成| 25 | |4.4.1.2 将操作排入队列| yusicheng|已完成| 26 | |4.4.1.3 更新连接状态| yusicheng|已完成| 27 | |4.4.1.4 更新 ICE 收集状态| yusicheng|已完成| 28 | |4.4.1.5 更新 ICE 连接状态| yusicheng|已完成| 29 | |4.4.1.6 设置 RTCSessionDescription| yusicheng|已完成| 30 | |4.4.2 接口定义| yusicheng|审校| 31 | |4.4.3 旧接口扩展| yusicheng|已完成| 32 | |4.4.3.1方法扩展| yusicheng|已完成| 33 | |4.4.3.2 旧版配置扩展| yusicheng|已完成| 34 | |4.4.4 垃圾回收| yusicheng|已完成| 35 | |4.5 错误处理| neo|审校| 36 | |4.6 会话描述类型| neo|审校| 37 | |4.6.2 RTCSessionDescription 类| neo|审校| 38 | |4.7 会话谈判模型| neo|审校| 39 | |4.7.1 Setting Negotiation-Needed zh:4.7.1设置协商需要| neo|审校| 40 | |4.7.2 Clearing Negotiation-Needed| neo|审校| 41 | |4.7.3 Updating the Negotiation-Needed flag| neo|审校| 42 | |4.8 连接建立接口| neo|审校| 43 | |4.8.1.1 候选属性语法| neo|审校| 44 | |4.8.1.2 RTCIceProtocol枚举| neo|审校| 45 | |4.8.1.3 RTCIceTcpCandidateType枚举| neo|审校| 46 | |4.8.1.4 RTCIceCandidateType枚举| neo|审校| 47 | |4.8.2 RTCPeerConnectionIceEvent| neo|审校| 48 | |4.8.3 RTCPeerConnectionIceErrorEvent| neo|审校| 49 | |4.9优先级和QoS模型| maojie|完成| 50 | |4.9.1 RTCPriorityType枚举| maojie|完成| 51 | |5. RTP Media API | Gong|审校| 52 | |5.1 RTCPeerConnection Interface Extensions|[liaojunleon](https://github.com/liaojunleon)|完成| 53 | |5.1.1 Processing Remote MediaStreamTracks|[liaojunleon](https://github.com/liaojunleon)|完成| 54 | |5.2 RTCRtpSender Interface|wsuai1234|审校| 55 | |5.2.1 RTCRtpParameters Dictionary|wsuai1234|审校| 56 | |5.2.2 RTCRtpSendParameters Dictionary|wsuai1234|审校| 57 | |5.2.3 RTCRtpReceiveParameters Dictionary|wsuai1234|审校| 58 | |5.2.4 RTCRtpCodingParameters Dictionary|wsuai1234|审校| 59 | |5.2.5 RTCRtpDecodingParameters Dictionary|wsuai1234|审校| 60 | |5.2.6 RTCRtpEncodingParameters Dictionary|wsuai1234|审校| 61 | |5.2.7 RTCDtxStatus Enum|wsuai1234|审校| 62 | |5.2.8 RTCDegradationPreference Enum|wsuai1234|审校| 63 | |5.2.9 RTCRtcpParameters Dictionary|wsuai1234|审校| 64 | |5.2.10 RTCRtpHeaderExtensionParameters Dictionary|wsuai1234|审校| 65 | |5.2.11 RTCRtpCodecParameters Dictionary|wsuai1234|审校| 66 | |5.2.12 RTCRtpCapabilities Dictionary|wsuai1234|审校| 67 | |5.2.13 RTCRtpCodecCapability Dictionary|wsuai1234|审校| 68 | |5.2.14 RTCRtpHeaderExtensionCapability Dictionary|wsuai1234|审校| 69 | |5.3 RTCRtpReceiver Interface|[arthurwufeng](https://github.com/arthurwufeng)|完成| 70 | |5.4 RTCRtpTransceiver Interface|[arthurwufeng](https://github.com/arthurwufeng)|完成| 71 | |5.4.1 Simulcast functionality|[arthurwufeng](https://github.com/arthurwufeng)|完成| 72 | |5.4.1.1 Encoding Parameter Examples|[arthurwufeng](https://github.com/arthurwufeng)|完成| 73 | |5.4.2 "Hold" functionality|[arthurwufeng](https://github.com/arthurwufeng)|完成| 74 | |5.5 RTCDtlsTransport Interface|[wshuai1234](https://github.com/wshuai1234)|完成| 75 | |5.5.1RTCDtlsFingerprint Dictionary|[wshuai1234](https://github.com/wshuai1234)|完成| 76 | |5.6RTCIceTransport Interface|[wshuai1234](https://github.com/wshuai1234)|完成| 77 | |5.6.1 RTCIceParameters Dictionary|[wshuai1234](https://github.com/wshuai1234)|完成| 78 | |5.6.2 RTCIceCandidatePair Dictionary|[wshuai1234](https://github.com/wshuai1234)|完成| 79 | |5.6.3 RTCIceGathererState Enum|[wshuai1234](https://github.com/wshuai1234)|完成| 80 | |5.6.4 RTCIceTransportState Enum|[wshuai1234](https://github.com/wshuai1234)|完成| 81 | |5.6.5 RTCIceRole Enum|[wshuai1234](https://github.com/wshuai1234)|完成| 82 | |5.6.6 RTCIceComponent Enum|[wshuai1234](https://github.com/wshuai1234)|完成| 83 | |5.7 RTCTrackEvent|[wshuai1234](https://github.com/wshuai1234)|完成| 84 | |6. Peer-to-peer Data API|[wshuai1234](https://github.com/wshuai1234)|完成| 85 | |6.1 RTCPeerConnection Interface Extensions|[wshuai1234](https://github.com/wshuai1234)|完成| 86 | |6.1.1 RTCSctpTransport Interface|[wshuai1234](https://github.com/wshuai1234)|完成| 87 | |6.1.1.1 Create an instance|[wshuai1234](https://github.com/wshuai1234)|完成| 88 | |6.1.1.2 Update max message size|[wshuai1234](https://github.com/wshuai1234)|完成| 89 | |6.1.1.3 Connected procedure|[wshuai1234](https://github.com/wshuai1234)|完成| 90 | |6.1.2 RTCSctpTransportState Enum|[wshuai1234](https://github.com/wshuai1234)|完成| 91 | |6.2 RTCDataChannel|[wshuai1234](https://github.com/wshuai1234)|完成| 92 | |6.3 RTCDataChannelEvent|[wshuai1234](https://github.com/wshuai1234)|完成| 93 | |6.4 Garbage Collection|[wshuai1234](https://github.com/wshuai1234)|完成| 94 | |7. Peer-to-peer DTMF|[wshuai1234](https://github.com/wshuai1234)|完成| 95 | |7.1 RTCRtpSender Interface Extensions|[wshuai1234](https://github.com/wshuai1234)|完成| 96 | |7.2 RTCDTMFSender|[wshuai1234](https://github.com/wshuai1234)|完成| 97 | |7.3 canInsertDTMF algorithm|[wshuai1234](https://github.com/wshuai1234)|完成| 98 | |7.4 RTCDTMFToneChangeEvent|[wshuai1234](https://github.com/wshuai1234)|完成| 99 | |8.1 Statistics Model|[wshuai1234](https://github.com/wshuai1234)|完成| 100 | |8.2 RTCPeerConnection Interface Extensions|[wshuai1234](https://github.com/wshuai1234)|完成| 101 | |8.3 RTCStatsReport Object|[wshuai1234](https://github.com/wshuai1234)|完成| 102 | |8.4 RTCStats Dictionary|[wshuai1234](https://github.com/wshuai1234)|完成| 103 | |8.5 RTCStatsEvent|[wshuai1234](https://github.com/wshuai1234)|完成| 104 | |8.6 The stats selection algorithm|[wshuai1234](https://github.com/wshuai1234)|完成| 105 | |8.7 Mandatory To Implement Stats|[wshuai1234](https://github.com/wshuai1234)|完成| 106 | |8.8 GetStats Example|[wshuai1234](https://github.com/wshuai1234)|完成| 107 | |9.1 Media Stream API Extensions for Network Use|[wshuai1234](https://github.com/wshuai1234)|完成| 108 | |9.2 MediaStream|[wshuai1234](https://github.com/wshuai1234)|完成| 109 | |9.3 MediaStreamTrack|[wshuai1234](https://github.com/wshuai1234)|完成| 110 | |9.3.1 MediaTrackSupportedConstraints, MediaTrackCapabilities, MediaTrackConstraints and MediaTrackSettings|[wshuai1234](https://github.com/wshuai1234)|完成| 111 | |10. 示例和呼叫流程|[wshuai1234](https://github.com/wshuai1234)|完成| 112 | |11、12、13章节|[wshuai1234](https://github.com/wshuai1234)|完成| 113 | -------------------------------------------------------------------------------- /resource/chapter5/5_2 RTCRtpSender 接口.md: -------------------------------------------------------------------------------- 1 | ## 5.2 `RTCRtpSender` Interface 2 | 3 | `RTCRtpSender`接口允许应用程序控制给定`MediaStreamTrack`的编码方式并将其传输到远程对等方。在`RTCRtpSender`对象上调用`setParameters`时，编码会相应更改。 4 | 5 | 要使用`MediaStreamTrack`**创建RTCRtpSender**,跟踪，字符串，种类，`MediaStream`对象列表，流以及可选的`RTCRtpEncodingParameters`对象列表，**sendEncodings**,请运行以下步骤： 6 | 7 | 1. 让sender成为新的`RTCRtpSender`对象。 8 | 2. 让sender具有初始化为track的**[[SenderTrack]]**内部插槽。 9 | 3. 让sender具有初始化为null的**[[SenderTransport]]**内部插槽。 10 | 4. 让sender具有初始化为null的**[[Dtmf]]**内部插槽。 11 | 5. 如果种类是`“audio”`，则创建一个`RTCDTMFSender` **dtmf**并将[[Dtmf]]内部插槽设置为**dtmf**。 12 | 6. 让sender具有初始化为null的**[[SenderRtcpTransport]]**内部插槽。 13 | 7. 让sender具有一个**[[AssociatedMediaStreamsIds]]**内部插槽，表示此发件人要关联的`MediaStream`对象的Id列表。如[JSEP] (第5.2.1节)中所述，当发送方在SDP中表示时，使用`[[AssociatedMediaStreamIds]]`槽。 14 | 8. 设置sender的`[[AssociatedMediaStreamIds]]`为空集合。 15 | 9. 对于stream中的所有流，如果不存在则向`[[AssociatedMediaStreamIds]]`添加stream.id。 16 | 10. 让sender具有**[[SendEncodings]]**内部插槽，表示`RTCRtpEncodingParameters`字典列表。 17 | 11. 如果sendEncodings作为算法输入，并且非空，设置[[SendEncodings]]插槽为sendEncodings。否则，设置它为一个列表，包含单一`RTCRtpEncodingParameters`，并且`active`设置为`true`。 18 | 12. 让sender具有**[[SendCodecs]]**内部插槽，表示`RTCRtpCodecParameters`字典列表，并且初始化为空列表。 19 | 13. 让sender具有**[[LastReturnedParameters]]**内部插槽，它被用来匹配`getParameters`和`setParameters`操作。 20 | 14. 返回sender。 21 | 22 | ```java 23 | [Exposed=Window] interface RTCRtpSender { 24 | readonly attribute MediaStreamTrack? track; 25 | readonly attribute RTCDtlsTransport? transport; 26 | readonly attribute RTCDtlsTransport? rtcpTransport; 27 | static RTCRtpCapabilities? getCapabilities (DOMString kind); 28 | Promise setParameters (RTCRtpSendParameters parameters); 29 | RTCRtpSendParameters getParameters (); 30 | Promise replaceTrack (MediaStreamTrack? withTrack); 31 | void setStreams(MediaStream... streams); 32 | Promise getStats(); 33 | }; 34 | 35 | 36 | ``` 37 | 38 | **属性** 39 | 40 | MediaStreamTrack类型的``track``，只读，可以为null： 41 | 42 | `track`属性是与此`RTCRtpSender`对象关联的轨道。如果`track`结束，或者输出被禁用，即track被禁用和/或静音，则`RTCRtpSender`必须发送静音(音频)，黑帧(视频)，或零信息内容等效物。在视频的情况下，`RTCRtpSender`应该每秒发送一个黑帧。如果`track`为null，则`RTCRtpSender`不发送。获取时，属性必须返回[[SenderTrack]]插槽的值。 43 | 44 | `RTCDtlsTransport`类型的`transport`，只读，可以为null： 45 | 46 | `transport`属性是一个传输，在此之上来自`track`的媒体通过RTP数据包的形式被发送。在`RTCDtlsTransport`对象构造之前，`transport`属性将会为null。当使用了绑定，多个`RTCRtpSender`对象共享一个`transport`并且都会在相同的传输上发送RTP和RTCP。 47 | 48 | 获取时，属性必须返回[[SenderTransport]]插槽的值。 49 | 50 | `RTCDtlsTransport`类型的`rtcpTransport`，只读，可以为null: 51 | 52 | `rtcpTransport`属性是一个传输，在此之上RTCP被发送和接收。在`RTCDtlsTransport`对象构造之前，`rtcpTransport`属性将会是null。当多路RTCP复用时，`rtcpTransport`将会为null，并且RTP和RTCP流都会进入`transport`描述的传输。 53 | 54 | 获取时，属性必须返回[[SenderRtcpTransport]]插槽的值。 55 | 56 | **方法** 57 | 58 | `getCapabilities`, static 59 | 60 | `getCapabilities()`方法返回用于发送指定媒体的系统功能的最优化视图。它不会保存任何资源，端口，或者其它状态，但旨在提供一种方法来发现浏览器的功能类型，包括可能支持的编解码器。用户代理必须支持`"audio"`和`"video"`的类型值。如果系统没有与此类型参数值对应的功能，`getCapabilities`返回`null`。 61 | 62 | 这些功能通常在设备上提供持久的跨源信息，从而增加了应用程序的指纹表面。在隐私敏感的上下文中，浏览器可能考虑缓解，例如仅报告功能的公共子集。 63 | 64 | `setParameters` 65 | 66 | `setParameters`方法更新`track`如何编码并传输到远程对等端。 67 | 68 | 当调用`setParameters`方法时，用户代理必须运行以下步骤： 69 | 70 | 1. 让parameters成为方法的第一个参数。 71 | 2. 让sender成为调用`setParameters`的`RTCRtpSender`对象。 72 | 3. 让transceiver成为与sender关联的`RTCRtpTransceiver`对象、 73 | 4. 如果transceiver的[[Stopped]]插槽为`true`，返回一个promise，reject为一个新创建的`InvalidStateError`。 74 | 5. 如果sender的[[LastReturnedParameters]]内部插槽为`null`，返回一个promise，reject为新创建的`InvalidStateError`。 75 | 6. 通过以下步骤验证parameter： 76 | 1. 让encodings为`parameters.encodings`。 77 | 2. 让codecs为`parameters.codecs`。 78 | 3. 让N为存储在sender的内部插槽[[SendEncodings]]中的`RTCRtpEncodingParameters`数量。 79 | 4. 如果符合以下条件任意之一，返回一个promise，reject为新创建的`InvalidModificationError`: 80 | 1. `encodings.length`与N不同。 81 | 2. encodings已经被重新排序。 82 | 3. parameters中的任何参数被标记为只读参数(例如RID)，并且具有与相应sender的[[LastReturnedParameters]]内部插槽不同的值。注意这对transactionId同样有效。 83 | 5. 验证encodings中的每个`scaleResolutionDownBy`值大于等于1.0。如果任意一个值不满足条件，返回一个promise，reject为新创建的`RangeError`。 84 | 6. 验证encodings中的每个`maxFramerate`值大于等于0.0。如果其中一个值不满足条件，返回一个承诺，reject为新创建的`RangeError`。 85 | 7. 让p成为一个新的promise。 86 | 8. 同时，配置媒体栈来使用parameters传输sender的[[SenderTrack]]。 87 | 1. 如果使用parameters成功配置了媒体栈，对任务进行排序，允许下列步骤： 88 | 1. 让sender的内部[[LastReturnedParameters]]插槽为null。 89 | 2. 让sender的内部[[SendEncodings]]插槽为`parameters.encodings`。 90 | 3. 解析p为undefined。 91 | 2. 如果配置媒体栈的时候出现了error，排序任务运行以下步骤： 92 | 1. 如果由于硬件资源不可用引发error，reject p为新创建的`RTCError`,它的`errorDetail`被设置为"硬件编码器不可用"，并且中断这些步骤。 93 | 2. 如果由于硬件编码器不支持parameters引发error，reject p为新创建的`RTCError`,它的`errorDetail`被设置为"硬件编码器错误"并且中断这些步骤。 94 | 3. 其它错误，reject p为新创建的`OperationError`。 95 | 9. 返回p。 96 | 97 | `setParameters`不会导致SDP重新协商，只能被用于更改媒体栈在由Offer/Answer协商的信封中发送或接收的内容。`RTCRtpSendParameters`字典中的属性旨在不启用此属性，因此像`cname`之类无法更改的属性是只读的。另外，像比特率，由`maxBitrate`之类的界限控制，此处用户代理需要确保没有超出`maxBitrate`指定的最大比特率，同时确保它满足其它例如SDP的地方指定的对比特率的限制。 98 | 99 | `getParameters` 100 | 101 | `getParameters()`方法返回`RTCRtpSender`对象当前参数，此参数表示`track`是如何编码并传输到远程`RTCRtpReceiver`。 102 | 103 | 当调用`getParameters`时，`RTCRtpSendParameters`字典构造如下： 104 | 105 | - `transactionId`被设置为新的独特Id,被用来将此次`getParameters`调用与将来可能会出现的`setParameters`调用匹配。 106 | - `encodings`被设置为[[SendEncodings]]内部插槽的值。 107 | - `headerExtensions`序列根据已协商发送的标头扩展名进行填充。 108 | - `codecs`被设置为[[SendCodecs]]内部插槽的值。 109 | - `rtcp.cname`被设置为关联`RTCPeerConnection`的CNAME。`rtcp.reducedSize`被设置为`true`，如果reduced-size RTCP已经被协商发送，否则为`false`。 110 | - `degradationPreference`被设置为传入`setParameters`的最后一个值，如果`setParameters`还未调用，则设置为默认值"balanced"。 111 | 112 | 返回的`RTCRtpSendParameters`字典必须存入`RTCRtpSender`对象的[[LastReturnedParameters]]内部插槽。 113 | 114 | getParameters可能与setParameters并用，更改参数： 115 | 116 | ```java 117 | async function updateParameters() { 118 | try { 119 | const params = sender.getParameters(); 120 | // ... make changes to parameters 121 | params.encodings[0].active = false; 122 | await sender.setParameters(params); 123 | } catch (err) { 124 | console.error(err); 125 | } 126 | } 127 | ``` 128 | 129 | 在对`setParameters`的完全调用后，后续对`getParameters`调用将会返回修改后的参数集合。 130 | 131 | `replaceTrack` 132 | 133 | 试图将`RTCRtpSender`当前的`track`替换为指定的track，而不需要重新协商。 134 | 135 | 当`replaceTrack`方法被调用时，用户代理必须运行以下步骤： 136 | 137 | 1. 让sender成为`RTCRtpSender`对象，并在此对象上调用`replaceTrack`。 138 | 2. 让transceiver成为与sender关联的`RTCRtpTransceiver`对象。 139 | 3. 让connection成为与sender关联的`RTCPeerConnection`对象。 140 | 4. 让withTrack成为方法参数。 141 | 5. 如果`withTrack`不为null，并且`withTrack.kind`与transceiver的transceiver类别不同，返回一个promise，reject为新创建的`TypeError`. 142 | 6. 返回将下列步骤加入connection的运行队列之后的结果： 143 | 1. 如果transceiver的[[Stopped]]插槽为true，返回一个promise，reject为新创建的`InvalidStateError`。 144 | 2. 让p成为新的promise。 145 | 3. 让sending为`true`，如果transceiver的[[CurrentDirection]]是`"sendrecv"`或`"sendonly"`，否则为`false`。 146 | 4. 并行运行以下步骤： 147 | 1. 如果sending为`true`，并且withTrack为`null`，使sender停止发送。 148 | 2. 如果sending为`true`，withTrack不为`null`，确定withTrack是否可以由发送方立即发送而不违反发送方协商好的信封，如果不能，则reject p为新创建的`InvalidModificationError`，并中断这些步骤。 149 | 3. 如果sending为`true`，withTrack不为`null`，让发送方无缝切换到传输withTrack，而不是sender现存的track。 150 | 4. 对任务进行排序，运行以下步骤： 151 | 1. 如果connection的[[IsClosed]]插槽为`true`，中断下列步骤。 152 | 2. 设置sender的`track`属性为withTrack。 153 | 3. 用`undefined`解析p。 154 | 5. 返回p。 155 | 156 | > NOTE:改变尺寸和/或帧率可能不需要协商。可能需要协商的情形包括: 157 | > 158 | > 1. 将分辨率改为超出协商好的imageattr边界的值，如[RFC6236]中所述。 159 | > 2. 将帧率改为导致编码器block rate超出的值。 160 | > 3. 视频轨道与原始格式和预编码格式不同。 161 | > 4. 音轨具有不同数量的通道数。 162 | > 5. 同样编码的源(通常是硬件编码器)可能无法生成协商的编解码器；类似的，软件源可能不会实现为编码源协商的编解码器。 163 | 164 | `setStreams` 165 | 166 | 设置`MediaStreams`与sender的track相关联。 167 | 168 | 当`setStreams`方法被调用后，用户代理必须运行以下步骤： 169 | 170 | 1. 让sender成为调用方法的`RTCRtpSender`对象。 171 | 2. 让connection成为调用方法的`RTCPeerConnection`对象。 172 | 3. 如果connection的[[IsClosed]]插槽为`true`，抛出`InvalidStateError`。 173 | 4. 让streams成为通过方法参数构建的MediaStream对象列表，如果方法没有传入参数被调用，则设置为空列表。 174 | 5. 设置sender的[[AssociatedMediaStreamIds]]为空集合。 175 | 6. 对于streams中的流，如果未存在则向[[AssocaitedMediaStreamIds]]中添加stream.id。 176 | 7. 更新连接的negotiation-needed 标记。 177 | 178 | `getStats` 179 | 180 | 仅收集发送方的统计信息，并异步报告结果。 181 | 182 | 当调用`getStats()`后，用户代理必须运行以下步骤： 183 | 184 | 1. 让selector成为调用方法的`RTCRtpSender`对象。 185 | 2. 让p成为新的promise，并行运行以下步骤： 186 | 1. 根据统计选择算法收集selector指定的统计信息。 187 | 2. 使用`RTCStatsReport`对象解析p，包含收集到的统计信息。 188 | 3. 返回p。 189 | 190 | 191 | 192 | -------------------------------------------------------------------------------- /resource/chapter5/5_1 RTCPeerConnection 接口扩展.md: -------------------------------------------------------------------------------- 1 | ## [5.1 RTCPeerConnection Interface Extensions](http://w3c.github.io/webrtc-pc/#rtcpeerconnection-interface-extensions) 2 | 3 | RTP媒体API扩展了RTCPeerConnection接口，如下所述。 4 | 5 | ``` 6 | partial interface RTCPeerConnection { 7 | sequence getSenders (); 8 | sequence getReceivers (); 9 | sequence getTransceivers (); 10 | RTCRtpSender addTrack (MediaStreamTrack track, MediaStream... streams); 11 | void removeTrack (RTCRtpSender sender); 12 | RTCRtpTransceiver addTransceiver ((MediaStreamTrack or DOMString) trackOrKind, optional RTCRtpTransceiverInit init); 13 | attribute EventHandler ontrack; 14 | }; 15 | ``` 16 | 17 | **属性** 18 | 19 | *ontrack* 数据类型为EventHandler: 20 | 21 | 该事件句柄的事件类型是track。 22 | 23 | **方法** 24 | 25 | `getSenders` 26 | 27 | 该方法返回一系列RTCRtpSender对象，这些对象是RTP数据的发送者，从属于未停止的RTCRtpTransceiver对象，并且当前被附加到此RTCPeerConnection中。 28 | 29 | 当调用getSenders方法时，用户代理必须返回执行CollectSenders算法的结果。 30 | 31 | CollectSenders算法定义如下： 32 | 33 | 1. 执行CollectTransceivers算法，结果得到一个收发器序列。 34 | 2. 将发送者序列置为空。 35 | 3. 遍历收发器序列中的每个收发器， 36 | 1. 如果收发器的[[Stopped]]为false，则将该收发器的[[Sender]]添加到发送者序列。 37 | 4. 返回发送者序列。 38 | 39 | `getReceivers` 40 | 41 | 该方法返回一系列RTCRtpReceiver对象，这些对象是RTP数据的接收者，从属于未停止的RTCRtpTransceiver对象，并且当前被附加到此RTCPeerConnection中。 42 | 43 | 当调用getReceivers方法时，用户代理必须运行以下步骤： 44 | 45 | 1. 执行CollectTransceivers算法，结果得到一个收发器序列。 46 | 2. 将接收者序列置为空。 47 | 3. 遍历收发器序列中的每个收发器， 48 | 1. 如果收发器的[[Stopped]]为false，则将该收发器的[[Receiver]]添加到接收者序列。 49 | 4. 返回接收者序列。 50 | 51 | `getTransceivers` 52 | 53 | 该方法返回一系列RTCRtpTransceiver对象，这些对象是RTP数据的收发器，且当前被附加到此RTCPeerConnection中。 54 | 55 | getTransceivers方法必须返回执行CollectTransceivers算法的结果。 56 | 57 | CollectTransceivers算法定义如下： 58 | 59 | 1. 将收发器序列置为空，由该RTCPeerConnection对象收集所有RTCRtpTransceiver对象并插入收发器序列，按插入顺序排列。 60 | 2. 返回收发器序列。 61 | 62 | `addTrack` 63 | 64 | 向RTCPeerConnection添加新轨道，并表明它包含在指定的MediaStream中。 65 | 66 | 当调用addTrack方法时，用户代理必须运行以下步骤： 67 | 68 | 1. 让connection成为调用此方法的RTCPeerConnection对象。 69 | 70 | 2. 让track成为方法第一个参数指示的MediaStreamTrack对象。 71 | 72 | 3. 让kind成为track.kind。 73 | 74 | 4. 剩余参数为MediaStream对象列表，如果使用单个参数调用该方法，则该列表为空。 75 | 76 | 5. 如果connection的slot为true，则抛出InvalidStateError。 77 | 78 | 6. 发送者列表应该是执行CollectSenders算法的结果，如果track中的RTCRtpSender已经存在，则抛出InvalidAccessError。 79 | 80 | 7. 以下步骤描述了如何确定是否可以重用现有发送者对象。这样做可以在将来调用createOffer和createAnswer时能够将相应的media描述标记为sendrecv或sendonly，并添加发送者流的MSID，如[JSEP]（第5.2.2节和第5.3.2节）中所定义。 81 | 82 | 如果发送者序列中的任何RTCRtpSender对象符合以下所有条件，则让该发送者成为可重用的对象，否则为null： 83 | 84 | * 发送者的track为空。 85 | 86 | * 发送者和与其相关联的收发器的kind类型相匹配。 87 | 88 | * 收发器没有停止。更确切地说，与发送者关联的收发器的[[Stopped]]为false。 89 | 90 | * 发送者从未被用来发送。更确切地说，与发送者关联的收发器的[[CurrentDirection]]从未具有sendrecv或sendonly的值。 91 | 92 | 8. 如果发送者不为空，请执行以下步骤以使用该发送者： 93 | 94 | 1. 将发送者设置到track里面。 95 | 96 | 2. 将发送者的[[AssociatedMediaStreamIds]]设置为空集。 97 | 98 | 3. 对于流列表中的每个流，如果stream.id在[[AssociatedMediaStreamIds]]中不存在则将id添加进去。 99 | 100 | 4. 让收发器成为与发送者关联的RTCRtpTransceiver对象。 101 | 102 | 5. 如果收发器的[[Direction]]值是recvonly，请将收发器的[[Direction]]值设置为sendrecv。 103 | 104 | 6. 如果收发器的[[Direction]]为无效值，则将收发器的[[Direction]]设置为sendonly。 105 | 106 | 9. 如果发送者为空，请执行以下步骤： 107 | 108 | 1. 创建一个包含track，kind和streams的发送者。 109 | 110 | 2. 创建一个包含kind的接收器。 111 | 112 | 3. 创建一个包含之前创建的发送者，接收者并且RTCRtpTransceiverDirection值为sendrecv的收发器。 113 | 114 | 4. 将收发器添加到connection的收发器集 115 | 116 | 10. track中可能包含应用程序无法访问的内容。这可能是由于track被标记了peerIdentity选项或任何会使track CORS交叉起源的选项。这些track可以提供给addTrack方法，并为它们创建一个RTCRtpSender对象，但内容绝不能被传输，除非它们也标记为peerIdentity并且它们符合发送要求（参见隔离流）。应用程序无法访问的所有其他tracks不得发送给对端，取而代之的是发送静音（音频），黑帧（视频）或等效的内容。请注意，此属性可能会随时间而变化。 117 | 118 | 11. 更新连接所需的协商标志。 119 | 120 | 12. 返回发送者对象。 121 | 122 | `removeTrack` 123 | 124 | 发送者停止发送媒体数据，但getSenders仍然可以获取RTCRtpSender。这样将来调用createOffer时可以将相应收发器的媒体描述标记为recvonly或inactive，如[JSEP]（第5.2.2节）中所定义。 125 | 126 | 当另一端用这种方式停止发送一个track，这个track将从最初在track事件中显示的任何远端MediaStream中移除，并且如果MediaStreamTrack尚未静音，则在轨道处触发静音事件。 127 | 128 | 当调用removeTrack方法时，用户代理必须执行以下步骤： 129 | 130 | 1. 让sender成为removeTrack的参数。 131 | 132 | 2. 让connection成为调用该方法的RTCPeerConnection对象。 133 | 134 | 3. 如果connection的[[IsClosed]]值为true，则抛出InvalidStateError异常。 135 | 136 | 4. 如果sender不是connection创建的，则抛出InvalidAccessError异常。 137 | 138 | 5. 执行CollectSenders算法返回所有的sender。 139 | 140 | 6. 如果sender不在sender列表中（表示由于设置了“回滚”类型的RTCSessionDescription而将其删除），则中止这些步骤。 141 | 142 | 7. 如果sender的[[SenderTrack]]值为空，则中止这些步骤。 143 | 144 | 8. 将sender的[[SenderTrack]]值设置为null。 145 | 146 | 9. 将收发器设置为与发送者对应的RTCRtpTransceiver对象。 147 | 148 | 10. 如果收发器的[[Direction]]值是sendrecv，请将收发器的[[Direction]]值设置为recvonly。 149 | 150 | 11. 如果收发器的[[Direction]]值是sendonly，则将收发器的[[Direction]]值设置为inactive。 151 | 152 | 12. 更新连接所需的协商标志。 153 | 154 | 155 | `addTransceiver` 156 | 157 | 创建一个新的RTCRtpTransceiver并将其添加到收发器序列。 158 | 159 | 添加一个收发器，则将来调用createOffer会为相应的收发器添加媒体描述，如[JSEP]（第5.2.2节）中所定义。 160 | 161 | mid的初始值为null，设置新的RTCSessionDescription可能会将其更改为非空值，如[JSEP]（第5.5节和第5.6节）中所定义。 162 | 163 | sendEncodings参数可用于指定提供的联播编码的数量，以及可选的RID和编码参数。 164 | 165 | 当调用此方法时，用户代理必须执行以下步骤： 166 | 167 | 1. 让init成为第二个参数。 168 | 169 | 2. 让streams成为init的streams成员。 170 | 171 | 3. 让sendEncodings成为init的sendEncodings成员。 172 | 173 | 4. 让direction成为init的direction成员。 174 | 175 | 5. 如果第一个参数是一个字符串，那就让它成为kind，然后运行以下步骤： 176 | 177 | 1. 如果kind不是合法的MediaStreamTrack类型，则抛出TypeError。 178 | 179 | 2. 将track置为空。 180 | 181 | 6. 如果第一个参数是MediaStreamTrack，那么让它成为track并将kind赋值track.kind。 182 | 183 | 7. 如果connection的[[IsClosed]]值为true，则抛出InvalidStateError异常。 184 | 185 | 8. 通过运行以下步骤验证sendEncodings合法性： 186 | 187 | 1. 验证sendEncodings中的每个rid值仅由字母数字字符（a-z，A-Z，0-9）组成，最多16个字符。如果其中一个RID不满足这些要求，则抛出TypeError异常。 188 | 189 | 2. 如果sendEncodings中的任何RTCRtpEncodingParameters字典包含除rid之外的只读参数，则抛出InvalidAccessError异常。 190 | 191 | 3. 验证sendEncodings中的每个scaleResolutionDownBy值是否大于或等于1.0。如果scaleResolutionDownBy值之一不满足此要求，则抛出RangeError异常。 192 | 193 | 4. 验证sendEncodings中的每个maxFramerate值是否大于或等于0.0。如果其中一个maxFramerate值不满足此要求，则抛出RangeError异常。 194 | 195 | 5. 令maxN为用户代理可以支持的最大同时编码的数量，至少为1.这应该是一个乐观的数字，因为要使用的编解码器还不知道。 196 | 197 | 6. 如果存储在sendEncodings中的RTCRtpEncodingParameters的数量超过maxN，则从尾部修剪sendEncodings直到其长度为maxN。 198 | 199 | 7. 如果现在存储在sendEncodings中的RTCRtpEncodingParameters的数量为1，则从单个条目中删除任何rid成员。 200 | 201 | 注意： 202 | 如果在sendEncodings中只提供单个默认RTCRtpEncodingParameters，则允许应用程序随后使用setParameters方法设置编码参数，即使未使用联播也是如此。 203 | 204 | 9. 创建一个包含track，kind，streams和sendEncodings的RTCRtpSender。 205 | 206 | 如果设置了sendEncodings，则后续调用createOffer时将被配置为发送多个RTP编码，定义在[JSEP]（第5.2.2节和第5.2.1节）。当使用能够接收多个RTP编码，定义在[JSEP]（第3.7节），的相应远程描述调用setRemoteDescription方法时，RTCRtpSender可以发送多个RTP编码，并且通过收发器的sender.getParameters()检索的参数可以反映出来协商的编码格式。 207 | 208 | 10. 创建一个带有kind的RTCRtpReceiver。 209 | 210 | 11. 创建一个带sender，receiver和direction的RTCRtpTransceiver。 211 | 212 | 12. 将收发器添加到connection的收发器序列 213 | 214 | 13. 更新connection所需的协商标志。 215 | 216 | 14. 返回收发器。 217 | 218 | 219 | ``` 220 | dictionary RTCRtpTransceiverInit { 221 | RTCRtpTransceiverDirection direction = "sendrecv"; 222 | sequence streams = []; 223 | sequence sendEncodings = []; 224 | }; 225 | ``` 226 | 227 | **字典 `RTCRtpTransceiverInit` 的参数列表** 228 | 229 | *direction* 类型为RTCRtpTransceiverDirection，默认为“sendrecv” 230 | 231 | 该参数属于RTCRtpTransceiver的成员。 232 | 233 | *streams* 类型为序列 234 | 235 | 当远程PeerConnection的track事件触发与正在添加的RTCRtpReceiver相对应时，这些streams将被放入事件中。 236 | 237 | *sendEncodings* 类型为序列 238 | 239 | 包含用于发送媒体的RTP编码的参数的序列。 240 | 241 | ``` 242 | enum RTCRtpTransceiverDirection { 243 | "sendrecv", 244 | "sendonly", 245 | "recvonly", 246 | "inactive" 247 | }; 248 | ``` 249 | 250 | 251 | 254 | 255 | 256 | 259 | 262 | 263 | 264 | 267 | 270 | 271 | 272 | 275 | 278 | 279 | 280 | 283 | 286 | 287 |
252 | RTCRtpTransceiverDirection 枚举值描述 253 |
257 | sendrecv 258 | 260 | RTCRtpTransceiver的类型为RTCRtpSender的sender将提供去发送RTP，并且如果远程对等方接受并且sender.getParameters().encodings[i].active对于任何i的值为true，则将发送RTP数据。 RTCRtpTransceiver的RTCRtpReceiver将提供去接收RTP，并在对端接受时接收RTP。 261 |
265 | sendonly 266 | 268 | RTCRtpTransceiver的类型为RTCRtpSender的sender将提供去发送RTP，并且如果远程对等方接受并且sender.getParameters().encodings[i].active对于任何i的值为true，则将发送RTP。 RTCRtpTransceiver的RTCRtpReceiver不会提供去接收RTP，也不会接收RTP。 269 |
273 | recvonly 274 | 276 | RTCRtpTransceiver的RTCRtpSender不会提供去发送RTP，也不会发送RTP。 RTCRtpTransceiver的RTCRtpReceiver将提供去接收RTP，并在对端接受时接收RTP。 277 |
281 | inactive 282 | 284 | RTCRtpTransceiver的RTCRtpSender不会提供去发送RTP，也不会发送RTP。 RTCRtpTransceiver的RTCRtpReceiver不会提供去接收RTP，也不会接收RTP。 285 |
288 | 289 | -------------------------------------------------------------------------------- /resource/chapter4/4_4_1_6 设置 RTCSessionDescription.md: -------------------------------------------------------------------------------- 1 | #### [4.4.1.6 设置 RTCSessionDescription](http://w3c.github.io/webrtc-pc/#set-the-rtcsessiondescription) 2 | 3 | 要在 RTCPeerConnection 对象连接上设置 RTCSessionDescription 描述，请将运行以下步骤加入 connection 的操作队列： 4 | 5 | 1. 让 p 成为新的 promise。 6 | 7 | 2. 同时，按照[JSEP]（第5.5节和第5.6节）中的描述，启动应用 description 的流程。 8 | 9 | 1. 如果应用 description 的过程因任何原因失败，则用户代理必须将运行以下步骤的任务加入队列： 10 | 11 | 1. 如果 connection 的[[IsClosed]] 值为true，则中止这些步骤。 12 | 13 | 2. 如果 description 的类型对于当前信令连接状态无效，如[JSEP]（第5.5节和第5.6节）中所述，则使用新创建的 InvalidStateError 错误，p 以拒绝的状态返回这个错误，并中止这些步骤。 14 | 15 | 3. 如果 description 被设置为本地描述，如果 escription.type 是 offer 并且description.sdp 不等于 connection 的[[LastOffer]]，则创建新的 InvalidModificationError 错误，p 以拒绝的状态返回这个错误，并中止这些步骤。 16 | 17 | 4. 如果将 description 设置为本地描述，如果 description.type 为“rollback”且信令状态为“stable”，则创建新的 InvalidStateError 错误，p以拒绝的状态返回这个错误，并中止这些步骤。 18 | 19 | 5. 如果description被设置为本地描述，如果description.type是“answer”或“pranswer”并且description.sdp不等于connection的[[LastAnswer]]，则创建新的 InvalidModificationError 错误，p 以拒绝的状态返回这个错误，并中止这些步骤。 20 | 21 | 6. zh: 如果 description 内容不是有效的SDP语法，则使用 RTCError 拒绝 p（将errorDetail设置为“sdp-syntax-error”并将 sdpLineNumber 属性设置为检测到语法错误的SDP中的行号）并中止这些步骤。 22 | 23 | 7. 如果将 description 设置为远程描述，则连接的 RTCRtcpMuxPolicy 是必需的，远程描述不使用 RTCP mux，然后创建新的 InvalidAccessError 错误，p 以拒绝的状态返回这个错误，并中止这些步骤。 24 | 25 | 8. 如果 description 内容无效，则创建新的 InvalidAccessError 错误，p 以拒绝的状态返回这个错误，并中止这些步骤。 26 | 27 | 9. 对于所有其他错误，创建新的 OperationError 错误，p 以拒绝的状态返回这个错误。 28 | 29 | 2. zh:如果成功应用 description，则用户代理必须对运行以下步骤的任务进行排队： 30 | 31 | 1. 如果connection的[[IsClosed]] 值为true，则中止这些步骤。 32 | 33 | 2. 如果将 description 设置为本地描述，则运行以下步骤之一： 34 | 35 | - 如果 description 是“offer”类型，则将connection的[[PendingLocalDescription]]设置为从 description 构造出的新 RTCSessionDescription 对象，并将信令状态设置为“have-local-offer”。 36 | 37 | - 如果 description 的类型为“answer”，那么这就完成了 offer/answer 协商。将[[CurrentLocalDescription]]连接到从 description 构造的新 RTCSessionDescription 对象，并设置connection的[[PendingRemoteDescription]]为connection的[[CurrentRemoteDescription]]。将connection的[[PendingRemoteDescription]]和connection的[[PendingLocalDescription]]设置为null。最后将连接的信令状态设置为“stable”。 38 | 39 | - 如果 description 是“rollback”类型，那么这是一个回滚。将connection的[[PendingLocalDescription]]设置为null，并将信令状态设置为“stable”。 40 | 41 | - 如果 description 是“pranswer”类型，则将connection的[[PendingLocalDescription]]设置为从 description 构造出的新 RTCSessionDescription 对象，并将信令状态设置为“have-local-pranswer”。 42 | 43 | 3. 否则，如果将 description 设置为远程描述，则运行以下步骤之一： 44 | 45 | - 如果将 description 设置为远程描述，如果description.type为“rollback”且信令状态为“stable”，则使用新创建的InvalidStateError拒绝p并中止这些步骤。 46 | 47 | - 如果 description 是“offer”类型，则将connection的[[PendingRemoteDescription]]属性设置为从 description 构造出的新 RTCSessionDescription 对象，并将信令状态设置为“have-remote-offer”。 48 | 49 | - 如果 description 的类型为“answer”，那么这就完成了 offer/answer 协商。将connection的[[CurrentRemoteDescription]]属性设置为从 description 构造出的新 RTCSessionDescription 对象，并设置connection的[[CurrentLocalDescription]]到connection的[[PendingLocalDescription]]。将connection的[[PendingRemoteDescription]]和connection的[[PendingLocalDescription]]设置为null。最后将连接的信令状态设置为“stable”。 50 | 51 | - 如果 description 是“rollback”类型，那么这是一个回滚。将connection的[[PendingRemoteDescription]]设置为 null，并将信令状态设置为“stable”。 52 | 53 | - 如果 description 是“pranswer”类型，则将connection的[[PendingRemoteDescription]]设置为从 description 构造出的新 RTCSessionDescription 对象。最后将连接的信令状态设置为“have-remote-pranswer”。 54 | 55 | 4. 如果 description 是“answer”类型，并且它启动现有 SCTP 关联的关闭，如[SCTP-SDP]第10.3和10.4节中所定义，则将 connection 的[[SctpTransport]]的值设置为null。 56 | 57 | 5. 如果 description 的类型为“answer”或“pranswer”，则执行以下步骤： 58 | 59 | 1. 如果 description 启动了新 SCTP 关联的建立，如[SCTP-SDP]第10.3和10.4节中所定义，则创建一个初始状态为“connecting”的 RTCSctpTransport ，并将结果分配给[[SctpTransport]]。 60 | 61 | 2. 否则，如果建立了 SCTP 关联，但更新了“max-message-size” SDP 属性，则更新connection的[[SctpTransport]]的最大消息大小。 62 | 63 | 3. 如果 description 协商 SCTP 传输的 DTLS 角色，并且存在具有空 id 的 RTCDataChannel，则根据[RTCWEB-DATA-PROTOCOL]生成ID。如果无法生成可用的ID，请运行以下步骤： 64 | 65 | 1. 设channel为无法生成ID的 RTCDataChannel 对象。 66 | 67 | 2. 将channel的[[ReadyState]]设置为“closed”。 68 | 69 | 3. 使用 RTCErrorEvent 接口触发名为 error 的事件，并在 channel 中将 errorDetail 属性设置为“data-channel-failure”。 70 | 71 | 4. 在 channel 上触发一个名为 close 的事件。 72 | 73 | 6. 让trackEventInits，muteTracks，addList和removeList为空列表。 74 | 75 | 7. 如果将 description 设置为本地描述，则运行以下步骤： 76 | 77 | 1. 对 description 中的每个媒体描述运行以下步骤： 78 | 1. 如果媒体描述尚未与 RTCRtpTransceiver 对象关联，请运行以下步骤： 79 | 80 | 1. 让收发器成为用于创建媒体描述的RTCRtpTransceiver。 81 | 82 | 2. 将收发器的中间值设置为媒体描述的中间值。 83 | 84 | 3. 如果收发器的[[Stopped]]为true，则中止这些子步骤。 85 | 86 | 4. 如果根据[BUNDLE]将媒体描述指示为使用现有媒体传输，则让 transport 和 rtcpTransport 分别为表示该传输的 RTP 和 RTCP 组件的R TCDtlsTransport 对象。 87 | 88 | 5. 否则，让 transport 和 rtcpTransport 成为新创建的 RTCDtlsTransport 对象，每个对象都有一个新的底层 RTCIceTransport。虽然如果根据[RFC5761]协商 RTCP 多路复用，或者如果需要 connection 的RTCRtcpMuxPolicy，则不要创建任何特定于 RTCP 的传输对象，而是让 rtcpTransport 等于传输。 89 | 90 | 6. 设置transceiver.[[Sender]].[[SenderTransport]]进行传输。 91 | 92 | 7. 将transceiver.[[Sender]].[[SenderRtcpTransport]]设置为 rtcpTransport。 93 | 94 | 8. 设置transceiver.[[接收器]].[[ReceiverTransport]]进行传输。 95 | 96 | 9. 将transceiver.[[Receiver]].[[ReceiverRtcpTransport]]设置为 rtcpTransport。 97 | 98 | 2. 让收发器成为与媒体描述相关联的 RTCRtpTransceiver。 99 | 100 | 3. 如果收发器的[[Stopped]]值为true，则中止这些子步骤。 101 | 102 | 4. 设方向是 RTCRtpTransceiverDirection 值，表示媒体描述的方向。 103 | 104 | 5. 如果 direction 是“sendrecv”或“recvonly”，则将收发器的[[Receptive]]值设置为true，否则将其设置为false。 105 | 106 | 6. 如果 description 的类型为“answer”或“pranswer”，则执行以下步骤： 107 | 108 | 1. 如果 direction 是“sendonly”或“inactive”，并且收发器的[[FiredDirection]]值是“sendrecv”或“recvonly”，则执行以下步骤： 109 | 110 | 1. 给收发器设置相关的transceiver.[[Receiver]]，空列表，另一个空列表和removeList。 111 | 112 | 2. 在给定收发器和静音轨道的情况下，处理媒体描述的远程轨道的移除。 113 | 114 | 2. 将收发器的[[CurrentDirection]]和[[FiredDirection]]值设置为方向。 115 | 116 | 8. 如果将 description 设置为远程描述，则运行以下步骤： 117 | 118 | 1. 对 description 中的每个媒体描述运行以下步骤： 119 | 120 | 1. 设方向是 RTCRtpTransceiverDirection 类型的值，表示来自媒体描述的方向，但发送方式和接收方向相反，以表示此对等方的视图。 121 | 122 | 2. 如[JSEP]（第5.10节）所述，尝试查找现有的 RTCRtpTransceiver 对象，收发器，以表示媒体描述。 123 | 124 | 3. 如果未找到合适的收发器（未设置收发器），请执行以下步骤： 125 | 126 | 1. 从媒体描述创建 RTCRtpSender 对象作为 sender。 127 | 128 | 2. 从媒体描述创建RTCRtpReceiver 对象作为 receiver。 129 | 130 | 3. 使用 sender、 receiver 和 值为“recvonly”的 RTCRtpTransceiverDirection 创建一个 RTCRtpTransceiver，并让收发器成为结果。 131 | 132 | 4. 将收发器的中间值设置为相应媒体描述的中间值。如果媒体描述没有 MID，并且未设置收发器的 mid，则生成随机值，如[JSEP]（第5.10节）中所述。 133 | 134 | 5. 如果 direction 是 “sendrecv” 或 “recvonly”，则让 msids 成为媒体描述指示收发器的 MSID 列表。[[Receiver]]。[[ReceiverTrack]]将与之关联。否则，让msids为空列表。 135 | 136 | 6. 给定 transceiver.[[Receiver]]，msids，addList 和 removeList 的相关远程流。 137 | 138 | 7. 如果上一步增加了 addList 的长度，或者收发器的[[FiredDirection]]值既不是 “sendrecv” 也不是 “recvonly”，则在给定收发器和 trackEventInits 的情况下添加媒体描述的远程轨道。 139 | 140 | 8. 如果direction是“sendonly”或“inactive”，则将收发器的[[Receptive]]值设置为 false。 141 | 142 | 9. 如果direction是“sendonly”或“inactive”，并且收发器的[[FiredDirection]]值是“sendrecv”或“recvonly”，则在给定收发器和muteTracks的情况下移除媒体描述的远程轨道。 143 | 144 | 10. 将收发器的[[FiredDirection]]值设置为方向。 145 | 146 | 11. 如果描述的类型为 “answer” 或 “pranswer”，则执行以下步骤： 147 | 148 | 1. 将收发器的[[CurrentDirection]]和[[Direction]]值设置为方向。 149 | 150 | 2. 根据[BUNDLE]，让 transport 和 rtcpTransport 成为 RTCDtlsTransport 对象，表示收发器相关媒体描述所使用的媒体传输的 RTP 和 RTCP 组件。 151 | 152 | 3. 设置收发器.[[Sender]].[[SenderTransport]]进行传输。 153 | 154 | 4. 将收发器.[[Sender]].[[SenderRtcpTransport]]设置为 rtcpTransport。 155 | 156 | 5. 设置收发器.[[接收器]].[[ReceiverTransport]]进行传输。 157 | 158 | 6. 将收发器.[[Receiver]].[[ReceiverRtcpTransport]]设置为rtcpTransport。 159 | 160 | 12. 如果媒体描述被拒绝，并且收发器尚未停止，请停止 RTCRtpTransceiver 收发器。 161 | 162 | 9. 如果 description 是 “rollback” 类型，则运行以下步骤： 163 | 164 | 1. 如果正在回滚的 RTCSessionDescription 将 RTCRtpTransceiver 的中间值设置为非空值，请将该收发器的中间值设置为 null，如[JSEP]（第4.1.8.2节）所述。 165 | 166 | 2. 如果通过应用正在回滚的 RTCSessionDescription 创建了 RTCRtpTransceiver，并且没有通过addTrack将轨道连接到它，则从 connection 的收发器集中删除该收发器，如[JSEP]（第4.1.8.2节）所述。 167 | 168 | 3. 对于保持 connection 的 RTCRtpTransceivers，对正在回滚的 RTCSessionDescription 应用程序所做的[[CurrentDirection]]和[[Receptive]]内部值的任何更改进行还原。 169 | 170 | 4. 将 connection 的[[SctpTransport]]的值恢复为上次稳定信令状态下的值。 171 | 172 | 10. 如果 connection 的信令状态发生变化，则在连接时触发名为 signalingstatechange 的事件。 173 | 174 | 11. 对于 muteTracks 中的每个轨道，将轨道的静音状态设置为值true。 175 | 176 | 12. 对于 removeList 中的每个流和轨道对，从流中删除轨道轨道。 177 | 178 | 13. 对于 addList 中的每个流和轨道对，将轨道轨道添加到流。 179 | 180 | 14. 对于 trackEventInits 中的每个条目，使用 RTCTrackEvent 接口触发名为track的事件，其 receiver 属性初始化为 entry.receiver，其 track 属性初始化为entry.track，其 streams 属性初始化为entry.streams，其 receiver 属性初始化为entry .transceiver 在 connection 对象。 181 | 182 | 15. 如果 connection 的信令状态现在是“stable”，则更新需要协商的标志。如果此更新之前和之后连接的[[NegotiationNeeded]]值均为true，则对运行以下步骤的任务进行排队： 183 | 184 | 1. 如果connection的[[IsClosed]]值为true，则中止这些步骤 185 | 186 | 2. 如果连接的[[NegotiationNeeded]]值为false，则中止这些步骤。 187 | 188 | 3. 在连接时触发名为 negotiationneeded 的事件。 189 | 190 | 16. 将 p 设为值为 undefined 的 Resolve 状态。 191 | 192 | 3. 返回p。 193 | 194 | -------------------------------------------------------------------------------- /resource/chapter6/6_2_RTCDataChannel.md: -------------------------------------------------------------------------------- 1 | ## 6.2 `RTCDataChannel` 2 | 3 | `RTCDataChannel`接口表示两个对等体之间的双向数据信道。 `RTCDataChannel`是通过`RTCPeerConnection`对象上的工厂方法创建的。浏览器之间发送的消息在[RTCWEB-DATA]和[RTCWEB-DATA-PROTOCOL]中描述。 4 | 5 | 有两种方法可以与`RTCDataChannel`建立连接。第一种方法是在其中一个对等体上创建一个`RTCDataChannel`，并且协商的`RTCDataChannelInit`字典成员为未设置或被设置为默认值false。这将在带内公布新通道，并在另一个对等体上触发带有相应`RTCDataChannel`对象的`RTCDataChannelEvent`。第二种方法是让应用程序协商`RTCDataChannel`。为此，创建一个`RTCDataChannel`对象，将协商的`RTCDataChannelInit`字典成员设置为true，并通过带外信号（例如通过Web服务器）向另一方发出信号，它应该创建一个带有协商的`RTCDataChannelInit`字典成员集的相应`RTCDataChannel`，字典成员被设置为true，并且具有相同`id`。这将连接两个单独创建的`RTCDataChannel`对象。第二种方法可以创建具有非对称属性的通道，并通过指定匹配的ID以声明方式创建通道。 6 | 7 | 每个`RTCDataChannel`都有一个关联的底层数据传输，用于将实际数据传输到另一个对等端。在SCTP数据信道利用`RTCSctpTransport`（表示SCTP关联的状态）的情况下，底层数据传输是SCTP流对。底层数据传输的传输属性（例如有序发送设置和可靠性模式）由对等方在创建通道时配置。创建通道后，通道的属性不会更改。对等体之间的实际有线协议由WebRTC DataChannel协议规范[RTCWEB-DATA]指定。 8 | 9 | 可以将`RTCDataChannel`配置为在不同的依赖模式下操作。可靠的信道确保通过重新传输在另一个对等体上传达数据。不可靠信道被配置为限制重传次数（`maxRetransmits`）或设置允许传输（包括重传）的时间（`maxPacketLifeTime`）。这些属性不能同时使用，这样做会导致错误。不设置任何这些属性会得到可靠的通道。 10 | 11 | 使用`createDataChannel`创建或通过`RTCDataChannelEvent`调度的`RTCDataChannel`必须最初处于`connecing`状态。当`RTCDataChannel`对象的底层数据传输准备就绪时，用户代理必须宣布`RTCDataChannel`为open。 12 | 13 | 要创建`RTCDataChannel`，请运行以下步骤: 14 | 15 | 1. 让channel成为新创建的`RTCDataChannel`对象。 16 | 2. 让通道将[[ReadyState]]内部插槽初始化为`“connecting”`。[测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCPeerConnection-ondatachannel.html) 17 | 3. 让通道将[[BufferedAmount]]内部插槽初始化为`0`。 18 | 4. 让通道具有内部插槽，名为[[DataChannelLabel]]，[[Ordered]]，[[MaxPacketLifeTime]]，[[MaxRetransmits]]，[[DataChannelProtocol]]，[[Negotiated]]，[[DataChannelId]]和[ [DataChannelPriority]。 19 | 5. 返回通道。 20 | 21 | 当用户代理宣布`RTCDataChannel`为open时，用户代理必须对任务进行排队,运行以下步骤： 22 | 23 | 1. 如果关联的`RTCPeerConnection`对象的[[IsClosed]]插槽为true，则中止这些步骤。 24 | 2. 让channel成为要宣布的`RTCDataChannel`对象。 25 | 3. 如果通道的[[ReadyState]]为`closing`或`closed`，请中止这些步骤。 26 | 4. 将通道的[[ReadyState]]插槽设置为`open`。 27 | 5. 在通道上触发一个名为open的事件。[测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCPeerConnection-ondatachannel.html) 28 | 29 | 当要宣布底层数据传输时（另一个对等方创建一个negotiated为未设置或设置为false的通道），未启动创建过程的对等方的用户代理必须对任务排序，以运行以下步骤： 30 | 31 | 1. 如果关联的`RTCPeerConnection`对象的[[IsClosed]]插槽为true，则中止这些步骤。 32 | 33 | 2. 创建一个`RTCDataChannel`，通道。 34 | 35 | 3. 让配置成为从另一个对等体接收的信息包，作为建立由WebRTC数据通道协议规范[RTCWEB-DATA-PROTOCOL]描述的底层数据传输的过程的一部分。 36 | 37 | 4. 将通道的[[DataChannelLabel]]，[[Ordered]]，[[MaxPacketLifeTime]]，[[MaxRetransmits]]，[[DataChannelProtocol]]和[[DataChannelId]]内部插槽初始化为配置中的相应值。 38 | 39 | 5. 将通道的[[Negotiated]]内部插槽初始化为`false`。 40 | 41 | 6. 根据配置中的整数优先级值初始化通道的[[DataChannelPriority]]内部插槽，根据以下映射： 42 | 43 | | configuration priority value | RTCPriorityType value | 44 | | ---------------------------- | --------------------- | 45 | | 0 to 128 | very-low | 46 | | 129 to 256 | low | 47 | | 257 to 512 | medium | 48 | | 513 and greater | high | 49 | 50 | 7. 将通道的[[ReadyState]]设置为`open`（但不要触发`open`事件）。 51 | 52 | > NOTE:这允许在触发open事件之前开始在`datachannel`事件处理程序内发送消息。 53 | 54 | 8. 使用`RTCDataChannelEvent`接口触发名为`datachannel`的事件，并将channel属性设置为`RTCPeerConnection`对象的channel。 55 | 56 | 9. 宣布数据通道处于open状态。 57 | 58 | 通过运行关闭过程，可以以非突然的方式拆除`RTCDataChannel`对象的底层数据传输。当发生这种情况时，用户代理必须排队任务以运行以下步骤： 59 | 60 | 1. 让channel成为其传输已关闭的`RTCDataChannel`对象。 61 | 2. 除非通过通道的`close`方法启动该过程，否则将通道的[[ReadyState]]插槽设置为`closing`。 62 | 3. 并行运行以下步骤: 63 | 1. 完成发送channel的所有当前待处理消息。 64 | 2. 遵循为通道的底层传输定义的关闭过程： 65 | 1. 如果是基于SCTP的传输，请按照[RTCWEB-DATA]的6.7节进行操作。 66 | 3. 按照相关步骤渲染通道的数据传输。 67 | 68 | 当`RTCDataChannel`对象的基础数据传输已关闭时，用户代理必须对任务进行排队以运行以下步骤： 69 | 70 | 1. 让channel成为其传输已关闭的`RTCDataChannel`对象。 71 | 2. 将通道的[[ReadyState]]插槽设置为`closed`。 72 | 3. 如果传输因错误而关闭，则使用`RTCErrorEvent`接口触发名为`error`的事件，并在通道中将其`errorDetail`属性设置为`“sctp-failure”`。 73 | 4. 在通道内发起一个名为`close`的事件。 74 | 75 | 在某些情况下，用户代理可能无法创建`RTCDataChannel`的基础数据传输。例如，数据通道的`id`可能超出SCTP握手中[RTCWEB-DATA]实现协商的范围。当用户代理确定无法创建`RTCDataChannel`的基础数据传输时，用户代理必须排队任务以运行以下步骤： 76 | 77 | 1. 令channel为`RTCDataChannel`对象，用户代理无法为其创建底层数据传输。 78 | 2. 将通道的[[ReadyState]]插槽设置为`closed`。 79 | 3. 使用`RTCErrorEvent`接口触发名为`error`的事件，并在通道中将`errorDetail`属性设置为“data-channel-failure”。 80 | 4. 在通道上发起一个名为`close`的事件。 81 | 82 | 当通过类型`type`和数据`rawData`的底层数据传输接收到`RTCDataChannel`消息时，用户代理必须排队任务以运行以下步骤： 83 | 84 | 1. 令channel为用户代理已收到消息的`RTCDataChannel`对象。 85 | 86 | 2. 如果通道的[[ReadyState]]插槽不为`open`，则中止这些步骤并丢弃`rawData`。 87 | 88 | 3. 通过打开`type`和`channel`的`binaryType`来执行子步骤： 89 | 90 | - 如果type表示rawData是一个字符串: 91 | 92 | 令数据为DOMString，表示将`rawData`解码为UTF-8的结果。 93 | 94 | [测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/datachannel-emptystring.html) 95 | 96 | - 如果type表示rawData是二进制而`binaryType`是`“blob”`： 97 | 98 | 让data成为包含rawData作为其原始数据源的新`Blob`对象。 99 | 100 | - 如果type表示rawData是二进制，而`binaryType`是`“arraybuffer”`： 101 | 102 | 让data成为一个新的`ArrayBuffer`对象，包含rawData作为原始数据源。 103 | 104 | 4. 使用MessageEvent接口触发名为`message`的事件，其`origin`属性初始化为创建通道关联的`RTCPeerConnection`的文档的原点，并且`data`属性初始化为通道上的数据。 105 | 106 | ```java 107 | [Exposed=Window] interface RTCDataChannel : EventTarget { 108 | readonly attribute USVString label; 109 | readonly attribute boolean ordered; 110 | readonly attribute unsigned short? maxPacketLifeTime; 111 | readonly attribute unsigned short? maxRetransmits; 112 | readonly attribute USVString protocol; 113 | readonly attribute boolean negotiated; 114 | readonly attribute unsigned short? id; 115 | readonly attribute RTCPriorityType priority; 116 | readonly attribute RTCDataChannelState readyState; 117 | readonly attribute unsigned long bufferedAmount; 118 | [EnforceRange] 119 | attribute unsigned long bufferedAmountLowThreshold; 120 | attribute EventHandler onopen; 121 | attribute EventHandler onbufferedamountlow; 122 | attribute EventHandler onerror; 123 | attribute EventHandler onclose; 124 | void close (); 125 | attribute EventHandler onmessage; 126 | attribute DOMString binaryType; 127 | void send (USVString data); 128 | void send (Blob data); 129 | void send (ArrayBuffer data); 130 | void send (ArrayBufferView data); 131 | }; 132 | ``` 133 | 134 | **属性** 135 | 136 | USVString类型的`label`，只读:label属性表示可用于将此`RTCDataChannel`对象与其他`RTCDataChannel`对象区分开的标签。允许脚本使用相同的标签创建多个`RTCDataChannel`对象。获取时，属性必须返回[[DataChannelLabel]]槽的值。[测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCPeerConnection-createDataChannel.html) 137 | 138 | boolean类型`ordered`，只读：如果`RTCDataChannel`有序，则`ordered`属性返回true，如果允许无序传递，则返回false。获取时，属性必须返回[[Ordered]]槽的值。 139 | 140 | unsigned short类型的`maxPacketLifeTime`，只读的，可以为null：`maxPacketLifeTime`属性返回在不可靠模式下可能发生传输和重传的时间窗口的长度（以毫秒为单位）。获取时，属性必须返回[[MaxPacketLifeTime]]槽的值。 141 | 142 | unsigned short类型的`maxRetransmits`，只读的，可以为null：`maxRetransmits`属性返回在不可靠模式下尝试的最大重新传输次数。获取时，属性必须返回[[MaxRetransmits]]槽的值。 143 | 144 | USVString类型的`protocol`，只读的：`protocol`属性返回与此`RTCDataChannel`一起使用的子协议的名称。获取时，属性必须返回[[DataChannelProtocol]]槽的值。 145 | 146 | boolean类型的`negotiated`，只读的：如果此`RTCDataChannel`由应用程序协商，则`negotiated`属性返回true，否则返回false。获取时，属性必须返回[[Negotiated]]插槽的值。 147 | 148 | unsigned short类型的`id`，只读的，可以为null：`id`属性返回此`RTCDataChannel`的ID。该值初始为null，如果在创建通道时未提供ID，则返回该值，并且尚未协商SCTP传输的DTLS角色。否则，它将返回由脚本选择的ID或由用户代理根据[RTCWEB-DATA-PROTOCOL]生成的ID。将ID设置为非空值后，它不会更改。获取时，属性必须返回[[DataChannelId]]槽的值。[测试2](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCDataChannel-id.html) 149 | 150 | RTCPriorityType类型的`priority`，只读:`priority`属性返回此`RTCDataChannel`的优先级。优先级由用户代理在通道创建时分配。获取时，属性必须返回[[DataChannelPriority]]槽的值。 151 | 152 | `RTCDataChannelState`类型的`readyState`，只读的：`readyState`属性表示`RTCDataChannel`对象的状态。获取时，属性必须返回[[ReadyState]]槽的值。 153 | 154 | unsigned long类型的`bufferedAmount`，只读的：获取时，`bufferedAmount`属性必须返回[[BufferedAmount]]槽的值。该属性公开使用`send（)`排队的应用程序数据（UTF-8文本和二进制数据）的字节数。即使数据传输可以并行发生，在当前任务返回事件循环以防止race condition之前，不得减小返回值。该值不包括协议产生的帧开销，或操作系统或网络硬件完成的缓冲。只要[[ReadyState]]插槽打开，[[BufferedAmount]]插槽的值只会随着每次调用send（）方法而增加;但是，一旦通道关闭，插槽不会重置为零。当底层数据传输从其队列发送数据时，用户代理必须排队一个任务，该任务随着发送的字节数减少[[BufferedAmount]]。 155 | 156 | unsigned long类型的`bufferedAmountLowThreshold`:`bufferedAmountLowThreshold`属性设置`bufferedAmount`被视为低的阈值。当`bufferedAmount`从此阈值以上减小到等于或低于此阈值时，将触发`bufferedamountlow`事件。 `bufferedAmountLowThreshold`在每个新的`RTCDataChannel`上最初为零，但应用程序可能随时更改其值。 157 | 158 | EventHandler类型的`onopen`:此事件处理程序的事件类型为`open`。 159 | 160 | eventHandler类型的`onbufferedamountlow`:此事件处理程序的事件类型为`bufferedamountlow`。 161 | 162 | eventHandler类型的`onerror`:此事件处理程序的事件类型是`RTCErrorEvent`。` errorDetail`包含“sctp-failure”，`sctpCauseCode`包含SCTP Cause Code值，并且`message`包含SCTP Cause-Specific-Information，可能包含其他文本。 163 | 164 | EventHandler类型的`onclose`:此事件处理程序的事件类型为`close`。 165 | 166 | eventHandler类型的`onmessage`:此事件处理程序的事件类型是`message`。 167 | 168 | DOMString类型的`binaryType`:获取时，`binaryType`属性必须返回上次设置的值。在设置时，如果新值是字符串`“blob”`或字符串`“arraybuffer”`，则将IDL属性设置为此新值。否则，抛出一个`SyntaxError`。创建`RTCDataChannel`对象时，必须将`binaryType`属性初始化为字符串`“blob”`。 169 | 170 | 此属性控制二进制数据如何向脚本公开。有关更多信息，请参阅[WEBSOCKETS-API]。 171 | 172 | **方法** 173 | 174 | `close`: 175 | 176 | 关闭`RTCDataChannel`。无论`RTCDataChannel`对象是由对等方还是远程对等方创建，都可以调用它。 177 | 178 | 调用close方法时，用户代理必须执行以下步骤： 179 | 180 | 1. 让channel成为即将关闭的`RTCDataChannel`对象。 181 | 2. 如果通道的[[ReadyState]]插槽为`closing`或`closed`，则中止这些步骤。 182 | 3. 将通道的[[ReadyState]]插槽设置为`closing`。 183 | 4. 如果关闭程序尚未开始，请启动它。 184 | 185 | `send` 186 | 187 | 使用参数类型`string`对象运行`send（）`算法描述的步骤。[测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCDataChannel-send.html) 188 | 189 | `send` 190 | 191 | 使用参数类型`Blob`对象运行`send（）`算法描述的步骤。 192 | 193 | `send` 194 | 195 | 使用参数类型`ArrayBuffer`对象运行`send（）`算法描述的步骤。 196 | 197 | `send` 198 | 199 | 使用参数类型`ArrayBufferView`对象运行`send（）`算法描述的步骤。 200 | 201 | `send()`方法被重载，用来处理不同数据参数类型。当该方法的任何版本被调用时，用户代理必须运行下列步骤： 202 | 203 | 1. 让channel成为将要发送数据的`RTCDataChannel`对象。 204 | 205 | 2. 如果channel的[ReadyState]插槽不为`open`，抛出`InvalidStateError`。 206 | 207 | 3. 执行对应方法参数类型的子步骤： 208 | 209 | - `string`对象: 210 | 211 | 让data成为byte buffer，表示将方法参数编码为UTF-8的结果。 212 | 213 | - `Blob`对象: 214 | 215 | 让data成为由`Blob`对象表示的原始数据。 216 | 217 | - `ArrayBuffer`对象: 218 | 219 | 让data成为由`ArrayBuffer`对象描述的存在buffer中的数据。 220 | 221 | - `ArrayBufferView`对象： 222 | 223 | 让data成为`ArrayBufferView`对象提到的`ArrayBuffer`对象描述的buffer中存储的数据。 224 | 225 | > NOTE:任何该方法没有重载的数据类型将会导致`TypeError`。这包括null和undefined。 226 | 227 | 4. 如果data的大小超过了channel的关联`RTCSctpTransport`上的`maxMessageSize`的值，抛出`TypeError`。 228 | 229 | 5. 对在channel的底层数据传输的data进行排队。 230 | 231 | > NOTE:实际数据传输是并行的。如果发送数据导致SCTP层级的错误，应用程序将会被通过`onerror`异步通知。 232 | 233 | 6. 增加[BufferedAmount]插槽的值，增加量为data的大小。 234 | 235 | ```java 236 | dictionary RTCDataChannelInit { 237 | boolean ordered = true; 238 | [EnforceRange] 239 | unsigned short maxPacketLifeTime; 240 | [EnforceRange] 241 | unsigned short maxRetransmits; 242 | USVString protocol = ""; 243 | boolean negotiated = false; 244 | [EnforceRange] 245 | unsigned short id; 246 | RTCPriorityType priority = "low"; 247 | }; 248 | ``` 249 | 250 | **字典`RTCDataChannelInit`成员** 251 | 252 | boolean类型的`ordered`，默认为true:如果设置为false，则允许数据不按顺序传送。默认值为true，保证数据按顺序传递。 253 | 254 | unsigned short类型的`maxPacketLifeTime`:限制通道在未确认的情况下传输或重新传输数据的时间（以毫秒为单位）。如果该值超过用户代理支持的最大值，则可以限制该值。[测试1](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCPeerConnection-createDataChannel.html) 255 | 256 | unsigned short类型的`maxRetransmits`:如果未成功传递，则限制通道重新传输数据的次数。如果该值超过用户代理支持的最大值，则可以限制该值。 257 | 258 | USVString类型的`protocol`，默认为`“”`:用于此通道的子协议名称。 259 | 260 | boolean类型的`negotiated`，默认为`false`:默认值false指示用户代理在带内通告通道并指示另一个对等方分派相应的`RTCDataChannel`对象。如果设置为true，则由应用程序协商通道并在另一个对等方创建具有相同ID的`RTCDataChannel`对象。 261 | 262 | > NOTE:如果设置为true，则应用程序还必须注意不要发送消息，直到另一个对等方创建了一个数据通道来接收它。在没有关联数据通道的SCTP流上接收消息是未定义的行为，可能会以静默方式丢弃。只要两个端点在第一个提议/应答交换完成之前创建其数据通道，就不可能实现这一点。 263 | 264 | unsigned short类型的`id`:重写此通道的默认ID选择。 265 | 266 | RTCPriorityType类型的`priority`，默认为`low`:此通道的优先级。 267 | 268 | ```java 269 | enum RTCDataChannelState { 270 | "connecting", 271 | "open", 272 | "closing", 273 | "closed" 274 | }; 275 | ``` 276 | 277 | | RTCDataChannelState枚举描述 | | 278 | | --------------------------- | ------------------------------------------------------------ | 279 | | `connecting` | 用户代理正在尝试建立底层数据传输。这是`RTCDataChannel`对象的初始状态，无论是使用`createDataChannel`创建，还是作为`RTCDataChannelEvent`的一部分调度。 | 280 | | `open` | 建立基础数据传输并且可以进行通信。 | 281 | | `closing` | 关闭底层数据传输的过程已经开始。 | 282 | | `closed` | 底层数据传输已关闭或无法建立。 | 283 | 284 | --------------------------------------------------------------------------------