WebRTC 获取本地媒体成功后 onnegotiateneeded 的处理顺序
WebRTC Order of processing after onnegotiateneeded on getlocalmedia success
启动 webrtc 环境并且 运行 在开始会话之前（例如，在初始化时）获取用户媒体时没有任何问题。但是，当我在会话启动和回答时获得用户媒体时，我无法成功地将回答方媒体添加到会话中（即，发起方视频在回答方可见，但回答方视频在发起时不可见边）。
我花了很多时间试图解决这个问题，但没有成功，希望有人能澄清关于 onnegotiationneeded 事件处理的要点。
情况如下：
A 端启动会话，获取用户媒体，一旦用户媒体可用并添加到对等连接，就会生成 SDP 提议并发送到远程端。
B 方收到报价，在屏幕上引发铃声类型的事件，并在用户决定回答后请求用户媒体。 getusermedia 的成功调用将本地描述添加到对等连接，并在某个时候生成 onnegotiationeeded 事件。
一切似乎都进展顺利（例如，在 B 侧 - 通过信号通道提供和候选人，然后 have_remote_offer，添加远程流，等等），
但是，我不清楚应答方在重新协商后（即处理 onnegotiationneeded 事件时）应该生成 SDP answer 还是 SDP offer。
此外，最好等到 getusermedia returns 成功后再发送 SDP 答复，还是应该根据发起方 SDP 报价发送 SDP 答复，而不等待本地用户媒体然后在需要协商后发送另一个 SDP（例如，根据前一段提供或回答）？
关于一个有点相关的问题是实际使用的 PRAnswer - 我在消息跟踪中没有看到这样的问题。
收到报价后，B 方需要给出答案，而不是报价。
B 方不应在回答期间重新协商，因为它已经在协商中。换句话说，您不希望 negotiationneeded 在回答期间触发。
你说 negotiationneeded 在 B 侧开火。那很糟糕。
它触发的原因可能有三个，没有代码我无法分辨是哪一个：
- 您在调用
setRemoteDescription 之前添加流
报价。
- 您的流中的视频 and/or 音轨数量超出了优惠中允许的数量。
- 您正在使用 Chrome.
根据规范，negotiationneeded 仅在 signalingState 为 "stable" 时触发（即未协商），但如果当时 localDescription [=26] =].
因此请确保您正在做三件事：
- 在 添加
getUserMedia 流之前调用 setRemoteDescription(offer) 。
- 除非双方都添加相同数量的视频 and/or 音轨，否则使用
RTCOfferOptions 和 createOffer。
- 在 Chrome 中，无论如何都要准备好忽略
negotiationneeded，因为它似乎有一个错误，它会在 "stable" 状态之外触发，这种情况会发生。
Here's an example 适用于 Firefox 和 Chrome 45.
在 Firefox 中你会看到：
addStream in have-remote-offer
checking
connected
而在 Chrome 45 中你会看到：
addStream in have-remote-offer
onnegotiationneeded fired in have-remote-offer
checking
connected
因为错误。
即使您的回答有更少的轨道，协商仍会完成，所以如果您想快速回答，这是一种方法（但是稍后您需要在添加媒体时重新协商）。
PRAnswer 未在任何浏览器 AFAIK 中实现。
启动 webrtc 环境并且 运行 在开始会话之前（例如，在初始化时）获取用户媒体时没有任何问题。但是，当我在会话启动和回答时获得用户媒体时，我无法成功地将回答方媒体添加到会话中（即，发起方视频在回答方可见，但回答方视频在发起时不可见边）。 我花了很多时间试图解决这个问题，但没有成功，希望有人能澄清关于 onnegotiationneeded 事件处理的要点。
情况如下：
A 端启动会话，获取用户媒体，一旦用户媒体可用并添加到对等连接，就会生成 SDP 提议并发送到远程端。
B 方收到报价，在屏幕上引发铃声类型的事件，并在用户决定回答后请求用户媒体。 getusermedia 的成功调用将本地描述添加到对等连接，并在某个时候生成 onnegotiationeeded 事件。
一切似乎都进展顺利（例如，在 B 侧 - 通过信号通道提供和候选人，然后 have_remote_offer，添加远程流，等等），
但是，我不清楚应答方在重新协商后（即处理 onnegotiationneeded 事件时）应该生成 SDP answer 还是 SDP offer。
此外，最好等到 getusermedia returns 成功后再发送 SDP 答复，还是应该根据发起方 SDP 报价发送 SDP 答复，而不等待本地用户媒体然后在需要协商后发送另一个 SDP（例如，根据前一段提供或回答）？
关于一个有点相关的问题是实际使用的 PRAnswer - 我在消息跟踪中没有看到这样的问题。
收到报价后，B 方需要给出答案，而不是报价。
B 方不应在回答期间重新协商，因为它已经在协商中。换句话说，您不希望 negotiationneeded 在回答期间触发。
你说 negotiationneeded 在 B 侧开火。那很糟糕。
它触发的原因可能有三个，没有代码我无法分辨是哪一个：
- 您在调用
setRemoteDescription之前添加流 报价。 - 您的流中的视频 and/or 音轨数量超出了优惠中允许的数量。
- 您正在使用 Chrome.
根据规范，negotiationneeded 仅在 signalingState 为 "stable" 时触发（即未协商），但如果当时 localDescription [=26] =].
因此请确保您正在做三件事：
- 在 添加
getUserMedia流之前调用setRemoteDescription(offer)。 - 除非双方都添加相同数量的视频 and/or 音轨，否则使用
RTCOfferOptions和createOffer。 - 在 Chrome 中，无论如何都要准备好忽略
negotiationneeded，因为它似乎有一个错误，它会在"stable"状态之外触发，这种情况会发生。
Here's an example 适用于 Firefox 和 Chrome 45.
在 Firefox 中你会看到：
addStream in have-remote-offer
checking
connected
而在 Chrome 45 中你会看到：
addStream in have-remote-offer
onnegotiationneeded fired in have-remote-offer
checking
connected
因为错误。
即使您的回答有更少的轨道，协商仍会完成，所以如果您想快速回答，这是一种方法（但是稍后您需要在添加媒体时重新协商）。
PRAnswer 未在任何浏览器 AFAIK 中实现。