2018-10-16 10:41:42 +02:00
|
|
|
/*
|
|
|
|
|
* 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_
|
|
|
|
|
|
2018-11-08 11:23:22 -08:00
|
|
|
#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>
|
2018-10-16 10:41:42 +02:00
|
|
|
#include <utility>
|
2019-01-07 15:54:47 +01:00
|
|
|
#include <vector>
|
2018-10-16 10:41:42 +02:00
|
|
|
|
2019-09-12 13:59:36 +02:00
|
|
|
#include "api/transport/datagram_transport_interface.h"
|
|
|
|
|
#include "api/transport/media/media_transport_interface.h"
|
2019-01-11 09:11:00 -08:00
|
|
|
#include "rtc_base/async_invoker.h"
|
|
|
|
|
#include "rtc_base/critical_section.h"
|
2018-11-01 16:42:44 -07:00
|
|
|
#include "rtc_base/thread.h"
|
2018-11-08 11:23:22 -08:00
|
|
|
#include "rtc_base/thread_checker.h"
|
2018-10-16 10:41:42 +02:00
|
|
|
|
|
|
|
|
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();
|
2018-11-08 11:23:22 -08:00
|
|
|
class WrapperMediaTransportFactory : public MediaTransportFactory {
|
|
|
|
|
public:
|
2019-11-26 09:19:40 -08:00
|
|
|
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);
|
2018-11-08 11:23:22 -08:00
|
|
|
|
|
|
|
|
RTCErrorOr<std::unique_ptr<MediaTransportInterface>> CreateMediaTransport(
|
|
|
|
|
rtc::PacketTransportInternal* packet_transport,
|
|
|
|
|
rtc::Thread* network_thread,
|
2018-11-30 09:35:52 +01:00
|
|
|
const MediaTransportSettings& settings) override;
|
2018-11-08 11:23:22 -08:00
|
|
|
|
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;
|
|
|
|
|
|
2018-11-08 11:23:22 -08:00
|
|
|
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;
|
2018-11-08 11:23:22 -08:00
|
|
|
};
|
|
|
|
|
|
2018-10-16 10:41:42 +02:00
|
|
|
// Contains two MediaTransportsInterfaces that are connected to each other.
|
|
|
|
|
// Currently supports audio only.
|
|
|
|
|
class MediaTransportPair {
|
|
|
|
|
public:
|
2018-11-20 14:52:05 +01:00
|
|
|
struct Stats {
|
|
|
|
|
int sent_audio_frames = 0;
|
|
|
|
|
int received_audio_frames = 0;
|
2018-11-28 15:34:37 +01:00
|
|
|
int sent_video_frames = 0;
|
|
|
|
|
int received_video_frames = 0;
|
2018-11-20 14:52:05 +01:00
|
|
|
};
|
|
|
|
|
|
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();
|
2018-10-16 10:41:42 +02:00
|
|
|
|
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_;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-08 11:23:22 -08:00
|
|
|
std::unique_ptr<MediaTransportFactory> first_factory() {
|
2019-09-17 17:06:18 +02:00
|
|
|
return std::make_unique<WrapperMediaTransportFactory>(&first_factory_);
|
2018-11-08 11:23:22 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::unique_ptr<MediaTransportFactory> second_factory() {
|
2019-09-17 17:06:18 +02:00
|
|
|
return std::make_unique<WrapperMediaTransportFactory>(&second_factory_);
|
2018-11-08 11:23:22 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
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);
|
2018-11-08 11:23:22 -08:00
|
|
|
}
|
|
|
|
|
|
2020-01-28 17:06:55 -08:00
|
|
|
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));
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-01 16:42:44 -07:00
|
|
|
void FlushAsyncInvokes() {
|
2019-11-26 09:19:40 -08:00
|
|
|
first_datagram_transport_.FlushAsyncInvokes();
|
|
|
|
|
second_datagram_transport_.FlushAsyncInvokes();
|
2018-11-01 16:42:44 -07:00
|
|
|
}
|
2018-10-16 10:41:42 +02:00
|
|
|
|
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();
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-16 10:41:42 +02:00
|
|
|
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;
|
2020-01-28 17:06:55 -08:00
|
|
|
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);
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-28 17:06:55 -08:00
|
|
|
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:
|
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_;
|
|
|
|
|
|
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_;
|
2020-01-28 17:06:55 -08:00
|
|
|
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; };
|
2019-09-23 14:53:54 -07:00
|
|
|
|
|
|
|
|
absl::optional<MediaTransportState> state_after_connect_;
|
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_;
|
2018-10-16 10:41:42 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
} // namespace webrtc
|
|
|
|
|
|
|
|
|
|
#endif // API_TEST_LOOPBACK_MEDIA_TRANSPORT_H_
|