The old iceConnectionState only becomes completed on the controlling side, and only if we're not configured to continually gather ICE candidates. This change makes the new ICE connection state do the same thing.
Bug: webrtc:10356
Change-Id: I82ca854a638a52674e4ca43364cf454dacb0cf1e
Reviewed-on: https://webrtc-review.googlesource.com/c/124360
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26950}
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}
This involves inserting an extra layer between jsep_transport_controller
and the cricket::SctpTransportInternal layer. The objects at this layer
are reference counted.
Bug: chromium:818643
Change-Id: Ibed57c4a538de981cee63e0f7f1f319f029cab39
Reviewed-on: https://webrtc-review.googlesource.com/c/123884
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26889}
If x-mt line is present (one or more), and the first line is dedicated
for the media transport that we support, pass the config down to this
media transport.
In the future we will do 3 changes:
1) Add MediaTransportFactory::IsSupported(config) to let the
implementation decide whether the current factory can support a given
setting
2) Add support for multiple x-mt lines. Right now the support is
minimal: we only look at the first line (because we only allow single
media transport factory). In the future, when RtpMediaTransport is
introduced, this may and will change.
3) Allow multiple MediaTransportFactories and add fallback to RTP if
media transport is not supported.
Current solution provides backward compatibility for the 2 above
extensions.
Bug: webrtc:9719
Change-Id: I82a469fecda57effc95d7d8191f4a9e4a01d199c
Reviewed-on: https://webrtc-review.googlesource.com/c/124800
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26882}
It is possible to get event logs from both RTP and MediaTransport when
media transport is only used for data channel. This is undesirable. We
would rather not get any logs from media transport when it's not used
for media.
This change disables rtc event log when media transport is not used for
media.
Bug: webrtc:9719
Change-Id: Ibc660b37c5d98001144e5f68b32f0608fd6ede33
Reviewed-on: https://webrtc-review.googlesource.com/c/123260
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26776}
This CL applies clang-tidy's performance-for-range-copy [1] on the
WebRTC codebase.
All changes in this CL are automatically generated by both clang-tidy
and 'git cl format'.
[1] - https://clang.llvm.org/extra/clang-tidy/checks/performance-for-range-copy.html
Bug: webrtc:10215
Change-Id: I7c83290b8866d76129bbec4e24e6701f5014102e
Reviewed-on: https://webrtc-review.googlesource.com/c/120043
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26420}
Currently it's possible that no-op DTLS is created if media transport is only used for data channels.
Changing it so that no-op DTLS is only created when both media & data will flow through media transport.
Bug: webrtc:9719
Change-Id: I87f27fc778ea21b12f2904bad1452d893f66b541
Reviewed-on: https://webrtc-review.googlesource.com/c/119909
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26416}
It is possible that media transport is re-set by the caller, but once
disabled it should stay disabled.
it's possible to fail this check the check in JsepTransportController::SetMediaTransportFactory in such case.
We should also change the caller to not invoke SetMediaTransportFactory
multiple times (with the same value), but I'll leave it as an excercise
to someone else :)
Bug: webrtc:9719
Change-Id: Ideea8a50d863edf4ef59e594a78c74bb9aba5aa7
Reviewed-on: https://webrtc-review.googlesource.com/c/119911
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26411}
This is in preparation for letting Chrome extract DTLSTransport
information after SLD/SRD instead of doing it on-demand.
Bug: chromium:907849
Change-Id: Iac6b174c98d3d14136e1fd25bce4a9292f6c8b41
Reviewed-on: https://webrtc-review.googlesource.com/c/116984
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26289}
We'd like to disable RTP code path when media transport is used. In particular, we don't want occasional RTP/RTCP packets sent from the RTP code path when media transport is used.
Long term we will remove this new NoOp DTLS transport, when we stop creating rtp transport.
Bug: webrtc:9719
Change-Id: I27f121edef394465ddc8fe8003e6f4428b10c022
Reviewed-on: https://webrtc-review.googlesource.com/c/117700
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26286}
The new iceTransportState depends on the transports to signal when they have disconnected, this change ensures that they do so.
The logic is similar to what the old iceConnectionState did, but it uses the ice transports writable() flag instead of the one from the containing dtls transport.
Bug: webrtc:10199, webrtc:9308
Change-Id: I8a2a71a689b2a7027fe9117c79144811367d2165
Reviewed-on: https://webrtc-review.googlesource.com/c/117565
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26269}
