webrtc_m130/api/test/loopback_media_transport.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

270 lines
9.1 KiB
C
Raw Normal View History

/*
* Copyright 2018 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 API_TEST_LOOPBACK_MEDIA_TRANSPORT_H_
#define API_TEST_LOOPBACK_MEDIA_TRANSPORT_H_
#include <memory>
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
#include <string>
#include <utility>
#include <vector>
#include "api/transport/datagram_transport_interface.h"
#include "api/transport/media/media_transport_interface.h"
#include "rtc_base/async_invoker.h"
#include "rtc_base/critical_section.h"
#include "rtc_base/thread.h"
#include "rtc_base/thread_checker.h"
namespace webrtc {
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
// Wrapper used to hand out unique_ptrs to loopback media
// transport without ownership changes to the underlying
// transport.
// It works in two modes:
// It can either wrap a factory, or it can wrap an existing interface.
// In the former mode, it delegates the work to the wrapped factory.
// In the latter mode, it always returns static instance of the transport
// interface.
//
// Example use:
// Factory wrap_static_interface = Wrapper(media_transport_interface);
// Factory wrap_factory = Wrapper(wrap_static_interface);
// The second factory may be created multiple times, and ownership may be passed
// to the client. The first factory counts the number of invocations of
// CreateMediaTransport();
class WrapperMediaTransportFactory : public MediaTransportFactory {
public:
explicit WrapperMediaTransportFactory(
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
DatagramTransportInterface* wrapped_datagram_transport);
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
explicit WrapperMediaTransportFactory(MediaTransportFactory* wrapped);
RTCErrorOr<std::unique_ptr<MediaTransportInterface>> CreateMediaTransport(
rtc::PacketTransportInternal* packet_transport,
rtc::Thread* network_thread,
const MediaTransportSettings& settings) override;
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
RTCErrorOr<std::unique_ptr<MediaTransportInterface>> CreateMediaTransport(
rtc::Thread* network_thread,
const MediaTransportSettings& settings) override;
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
RTCErrorOr<std::unique_ptr<DatagramTransportInterface>>
CreateDatagramTransport(rtc::Thread* network_thread,
const MediaTransportSettings& settings) override;
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
std::string GetTransportName() const override;
int created_transport_count() const;
private:
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
DatagramTransportInterface* wrapped_datagram_transport_ = nullptr;
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
MediaTransportFactory* wrapped_factory_ = nullptr;
int created_transport_count_ = 0;
};
// Contains two MediaTransportsInterfaces that are connected to each other.
// Currently supports audio only.
class MediaTransportPair {
public:
struct Stats {
int sent_audio_frames = 0;
int received_audio_frames = 0;
int sent_video_frames = 0;
int received_video_frames = 0;
};
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
explicit MediaTransportPair(rtc::Thread* thread);
~MediaTransportPair();
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
DatagramTransportInterface* first_datagram_transport() {
return &first_datagram_transport_;
}
DatagramTransportInterface* second_datagram_transport() {
return &second_datagram_transport_;
}
std::unique_ptr<MediaTransportFactory> first_factory() {
Use std::make_unique instead of absl::make_unique. WebRTC is now using C++14 so there is no need to use the Abseil version of std::make_unique. This CL has been created with the following steps: git grep -l absl::make_unique | sort | uniq > /tmp/make_unique.txt git grep -l absl::WrapUnique | sort | uniq > /tmp/wrap_unique.txt git grep -l "#include <memory>" | sort | uniq > /tmp/memory.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/make_unique.txt /tmp/wrap_unique.txt | sort | \ uniq > /tmp/only_make_unique.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/only_make_unique.txt /tmp/memory.txt | \ xargs grep -l "absl/memory" > /tmp/add-memory.txt git grep -l "\babsl::make_unique\b" | \ xargs sed -i "s/\babsl::make_unique\b/std::make_unique/g" git checkout PRESUBMIT.py abseil-in-webrtc.md cat /tmp/add-memory.txt | \ xargs sed -i \ 's/#include "absl\/memory\/memory.h"/#include <memory>/g' git cl format # Manual fix order of the new inserted #include <memory> cat /tmp/only_make_unique | xargs grep -l "#include <memory>" | \ xargs sed -i '/#include "absl\/memory\/memory.h"/d' git ls-files | grep BUILD.gn | \ xargs sed -i '/\/\/third_party\/abseil-cpp\/absl\/memory/d' python tools_webrtc/gn_check_autofix.py \ -m tryserver.webrtc -b linux_rel # Repead the gn_check_autofix step for other platforms git ls-files | grep BUILD.gn | \ xargs sed -i 's/absl\/memory:memory/absl\/memory/g' git cl format Bug: webrtc:10945 Change-Id: I3fe28ea80f4dd3ba3cf28effd151d5e1f19aff89 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153221 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29209}
2019-09-17 17:06:18 +02:00
return std::make_unique<WrapperMediaTransportFactory>(&first_factory_);
}
std::unique_ptr<MediaTransportFactory> second_factory() {
Use std::make_unique instead of absl::make_unique. WebRTC is now using C++14 so there is no need to use the Abseil version of std::make_unique. This CL has been created with the following steps: git grep -l absl::make_unique | sort | uniq > /tmp/make_unique.txt git grep -l absl::WrapUnique | sort | uniq > /tmp/wrap_unique.txt git grep -l "#include <memory>" | sort | uniq > /tmp/memory.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/make_unique.txt /tmp/wrap_unique.txt | sort | \ uniq > /tmp/only_make_unique.txt diff --new-line-format="" --unchanged-line-format="" \ /tmp/only_make_unique.txt /tmp/memory.txt | \ xargs grep -l "absl/memory" > /tmp/add-memory.txt git grep -l "\babsl::make_unique\b" | \ xargs sed -i "s/\babsl::make_unique\b/std::make_unique/g" git checkout PRESUBMIT.py abseil-in-webrtc.md cat /tmp/add-memory.txt | \ xargs sed -i \ 's/#include "absl\/memory\/memory.h"/#include <memory>/g' git cl format # Manual fix order of the new inserted #include <memory> cat /tmp/only_make_unique | xargs grep -l "#include <memory>" | \ xargs sed -i '/#include "absl\/memory\/memory.h"/d' git ls-files | grep BUILD.gn | \ xargs sed -i '/\/\/third_party\/abseil-cpp\/absl\/memory/d' python tools_webrtc/gn_check_autofix.py \ -m tryserver.webrtc -b linux_rel # Repead the gn_check_autofix step for other platforms git ls-files | grep BUILD.gn | \ xargs sed -i 's/absl\/memory:memory/absl\/memory/g' git cl format Bug: webrtc:10945 Change-Id: I3fe28ea80f4dd3ba3cf28effd151d5e1f19aff89 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/153221 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Alessio Bazzica <alessiob@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#29209}
2019-09-17 17:06:18 +02:00
return std::make_unique<WrapperMediaTransportFactory>(&second_factory_);
}
void SetState(MediaTransportState state) {
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
first_datagram_transport_.SetState(state);
second_datagram_transport_.SetState(state);
}
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
void SetFirstState(MediaTransportState state) {
first_datagram_transport_.SetState(state);
}
void SetSecondStateAfterConnect(MediaTransportState state) {
second_datagram_transport_.SetState(state);
}
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 SetFirstDatagramTransportParameters(const std::string& params) {
first_datagram_transport_.set_transport_parameters(params);
}
void SetSecondDatagramTransportParameters(const std::string& params) {
second_datagram_transport_.set_transport_parameters(params);
}
void SetFirstDatagramTransportParametersComparison(
std::function<bool(absl::string_view, absl::string_view)> comparison) {
first_datagram_transport_.set_transport_parameters_comparison(
std::move(comparison));
}
void SetSecondDatagramTransportParametersComparison(
std::function<bool(absl::string_view, absl::string_view)> comparison) {
second_datagram_transport_.set_transport_parameters_comparison(
std::move(comparison));
}
void FlushAsyncInvokes() {
first_datagram_transport_.FlushAsyncInvokes();
second_datagram_transport_.FlushAsyncInvokes();
}
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
int first_factory_transport_count() const {
return first_factory_.created_transport_count();
}
int second_factory_transport_count() const {
return second_factory_.created_transport_count();
}
private:
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
class LoopbackDataChannelTransport : public DataChannelTransportInterface {
public:
explicit LoopbackDataChannelTransport(rtc::Thread* thread);
~LoopbackDataChannelTransport() override;
void Connect(LoopbackDataChannelTransport* other);
RTCError OpenChannel(int channel_id) override;
RTCError SendData(int channel_id,
const SendDataParams& params,
const rtc::CopyOnWriteBuffer& buffer) override;
RTCError CloseChannel(int channel_id) override;
bool IsReadyToSend() const override;
void SetDataSink(DataChannelSink* sink) override;
void OnReadyToSend(bool ready_to_send);
void FlushAsyncInvokes();
private:
void OnData(int channel_id,
DataMessageType type,
const rtc::CopyOnWriteBuffer& buffer);
void OnRemoteCloseChannel(int channel_id);
rtc::Thread* const thread_;
rtc::CriticalSection sink_lock_;
DataChannelSink* data_sink_ RTC_GUARDED_BY(sink_lock_) = nullptr;
bool ready_to_send_ RTC_GUARDED_BY(sink_lock_) = false;
LoopbackDataChannelTransport* other_;
rtc::AsyncInvoker invoker_;
};
class LoopbackDatagramTransport : public DatagramTransportInterface {
public:
explicit LoopbackDatagramTransport(rtc::Thread* thread);
void Connect(LoopbackDatagramTransport* other);
// Datagram transport overrides.
void Connect(rtc::PacketTransportInternal* packet_transport) override;
CongestionControlInterface* congestion_control() override;
void SetTransportStateCallback(
MediaTransportStateCallback* callback) override;
RTCError SendDatagram(rtc::ArrayView<const uint8_t> data,
DatagramId datagram_id) override;
size_t GetLargestDatagramSize() const override;
void SetDatagramSink(DatagramSinkInterface* sink) override;
std::string GetTransportParameters() const override;
RTCError SetRemoteTransportParameters(
absl::string_view remote_parameters) override;
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
// Data channel overrides.
RTCError OpenChannel(int channel_id) override;
RTCError SendData(int channel_id,
const SendDataParams& params,
const rtc::CopyOnWriteBuffer& buffer) override;
RTCError CloseChannel(int channel_id) override;
void SetDataSink(DataChannelSink* sink) override;
bool IsReadyToSend() const override;
// Loopback-specific functionality.
void SetState(MediaTransportState state);
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
// When Connect() is called, the datagram transport will enter this state.
// This is useful for mimicking zero-RTT connectivity, for example.
void SetStateAfterConnect(MediaTransportState state);
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 FlushAsyncInvokes();
void set_transport_parameters(const std::string& value) {
transport_parameters_ = value;
}
void set_transport_parameters_comparison(
std::function<bool(absl::string_view, absl::string_view)> comparison) {
thread_->Invoke<void>(
RTC_FROM_HERE, [this, comparison = std::move(comparison)] {
RTC_DCHECK_RUN_ON(thread_);
transport_parameters_comparison_ = std::move(comparison);
});
}
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
private:
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
void DeliverDatagram(rtc::CopyOnWriteBuffer buffer);
rtc::Thread* thread_;
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
LoopbackDataChannelTransport dc_transport_;
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
MediaTransportState state_ RTC_GUARDED_BY(thread_) =
MediaTransportState::kPending;
DatagramSinkInterface* sink_ RTC_GUARDED_BY(thread_) = nullptr;
MediaTransportStateCallback* state_callback_ RTC_GUARDED_BY(thread_) =
nullptr;
LoopbackDatagramTransport* other_;
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
std::string transport_parameters_;
std::function<bool(absl::string_view, absl::string_view)>
transport_parameters_comparison_ RTC_GUARDED_BY(thread_) =
[](absl::string_view a, absl::string_view b) { return a == b; };
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
absl::optional<MediaTransportState> state_after_connect_;
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
rtc::AsyncInvoker invoker_;
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
};
LoopbackDatagramTransport first_datagram_transport_;
LoopbackDatagramTransport second_datagram_transport_;
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
WrapperMediaTransportFactory first_factory_;
WrapperMediaTransportFactory second_factory_;
};
} // namespace webrtc
#endif // API_TEST_LOOPBACK_MEDIA_TRANSPORT_H_