webrtc_m130/pc/jsep_transport_controller.h

545 lines
24 KiB
C
Raw Normal View History

/*
* Copyright 2017 The WebRTC Project Authors. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#ifndef PC_JSEP_TRANSPORT_CONTROLLER_H_
#define PC_JSEP_TRANSPORT_CONTROLLER_H_
#include <map>
#include <memory>
#include <string>
#include <utility>
#include <vector>
#include "api/candidate.h"
#include "api/crypto/crypto_options.h"
#include "api/ice_transport_factory.h"
#include "api/peer_connection_interface.h"
#include "api/rtc_event_log/rtc_event_log.h"
#include "api/transport/media/media_transport_config.h"
#include "api/transport/media/media_transport_interface.h"
#include "media/sctp/sctp_transport_internal.h"
#include "p2p/base/dtls_transport.h"
#include "p2p/base/dtls_transport_factory.h"
#include "p2p/base/p2p_transport_channel.h"
#include "pc/channel.h"
#include "pc/dtls_srtp_transport.h"
#include "pc/dtls_transport.h"
#include "pc/jsep_transport.h"
#include "pc/rtp_transport.h"
#include "pc/srtp_transport.h"
#include "rtc_base/async_invoker.h"
#include "rtc_base/constructor_magic.h"
#include "rtc_base/ref_counted_object.h"
#include "rtc_base/third_party/sigslot/sigslot.h"
namespace rtc {
class Thread;
class PacketTransportInternal;
} // namespace rtc
namespace webrtc {
class JsepTransportController : public sigslot::has_slots<> {
public:
// Used when the RtpTransport/DtlsTransport of the m= section is changed
// because the section is rejected or BUNDLE is enabled.
class Observer {
public:
virtual ~Observer() {}
// Returns true if media associated with |mid| was successfully set up to be
// demultiplexed on |rtp_transport|. Could return false if two bundled m=
// sections use the same SSRC, for example.
Changes to enable use of DatagramTransport as a data channel transport. PeerConnection now has a new setting in RTCConfiguration to enable use of datagram transport for data channels. There is also a corresponding field trial, which has both a kill-switch and a way to change the default value. PeerConnection's interaction with MediaTransport for data channels has been refactored to work with DataChannelTransportInterface instead. Adds a DataChannelState and OnStateChanged() to the DataChannelSink callbacks. This allows PeerConnection to listen to the data channel's state directly, instead of indirectly by monitoring media transport state. This is necessary to enable use of non-media-transport (eg. datagram transport) data channel transports. For now, PeerConnection watches the state through MediaTransport as well. This will persist until MediaTransport implements the new callback. Datagram transport use is negotiated. As such, an offer that requests to use datagram transport for data channels may be rejected by the answerer. If the offer includes DTLS, the data channels will be negotiated as SCTP/DTLS data channels with an extra x-opaque parameter for datagram transport. If the opaque parameter is rejected (by an answerer without datagram support), the offerer may fall back to SCTP. If DTLS is not enabled, there is no viable fallback. In this case, the data channels are negotiated as media transport data channels. If the receiver does not understand the x-opaque line, it will reject these data channels, and the offerer's data channels will be closed. Bug: webrtc:9719 Change-Id: Ic1bf3664c4bcf9d754482df59897f5f72fe68fcc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147702 Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28932}
2019-08-21 10:44:59 -07:00
//
// If a data channel transport must be negotiated, |data_channel_transport|
// and |negotiation_state| indicate negotiation status. If
// |data_channel_transport| is null, the data channel transport should not
// be used. Otherwise, the value is a pointer to the transport to be used
// for data channels on |mid|, if any.
//
// The observer should not send data on |data_channel_transport| until
// |negotiation_state| is provisional or final. It should not delete
// |data_channel_transport| or any fallback transport until
// |negotiation_state| is final.
virtual bool OnTransportChanged(
const std::string& mid,
RtpTransportInternal* rtp_transport,
rtc::scoped_refptr<DtlsTransport> dtls_transport,
Changes to enable use of DatagramTransport as a data channel transport. PeerConnection now has a new setting in RTCConfiguration to enable use of datagram transport for data channels. There is also a corresponding field trial, which has both a kill-switch and a way to change the default value. PeerConnection's interaction with MediaTransport for data channels has been refactored to work with DataChannelTransportInterface instead. Adds a DataChannelState and OnStateChanged() to the DataChannelSink callbacks. This allows PeerConnection to listen to the data channel's state directly, instead of indirectly by monitoring media transport state. This is necessary to enable use of non-media-transport (eg. datagram transport) data channel transports. For now, PeerConnection watches the state through MediaTransport as well. This will persist until MediaTransport implements the new callback. Datagram transport use is negotiated. As such, an offer that requests to use datagram transport for data channels may be rejected by the answerer. If the offer includes DTLS, the data channels will be negotiated as SCTP/DTLS data channels with an extra x-opaque parameter for datagram transport. If the opaque parameter is rejected (by an answerer without datagram support), the offerer may fall back to SCTP. If DTLS is not enabled, there is no viable fallback. In this case, the data channels are negotiated as media transport data channels. If the receiver does not understand the x-opaque line, it will reject these data channels, and the offerer's data channels will be closed. Bug: webrtc:9719 Change-Id: Ic1bf3664c4bcf9d754482df59897f5f72fe68fcc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147702 Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28932}
2019-08-21 10:44:59 -07:00
MediaTransportInterface* media_transport,
Reland "Reland "Refactor SCTP data channels to use DataChannelTransportInterface."" This is a reland of 487f9a17e426fd14bb06b13e861071b3f15d119b Original change's description: > Reland "Refactor SCTP data channels to use DataChannelTransportInterface." > > Also clears SctpTransport before deleting JsepTransport. > > SctpTransport is ref-counted, but the underlying transport is deleted when > JsepTransport clears the rtp_dtls_transport. This results in crashes when > usrsctp attempts to send outgoing packets through a dangling pointer to the > underlying transport. > > Clearing SctpTransport before DtlsTransport removes the pointer to the > underlying transport before it becomes invalid. > > This fixes a crash in chromium's web platform tests (see > https://chromium-review.googlesource.com/c/chromium/src/+/1776711). > > Original change's description: > > Refactor SCTP data channels to use DataChannelTransportInterface. > > > > This change moves SctpTransport to be owned by JsepTransport, which now > > holds a DataChannelTransport implementation for SCTP when it is used for > > data channels. > > > > This simplifies negotiation and fallback to SCTP. Negotiation can now > > use a composite DataChannelTransport, just as negotiation for RTP uses a > > composite RTP transport. > > > > PeerConnection also has one fewer way it needs to manage data channels. > > It now handles SCTP and datagram- or media-transport-based data channels > > the same way. > > > > There are a few leaky abstractions left. For example, PeerConnection > > calls Start() on the SctpTransport at a particular point in negotiation, > > but does not need to call this for other transports. Similarly, PC > > exposes an interface to the SCTP transport directly to the user; there > > is no equivalent for other transports. > > Bug: webrtc:9719 > Change-Id: I64e94b88afb119fdbf5f22750f88c8a084d53937 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151981 > Reviewed-by: Benjamin Wright <benwright@webrtc.org> > Reviewed-by: Steve Anton <steveanton@webrtc.org> > Commit-Queue: Benjamin Wright <benwright@webrtc.org> > Commit-Queue: Bjorn Mellem <mellem@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#29120} Bug: webrtc:9719 Change-Id: I28481a3de64a3506bc57748106383eeba4ef205c Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152740 Reviewed-by: Artem Titov <titovartem@webrtc.org> Reviewed-by: Benjamin Wright <benwright@webrtc.org> Reviewed-by: Seth Hampson <shampson@webrtc.org> Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29290}
2019-09-23 14:53:54 -07:00
DataChannelTransportInterface* data_channel_transport) = 0;
};
struct Config {
// If |redetermine_role_on_ice_restart| is true, ICE role is redetermined
// upon setting a local transport description that indicates an ICE
// restart.
bool redetermine_role_on_ice_restart = true;
rtc::SSLProtocolVersion ssl_max_version = rtc::SSL_PROTOCOL_DTLS_12;
// |crypto_options| is used to determine if created DTLS transports
// negotiate GCM crypto suites or not.
Reland "Move CryptoOptions to api/crypto from rtc_base/sslstreamadapter.h" Promotes rtc::CryptoOptions to webrtc::CryptoOptions converting it from class that only handles SRTP configuration to a more generic structure that can be used and extended for all per peer connection CryptoOptions that can be on a given PeerConnection. Now all SRTP related options are under webrtc::CryptoOptions::Srtp and can be accessed as crypto_options.srtp.whatever_option_name. This is more inline with other structures we have in WebRTC such as VideoConfig. As additional features are added over time this will allow the structure to remain compartmentalized and concerned components can only request a subset of the overall configuration structure e.g: void MySrtpFunction(const webrtc::CryptoOptions::Srtp& srtp_config); In addition to this it made little sense for sslstreamadapter.h to hold all Srtp related configuration options. The header has become loo large and takes on too many responsibilities and spilting this up will lead to more maintainable code going forward. This will be used in a future CL to enable configuration options for the newly supported Frame Crypto. Reland Fix: - cryptooptions.h - now has enable_aes128_sha1_32_crypto_cipher as an optional root level configuration. - peerconnectionfactory - If this optional is set will now overwrite the underyling value. This along with the other field will be deprecated once dependent projects are updated. TBR=sakal@webrtc.org,kthelgason@webrtc.org,emadomara@webrtc.org,qingsi@webrtc.org Bug: webrtc:9681 Change-Id: Iaa6b741baafb85d352e42f54226119f19d97151d Reviewed-on: https://webrtc-review.googlesource.com/c/105560 Reviewed-by: Benjamin Wright <benwright@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Reviewed-by: Emad Omara <emadomara@webrtc.org> Commit-Queue: Benjamin Wright <benwright@webrtc.org> Cr-Commit-Position: refs/heads/master@{#25135}
2018-10-11 15:33:17 -07:00
webrtc::CryptoOptions crypto_options;
PeerConnectionInterface::BundlePolicy bundle_policy =
PeerConnectionInterface::kBundlePolicyBalanced;
PeerConnectionInterface::RtcpMuxPolicy rtcp_mux_policy =
PeerConnectionInterface::kRtcpMuxPolicyRequire;
bool disable_encryption = false;
bool enable_external_auth = false;
// Used to inject the ICE/DTLS transports created externally.
webrtc::IceTransportFactory* ice_transport_factory = nullptr;
cricket::DtlsTransportFactory* dtls_transport_factory = nullptr;
Observer* transport_observer = nullptr;
// Must be provided and valid for the lifetime of the
// JsepTransportController instance.
std::function<void(const rtc::CopyOnWriteBuffer& packet,
int64_t packet_time_us)>
rtcp_handler;
bool active_reset_srtp_params = false;
RtcEventLog* event_log = nullptr;
Reland "Reland "Refactor SCTP data channels to use DataChannelTransportInterface."" This is a reland of 487f9a17e426fd14bb06b13e861071b3f15d119b Original change's description: > Reland "Refactor SCTP data channels to use DataChannelTransportInterface." > > Also clears SctpTransport before deleting JsepTransport. > > SctpTransport is ref-counted, but the underlying transport is deleted when > JsepTransport clears the rtp_dtls_transport. This results in crashes when > usrsctp attempts to send outgoing packets through a dangling pointer to the > underlying transport. > > Clearing SctpTransport before DtlsTransport removes the pointer to the > underlying transport before it becomes invalid. > > This fixes a crash in chromium's web platform tests (see > https://chromium-review.googlesource.com/c/chromium/src/+/1776711). > > Original change's description: > > Refactor SCTP data channels to use DataChannelTransportInterface. > > > > This change moves SctpTransport to be owned by JsepTransport, which now > > holds a DataChannelTransport implementation for SCTP when it is used for > > data channels. > > > > This simplifies negotiation and fallback to SCTP. Negotiation can now > > use a composite DataChannelTransport, just as negotiation for RTP uses a > > composite RTP transport. > > > > PeerConnection also has one fewer way it needs to manage data channels. > > It now handles SCTP and datagram- or media-transport-based data channels > > the same way. > > > > There are a few leaky abstractions left. For example, PeerConnection > > calls Start() on the SctpTransport at a particular point in negotiation, > > but does not need to call this for other transports. Similarly, PC > > exposes an interface to the SCTP transport directly to the user; there > > is no equivalent for other transports. > > Bug: webrtc:9719 > Change-Id: I64e94b88afb119fdbf5f22750f88c8a084d53937 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151981 > Reviewed-by: Benjamin Wright <benwright@webrtc.org> > Reviewed-by: Steve Anton <steveanton@webrtc.org> > Commit-Queue: Benjamin Wright <benwright@webrtc.org> > Commit-Queue: Bjorn Mellem <mellem@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#29120} Bug: webrtc:9719 Change-Id: I28481a3de64a3506bc57748106383eeba4ef205c Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152740 Reviewed-by: Artem Titov <titovartem@webrtc.org> Reviewed-by: Benjamin Wright <benwright@webrtc.org> Reviewed-by: Seth Hampson <shampson@webrtc.org> Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29290}
2019-09-23 14:53:54 -07:00
// Factory for SCTP transports.
cricket::SctpTransportInternalFactory* sctp_factory = nullptr;
// Whether media transport is used for media.
bool use_media_transport_for_media = false;
// Whether media transport is used for data channels.
bool use_media_transport_for_data_channels = false;
// Whether an RtpMediaTransport should be created as default, when no
// MediaTransportFactory is provided.
bool use_rtp_media_transport = false;
// Use encrypted datagram transport to send packets.
bool use_datagram_transport = false;
Changes to enable use of DatagramTransport as a data channel transport. PeerConnection now has a new setting in RTCConfiguration to enable use of datagram transport for data channels. There is also a corresponding field trial, which has both a kill-switch and a way to change the default value. PeerConnection's interaction with MediaTransport for data channels has been refactored to work with DataChannelTransportInterface instead. Adds a DataChannelState and OnStateChanged() to the DataChannelSink callbacks. This allows PeerConnection to listen to the data channel's state directly, instead of indirectly by monitoring media transport state. This is necessary to enable use of non-media-transport (eg. datagram transport) data channel transports. For now, PeerConnection watches the state through MediaTransport as well. This will persist until MediaTransport implements the new callback. Datagram transport use is negotiated. As such, an offer that requests to use datagram transport for data channels may be rejected by the answerer. If the offer includes DTLS, the data channels will be negotiated as SCTP/DTLS data channels with an extra x-opaque parameter for datagram transport. If the opaque parameter is rejected (by an answerer without datagram support), the offerer may fall back to SCTP. If DTLS is not enabled, there is no viable fallback. In this case, the data channels are negotiated as media transport data channels. If the receiver does not understand the x-opaque line, it will reject these data channels, and the offerer's data channels will be closed. Bug: webrtc:9719 Change-Id: Ic1bf3664c4bcf9d754482df59897f5f72fe68fcc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147702 Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28932}
2019-08-21 10:44:59 -07:00
// Use datagram transport's implementation of data channels instead of SCTP.
bool use_datagram_transport_for_data_channels = false;
// Whether |use_datagram_transport_for_data_channels| applies to outgoing
// calls. If true, |use_datagram_transport_for_data_channels| applies only
// to incoming calls.
bool use_datagram_transport_for_data_channels_receive_only = false;
// Optional media transport factory (experimental). If provided it will be
// used to create media_transport (as long as either
// |use_media_transport_for_media| or
// |use_media_transport_for_data_channels| is set to true). However, whether
// it will be used to send / receive audio and video frames instead of RTP
// is determined by |use_media_transport_for_media|. Note that currently
// media_transport co-exists with RTP / RTCP transports and may use the same
// underlying ICE transport.
MediaTransportFactory* media_transport_factory = nullptr;
};
// The ICE related events are signaled on the |signaling_thread|.
// All the transport related methods are called on the |network_thread|.
JsepTransportController(rtc::Thread* signaling_thread,
rtc::Thread* network_thread,
cricket::PortAllocator* port_allocator,
AsyncResolverFactory* async_resolver_factory,
Config config);
virtual ~JsepTransportController();
// The main method to be called; applies a description at the transport
// level, creating/destroying transport objects as needed and updating their
// properties. This includes RTP, DTLS, and ICE (but not SCTP). At least not
// yet? May make sense to in the future.
RTCError SetLocalDescription(SdpType type,
const cricket::SessionDescription* description);
RTCError SetRemoteDescription(SdpType type,
const cricket::SessionDescription* description);
// Get transports to be used for the provided |mid|. If bundling is enabled,
// calling GetRtpTransport for multiple MIDs may yield the same object.
RtpTransportInternal* GetRtpTransport(const std::string& mid) const;
cricket::DtlsTransportInternal* GetDtlsTransport(const std::string& mid);
const cricket::DtlsTransportInternal* GetRtcpDtlsTransport(
const std::string& mid) const;
// Gets the externally sharable version of the DtlsTransport.
rtc::scoped_refptr<webrtc::DtlsTransport> LookupDtlsTransportByMid(
const std::string& mid);
Reland "Reland "Refactor SCTP data channels to use DataChannelTransportInterface."" This is a reland of 487f9a17e426fd14bb06b13e861071b3f15d119b Original change's description: > Reland "Refactor SCTP data channels to use DataChannelTransportInterface." > > Also clears SctpTransport before deleting JsepTransport. > > SctpTransport is ref-counted, but the underlying transport is deleted when > JsepTransport clears the rtp_dtls_transport. This results in crashes when > usrsctp attempts to send outgoing packets through a dangling pointer to the > underlying transport. > > Clearing SctpTransport before DtlsTransport removes the pointer to the > underlying transport before it becomes invalid. > > This fixes a crash in chromium's web platform tests (see > https://chromium-review.googlesource.com/c/chromium/src/+/1776711). > > Original change's description: > > Refactor SCTP data channels to use DataChannelTransportInterface. > > > > This change moves SctpTransport to be owned by JsepTransport, which now > > holds a DataChannelTransport implementation for SCTP when it is used for > > data channels. > > > > This simplifies negotiation and fallback to SCTP. Negotiation can now > > use a composite DataChannelTransport, just as negotiation for RTP uses a > > composite RTP transport. > > > > PeerConnection also has one fewer way it needs to manage data channels. > > It now handles SCTP and datagram- or media-transport-based data channels > > the same way. > > > > There are a few leaky abstractions left. For example, PeerConnection > > calls Start() on the SctpTransport at a particular point in negotiation, > > but does not need to call this for other transports. Similarly, PC > > exposes an interface to the SCTP transport directly to the user; there > > is no equivalent for other transports. > > Bug: webrtc:9719 > Change-Id: I64e94b88afb119fdbf5f22750f88c8a084d53937 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151981 > Reviewed-by: Benjamin Wright <benwright@webrtc.org> > Reviewed-by: Steve Anton <steveanton@webrtc.org> > Commit-Queue: Benjamin Wright <benwright@webrtc.org> > Commit-Queue: Bjorn Mellem <mellem@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#29120} Bug: webrtc:9719 Change-Id: I28481a3de64a3506bc57748106383eeba4ef205c Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152740 Reviewed-by: Artem Titov <titovartem@webrtc.org> Reviewed-by: Benjamin Wright <benwright@webrtc.org> Reviewed-by: Seth Hampson <shampson@webrtc.org> Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29290}
2019-09-23 14:53:54 -07:00
rtc::scoped_refptr<SctpTransport> GetSctpTransport(
const std::string& mid) const;
MediaTransportConfig GetMediaTransportConfig(const std::string& mid) const;
Changes to enable use of DatagramTransport as a data channel transport. PeerConnection now has a new setting in RTCConfiguration to enable use of datagram transport for data channels. There is also a corresponding field trial, which has both a kill-switch and a way to change the default value. PeerConnection's interaction with MediaTransport for data channels has been refactored to work with DataChannelTransportInterface instead. Adds a DataChannelState and OnStateChanged() to the DataChannelSink callbacks. This allows PeerConnection to listen to the data channel's state directly, instead of indirectly by monitoring media transport state. This is necessary to enable use of non-media-transport (eg. datagram transport) data channel transports. For now, PeerConnection watches the state through MediaTransport as well. This will persist until MediaTransport implements the new callback. Datagram transport use is negotiated. As such, an offer that requests to use datagram transport for data channels may be rejected by the answerer. If the offer includes DTLS, the data channels will be negotiated as SCTP/DTLS data channels with an extra x-opaque parameter for datagram transport. If the opaque parameter is rejected (by an answerer without datagram support), the offerer may fall back to SCTP. If DTLS is not enabled, there is no viable fallback. In this case, the data channels are negotiated as media transport data channels. If the receiver does not understand the x-opaque line, it will reject these data channels, and the offerer's data channels will be closed. Bug: webrtc:9719 Change-Id: Ic1bf3664c4bcf9d754482df59897f5f72fe68fcc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147702 Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28932}
2019-08-21 10:44:59 -07:00
DataChannelTransportInterface* GetDataChannelTransport(
const std::string& mid) const;
// TODO(sukhanov): Deprecate, return only config.
MediaTransportInterface* GetMediaTransport(const std::string& mid) const {
return GetMediaTransportConfig(mid).media_transport;
}
MediaTransportState GetMediaTransportState(const std::string& mid) const;
/*********************
* ICE-related methods
********************/
// This method is public to allow PeerConnection to update it from
// SetConfiguration.
void SetIceConfig(const cricket::IceConfig& config);
// Set the "needs-ice-restart" flag as described in JSEP. After the flag is
// set, offers should generate new ufrags/passwords until an ICE restart
// occurs.
void SetNeedsIceRestartFlag();
// Returns true if the ICE restart flag above was set, and no ICE restart has
// occurred yet for this transport (by applying a local description with
// changed ufrag/password). If the transport has been deleted as a result of
// bundling, returns false.
bool NeedsIceRestart(const std::string& mid) const;
// Start gathering candidates for any new transports, or transports doing an
// ICE restart.
void MaybeStartGathering();
RTCError AddRemoteCandidates(
const std::string& mid,
const std::vector<cricket::Candidate>& candidates);
RTCError RemoveRemoteCandidates(
const std::vector<cricket::Candidate>& candidates);
/**********************
* DTLS-related methods
*********************/
// Specifies the identity to use in this session.
// Can only be called once.
bool SetLocalCertificate(
const rtc::scoped_refptr<rtc::RTCCertificate>& certificate);
rtc::scoped_refptr<rtc::RTCCertificate> GetLocalCertificate(
const std::string& mid) const;
// Caller owns returned certificate chain. This method mainly exists for
// stats reporting.
std::unique_ptr<rtc::SSLCertChain> GetRemoteSSLCertChain(
const std::string& mid) const;
// Get negotiated role, if one has been negotiated.
absl::optional<rtc::SSLRole> GetDtlsRole(const std::string& mid) const;
// TODO(deadbeef): GetStats isn't const because all the way down to
// OpenSSLStreamAdapter, GetSslCipherSuite and GetDtlsSrtpCryptoSuite are not
// const. Fix this.
bool GetStats(const std::string& mid, cricket::TransportStats* stats);
bool initial_offerer() const { return initial_offerer_ && *initial_offerer_; }
void SetActiveResetSrtpParams(bool active_reset_srtp_params);
// Allows to overwrite the settings from config. You may set or reset the
// media transport configuration on the jsep transport controller, as long as
// you did not call 'GetMediaTransport' or 'MaybeCreateJsepTransport'. Once
// Jsep transport is created, you can't change this setting.
void SetMediaTransportSettings(
bool use_media_transport_for_media,
bool use_media_transport_for_data_channels,
bool use_datagram_transport,
bool use_datagram_transport_for_data_channels,
bool use_datagram_transport_for_data_channels_receive_only);
// TODO(elrello): For now the rollback only removes mid to transport mapping
// and deletes unused transport, but doesn't consider anything more complex.
void RollbackTransportForMid(const std::string& mid);
Add x-mt line to the offer. We already support decoding of the x-mt line. This change adds the a=x-mt line to the SDP offer. This is not a backward compatible change for media transport (because of the changes in pre-shared key handling) 1) if media transport is enabled, and SDES is enabled, generate the media transport offer. 2) if media transport generated the offer, add that offer to the x-mt line. 3) in order to create media transport, require an x-mt line (backward incompatible). The way it works is that 1) PeerConnection, on the offerer, asks jsep transport for the configuration of the media transport. 2) Tentative media transport is created in JsepTransportController when that happens. 3) SessionDescription will include configuration from this tentative media transport. 4) When the LocalDescription is set on the offerer, the tentative media transport is promoted to the real media transport. Caveats: - now we really only support MaxBundle. In the previous implementations, two media transports were briefly created in some tests, and the second one was destroyed shortly after instantiation. - we, for now, enforce SDES. In the future, whether SDES is used will be refactored out of the peer connection. In the future (on the callee) we should ignore 'is_media_transport' setting. If Offer contains x-mt, media transport should be used (if the factory is present). However, we need to decide how to negotiate media transport for data channels vs data transport for media (x-mt line at this point doesn't differentiate the two, so we still need to use app setting). This change also removes the negotation of pre-shared key from the a=crypto line. Instead, media transport will have its own, 256bit key. Such key should be transported in the x-mt line. This makes the code much simpler, and simplifies the dependency / a=crypto lines parsing. Also, adds a proper test for the connection re-offer (on both sides: callee and caller). Before, it was possible that media transport could get recreated, based on the offer. The tests we had didn't test this scenario, and the loopback media factory didn't allow for such test. This change adds counts to that loopback media factory, and asserts that only 1 media transport is created, even when there is a re-offer. Bug: webrtc:9719 Change-Id: Ibd8739af90e914da40ab412454bba8e1529f5a01 Reviewed-on: https://webrtc-review.googlesource.com/c/125040 Reviewed-by: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Commit-Queue: Peter Slatala <psla@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26933}
2019-03-01 11:14:05 -08:00
// If media transport is present enabled and supported,
// when this method is called, it creates a media transport and generates its
// offer. The new offer is then returned, and the created media transport will
// subsequently be used.
absl::optional<cricket::SessionDescription::MediaTransportSetting>
GenerateOrGetLastMediaTransportOffer();
Reland: Implement true negotiation for DatagramTransport with fallback to RTP. In short, the caller places a x-opaque line in SDP for each m= section that uses datagram transport. If the answerer supports datagram transport, it will parse this line and create a datagram transport. It will then echo the x-opaque line into the answer (to indicate that it accepted use of datagram transport). If the offer and answer contain exactly the same x-opaque line, both peers will use datagram transport. If the x-opaque line is omitted from the answer (or is different in the answer) they will fall back to RTP. Note that a different x-opaque line in the answer means the answerer did not understand something in the negotiation proto. Since WebRTC cannot know what was misunderstood, or whether it's still possible to use the datagram transport, it must fall back to RTP. This may change in the future, possibly by passing the answer to the datagram transport, but it's good enough for now. Negotiation consists of four parts: 1. DatagramTransport exposes transport parameters for both client and server perspectives. The client just echoes what it received from the server (modulo any fields it might not have understood). 2. SDP adds a x-opaque line for opaque transport parameters. Identical to x-mt, but this is specific to datagram transport and goes in each m= section, and appears in the answer as well as the offer. - This is propagated to Jsep as part of the TransportDescription. - SDP files: transport_description.h,cc, transport_description_factory.h,cc, media_session.cc, webrtc_sdp.cc 3. JsepTransport/Controller: - Exposes opaque parameters for each mid (m= section). On offerer, this means pre-allocating a datagram transport and getting its parameters. On the answerer, this means echoing the offerer's parameters. - Uses a composite RTP transport to receive from either default RTP or datagram transport until both offer and answer arrive. - If a provisional answer arrives, sets the composite to send on the provisionally selected transport. - Once both offer and answer are set, deletes the unneeded transports and keeps whichever transport is selected. 4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP. Bug: webrtc:9719 Change-Id: Ifcc428c8d76fb77dcc8abaa79507c620bcfb31b9 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140920 Reviewed-by: Steve Anton <steveanton@webrtc.org> Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28198}
2019-06-07 10:28:06 -07:00
// Gets the transport parameters for the transport identified by |mid|.
// If |mid| is bundled, returns the parameters for the bundled transport.
// If the transport for |mid| has not been created yet, it may be allocated in
// order to generate transport parameters.
absl::optional<cricket::OpaqueTransportParameters> GetTransportParameters(
const std::string& mid);
// All of these signals are fired on the signaling thread.
// If any transport failed => failed,
// Else if all completed => completed,
// Else if all connected => connected,
// Else => connecting
sigslot::signal1<cricket::IceConnectionState> SignalIceConnectionState;
sigslot::signal1<PeerConnectionInterface::PeerConnectionState>
SignalConnectionState;
sigslot::signal1<PeerConnectionInterface::IceConnectionState>
SignalStandardizedIceConnectionState;
// If all transports done gathering => complete,
// Else if any are gathering => gathering,
// Else => new
sigslot::signal1<cricket::IceGatheringState> SignalIceGatheringState;
// (mid, candidates)
sigslot::signal2<const std::string&, const std::vector<cricket::Candidate>&>
SignalIceCandidatesGathered;
sigslot::signal1<const cricket::IceCandidateErrorEvent&>
SignalIceCandidateError;
sigslot::signal1<const std::vector<cricket::Candidate>&>
SignalIceCandidatesRemoved;
sigslot::signal1<const cricket::CandidatePairChangeEvent&>
SignalIceCandidatePairChanged;
sigslot::signal1<rtc::SSLHandshakeError> SignalDtlsHandshakeError;
private:
RTCError ApplyDescription_n(bool local,
SdpType type,
const cricket::SessionDescription* description);
RTCError ValidateAndMaybeUpdateBundleGroup(
bool local,
SdpType type,
const cricket::SessionDescription* description);
RTCError ValidateContent(const cricket::ContentInfo& content_info);
void HandleRejectedContent(const cricket::ContentInfo& content_info,
const cricket::SessionDescription* description);
bool HandleBundledContent(const cricket::ContentInfo& content_info);
bool SetTransportForMid(const std::string& mid,
cricket::JsepTransport* jsep_transport);
void RemoveTransportForMid(const std::string& mid);
cricket::JsepTransportDescription CreateJsepTransportDescription(
const cricket::ContentInfo& content_info,
const cricket::TransportInfo& transport_info,
const std::vector<int>& encrypted_extension_ids,
Add an alt-protocol to SDP to indicate which m= sections use a plugin transport. The plugin transport parameters (a=x-opaque: lines) relate to how to create and set up a plugin transport. When SDP bundle is used, the x-opaque line needs to be copied into the bundled m= section. This means x-opaque can appear on a section even if the offerer does not intend to use the transport for the media described by that section. Consequently, the answerer cannot currently tell whether the caller is offering an alternate transport for media, data, or both. This change adds an a=x-alt-protocol: line to SDP. The value following this line matches the <protocol> part of the x-opaque:<protocol>:<params> line. However, alt-protocol is not bundled--it only ever applies to the m= section that contains the line. This allows the offerer to express which m= sections should actually use an alternate transport, even in the case of bundle. Note that this is still limited by the available configuration options: datagram transport can be used for media (audio + video) and/or data. It is still not possible to use it for audio but not video, or vice versa. PeerConnection places an alt-protocol line in each media (audio/video) m= section if it is configured to use a datagram transport for media. It places an alt-protocol line in each data m= section if it is configured to use a datagram transport for data channels. PeerConnection leaves alt-protocol in media (audio/video) m= sections of the answer if it is configured to use a datagram transport for media, and in data m= sections of the answer if it is configured to use a datagram transport for data channels. JsepTransport now negotiates use of the datagram transport independently for media and data channels. It only uses it for media if the m= sections for bundled audio/video have an alt-protocol line matching the x-opaque protocol, and only uses it for data channels if a bundled m= section for data has an alt-protocol line matching the x-opaque protocol. Bug: webrtc:9719 Change-Id: I773e4fc10c57d815afcd76a2a74da38dd0c52b3b Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154763 Reviewed-by: Steve Anton <steveanton@webrtc.org> Reviewed-by: Seth Hampson <shampson@webrtc.org> Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29351}
2019-09-30 15:12:47 -07:00
int rtp_abs_sendtime_extn_id,
absl::optional<std::string> media_alt_protocol,
absl::optional<std::string> data_alt_protocol);
absl::optional<std::string> bundled_mid() const {
absl::optional<std::string> bundled_mid;
if (bundle_group_ && bundle_group_->FirstContentName()) {
bundled_mid = *(bundle_group_->FirstContentName());
}
return bundled_mid;
}
bool IsBundled(const std::string& mid) const {
return bundle_group_ && bundle_group_->HasContentName(mid);
}
bool ShouldUpdateBundleGroup(SdpType type,
const cricket::SessionDescription* description);
std::vector<int> MergeEncryptedHeaderExtensionIdsForBundle(
const cricket::SessionDescription* description);
std::vector<int> GetEncryptedHeaderExtensionIds(
const cricket::ContentInfo& content_info);
Add an alt-protocol to SDP to indicate which m= sections use a plugin transport. The plugin transport parameters (a=x-opaque: lines) relate to how to create and set up a plugin transport. When SDP bundle is used, the x-opaque line needs to be copied into the bundled m= section. This means x-opaque can appear on a section even if the offerer does not intend to use the transport for the media described by that section. Consequently, the answerer cannot currently tell whether the caller is offering an alternate transport for media, data, or both. This change adds an a=x-alt-protocol: line to SDP. The value following this line matches the <protocol> part of the x-opaque:<protocol>:<params> line. However, alt-protocol is not bundled--it only ever applies to the m= section that contains the line. This allows the offerer to express which m= sections should actually use an alternate transport, even in the case of bundle. Note that this is still limited by the available configuration options: datagram transport can be used for media (audio + video) and/or data. It is still not possible to use it for audio but not video, or vice versa. PeerConnection places an alt-protocol line in each media (audio/video) m= section if it is configured to use a datagram transport for media. It places an alt-protocol line in each data m= section if it is configured to use a datagram transport for data channels. PeerConnection leaves alt-protocol in media (audio/video) m= sections of the answer if it is configured to use a datagram transport for media, and in data m= sections of the answer if it is configured to use a datagram transport for data channels. JsepTransport now negotiates use of the datagram transport independently for media and data channels. It only uses it for media if the m= sections for bundled audio/video have an alt-protocol line matching the x-opaque protocol, and only uses it for data channels if a bundled m= section for data has an alt-protocol line matching the x-opaque protocol. Bug: webrtc:9719 Change-Id: I773e4fc10c57d815afcd76a2a74da38dd0c52b3b Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154763 Reviewed-by: Steve Anton <steveanton@webrtc.org> Reviewed-by: Seth Hampson <shampson@webrtc.org> Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29351}
2019-09-30 15:12:47 -07:00
// Extracts the alt-protocol settings that apply to the bundle group.
RTCError GetAltProtocolsForBundle(
const cricket::SessionDescription* description,
absl::optional<std::string>* media_alt_protocol,
absl::optional<std::string>* data_alt_protocol);
int GetRtpAbsSendTimeHeaderExtensionId(
const cricket::ContentInfo& content_info);
// This method takes the BUNDLE group into account. If the JsepTransport is
// destroyed because of BUNDLE, it would return the transport which other
// transports are bundled on (In current implementation, it is the first
// content in the BUNDLE group).
const cricket::JsepTransport* GetJsepTransportForMid(
const std::string& mid) const;
cricket::JsepTransport* GetJsepTransportForMid(const std::string& mid);
// Get the JsepTransport without considering the BUNDLE group. Return nullptr
// if the JsepTransport is destroyed.
const cricket::JsepTransport* GetJsepTransportByName(
const std::string& transport_name) const;
cricket::JsepTransport* GetJsepTransportByName(
const std::string& transport_name);
// Creates jsep transport. Noop if transport is already created.
// Transport is created either during SetLocalDescription (|local| == true) or
// during SetRemoteDescription (|local| == false). Passing |local| helps to
// differentiate initiator (caller) from answerer (callee).
RTCError MaybeCreateJsepTransport(
bool local,
const cricket::ContentInfo& content_info,
const cricket::SessionDescription& description);
Add x-mt line to the offer. We already support decoding of the x-mt line. This change adds the a=x-mt line to the SDP offer. This is not a backward compatible change for media transport (because of the changes in pre-shared key handling) 1) if media transport is enabled, and SDES is enabled, generate the media transport offer. 2) if media transport generated the offer, add that offer to the x-mt line. 3) in order to create media transport, require an x-mt line (backward incompatible). The way it works is that 1) PeerConnection, on the offerer, asks jsep transport for the configuration of the media transport. 2) Tentative media transport is created in JsepTransportController when that happens. 3) SessionDescription will include configuration from this tentative media transport. 4) When the LocalDescription is set on the offerer, the tentative media transport is promoted to the real media transport. Caveats: - now we really only support MaxBundle. In the previous implementations, two media transports were briefly created in some tests, and the second one was destroyed shortly after instantiation. - we, for now, enforce SDES. In the future, whether SDES is used will be refactored out of the peer connection. In the future (on the callee) we should ignore 'is_media_transport' setting. If Offer contains x-mt, media transport should be used (if the factory is present). However, we need to decide how to negotiate media transport for data channels vs data transport for media (x-mt line at this point doesn't differentiate the two, so we still need to use app setting). This change also removes the negotation of pre-shared key from the a=crypto line. Instead, media transport will have its own, 256bit key. Such key should be transported in the x-mt line. This makes the code much simpler, and simplifies the dependency / a=crypto lines parsing. Also, adds a proper test for the connection re-offer (on both sides: callee and caller). Before, it was possible that media transport could get recreated, based on the offer. The tests we had didn't test this scenario, and the loopback media factory didn't allow for such test. This change adds counts to that loopback media factory, and asserts that only 1 media transport is created, even when there is a re-offer. Bug: webrtc:9719 Change-Id: Ibd8739af90e914da40ab412454bba8e1529f5a01 Reviewed-on: https://webrtc-review.googlesource.com/c/125040 Reviewed-by: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Commit-Queue: Peter Slatala <psla@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26933}
2019-03-01 11:14:05 -08:00
// Creates media transport if config wants to use it, and a=x-mt line is
// present for the current media transport. Returned MediaTransportInterface
// is not connected, and must be connected to ICE. You must call
// |GenerateOrGetLastMediaTransportOffer| on the caller before calling
// MaybeCreateMediaTransport.
std::unique_ptr<webrtc::MediaTransportInterface> MaybeCreateMediaTransport(
const cricket::ContentInfo& content_info,
const cricket::SessionDescription& description,
Add x-mt line to the offer. We already support decoding of the x-mt line. This change adds the a=x-mt line to the SDP offer. This is not a backward compatible change for media transport (because of the changes in pre-shared key handling) 1) if media transport is enabled, and SDES is enabled, generate the media transport offer. 2) if media transport generated the offer, add that offer to the x-mt line. 3) in order to create media transport, require an x-mt line (backward incompatible). The way it works is that 1) PeerConnection, on the offerer, asks jsep transport for the configuration of the media transport. 2) Tentative media transport is created in JsepTransportController when that happens. 3) SessionDescription will include configuration from this tentative media transport. 4) When the LocalDescription is set on the offerer, the tentative media transport is promoted to the real media transport. Caveats: - now we really only support MaxBundle. In the previous implementations, two media transports were briefly created in some tests, and the second one was destroyed shortly after instantiation. - we, for now, enforce SDES. In the future, whether SDES is used will be refactored out of the peer connection. In the future (on the callee) we should ignore 'is_media_transport' setting. If Offer contains x-mt, media transport should be used (if the factory is present). However, we need to decide how to negotiate media transport for data channels vs data transport for media (x-mt line at this point doesn't differentiate the two, so we still need to use app setting). This change also removes the negotation of pre-shared key from the a=crypto line. Instead, media transport will have its own, 256bit key. Such key should be transported in the x-mt line. This makes the code much simpler, and simplifies the dependency / a=crypto lines parsing. Also, adds a proper test for the connection re-offer (on both sides: callee and caller). Before, it was possible that media transport could get recreated, based on the offer. The tests we had didn't test this scenario, and the loopback media factory didn't allow for such test. This change adds counts to that loopback media factory, and asserts that only 1 media transport is created, even when there is a re-offer. Bug: webrtc:9719 Change-Id: Ibd8739af90e914da40ab412454bba8e1529f5a01 Reviewed-on: https://webrtc-review.googlesource.com/c/125040 Reviewed-by: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Commit-Queue: Peter Slatala <psla@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26933}
2019-03-01 11:14:05 -08:00
bool local);
// Creates datagram transport if config wants to use it, and a=x-mt line is
// present for the current media transport. Returned
// DatagramTransportInterface is not connected, and must be connected to ICE.
// You must call |GenerateOrGetLastMediaTransportOffer| on the caller before
// calling MaybeCreateDatagramTransport.
std::unique_ptr<webrtc::DatagramTransportInterface>
MaybeCreateDatagramTransport(const cricket::ContentInfo& content_info,
const cricket::SessionDescription& description,
bool local);
void MaybeDestroyJsepTransport(const std::string& mid);
void DestroyAllJsepTransports_n();
void SetIceRole_n(cricket::IceRole ice_role);
cricket::IceRole DetermineIceRole(
cricket::JsepTransport* jsep_transport,
const cricket::TransportInfo& transport_info,
SdpType type,
bool local);
std::unique_ptr<cricket::DtlsTransportInternal> CreateDtlsTransport(
const cricket::ContentInfo& content_info,
cricket::IceTransportInternal* ice,
DatagramTransportInterface* datagram_transport);
rtc::scoped_refptr<webrtc::IceTransportInterface> CreateIceTransport(
const std::string& transport_name,
bool rtcp);
std::unique_ptr<webrtc::RtpTransport> CreateUnencryptedRtpTransport(
const std::string& transport_name,
rtc::PacketTransportInternal* rtp_packet_transport,
rtc::PacketTransportInternal* rtcp_packet_transport);
std::unique_ptr<webrtc::SrtpTransport> CreateSdesTransport(
const std::string& transport_name,
cricket::DtlsTransportInternal* rtp_dtls_transport,
cricket::DtlsTransportInternal* rtcp_dtls_transport);
std::unique_ptr<webrtc::DtlsSrtpTransport> CreateDtlsSrtpTransport(
const std::string& transport_name,
cricket::DtlsTransportInternal* rtp_dtls_transport,
cricket::DtlsTransportInternal* rtcp_dtls_transport);
// Collect all the DtlsTransports, including RTP and RTCP, from the
// JsepTransports. JsepTransportController can iterate all the DtlsTransports
// and update the aggregate states.
std::vector<cricket::DtlsTransportInternal*> GetDtlsTransports();
// Handlers for signals from Transport.
void OnTransportWritableState_n(rtc::PacketTransportInternal* transport);
void OnTransportReceivingState_n(rtc::PacketTransportInternal* transport);
void OnTransportGatheringState_n(cricket::IceTransportInternal* transport);
void OnTransportCandidateGathered_n(cricket::IceTransportInternal* transport,
const cricket::Candidate& candidate);
void OnTransportCandidateError_n(
cricket::IceTransportInternal* transport,
const cricket::IceCandidateErrorEvent& event);
void OnTransportCandidatesRemoved_n(cricket::IceTransportInternal* transport,
const cricket::Candidates& candidates);
void OnTransportRoleConflict_n(cricket::IceTransportInternal* transport);
void OnTransportStateChanged_n(cricket::IceTransportInternal* transport);
void OnMediaTransportStateChanged_n();
void OnTransportCandidatePairChanged_n(
const cricket::CandidatePairChangeEvent& event);
Changes to enable use of DatagramTransport as a data channel transport. PeerConnection now has a new setting in RTCConfiguration to enable use of datagram transport for data channels. There is also a corresponding field trial, which has both a kill-switch and a way to change the default value. PeerConnection's interaction with MediaTransport for data channels has been refactored to work with DataChannelTransportInterface instead. Adds a DataChannelState and OnStateChanged() to the DataChannelSink callbacks. This allows PeerConnection to listen to the data channel's state directly, instead of indirectly by monitoring media transport state. This is necessary to enable use of non-media-transport (eg. datagram transport) data channel transports. For now, PeerConnection watches the state through MediaTransport as well. This will persist until MediaTransport implements the new callback. Datagram transport use is negotiated. As such, an offer that requests to use datagram transport for data channels may be rejected by the answerer. If the offer includes DTLS, the data channels will be negotiated as SCTP/DTLS data channels with an extra x-opaque parameter for datagram transport. If the opaque parameter is rejected (by an answerer without datagram support), the offerer may fall back to SCTP. If DTLS is not enabled, there is no viable fallback. In this case, the data channels are negotiated as media transport data channels. If the receiver does not understand the x-opaque line, it will reject these data channels, and the offerer's data channels will be closed. Bug: webrtc:9719 Change-Id: Ic1bf3664c4bcf9d754482df59897f5f72fe68fcc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/147702 Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Cr-Commit-Position: refs/heads/master@{#28932}
2019-08-21 10:44:59 -07:00
void OnDataChannelTransportNegotiated_n(
cricket::JsepTransport* transport,
Reland "Reland "Refactor SCTP data channels to use DataChannelTransportInterface."" This is a reland of 487f9a17e426fd14bb06b13e861071b3f15d119b Original change's description: > Reland "Refactor SCTP data channels to use DataChannelTransportInterface." > > Also clears SctpTransport before deleting JsepTransport. > > SctpTransport is ref-counted, but the underlying transport is deleted when > JsepTransport clears the rtp_dtls_transport. This results in crashes when > usrsctp attempts to send outgoing packets through a dangling pointer to the > underlying transport. > > Clearing SctpTransport before DtlsTransport removes the pointer to the > underlying transport before it becomes invalid. > > This fixes a crash in chromium's web platform tests (see > https://chromium-review.googlesource.com/c/chromium/src/+/1776711). > > Original change's description: > > Refactor SCTP data channels to use DataChannelTransportInterface. > > > > This change moves SctpTransport to be owned by JsepTransport, which now > > holds a DataChannelTransport implementation for SCTP when it is used for > > data channels. > > > > This simplifies negotiation and fallback to SCTP. Negotiation can now > > use a composite DataChannelTransport, just as negotiation for RTP uses a > > composite RTP transport. > > > > PeerConnection also has one fewer way it needs to manage data channels. > > It now handles SCTP and datagram- or media-transport-based data channels > > the same way. > > > > There are a few leaky abstractions left. For example, PeerConnection > > calls Start() on the SctpTransport at a particular point in negotiation, > > but does not need to call this for other transports. Similarly, PC > > exposes an interface to the SCTP transport directly to the user; there > > is no equivalent for other transports. > > Bug: webrtc:9719 > Change-Id: I64e94b88afb119fdbf5f22750f88c8a084d53937 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151981 > Reviewed-by: Benjamin Wright <benwright@webrtc.org> > Reviewed-by: Steve Anton <steveanton@webrtc.org> > Commit-Queue: Benjamin Wright <benwright@webrtc.org> > Commit-Queue: Bjorn Mellem <mellem@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#29120} Bug: webrtc:9719 Change-Id: I28481a3de64a3506bc57748106383eeba4ef205c Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152740 Reviewed-by: Artem Titov <titovartem@webrtc.org> Reviewed-by: Benjamin Wright <benwright@webrtc.org> Reviewed-by: Seth Hampson <shampson@webrtc.org> Commit-Queue: Bjorn Mellem <mellem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29290}
2019-09-23 14:53:54 -07:00
DataChannelTransportInterface* data_channel_transport);
void UpdateAggregateStates_n();
void OnRtcpPacketReceived_n(rtc::CopyOnWriteBuffer* packet,
int64_t packet_time_us);
void OnDtlsHandshakeError(rtc::SSLHandshakeError error);
rtc::Thread* const signaling_thread_ = nullptr;
rtc::Thread* const network_thread_ = nullptr;
cricket::PortAllocator* const port_allocator_ = nullptr;
AsyncResolverFactory* const async_resolver_factory_ = nullptr;
std::map<std::string, std::unique_ptr<cricket::JsepTransport>>
jsep_transports_by_name_;
// This keeps track of the mapping between media section
// (BaseChannel/SctpTransport) and the JsepTransport underneath.
std::map<std::string, cricket::JsepTransport*> mid_to_transport_;
// Aggregate states for Transports.
// standardized_ice_connection_state_ is intended to replace
// ice_connection_state, see bugs.webrtc.org/9308
cricket::IceConnectionState ice_connection_state_ =
cricket::kIceConnectionConnecting;
PeerConnectionInterface::IceConnectionState
standardized_ice_connection_state_ =
PeerConnectionInterface::kIceConnectionNew;
PeerConnectionInterface::PeerConnectionState combined_connection_state_ =
PeerConnectionInterface::PeerConnectionState::kNew;
cricket::IceGatheringState ice_gathering_state_ = cricket::kIceGatheringNew;
Config config_;
Add x-mt line to the offer. We already support decoding of the x-mt line. This change adds the a=x-mt line to the SDP offer. This is not a backward compatible change for media transport (because of the changes in pre-shared key handling) 1) if media transport is enabled, and SDES is enabled, generate the media transport offer. 2) if media transport generated the offer, add that offer to the x-mt line. 3) in order to create media transport, require an x-mt line (backward incompatible). The way it works is that 1) PeerConnection, on the offerer, asks jsep transport for the configuration of the media transport. 2) Tentative media transport is created in JsepTransportController when that happens. 3) SessionDescription will include configuration from this tentative media transport. 4) When the LocalDescription is set on the offerer, the tentative media transport is promoted to the real media transport. Caveats: - now we really only support MaxBundle. In the previous implementations, two media transports were briefly created in some tests, and the second one was destroyed shortly after instantiation. - we, for now, enforce SDES. In the future, whether SDES is used will be refactored out of the peer connection. In the future (on the callee) we should ignore 'is_media_transport' setting. If Offer contains x-mt, media transport should be used (if the factory is present). However, we need to decide how to negotiate media transport for data channels vs data transport for media (x-mt line at this point doesn't differentiate the two, so we still need to use app setting). This change also removes the negotation of pre-shared key from the a=crypto line. Instead, media transport will have its own, 256bit key. Such key should be transported in the x-mt line. This makes the code much simpler, and simplifies the dependency / a=crypto lines parsing. Also, adds a proper test for the connection re-offer (on both sides: callee and caller). Before, it was possible that media transport could get recreated, based on the offer. The tests we had didn't test this scenario, and the loopback media factory didn't allow for such test. This change adds counts to that loopback media factory, and asserts that only 1 media transport is created, even when there is a re-offer. Bug: webrtc:9719 Change-Id: Ibd8739af90e914da40ab412454bba8e1529f5a01 Reviewed-on: https://webrtc-review.googlesource.com/c/125040 Reviewed-by: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Commit-Queue: Peter Slatala <psla@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26933}
2019-03-01 11:14:05 -08:00
// Early on in the call we don't know if media transport is going to be used,
// but we need to get the server-supported parameters to add to an SDP.
// This server media transport will be promoted to the used media transport
// after the local description is set, and the ownership will be transferred
// to the actual JsepTransport.
// This "offer" media transport is not created if it's done on the party that
// provides answer. This offer media transport is only created once at the
// beginning of the connection, and never again.
std::unique_ptr<MediaTransportInterface> offer_media_transport_ = nullptr;
// Contains the offer of the |offer_media_transport_|, in case if it needs to
// be repeated.
absl::optional<cricket::SessionDescription::MediaTransportSetting>
media_transport_offer_settings_;
// Early on in the call we don't know if datagram transport is going to be
// used, but we need to get the server-supported parameters to add to an SDP.
// This server datagram transport will be promoted to the used datagram
// transport after the local description is set, and the ownership will be
// transferred to the actual JsepTransport. This "offer" datagram transport is
// not created if it's done on the party that provides answer. This offer
// datagram transport is only created once at the beginning of the connection,
// and never again.
std::unique_ptr<DatagramTransportInterface> offer_datagram_transport_ =
nullptr;
// Contains the offer of the |offer_datagram_transport_|, in case if it needs
// to be repeated.
absl::optional<cricket::SessionDescription::MediaTransportSetting>
datagram_transport_offer_settings_;
Add x-mt line to the offer. We already support decoding of the x-mt line. This change adds the a=x-mt line to the SDP offer. This is not a backward compatible change for media transport (because of the changes in pre-shared key handling) 1) if media transport is enabled, and SDES is enabled, generate the media transport offer. 2) if media transport generated the offer, add that offer to the x-mt line. 3) in order to create media transport, require an x-mt line (backward incompatible). The way it works is that 1) PeerConnection, on the offerer, asks jsep transport for the configuration of the media transport. 2) Tentative media transport is created in JsepTransportController when that happens. 3) SessionDescription will include configuration from this tentative media transport. 4) When the LocalDescription is set on the offerer, the tentative media transport is promoted to the real media transport. Caveats: - now we really only support MaxBundle. In the previous implementations, two media transports were briefly created in some tests, and the second one was destroyed shortly after instantiation. - we, for now, enforce SDES. In the future, whether SDES is used will be refactored out of the peer connection. In the future (on the callee) we should ignore 'is_media_transport' setting. If Offer contains x-mt, media transport should be used (if the factory is present). However, we need to decide how to negotiate media transport for data channels vs data transport for media (x-mt line at this point doesn't differentiate the two, so we still need to use app setting). This change also removes the negotation of pre-shared key from the a=crypto line. Instead, media transport will have its own, 256bit key. Such key should be transported in the x-mt line. This makes the code much simpler, and simplifies the dependency / a=crypto lines parsing. Also, adds a proper test for the connection re-offer (on both sides: callee and caller). Before, it was possible that media transport could get recreated, based on the offer. The tests we had didn't test this scenario, and the loopback media factory didn't allow for such test. This change adds counts to that loopback media factory, and asserts that only 1 media transport is created, even when there is a re-offer. Bug: webrtc:9719 Change-Id: Ibd8739af90e914da40ab412454bba8e1529f5a01 Reviewed-on: https://webrtc-review.googlesource.com/c/125040 Reviewed-by: Bjorn Mellem <mellem@webrtc.org> Reviewed-by: Steve Anton <steveanton@webrtc.org> Commit-Queue: Peter Slatala <psla@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26933}
2019-03-01 11:14:05 -08:00
// When the new offer is regenerated (due to upgrade), we don't want to
// re-create media transport. New streams might be created; but media
// transport stays the same. This flag prevents re-creation of the transport
// on the offerer.
// The first media transport is created in jsep transport controller as the
// |offer_media_transport_|, and then the ownership is moved to the
// appropriate JsepTransport, at which point |offer_media_transport_| is
// zeroed out. On the callee (answerer), the first media transport is not even
// assigned to |offer_media_transport_|. Both offerer and answerer can
// recreate the Offer (e.g. after adding streams in Plan B), and so we want to
// prevent recreation of the media transport when that happens.
bool media_transport_created_once_ = false;
const cricket::SessionDescription* local_desc_ = nullptr;
const cricket::SessionDescription* remote_desc_ = nullptr;
absl::optional<bool> initial_offerer_;
absl::optional<cricket::ContentGroup> bundle_group_;
cricket::IceConfig ice_config_;
cricket::IceRole ice_role_ = cricket::ICEROLE_CONTROLLING;
uint64_t ice_tiebreaker_ = rtc::CreateRandomId64();
rtc::scoped_refptr<rtc::RTCCertificate> certificate_;
rtc::AsyncInvoker invoker_;
RTC_DISALLOW_COPY_AND_ASSIGN(JsepTransportController);
};
} // namespace webrtc
#endif // PC_JSEP_TRANSPORT_CONTROLLER_H_