This patch estimates the connection RTT using
EventBasedExponentialMovingAverage. The half time is
set to 500 but can be modified using field trials.
This new metric is currently unused, but will
be used for exploration of of whether it can be used
instead of the existing metric.
Bug: webrtc:11140
Change-Id: I9db93e9b9eb932e3cd18935cd4ce0d90fc1cb293
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161000
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29944}
This patch makes Connection::port() protected
and add explicit methods for the use cases instead
- network() - port()->Network()
- generation() - port()->generation()
This is done to easier mock a Connection.
BUG=webrtc:10647
Change-Id: I5b35477ed9f81d57cd871072874262d0a8af2d4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160784
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29929}
Several patches for webrtc:10647 has split the
P2PTransportChannel class/file. This has had the
side effect of it being hard to share the IceFieldTrials-struct.
This patch moves that struct into own file so that can be included
from other components. This patch is a behavioral NOP.
BUG=webrtc:10647
Change-Id: If49cd4d919684a48dde3188a26baf20e4ff2cd8e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160301
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29876}
This patch moves the logic for
- selection of connection to ping
- selection of connection to use
- selection of connection to prune
into own file and puts it behind a new interface called 'IceControllerInterface'.
BUG=webrtc:10647
Change-Id: I10228b3edd361d3200fa4a734d74a319560966c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158205
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Honghai Zhang <honghaiz@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29850}
We now have two downstream users of stun.h, so it appears to be
generally usable. I put this in a new dir networking/, but I'm open to
suggestions here (maybe some things in api/ should move in there).
I checked what our downstream users are actually using, and it's
cricket::ComputeStunCredentialHash
cricket::<constants>
cricket::TurnMessage
cricket::GetStunErrorResponseType
cricket::StunAttribute::CreateAddress
cricket::StunErrorCodeAttribute
cricket::StunByteStringAttribute
StunAttribute::CreateUnknownAttributes
cricket::TurnErrorType
cricket::StunMessage
I reckoned that was pretty much everything in stun.h, so I didn't
bother splitting it up. They don't use every function and constant
in there, but all _types_ of functions and constants, so for the
sake of coherence I don't think it makes sense to split it.
There's some old stuff in there like GTURN which could arguably
be split out, but it should likely go away soon anyway, so I don't
think it's worth the effort.
Steps:
1) land this
2) update downstream to point to the new header and target
3) remove p2p/base:stun_types.
Bug: webrtc:11091
Change-Id: I1f05bf06055475d25601197ec6fefb8d3b55e8e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/159923
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29822}
this patch is puts frequently used check into a set of Check-functions.
the behavior of p2p_transport_channel_unittest is almost unchanged,
the minor change is that when waiting for connection between specific
addresses it waits and does not assume that a particular set of
local/remote addresses will be selected first.
the patch also changes a few EXPECT_ to ASSERT_ since the
tests are not useful where the first EXPECT fails.
BUG=webrtc:10647
Change-Id: Iddcc3c88114db80576e9ebc500572a00dbafdd84
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/159882
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Honghai Zhang <honghaiz@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29812}
The existing ICE stack will choose *the first* connection
that becomes writable.
It is possible that waiting a fixed time will choose a
better connection, avoiding a switch, and making the experience better
in total.
This patch is add two field trials to *explore*
that dimension. I.e the code will be rolled back once
experiments has been performed.
- initial_select_dampening, delays selection by X ms.
- initial_select_dampening_ping_received, delays selection for
candidate that has received ping by X ms.
BUG=webrtc:11054
Change-Id: Ifcdde5183f318815e0f5db5802fbf6b542a95f5b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158410
Reviewed-by: Honghai Zhang <honghaiz@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29623}
To avoid IP leak from the CreatePermission request, local relay
candidates must not be paired with remote mDNS candidates, per Section
3.3.2 in draft-ietf-rtcweb-mdns-ice-candidates-04.
Bug: webrtc:11038
Change-Id: I13aada79c812712b850293c7e17094dc8f77105a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157340
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Honghai Zhang <honghaiz@webrtc.org>
Reviewed-by: Alex Drake <alexdrake@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29546}
This patch adds a feature enabled using webrtc field trial
that remove connections between RELAY and non-RELAY candidates.
Bug: webrtc:11021
Change-Id: I924076277a843bffc1d25f6de14d2165f7012c4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156083
Reviewed-by: Honghai Zhang <honghaiz@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29464}
There were two different codepaths that could trigger identical LOGs.
b/136184428
Bug: None
Change-Id: I3297c4e957177c3ffdd4c120cfa1b17d250f0a47
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/155582
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29381}
I gave up on removing proxy_info, user_agent and tcp_options. I don't
think it's feasible to remove them without removing all the proxy code.
The assumption that you can set the proxy and user agent long after
you have created the factory is entrenched in unit tests and the code
itself. So is the ability to set tcp opts depending on protocol or
endpoint properties.
It may be easier to untangle proxy stuff from the factory later,
when it becomes a more first-class citizen and isn't passed via
the allocator.
Requires https://chromium-review.googlesource.com/c/chromium/src/+/1778870
to land first.
Bug: webrtc:7447
Change-Id: Ib496e2bb689ea415e9f8ec1dfedff13a83fa4a8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150799
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29091}
This is part of a larger refactoring:
1) Add new method and provide default implementations for the other
Create* methods (this CL) so they can be removed downstream.
2) Implement new method in Chromium and remove the overrides of the
other Create* methods from subclasses of PacketSocketFactory.
3) Remove other Create* methods from PacketSocketFactory and make
the new Create method pure virtual. Make BasicPacketSocketFactory
take user_agent and proxy_info in the constructor.
4) Move the slimmed-down packet_socket_factory into api/.
Bug: webrtc:7447
Change-Id: I961fcc4451c9fb2bc7a049b8f57d5894209fd262
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150941
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29026}
This patch adds a new (optional) attribute to TURN_ALLOCATE_REQUEST,
TURN_LOGGING_ID (0xFF05).
The attribute is put into the comprehension-optional range
so that a TURN server should ignore it if it doesn't know if.
https://tools.ietf.org/html/rfc5389#section-18.2
The intended usage of this attribute is to correlate client and
backend logs.
Bug: webrtc:10897
Change-Id: I51fdbe15f9025e817cd91ee8e2c3355133212daa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149829
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28966}
The public API to obtain the selected candidate pair is changed to
GetSelectedCandidatePair in the ICE transport, and the returned pair
has address-sanitized candidates.
Bug: chromium:993878
Change-Id: I44f9d2385a84f9e22447108be2e57ef9e62671eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149080
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28869}
Datagram_dtls_adaptor needs access to rtp_rtcp modules and this moves helps to keep p2p/base/ without dependency on rtp_rtcp.
Bug: webrtc:9719
Change-Id: Ic337be3fb9f68106187a84efa815eefbe5b0fcd7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145267
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28533}
outgoing checks.
This change adds an experimental feature to allow an ICE agent to embed
the transaction ID of the latest connectivity check received from the
remote peer, as an auxiliary acknowledgement in additional to the check
response, in its own checks. This could facilitate the establishment of
ICE connectivity if the check process has a high RTT.
Bug: None
Change-Id: If3e6327720f13beeb14f103af3b5ffb4f9692998
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/142682
Reviewed-by: Honghai Zhang <honghaiz@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28316}
In short, the caller places a x-opaque line in SDP for each m= section that
uses datagram transport. If the answerer supports datagram transport, it will
parse this line and create a datagram transport. It will then echo the x-opaque
line into the answer (to indicate that it accepted use of datagram transport).
If the offer and answer contain exactly the same x-opaque line, both peers will
use datagram transport. If the x-opaque line is omitted from the answer (or is
different in the answer) they will fall back to RTP.
Note that a different x-opaque line in the answer means the answerer did not
understand something in the negotiation proto. Since WebRTC cannot know what
was misunderstood, or whether it's still possible to use the datagram transport,
it must fall back to RTP. This may change in the future, possibly by passing
the answer to the datagram transport, but it's good enough for now.
Negotiation consists of four parts:
1. DatagramTransport exposes transport parameters for both client and server
perspectives. The client just echoes what it received from the server (modulo
any fields it might not have understood).
2. SDP adds a x-opaque line for opaque transport parameters. Identical to
x-mt, but this is specific to datagram transport and goes in each m= section,
and appears in the answer as well as the offer.
- This is propagated to Jsep as part of the TransportDescription.
- SDP files: transport_description.h,cc, transport_description_factory.h,cc,
media_session.cc, webrtc_sdp.cc
3. JsepTransport/Controller:
- Exposes opaque parameters for each mid (m= section). On offerer, this means
pre-allocating a datagram transport and getting its parameters. On the
answerer, this means echoing the offerer's parameters.
- Uses a composite RTP transport to receive from either default RTP or
datagram transport until both offer and answer arrive.
- If a provisional answer arrives, sets the composite to send on the
provisionally selected transport.
- Once both offer and answer are set, deletes the unneeded transports and
keeps whichever transport is selected.
4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
Bug: webrtc:9719
Change-Id: Ifcc428c8d76fb77dcc8abaa79507c620bcfb31b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140920
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28198}
This reverts commit 71c6482baf0ff17141c635e6a7639493db68a65c.
Reason for revert: Lands too much at once and breaks downstream tests that need to implement new interfaces first.
Original change's description:
> Implement true negotiation for DatagramTransport with fallback to RTP.
>
> In short, the caller places a x-opaque line in SDP for each m= section that
> uses datagram transport. If the answerer supports datagram transport, it will
> parse this line and create a datagram transport. It will then echo the x-opaque
> line into the answer (to indicate that it accepted use of datagram transport).
>
> If the offer and answer contain exactly the same x-opaque line, both peers will
> use datagram transport. If the x-opaque line is omitted from the answer (or is
> different in the answer) they will fall back to RTP.
>
> Note that a different x-opaque line in the answer means the answerer did not
> understand something in the negotiation proto. Since WebRTC cannot know what
> was misunderstood, or whether it's still possible to use the datagram transport,
> it must fall back to RTP. This may change in the future, possibly by passing
> the answer to the datagram transport, but it's good enough for now.
>
> Negotiation consists of four parts:
> 1. DatagramTransport exposes transport parameters for both client and server
> perspectives. The client just echoes what it received from the server (modulo
> any fields it might not have understood).
>
> 2. SDP adds a x-opaque line for opaque transport parameters. Identical to
> x-mt, but this is specific to datagram transport and goes in each m= section,
> and appears in the answer as well as the offer.
> - This is propagated to Jsep as part of the TransportDescription.
> - SDP files: transport_description.h,cc, transport_description_factory.h,cc,
> media_session.cc, webrtc_sdp.cc
>
> 3. JsepTransport/Controller:
> - Exposes opaque parameters for each mid (m= section). On offerer, this means
> pre-allocating a datagram transport and getting its parameters. On the
> answerer, this means echoing the offerer's parameters.
> - Uses a composite RTP transport to receive from either default RTP or
> datagram transport until both offer and answer arrive.
> - If a provisional answer arrives, sets the composite to send on the
> provisionally selected transport.
> - Once both offer and answer are set, deletes the unneeded transports and
> keeps whichever transport is selected.
>
> 4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
>
> Bug: webrtc:9719
> Change-Id: Id8996eb1871e79d93b7923a5d7eb3431548c798d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140700
> Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28182}
TBR=steveanton@webrtc.org,mellem@webrtc.org,sukhanov@webrtc.org
Change-Id: I0d502c4a6d27516c35ed85154f3fa5869f88b3b7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9719
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140822
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28188}
In short, the caller places a x-opaque line in SDP for each m= section that
uses datagram transport. If the answerer supports datagram transport, it will
parse this line and create a datagram transport. It will then echo the x-opaque
line into the answer (to indicate that it accepted use of datagram transport).
If the offer and answer contain exactly the same x-opaque line, both peers will
use datagram transport. If the x-opaque line is omitted from the answer (or is
different in the answer) they will fall back to RTP.
Note that a different x-opaque line in the answer means the answerer did not
understand something in the negotiation proto. Since WebRTC cannot know what
was misunderstood, or whether it's still possible to use the datagram transport,
it must fall back to RTP. This may change in the future, possibly by passing
the answer to the datagram transport, but it's good enough for now.
Negotiation consists of four parts:
1. DatagramTransport exposes transport parameters for both client and server
perspectives. The client just echoes what it received from the server (modulo
any fields it might not have understood).
2. SDP adds a x-opaque line for opaque transport parameters. Identical to
x-mt, but this is specific to datagram transport and goes in each m= section,
and appears in the answer as well as the offer.
- This is propagated to Jsep as part of the TransportDescription.
- SDP files: transport_description.h,cc, transport_description_factory.h,cc,
media_session.cc, webrtc_sdp.cc
3. JsepTransport/Controller:
- Exposes opaque parameters for each mid (m= section). On offerer, this means
pre-allocating a datagram transport and getting its parameters. On the
answerer, this means echoing the offerer's parameters.
- Uses a composite RTP transport to receive from either default RTP or
datagram transport until both offer and answer arrive.
- If a provisional answer arrives, sets the composite to send on the
provisionally selected transport.
- Once both offer and answer are set, deletes the unneeded transports and
keeps whichever transport is selected.
4. PeerConnection pulls transport parameters out of Jsep and adds them to SDP.
Bug: webrtc:9719
Change-Id: Id8996eb1871e79d93b7923a5d7eb3431548c798d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/140700
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28182}
- This makes it consistent with ICE and MediaTransport ownership.
- Removes unnecessary datagram_transport() getter in DtlsTransportInternal
As a side effect this fixes bug in JsepTransportController, which moved datagram_transport to Dtls after creating it, then checked if (datagram_transport) to decide which RTP transport to create. As a result of this bug we were creating Sded instead of Unencrypted RTP with datagram transport.
Bug: webrtc:9719
Change-Id: Ic5b13a450ce6ac5b2a20d388657e3949aabef079
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139620
Commit-Queue: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28146}
It does not make sense for DtlsTransport to own ICE, and this arrangement will
not work when negotiating datagram or DTLS transport. During negotiation, both
a DTLS transport and a datagram transport need to be ready to receive from the
same ICE transport, depending on which protocol is chosen by the answerer. Once
the answerer chooses a protocol, the transport that is not chosen must be
deleted, but ICE must be left intact for use by the remaining transport.
Bug: webrtc:9719
Change-Id: Ibab969b574c981e3834ced71f8ff88008cb26a6c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139340
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28113}
