为什么我必须在发送对等连接提供之前打开数据通道?

时间:2022-08-26 18:57:42

I'm coding a simple chat application and I'd like to add a shared drawing canvas to my application which is using data channel to send canvas points between them. But it's a optional specification so I don't want open a data channel each time of opening a chat. If I open data channel after establish the peer connection (after offer), I can not send any data over data channel. Otherwise I can send (I got this point from here: https://*.com/a/35141500/5663292). So why I have to open data channel before peer connection offer?

我正在编写一个简单的聊天应用程序,我想在我的应用程序中添加一个共享绘图画布,它使用数据通道在它们之间发送画布点。但它是一个可选的规范,所以我不希望每次打开聊天时都打开一个数据通道。如果我在建立对等连接后打开数据通道(在提供之后),我就无法通过数据通道发送任何数据。否则我可以发送(我从这里得到这一点:https://*.com/a/35141500/5663292)。那么为什么我必须在对等连接提供之前打开数据通道?

1 个解决方案

#1


1  

The SDP offer/answer is what establishes how exactly your peers want to communicate. The offer includes the actual connection method (IP/port/TURN relay) and what streams, codecs and channels you want to use. The answer narrows this down/confirms what the other peer can accept.

SDP提供/答案确定了您的同伴之间的沟通方式。优惠包括实际连接方法(IP /端口/ TURN中继)以及您要使用的流,编解码器和通道。答案缩小了这个范围,确认了其他同行可以接受的内容。

If you want to add anything to the communication, like an additional media stream or a data channel, you need to inform the other peer of that, otherwise it doesn't expect anything/can't handle it.

如果要向通信中添加任何内容,例如其他媒体流或数据通道,则需要通知其他对等方,否则它不会期望任何/无法处理它。

The flow is always:

流程总是:

  1. prepare anything you want to send to a remote peer on your local RTCPeerConnection
  2. 准备要发送到本地RTCPeerConnection上的远程对等方的任何内容

  3. generate a local description
  4. 生成本地描述

  5. send it to the remote peer
  6. 将其发送给远程对等方

  7. await the remote peer's answer
  8. 等待远程同行的回答

  9. incorporate the remote's answer (setRemoteDescription)
  10. 合并遥控器的答案(setRemoteDescription)

Only then are both peers on the same page and can really talk to one another. Repeat this procedure whenever necessary, i.e. whenever you substantially change anything about what you're sending.

只有这样,同一页面上的两个同伴才能真正相互交谈。必要时重复此过程,即每当您对发送的内容进行实质性更改时。

#1


1  

The SDP offer/answer is what establishes how exactly your peers want to communicate. The offer includes the actual connection method (IP/port/TURN relay) and what streams, codecs and channels you want to use. The answer narrows this down/confirms what the other peer can accept.

SDP提供/答案确定了您的同伴之间的沟通方式。优惠包括实际连接方法(IP /端口/ TURN中继)以及您要使用的流,编解码器和通道。答案缩小了这个范围,确认了其他同行可以接受的内容。

If you want to add anything to the communication, like an additional media stream or a data channel, you need to inform the other peer of that, otherwise it doesn't expect anything/can't handle it.

如果要向通信中添加任何内容,例如其他媒体流或数据通道,则需要通知其他对等方,否则它不会期望任何/无法处理它。

The flow is always:

流程总是:

  1. prepare anything you want to send to a remote peer on your local RTCPeerConnection
  2. 准备要发送到本地RTCPeerConnection上的远程对等方的任何内容

  3. generate a local description
  4. 生成本地描述

  5. send it to the remote peer
  6. 将其发送给远程对等方

  7. await the remote peer's answer
  8. 等待远程同行的回答

  9. incorporate the remote's answer (setRemoteDescription)
  10. 合并遥控器的答案(setRemoteDescription)

Only then are both peers on the same page and can really talk to one another. Repeat this procedure whenever necessary, i.e. whenever you substantially change anything about what you're sending.

只有这样,同一页面上的两个同伴才能真正相互交谈。必要时重复此过程,即每当您对发送的内容进行实质性更改时。