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
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
Removes calls to the win32k API.
Replaces hardware and event timers with waitable timers.
Removes handling various task objects through the thread message queue.
Removes ProcessQueuedMessages, CancelTimers functions.
Adds event handle for stopping the TaskQueue thread.
Adds ReplyHandler class as an in between for TaskQueue objects to post tasks to each other without worrying if the other TaskQueue remains valid.
Adds rtc::CriticalSection's for timer_tasks_.
Removes ThreadState scoped class.
Differential Revision: https://phabricator.services.mozilla.com/D43480
--HG--
extra : moz-landing-system : lando
This moves the telemetry and preferences out into their own files and restores the parse result telemetery.
Differential Revision: https://phabricator.services.mozilla.com/D52749
--HG--
extra : moz-landing-system : lando
This moves the telemetry and preferences out into their own files and restores the parse result telemetery.
Differential Revision: https://phabricator.services.mozilla.com/D52749
--HG--
extra : moz-landing-system : lando
This moves the telemetry and preferences out into their own files and restores the parse result telemetery.
Differential Revision: https://phabricator.services.mozilla.com/D52749
--HG--
extra : moz-landing-system : lando
PhysicalSocketServer isn't currently used by Mozilla's WebRTC
integration, but just in case, let's make sure that this array index is
bounds-checked in actual use, not just in debug builds (which tend to
never see realistic test conditions).
Differential Revision: https://phabricator.services.mozilla.com/D52745
--HG--
extra : moz-landing-system : lando
This adds a whitelist of domains for which mDNS hostname obfuscation is
disabled. The implementation is an updated version of the old screensharing
whitelist code.
Differential Revision: https://phabricator.services.mozilla.com/D52012
--HG--
extra : moz-landing-system : lando
This adds a whitelist of domains for which mDNS hostname obfuscation is
disabled. The implementation is an updated version of the old screensharing
whitelist code.
Differential Revision: https://phabricator.services.mozilla.com/D52012
--HG--
extra : moz-landing-system : lando
The mDNS code makes use of the StunAddrsRequest which does not exist when
we are running with e10s disabled. If e10s is disabled, PeerConnectionMedia
will not be in the content process, and we can disable hostname obfuscation
in that case.
Differential Revision: https://phabricator.services.mozilla.com/D51986
--HG--
extra : moz-landing-system : lando
This swaps things around so that received tracks in peer connections have a
content principal instead of a null principal initially.
This puts an extra requirement on us to not output any frames under the content
principal after ALPN has been negotiated with requested privacy, but before this
private principal has been signaled to the MediaPipelines. The private principal
is signaled from the STS thread, via the main thread, whereas media is consumed
directly by MediaPipelines after being received on the STS thread.
This patch adds an extra signaling path directly from the STS thread that tells
MediaPipelines to make their PrincipalHandle private, and to ignore any data
until the private PrincipalHandle is set. It also moves the responsibility of
updating the principal of the received MediaStreamTracks from TransceiverImpl
to MediaPipeline, so it's all in the same path.
This lets all MediaStream and MediaStreamTrack APIs consume received tracks
directly after getting exposed to JS without errors. In case privacy is later
requested, consumers that have already been set up must handle this on the fly.
(They do, in specs and impls)
Differential Revision: https://phabricator.services.mozilla.com/D48947
--HG--
extra : moz-landing-system : lando
nsISerialEventTarget is more semantically accurate for these uses, as the
dispatched runnables cannot run in parallel. It also allows us to use
InvokeAsync in future patches, as that function only takes nsISerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D49262
--HG--
extra : moz-landing-system : lando
