WebRTC源码分析-呼叫建立过程之四（下）(创建数据通道DataChannel)

最新推荐文章于 2023-08-23 11:08:35 发布

ice_ly000

最新推荐文章于 2023-08-23 11:08:35 发布

阅读量4.6k

点赞数 14

分类专栏： WebRTC源码分析

本文链接：https://blog.csdn.net/ice_ly000/article/details/105967584

版权

WebRTC源码分析专栏收录该内容

38 篇文章 180 订阅

订阅专栏

1. 引言

创建完PeerConnectionFactory 和 PeerConnection这两个API层的操盘对象之后，紧接着需要初始化本地的媒体，也即创建本地的音频轨、视频轨、数据通道，并将这些本地的媒体轨道添加到PeerConnection对象中。如图中红色标注所示。

本文将详细描述上述数据通道的创建细节。
在这里插入图片描述

2. 数据通道的创建

应用层通过调用PC的CreateDataChannel方法来创建DataChannel，PC有两个CreateDataChannel方法，其中一个入参是mid值，另外一个如下源码所示。

2.1 PeerConnection::CreateDataChannel方法

rtc::scoped_refptr<DataChannelInterface> PeerConnection::CreateDataChannel(
    const std::string& label,
    const DataChannelInit* config) {
  // 1. 判断是否运行于信令线程，输出日志
  RTC_DCHECK_RUN_ON(signaling_thread());
  TRACE_EVENT0("webrtc", "PeerConnection::CreateDataChannel");
  
  // 2. 是否为第一个数据通道？
  //    PC.data_channel_controller_有三个成员变量记录了DataChannel，分别是
  //    map<std::string, rtc::scoped_refptr<DataChannel>> rtp_data_channels_；
  //    vector<rtc::scoped_refptr<DataChannel>> sctp_data_channels_；
  //    vector<rtc::scoped_refptr<DataChannel>> sctp_data_channels_to_free_；
  //    第一个记录的是rtp作为datachannel底层传输的数据通道，并且记录label->DataChannel的映射
  //    第二个记录的是sctp作为datachannel底层传输的数据通道
  //    第三个记录的是已经需要进行释放的sctp作为datachannel底层传输的数据通道
  //
  //    是否是第一个，取决于rtp_data_channels_和sctp_data_channels_是否为空，为空，则是第一个；
  //    不需要判断第三个记录，因为已经是需要销毁释放的datachannel了。
  bool first_datachannel = !data_channel_controller_.HasDataChannels();

  // 3. 创建DataChannel对象
  // 3.1 创建内部使用的DataChannel初始化参数InternalDataChannelInit
  std::unique_ptr<InternalDataChannelInit> internal_config;
  if (config) {
    internal_config.reset(new InternalDataChannelInit(*config));
  }
  // 3.2 通过InternalCreateDataChannel方法来创建DataChannel
  rtc::scoped_refptr<DataChannelInterface> channel(
      data_channel_controller_.InternalCreateDataChannel(label, internal_config.get()));
  if (!channel.get()) {
    return nullptr;
  }
  // 3.3 如果创建的是RTP DataChannel或者是第一个SCTP DataChannel，需要报告给PC的观察者
  //     进行重新协商
  // Trigger the onRenegotiationNeeded event for every new RTP DataChannel, or
  // the first SCTP DataChannel.
  if (data_channel_type() == cricket::DCT_RTP || first_datachannel) {
    Observer()->OnRenegotiationNeeded();
  }
  // 3.4 记录DATA_ADDED事件到PC的成员usage_event_accumulator_
  NoteUsageEvent(UsageEvent::DATA_ADDED);
  
  // 4. 返回DataChannel的代理对象DataChannelProxy
  return DataChannelProxy::Create(signaling_thread(), channel.get());
}

分四步对CreateDataChannel()方法进行了初步分析，其中一些知识点拎出来再说明下：

从判断是否已经存在DataChannel这么一个判断的方式上看，PC的data_channel_controller_有两个成员存储了DataChannel，分别是成员rtp_data_channels_和成员sctp_data_channels_，从名称上可以看出这两个成员是用来保存不同传输协议实现的DataChannel：基于sctp 和基于rtp。
创建DataChannel过程中出现了两个特别重要的参数，一个是应用层传入的DataChannelInit，一个是PC的成员data_channel_type_。后续将对这两个主要的参数进行详细的阐述。
WebRTC的PC成员usage_event_accumulator_会以位去记录发生的事件，只要事件发生过一次，就会被usage_event_accumulator_标记上，这些事件大致如下：
最终返给用户层的是DataChannelProxy，这是WebRTC防止线程乱入的一贯做法，此处不展开详述了。

接下来是时候好好看看那两个重要的参数了：DataChannelInit && data_channel_type_

2.1.1 初始化参数DataChannelInit

当我们在网上搜索SCTP时，会看到相关的描述，将SCTP介绍为与UDP，TCP同一层次的传输层协议。最早STCP是把窄带7号信令的可靠性传输机制引入到IP协议、优化TCP协议的不能分帧传输的局限性提出来的，不过后来应用不是很广泛。在WebRTC中实现数据通道使用的SCTP是基于改良剪切版的，有两个草案描述了该改良版本《draft-ietf-rtcweb-data-channel-13》、《draft-ietf-rtcweb-data-protocol-09》（此处描述来源于webrtc数据通道之SCTP over DTLS简介）。WebRTC要求使用SCTP必须开启DTLS，协议的分层图如下：可以得知WebRTC中的SCTP实际上是基于UDP在应用层提供的相关实现，而非常规意义上的OSI模型中的传输层。

WebRTC根据实际的应用场景，提供了不同可靠程度的传输模式：可靠传输模式、部分可靠传输模式、不可靠传输模式。
在这里插入图片描述
采用哪种模式取决于结构体参数DataChannelInit，该参数包含的字段如下源码：

struct DataChannelInit {
  // Deprecated. Reliability is assumed, and channel will be unreliable if
  // maxRetransmitTime or MaxRetransmits is set.
  bool reliable = false;
  // True if ordered delivery is required.
  bool ordered = true;
  // The max period of time in milliseconds in which retransmissions will be
  // sent. After this time, no more retransmissions will be sent.
  //
  // Cannot be set along with |maxRetransmits|.
  // This is called |maxPacketLifeTime| in the WebRTC JS API.
  absl::optional<int> maxRetransmitTime;
  // The max number of retransmissions.
  //
  // Cannot be set along with |maxRetransmitTime|.
  absl::optional<int> maxRetransmits;
  // This is set by the application and opaque to the WebRTC implementation.
  std::string protocol;
  // True if the channel has been externally negotiated and we do not send an
  // in-band signalling in the form of an "open" message. If this is true, |id|
  // below must be set; otherwise it should be unset and will be negotiated
  // in-band.
  bool negotiated = false;
  // The stream id, or SID, for SCTP data channels. -1 if unset (see above).
  int id = -1;
};

reliable、ordered 、maxRetransmitTime、maxRetransmits确定了传输是否是可靠的，不可靠情况下如何重传，包是否要求有序到达。

参数取值	传输可靠性
reliable为true	可靠传输
reliable为false，maxRetransmitTime 或 maxRetransmits存在且有效	部分可靠传输
reliable为false，且maxRetransmitTime && maxRetransmits均无效	不可靠传输

protocol 字段描述DataChannel中传输数据的子协议，对于WebRTC来说是透明的
negotiated 和 id字段确定了通道协商的手段是通过带外数据协商，还是通过DataChannel本身传输数据协商。当negotiated为真时，说明通过SDP进行带外数据协商，此时，id必须提供有效的SID值；当negotiated为假时，需要建立DataChannel时，在底层通道链路建立后发送Open消息进行带内协商。

InternalDataChannelInit结构参数扩展了DataChannelInit ，增加了一个字段OpenHandshakeRole：

struct InternalDataChannelInit : public DataChannelInit {
  enum OpenHandshakeRole { kOpener, kAcker, kNone };
  // The default role is kOpener because the default |negotiated| is false.
  InternalDataChannelInit() : open_handshake_role(kOpener) {}
  explicit InternalDataChannelInit(const DataChannelInit& base);
  OpenHandshakeRole open_handshake_role;
};

在需要带外协商时，open_handshake_role为kNone；带内协商时open_handshake_role默认为kOpener（一方为kOpener、另一方为kAcker），kOpener主动向kAcker发送Open控制消息，进行带内协商。

2.1.2 PeerConnection.data_channel_controller_.data_channel_type_

PeerConnection.data_channel_controller_.data_channel_type_成员是一个枚举类型的变量，该变量影响到在创建DataChannel时，DataChannel底层使用的协议。

enum DataChannelType {
  // 不允许创建DataChannel；
  DCT_NONE = 0,
  // 基于RTP协议的DataChannel；
  DCT_RTP = 1,
  // 基于SCTP协议的DataChannel；
  DCT_SCTP = 2,
  // 有待解惑
  // Data channel transport over media transport.
  DCT_MEDIA_TRANSPORT = 3,
  // 基于UDP协议的DataChannel，与上一个相比行为一致，但不使用DTLS
  // Data channel transport over datagram transport (with no fallback).  This is
  // the same behavior as data channel transport over media transport, and is
  // usable without DTLS.
  DCT_DATA_CHANNEL_TRANSPORT = 4,
  // 基于UDP传输(使用SCTP协商语法，并可回退到SCTP)。必须使用DTLS。
  // Data channel transport over datagram transport (with SCTP negotiation
  // semantics and a fallback to SCTP).  Only usable with DTLS.
  DCT_DATA_CHANNEL_TRANSPORT_SCTP = 5,
};

PeerConnection.data_channel_controller_.data_channel_type_参数在PC初始化函数中赋值，之前在分析创建PC的文章中粗略地分析过PeerConnection::Initialize()方法，再次把其中与当前议题相关的部分截取出来以供分析：

  if (use_datagram_transport_for_data_channels_) {
    if (configuration.enable_rtp_data_channel) {
      RTC_LOG(LS_ERROR) << "enable_rtp_data_channel and "
                           "use_datagram_transport_for_data_channels are "
                           "incompatible and cannot both be set to true";
      return false;
    }
    if (configuration.enable_dtls_srtp && !*configuration.enable_dtls_srtp) {
      RTC_LOG(LS_INFO) << "Using data channel transport with no fallback";
      data_channel_controller_.set_data_channel_type(
          cricket::DCT_DATA_CHANNEL_TRANSPORT);
    } else {
      RTC_LOG(LS_INFO) << "Using data channel transport with fallback to SCTP";
      data_channel_controller_.set_data_channel_type(
          cricket::DCT_DATA_CHANNEL_TRANSPORT_SCTP);
      config.sctp_factory = sctp_factory_.get();
    }
  } else if (configuration.enable_rtp_data_channel) {
    // Enable creation of RTP data channels if the kEnableRtpDataChannels is
    // set. It takes precendence over the disable_sctp_data_channels
    // PeerConnectionFactoryInterface::Options.
    data_channel_controller_.set_data_channel_type(cricket::DCT_RTP);
  } else {
    // DTLS has to be enabled to use SCTP.
    if (!options.disable_sctp_data_channels && dtls_enabled_) {
      data_channel_controller_.set_data_channel_type(cricket::DCT_SCTP);
      config.sctp_factory = sctp_factory_.get();
    }
  }

首先，use_datagram_transport_for_data_channels_参数是否为真，决定了是否使用DatagramTrasnport接口来收发DataChannel数据（该套接口是后引入的，早期版本应该只有rtp和sctp-dtls）。该参数是否为真一方面取决于应用层给PC传入的RTCConfiguration配置参数中同名字段取值，另一方面还需PeerConnectionFactory中提供MediaTransportFactory用于创建DatagramTrasnport。当二者都具备时，use_datagram_transport_for_data_channels_为真，此时，将创建基于DatagramTrasnport接口的底层收发包对象。如上代码所示，实质上只会创建DCT_DATA_CHANNEL_TRANSPORT 或者 DCT_DATA_CHANNEL_TRANSPORT_SCTP类别的DataChannel，分别是直接基于UDP的DatagramTrasnport接口和基于SCTP的DatagramTrasnport接口。没有 DCT_MEDIA_TRANSPORT 这个类别的实现。
其次，当决定不使用DatagramTrasnport接口的实现时，判断是否使用RTP实现，即DCT_RTP类别。取决于应用层给PC传入的RTCConfiguration配置参数是否开启enable_rtp_data_channel。
最后，当既不使用DatagramTrasnport接口，又不使用RTP传输时，启用SCTP-DTLS实现。

总之：
DataChannel最终的类别取决于PC的RTCConfiguration配置参数中的两个取值：use_datagram_transport_for_data_channels_ 和 enable_rtp_data_channel；以及PC工厂类是否提供了MediaTransportFactory。

由于使用DatagramTrasnport接口来收发DataChannel数据的方式是后引入的，是一个实验特性，需要特意设置use_datagram_transport_for_data_channels_ 以及提供MediaTransportFactory来开启；

由于WebRTC中使用RTP来实现DataChannel是一个计划要淘汰的方式，因此，也需要外部设置RTCConfiguration.enable_rtp_data_channel来启用

由于SCTP是实现DataChannel最正式的方式，因此，在外界不提供额外设置的情况下，默认使用该方式。

2.2 DataChannelController::InternalCreateDataChannel方法

rtc::scoped_refptr<DataChannel> DataChannelController::InternalCreateDataChannel(
    const std::string& label,
    const InternalDataChannelInit* config) {
  // 1.判断PC状态是否已经关闭了
  if (IsClosed()) {
    return nullptr;
  }
  
  // 2. 若data_channel_type_为DCT_NONE，表示禁用DataChannel
  if (data_channel_type() == cricket::DCT_NONE) {
    RTC_LOG(LS_ERROR)
        << "InternalCreateDataChannel: Data is not supported in this call.";
    return nullptr;
  }
 
  // 3. 判断外部是否提供了InternalDataChannelInit，否则提供默认的
  InternalDataChannelInit new_config =
      config ? (*config) : InternalDataChannelInit();

  // 4. 如果DataChannel是类sctp类型，我们需要对sid进行处理
  //    类sctp已经在上文描述过
  if (DataChannel::IsSctpLike(data_channel_type_)) {
    // 4.1 如果new_config.id < 0，是无效的sid值，根据SSLRole是服务器还是客户端
    // 分配有效的sid
    if (new_config.id < 0) {
      rtc::SSLRole role;
      if ((GetSctpSslRole(&role)) &&
          !sid_allocator_.AllocateSid(role, &new_config.id)) {
        RTC_LOG(LS_ERROR)
            << "No id can be allocated for the SCTP data channel.";
        return nullptr;
      }
    // 4.2 如果new_config.id > 0，判断外部提供的new_config.id是否有效
    //     也即new_config.id是否超界或者已经被使用
    } else if (!sid_allocator_.ReserveSid(new_config.id)) {
      RTC_LOG(LS_ERROR) << "Failed to create a SCTP data channel "
                           "because the id is already in use or out of range.";
      return nullptr;
    }
  }

  // 5. DataChannel::Create根据datachannel类别，标签，参数来创建DataChannel
  rtc::scoped_refptr<DataChannel> channel(
      DataChannel::Create(this, data_channel_type(), label, new_config));
  if (!channel) {
    sid_allocator_.ReleaseSid(new_config.id);
    return nullptr;
  }

  // 6. 存储创建的DataChannel
  // 6.1 如果创建的是cricket::DCT_RTP类别的DataChannel，则放入成员rtp_data_channels_中
  if (channel->data_channel_type() == cricket::DCT_RTP) {
    if (rtp_data_channels_.find(channel->label()) != rtp_data_channels_.end()) {
      RTC_LOG(LS_ERROR) << "DataChannel with label " << channel->label()
                        << " already exists.";
      return nullptr;
    }
    rtp_data_channels_[channel->label()] = channel;
  // 6.2 如果创建的是类sctp的DataChannel，则放入成员sctp_data_channels_中
  } else {
    RTC_DCHECK(DataChannel::IsSctpLike(data_channel_type_));
    sctp_data_channels_.push_back(channel);
    // 绑定通道的关闭信号和PC对应的槽，让PC知道SCTP通道的关闭事件
    channel->SignalClosed.connect(this,
                                  &PeerConnection::OnSctpDataChannelClosed);
  }

  // 7. 发送通道创建的信号，一方面PC封装了DataChannelController的SignalDataChannelCreated_
  //    信号，PC肯定能获知该信号进行响应；另一方面RTCStatsCollector等对象通过关联PC封装的 
  //    SignalDataChannelCreated信号也可以处理数据通道被创建的消息。
  SignalDataChannelCreated_(channel.get());
  return channel;
}

该函数就不展开分析了，最终调用了DataChannel::Create()方法来创建DataChannel。后续来看下DataChannel::Create()方法的内容。

2.3 DataChannel::Create方法

分两步：构造DataChannel + 初始化DataChannel

rtc::scoped_refptr<DataChannel> DataChannel::Create(
    DataChannelProviderInterface* provider,
    cricket::DataChannelType dct,
    const std::string& label,
    const InternalDataChannelInit& config) {
  // 1. 调用DataChannel的构造函数
  rtc::scoped_refptr<DataChannel> channel(
      new rtc::RefCountedObject<DataChannel>(provider, dct, label));
  // 2. 调用初始化方法    
  if (!channel->Init(config)) {
    return NULL;
  }
  return channel;
}

2.3.1 DataChannel构造

初始化成员，各成员的用途

DataChannel::DataChannel(DataChannelProviderInterface* provider,
                         cricket::DataChannelType dct,
                         const std::string& label)
    : internal_id_(GenerateUniqueId()), 
      label_(label),
      observer_(nullptr),
      state_(kConnecting),
      messages_sent_(0),
      bytes_sent_(0),
      messages_received_(0),
      bytes_received_(0),
      buffered_amount_(0),
      data_channel_type_(dct),
      provider_(provider),
      handshake_state_(kHandshakeInit),
      connected_to_provider_(false),
      send_ssrc_set_(false),
      receive_ssrc_set_(false),
      writable_(false),
      send_ssrc_(0),
      receive_ssrc_(0) {}

internal_id_：内部使用的自增id，从0开始，每创建一个DataChanel单调递增1；
label_：通道的标识，与Track的label一样；
observer_：通道的观察者，包含通道状态改变回调、通道获取数据回调、通道缓冲数据大小改变时回调；
state_：通道的状态，包含kConnecting（通道连接中状态，无法发送数据）、kOpen（通道已连接状态，可发送数据，send_ssrc_和receive_ssrc_均有值）、kClosing（通道关闭中状态，不允许继续发送数据，但已在buffer中的数据将被发送）、kClosed（通道已关闭状态）；
messages_sent_ && bytes_sent_：发送消息个数和字节数；
messages_received_ && bytes_received_：接收消息个数和字节数；
buffered_amount_: DataChanel层发送缓存中缓存的还未发送的数据的字节数，当Transport要发送数据前该值增加，当发送成功后该值相应的减小；
data_channel_type_：通道类型RTP？SCTP？还是基于DatagramTransport的那3钟
provider_：实际上就DataChannelController，它继承实现了DataChannelProviderInterface，提供了实际上的数据发送功能，将把DataChannel要发送的数据代理到DataChannelTransport去发哦是那个。相当重要；
handshake_state_：握手状态，需要进行带内协商时该状态起着作用；
connected_to_provider_：是否与provider相关上；
send_ssrc_set_ && receive_ssrc_set_：send_ssrc_ && receive_ssrc_是否已经设置， RTP协议类别的使用；
writable_：通道是否已经准备ok，可以发送数据；
send_ssrc_ && receive_ssrc_：发送端ssrc和接收端ssrc，RTP协议类别的使用，SCTP协议类别使用SID，保存在成员config_.sid中，见后面的DataChannel::Init方法。

2.3.2 DataChannel初始化

bool DataChannel::Init(const InternalDataChannelInit& config) {
  // 根据通道类别进行分类处理
  // 1. RTP类别的通道
  if (data_channel_type_ == cricket::DCT_RTP) {
    // 1.1 入参判断：
    //     RTP通道不能提供可靠传输，因此，reliable不能为真；
    //     RTP通道id必须为-1，因为sid是为sctp准备的，RTP通道不应该设置该值；
    //     RTP通道不提供按重传次数或者最大重传时间这种部分可靠性，因此，maxRetransmits
    //           maxRetransmitTime不可存在。
    if (config.reliable || config.id != -1 || config.maxRetransmits ||
        config.maxRetransmitTime) {
      RTC_LOG(LS_ERROR) << "Failed to initialize the RTP data channel due to "
                           "invalid DataChannelInit.";
      return false;
    }
    //1.2 RTP通道不需要带内协商，因此，握手状态为kHandshakeReady即可
    handshake_state_ = kHandshakeReady;
    
  // 2. 类sctp类别的通道
  } else if (IsSctpLike(data_channel_type_)) {
    // 2.1 判断参数的有效性
    if (config.id < -1 ||
        (config.maxRetransmits && *config.maxRetransmits < 0) ||
        (config.maxRetransmitTime && *config.maxRetransmitTime < 0)) {
      RTC_LOG(LS_ERROR) << "Failed to initialize the SCTP data channel due to "
                           "invalid DataChannelInit.";
      return false;
    }
    // 2.2 按最大重传次数或最大重传时间来确定重传规则，二者不能同时存在
    if (config.maxRetransmits && config.maxRetransmitTime) {
      RTC_LOG(LS_ERROR)
          << "maxRetransmits and maxRetransmitTime should not be both set.";
      return false;
    }
    config_ = config;
    // 2.3 根据握手角色，确定本端握手初始状态
    switch (config_.open_handshake_role) {
      // 2.3.1 KNone表示不在此进行协商，进行带外协商，因此，状态置为已协商完成的
      //       kHandshakeReady状态即可。
      case webrtc::InternalDataChannelInit::kNone:  // pre-negotiated
        handshake_state_ = kHandshakeReady;
        break;
      // 2.3.2 kOpener表示通道打开者，主动发送Open消息方，状态置为kHandshakeShouldSendOpen
      //       表示需要但还未发送Open消息
      case webrtc::InternalDataChannelInit::kOpener:
        handshake_state_ = kHandshakeShouldSendOpen;
        break;
      // 2.3.3 kAcker表示通道的被动打开方，因此状态设置为kHandshakeShouldSendAck
      //       表示下一次要发送Ack，但还未发送的状态
      case webrtc::InternalDataChannelInit::kAcker:
        handshake_state_ = kHandshakeShouldSendAck;
        break;
    }

    // 2.4 尝试关联provider提供的底层transport，以防transport已经创建好了，错过其发出的
    //   ready信号
    // Try to connect to the transport in case the transport channel already
    // exists.
    OnTransportChannelCreated();

    // 2.5 如果底层transport已经是可以发送数据的状态（因为初始化通道ok的信号可能先于
    //    DataChannel创建被发送），以异步的方式来执行OnChannelReady(true)是因为
    //    在当前方法返回前，上层的对象还没建立起连接.
    // Checks if the transport is ready to send because the initial channel
    // ready signal may have been sent before the DataChannel creation.
    // This has to be done async because the upper layer objects (e.g.
    // Chrome glue and WebKit) are not wired up properly until after this
    // function returns.
    if (provider_->ReadyToSendData()) {
      invoker_.AsyncInvoke<void>(RTC_FROM_HERE, rtc::Thread::Current(),
                                 [this] { OnChannelReady(true); });
    }
  }

  return true;
}

之前我们提到RTP是会被淘汰的方式，SCTP是当前主流方式，因此，我们逮着SCTP来说明。DataChannel初始过程中，最重要的莫过于调用OnTransportChannelCreated()，使得provider将上层的DataChannel与底层的Transport对象给联系起来。我们来重点看下该方法。

2.3.3 DataChannel与底层Transport的关联

void DataChannel::OnTransportChannelCreated() {
  // 1. 只有类SCTP才需要进行关联
  RTC_DCHECK(IsSctpLike(data_channel_type_));
  // 2. 进行关联
  if (!connected_to_provider_) {
    connected_to_provider_ = provider_->ConnectDataChannel(this);
  }
  // 3. 关联时，sid会被清掉，因此，再设置一次。
  // The sid may have been unassigned when provider_->ConnectDataChannel was
  // done. So always add the streams even if connected_to_provider_ is true.
  if (config_.id >= 0) {
    provider_->AddSctpDataStream(config_.id);
  }
}

进一步看下真正的关联实现：

bool DataChannelController::ConnectDataChannel(
    DataChannel* webrtc_data_channel) {
  // 1. 必须运行在信令线程
  RTC_DCHECK_RUN_ON(signaling_thread());
 
  // 2. 如果底层传输通道还不存在，则不需要绑定了
  //    rtp_data_channel是RTP协议的底层Transport
  //    data_channel_transport是sctp协议的底层transport
  if (!rtp_data_channel() && !data_channel_transport()) {
    // Don't log an error here, because DataChannels are expected to call
    // ConnectDataChannel in this state. It's the only way to initially tell
    // whether or not the underlying transport is ready.
    return false;
  }
  
  // 3. 如果sctp协议的底层transport存在，则进行相关信号绑定。请注意：
  //    信号的发射者是DataChannelController，而非transport本身；
  //    信号的接收者是上层的DataChannel对象；
  //    势必.....DataChannelController还得与底层transport进行
  //    对应的关联...如何关联，往后看
  if (data_channel_transport()) {
    // 3.1 底层Transport处于可写状态
    SignalDataChannelTransportWritable_s.connect(webrtc_data_channel,
                                                 &DataChannel::OnChannelReady);
    // 3.2 底层Transport收到data                                             
    SignalDataChannelTransportReceivedData_s.connect(
        webrtc_data_channel, &DataChannel::OnDataReceived);
    // 3.3 底层Transport处于关闭过程中
    SignalDataChannelTransportChannelClosing_s.connect(
        webrtc_data_channel, &DataChannel::OnClosingProcedureStartedRemotely);
    // 3.4 底层Transport处于已关闭状态
    SignalDataChannelTransportChannelClosed_s.connect(
        webrtc_data_channel, &DataChannel::OnClosingProcedureComplete);
  }

  // 4. 如果是rtp协议的底层传输通道存在，则也进行相关信号绑定，状态没有sctp那么多
  //    并且与3应该是不会同时存在的，并且注意：
  //    信号发送者是底层传输通道，不需要provider做二道贩子
  //    信号接收者是上层DataChannel。
  if (rtp_data_channel()) {
    // 4.1 底层通道已处于可发送状态
    rtp_data_channel()->SignalReadyToSendData.connect(
        webrtc_data_channel, &DataChannel::OnChannelReady);
    // 4.2 底层通道有数据到达
    rtp_data_channel()->SignalDataReceived.connect(
        webrtc_data_channel, &DataChannel::OnDataReceived);
  }
  return true;
}

代码分析到这儿，DataChannel创建过程也分析完了，可能还会有懵逼的地方。比如，对于SCTP协议的传输，如上代码所示，DataChannelController做了二道贩子，在底层的Transport与DataChannel之间拉起了皮条。那么DataChannelController是如何与Transport勾搭上的呢？还有几个问题：

DataChannelController这个对象是什么时候创建的呢？
SCTP底层传输对象DataChannelTransportInterface到底实体类是哪个？什么时候创建的？
DataChannelController与DataChannelTransportInterface是如何建立关联，又是在何时建立的关联？

由于本篇文章已经很长了，打算另起一篇文章来说明下DataChannel相关的这几个类，并回答上述几个问题。WebRTC源码分析——DataChannel及其相关类

3. 总结

回顾下上述所说内容，捡要点做下总结：

DataChannel的底层传输实际上可以是SCTP传输，也可以是RTP传输。但是我们需要了解到RTP传输方式是将要被淘汰的方式。因此，以后分析只需要关注SCTP是如何做的即可。
创建PC时，应用层传输的RTCConfiguration中的几个字段决定了我们创建DataChannel是采用何种底层传输，细节可以再看看上文。当然，默认情况是采用SCTP。
创建DataChannel时传入的结构体DataChannelInit决定了底层传输数据的可靠级别：可靠、部分可靠、不可靠；也决定了协商方式：是进行带外协商，还是带内协商。
当使用带内协商时，SCTP传输在协商阶段是有角色的，一方是主动打开方，一方是被动打开方。主动打开方在底层通道链接建立后，需要主动发送Open消息，被动打开方需要回复Ack。
WebRTC中的SCTP并非是OSI模型中的传输层协议，而是应用层协议，并且使用STCP时，必须使用DLS。如下图所示：
DataChannel是WebRTC数据通道的顶层对象，底层根据选择的传输方式创建的底层传输对象是不一样的，比如支持SCTP协议的传输对象是实现了接口DataChannelTransportInterface的SctpDataChannelTransport对象；而支持RTP协议的传输对象层对象是RtpDataChannel对象。
DataChannel需要与底层传输对象SctpDataChannelTransport建立关联以便监控传输状态以及收发数据包。但二者中间隔了DataChannelController对象，DataChannelController起着桥梁作用。

ice_ly000

关注

14
点赞
踩
17

收藏

觉得还不错? 一键收藏
2
评论
WebRTC源码分析-呼叫建立过程之四（下）(创建数据通道DataChannel)

1. 引言创建完PeerConnectionFactory 和 PeerConnection这两个API层的操盘对象之后，紧接着需要初始化本地的媒体，也即创建本地的音频轨、视频轨、数据通道，并将这些本地的媒体轨道添加到PeerConnection对象中。如图中红色标注所示。本文将详细描述上述数据通道的创建细节。2. 数据通道的创建3. 数据通道对象4. 总结...
复制链接

扫一扫

专栏目录