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}
Bug: webrtc:9719
Change-Id: I9ec89fca7d4555f31b5192980f193b58d99e3b71
Reviewed-on: https://webrtc-review.googlesource.com/c/125100
Reviewed-by: Peter Slatala <psla@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26910}
Bug: webrtc:9719
Change-Id: I90bd1d9858c259d7339420c574ad83d6fb18299c
Reviewed-on: https://webrtc-review.googlesource.com/c/118946
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26426}
Needed for coming cls to be able to use rtc_base/timeutils.h, which
shouldn't be included by api/ headers.
Bug: webrtc:9719
Change-Id: Ia36c0a9218ad505e1eb4f2d9c26d44d5673c2632
Reviewed-on: https://webrtc-review.googlesource.com/c/112580
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25855}
Bug: webrtc:9719
Change-Id: I04e892ce0f2af5c48040dd92ff0701209104fe65
Reviewed-on: https://webrtc-review.googlesource.com/c/111287
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25734}
This changes PeerConnection to allow sending and receiving data channel
messages over the media transport. If |use_media_transport_for_data_channels|
is set, PeerConnection will use a DCT_MEDIA_TRANSPORT mode for data
channels.
DCT_MEDIA_TRANSPORT acts exactly like DCT_SCTP within the data channel
and peer connection layers. On the transport layer, it uses the media
transport instead of SCTP. It appears as an RTP data channel in SDP
(just as media over media-transport appears as RTP in SDP).
Bug: webrtc:9719
Change-Id: I6a90142bd3f43668479c825ed02689dcd0d58b78
Reviewed-on: https://webrtc-review.googlesource.com/c/109740
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25575}
This enables PeerConnection tests to use LoopbackMediaTransport to test
data-channel-over-media-transport code.
Also changes LoopbackMediaTransport to invoke callbacks asynchronously.
This is more accurate, as these callbacks are triggered by network
events. The caller should not block while the callback executes.
Since LoopbackMediaTransport is used for testing, it provides a
FlushAsyncInvokes() method which may be used to ensure that callbacks
occur deterministically (eg. before checking that data has been
received).
Bug: webrtc:9719
Change-Id: Ib8ea9aebf4a0ad3d5934a6fe4ab33432c68523fd
Tbr: stefan@webrtc.org
Reviewed-on: https://webrtc-review.googlesource.com/c/109060
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25489}
This change deletes the default implementations of state and data
channel methods (SetMediaTransportStateCallback, SendData, CloseChannel,
and SetDataSink). It adds stub implementations to LoopbackMediaTransport
and FakeMediaTransport.
Bug: webrtc:9719
Change-Id: I49b7780c055b552330546b460c2e79ce8df81833
Reviewed-on: https://webrtc-review.googlesource.com/c/108940
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25457}
Clients of media_transport_interface need the ability to monitor BWE
estimates, and this change adds a TargetBitrate observer to the media
transport interface.
Bug: webrtc:9719
Change-Id: I90ebbf684c6f269e0c3cd58428010cfa511cc970
Reviewed-on: https://webrtc-review.googlesource.com/c/108106
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25415}
