Currently we register mDNS hostnames when we gather the local interfaces. By
waiting until StartIceChecks is called, it is less likely that we will end up
starting the mdns_service for a site which is not using WebRTC for
communication. This is more efficient, and avoids surprises like triggering
the Windows Firewall dialog for sites which are using WebRTC to gather local
IP addresses.
Differential Revision: https://phabricator.services.mozilla.com/D59765
--HG--
extra : moz-landing-system : lando
The original values of 10ms were chosen arbitrarily. Decreasing the values may
help prevent shutdown hangs like those seen in Bug 1601992.
Differential Revision: https://phabricator.services.mozilla.com/D58844
--HG--
extra : moz-landing-system : lando
We did this for the VideoConduit in Bug 1404992, but not for the AudioConduit
because of the ongoing webrtc.org upstream merge.
Differential Revision: https://phabricator.services.mozilla.com/D59424
--HG--
extra : moz-landing-system : lando
We've already decided when to remove support for DTLS 1.0, so I don't think we
need to track DTLS version anymore. The DTLS and SRTP cipher probes are
intended to track cipher usage so we can remove less secure ciphers over time.
I had a look at the telemetry for these and I don't think there's a clear case
for removal at the moment, so we should renew these for now.
Differential Revision: https://phabricator.services.mozilla.com/D58835
--HG--
extra : moz-landing-system : lando
In media/mtransport/third_party/nICEr/src/stun/addrs.c:
stun_getifaddrs() is used on all non-WIN32 targets. It extracts from the
kernel an array describing network interfaces (I think). These are written
into its out-parameter nr_local_addr addrs[] and the number of entries is
written to int *count.
There is a path through the main loop in stun_getifaddrs() which can cause a
nr_local_addr record to be returned with its .interface.type field being
uninitialized, but which nevertheless is later used. It also looks as if the
.interface.estimated_speed field is not initialised.
This commit zero-initialises the entire output array before writing anything
into it, to avoid such problems, on all targets.
Differential Revision: https://phabricator.services.mozilla.com/D58822
--HG--
extra : moz-landing-system : lando
This removes various unused `#include "nsAutoPtr.h"` in `xpcom/`. Additionally
adds a few includes to the media stack.
Differential Revision: https://phabricator.services.mozilla.com/D58282
--HG--
extra : moz-landing-system : lando
Client of WebrtcMediaDataEncoder unregisters callback before calling
Shutdown(). When a pending encode promise gets resolved after that,
it will cause null pointer error.
Differential Revision: https://phabricator.services.mozilla.com/D55760
--HG--
extra : moz-landing-system : lando
UBSan was complaining about taking `&password_[0]` when the vector had zero capacity, because its STL's implementation of `operator[]` used a reference in an intermediate step, and putting null into a reference is prohibited.
While I'm here, I dropped the `const_cast`, since the callee was changed to accept `const UCHAR*` years ago.
Differential Revision: https://phabricator.services.mozilla.com/D58643
--HG--
extra : moz-landing-system : lando
We don't need to start transmitting until the transceiver asks us to. Doing
this early leads to creating and tearing down an audio send stream
unnecessarily, generating extra RTCP byes. These changes make the behaviour
consistent with the VideoConduit version.
Differential Revision: https://phabricator.services.mozilla.com/D57864
--HG--
extra : moz-landing-system : lando
This consolidates the shutdown code and ensures that an RTCP bye is sent
as part of tearing down a PeerConnection.
Differential Revision: https://phabricator.services.mozilla.com/D57861
--HG--
extra : moz-landing-system : lando
With tracks in different MTGs we risk of having thread races if we stop and start immediatelly. Previously, stoping and starting was happenign to the same MTG so this problem did not exist. This change wires a promise in the `MediaTrack::RemoveListener` method and perform the start when that step has been completed.
Differential Revision: https://phabricator.services.mozilla.com/D57947
--HG--
extra : moz-landing-system : lando
In `MediaPipelineTransmit::SetTrack()` the provided `MediaStreamTrack` connects to the existing send-track. This step crashes if the two tracks belong to different MTGs. With this change, when the two tracks belong to different MTGs, the existing send-track is stopped and deleted and a new send-track is created in the same MTG with the provided `MediaStreamTrack`.
Differential Revision: https://phabricator.services.mozilla.com/D57627
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
- Convert to a StunAddrRequestState enum so there is now a pending state,
rather than just done/not done. This is to make sure we don't have
multiple stun addrs requests in flight at the same time.
- Reset the stun addrs in PeerConnectionMedia from PeerConnectionImpl when
PeerConnectionImpl::SetSignalingState_m detects ICE restart in an offer.
- GatherIfReady will now request new stun addrs if none are available.
Differential Revision: https://phabricator.services.mozilla.com/D55883
--HG--
extra : moz-landing-system : lando
There are known bugs with recv_timeout which may explain the crashes we're
seeing in Bug 1603349. This patch switches to using try_recv which returns
immediately if no data is available. This thread already has timeouts set in
the UDP socket reads and writes, so the timeout with the receive channel
should not be necessary.
Differential Revision: https://phabricator.services.mozilla.com/D57448
--HG--
extra : moz-landing-system : lando
We should only add a hostname to mSignaledAddresses if it is not obfuscated.
Prior to Bug 1567201 this was handled by an early exit in
MediaTransportHandlerSTS::AddIceCandidate if the address was obfuscated.
With the changes in Bug 1567201, that early exit went away and we're now adding
all addresses to mSignaledAddresses which breaks hiding prflx and srflx
addresses. Unfortunately, this is not something that easily unit testable.
Differential Revision: https://phabricator.services.mozilla.com/D57140
--HG--
extra : moz-landing-system : lando
Bug 1598923 - P1 - Remove use of description API and use format in SDP rust to C bindings;r?drno
Bug 1598923 - P2 - Add pref to select strictness of SDP parsing success;r?drno
Bug 1598923 - P3 - Update to WEBRTC-SDP 0.3.2;r?drno
Bug 1598923 - P4 - update to WEBRTC-SDP 0.3.3;r?mjf
Bug 1598923 - P5 - Adapt channel handling to WEBRTC-SDP changes;r?mjf
Differential Revision: https://phabricator.services.mozilla.com/D55211
--HG--
extra : moz-landing-system : lando
The STS thread dispatches SyncRunnables to main thread. There are two cases of
blocking affected here:
- SyncRunnables from main to STS:
Can cause a deadlock.
- PR_Sleep on the main thread:
Effectively sleeps STS too, if STS dispatches a SyncRunnable to main during
main's sleep.
This patch gets rid of both of these.
Depends on D57001
Differential Revision: https://phabricator.services.mozilla.com/D57003
--HG--
extra : moz-landing-system : lando
Before this patch, if a send audio MediaStreamTrack ended, we ended up not
sending anything over the network. If replaceTrack() at that point replaced the
ended track with a live one, we'd start sending data again, but the rtp stream
would continue from where the previous track ended.
Having a gap in audio like that would confuse a receiver's *video* jitter
buffer, because it's trying to sync to an audio track that just had a massive
amount of "jitter" (it can't tell the difference).
This patch fixes this by adding a track layer in MediaPipelineTransmit that
remains active for as long as the MediaPipeline is active. Thus if the send
audio MediaStreamTrack ends, we continue sending silence over the network, which
the receiver can understand. If later replaced, the receiver sees real audio
instead of silence and continues gracefully.
Differential Revision: https://phabricator.services.mozilla.com/D56619
--HG--
extra : moz-landing-system : lando
Before this patch, if a send audio MediaStreamTrack ended, we ended up not
sending anything over the network. If replaceTrack() at that point replaced the
ended track with a live one, we'd start sending data again, but the rtp stream
would continue from where the previous track ended.
Having a gap in audio like that would confuse a receiver's *video* jitter
buffer, because it's trying to sync to an audio track that just had a massive
amount of "jitter" (it can't tell the difference).
This patch fixes this by adding a track layer in MediaPipelineTransmit that
remains active for as long as the MediaPipeline is active. Thus if the send
audio MediaStreamTrack ends, we continue sending silence over the network, which
the receiver can understand. If later replaced, the receiver sees real audio
instead of silence and continues gracefully.
Differential Revision: https://phabricator.services.mozilla.com/D56619
--HG--
extra : moz-landing-system : lando
