BlockingCall doesn't take rtc::Location parameter and thus most of the dependencies on location can be removed
Bug: webrtc:11318
Change-Id: I91a17e342dd9a9e3e2c8f7fbe267474c98a8d0e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274620
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38045}
This breaks the link from sdp_offer_answer.cc to channel.h.
Bug: webrtc:13931
Change-Id: I75608f75713bf4e69013ac5f5b17c19e53d07519
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261060
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36757}
Also eliminate FillBitrateInfo from the Channel object.
Bug: webrtc:13931
Change-Id: I5265b7629413a1ed04898272adf26708e2ee9b8d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260469
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36744}
Also apply IWYU to all .cc files in pc/, and correct BUILD file to match.
Note: Some files came out wrong when iwyu was applied. These are not included.
Bug: none
Change-Id: Ib5ea46b8fcc505414d0447cca7218ad3afc2e321
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/252280
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36064}
The interface is implemented by the ChannelManager and contains methods
to create and destroy media channel objects as used by a transceiver.
This will subsequently allow us to delete the channel objects from
the transceiver class where ownership really lies rather than from
the outside - which is currently required by some tests that keep
channel objects on the stack. We'll furthermore be able to do the
destruction asynchronously without additional Invoke()s as we do now
which will remove an Invoke when making sdp changes.
With introducing the interface, the following simplifications were made:
* ChannelManager constructed on the signaling thread.
Before, there was an Invoke in the context class, which existed
for the purposes of calling MediaEngine::Init() (which in turn is
only needed for the VoiceEngine). This Invoke has now been moved
into the CM (more tbd).
* The CM now has a pointer to the signaling thread (since that's the
construction thread). That allows us to remove the signaling thread
parameter from the CreateFooChannel methods.
* The ssrc_generator (UniqueRandomIdGenerator) instance for SSRCs moved
from SdpOfferAnswerHandler to the CM, as it's always used in
combination with the CM. This simplifies the CreateFooChannel methods
as well as a couple of other classes that have a CM dependency.
* Removed DestroyFooChannel related code from SdpOfferAnswerHandler since
the channel type detail can be taken care of by the CM.
Bug: webrtc:11992, webrtc:13540
Change-Id: I04938a803734de8489ba31e6212d9eaecc244126
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/247904
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35766}
...and one when destroying a channel object.
This CL removes Init_n() and Deinit_n() from the BaseChannel class.
Channel classes now use SetRtpTransport to do initialization and
uninitialization on the network thread.
Notably if an implementation has called SetRtpTransport() with a valid
transport pointer, it is required that SetRtpTransport be called again
with a nullptr before the channel object can be deleted.
In situations where multiple channels are created, this can mean
a substantial reduction in thread hops. We still hop to the worker
in order to construct the objects - this can probably be avoided
and SetChannel() is still a synchronous operation for the transceivers.
Furthermore, teardown of channel objects also still happens
synchronously and across network/worker/signaling threads.
Bug: webrtc:11992
Change-Id: I68ca7596e181fc82996e3e290733d97381aa5e78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246740
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35738}
Remove Init_w and Deinit(), both of which were wrappers around Invoke()
calls from the worker thread to the network thread.
Instead, replace them with Init_n() and Deinit_n() that are currently*
required to be called by external code in order to associate/disassociate
the channels with the transport.
This CL mostly moves things around in order to prepare for upcoming
changes, but it does change channel destruction in the following way:
- When destroying channels, we don't block the worker thread anymore
while uninitialization happens on the network thread. Previously
both signal and worker threads were blocked during the
uninitialization in the ChannelManager.
* In an upcoming CL, Init_n() and Deinit_n() will be called internally
from a different method that's always called on the network thread
when a channel is associated/disassociated with a transceiver. When
we're there, we will have removed several invokes that currently are
a part of constructing/destructing channel objects.
Bug: webrtc:11992
Change-Id: Ibc30447a40749ceb36d37834b0cfc5c5ea60e895
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246502
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35707}
This is a simple check for upcoming changes for media channels to
be able to check if the state on the network thread is consistent.
Bug: webrtc:11992
Change-Id: I8ed2d091ecf3869a66970fc4733aebf209c4ef82
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246681
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35706}
If a call to BaseChannel::SetPayloadTypeDemuxingEnabled does not result
in a demuxer criteria configuration change, we can avoid an Invoke
and speed up negotiations.
Bug: webrtc:11993
Change-Id: I80c894d7cc2a733ab84c1f4978f0c58c09a123a5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244920
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35649}
With these changes, we now often have 0 invokes and at most 1 when
calling SetLocalContent on a channel. Before we had at least 1 and
typically 2.
Summary of changes.
* Updating RtpExtension::DeduplicateHeaderExtensions to return a sorted
vector (+test) for easy detection of changes.
* Before updating the transport on the network thread, detect if
actual changes to the demuxer criteria or changes to the rtp header
extensions have been made.
* Consolidate both transport updates to a single call instead of two.
* Added DCHECK guards to catch regressions in number of invokes.
A possible upcoming improvement is to update the transport
asynchronously.
Bug: webrtc:13536
Change-Id: I71ef7b181635a796ffa1e3a02a0f661d28a4870c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244700
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35638}
This is a bit of refactoring to clear the way for some more upcoming
changes and fix little oddities here and there that are basically
artifacts of many small incremental changes throughout the years.
* Remove the CryptoOptions member variable and instead only keep around
the filter for rtp header extensions.
* Remove several member methods that only forwarded calls to
media_channel() and effectively reduced readability.
* Consolidated quite a bit of code related to UpdateRemoteStreams_w
and the copy/pasted code in the Video/Voice classes around calling it.
* UpdateRemoteStreams_w now returns an error when it's encountered.
Before, an error would still be returned in those cases but all
operations were unnecessarily performed.
Bug: none
Change-Id: I85a37b9e8f00584aa794abef11abfe89dec5d0a6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244098
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35637}
This is a slight refactoring while doing some other changes, so not
strictly necessary, but the error param is always supplied in practice
so it made sense to update the tests to reflect that, test that error
values are reported in (at least) some cases and remove the additional
code that checks for whether or not error information is requested.
Bug: none
Change-Id: Ia5739a18ea2beb6970eabf9d809c24dfa43466b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244097
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35632}
Improve consistency between using DCHECK checkers and compile time.
For virtual methods, we were sometimes using both and in other cases
we could be using compile time checks but were using runtime.
Added annotation for last_send_params_, last_recv_params_ in
audio/video channel classes.
Also removing redundant logging for when registration with the
transport fails. This is already being logged in the demuxer.
Bug: webrtc:12230
Change-Id: I48e156c9996dec26a990151301dabc06673541d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244095
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35630}
Remove unnecessary optimization from BaseChannel,
previous_demuxer_criteria_, that I'm not seeing as providing value.
Previously it was used to avoid a thread hop if a reconfiguration
wasn't needed, but the way that was done, wasn't thread safe. So after
addressing that issue, the variable more represents increased complexity
in the code than runtime efficiency.
Bug: webrtc:11993, webrtc:12230
Change-Id: Ic8e3e1d2f57e669a168cc7b5cf5d407133976e3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244093
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35628}
BaseChannel::content_name() is consistently used as the mid throughout
the code and the mid is stored in the demuxer criteria. Furthermore
there's a chance that the two variables might not be in sync if the
mid needs to be truncated, so it's better to use one source of truth.
Bug: webrtc:11993, webrtc:12230
Change-Id: Ia98443d8ee65fd0795651981acab27c29428ba0c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244092
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35622}
Make sure previous_demuxer_criteria_ is only accessed on the network
thread and add annotation.
Bug: webrtc:11993, webrtc:12230
Change-Id: I4700fe41c947a3b1cce9649642dcd38ed62f873d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244087
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35618}
Because of this (seemingly simple) change, I had to change the return
type of transport_name from `const std::string&` to `absl::string_view`
to handle the case when there's no transport assigned.
That in turn caused an avalanche of required updates.
Bug: webrtc:12230, webrtc:11993
Change-Id: I16ec6c6a5fc2f5f7c7de572355a3c6ca924bb9d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244084
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35617}
Add TODO for accessing `previous_demuxer_criteria_`, currently accessed
from two threads (unsafe).
Changed RtpDemuxerCriteria to be a class, all members private with
accessor methods instead of direct variable access. Moving forward
this can allow for things like checking for thread/sequence and state
consistency.
Bug: webrtc:12517, webrtc:11993
Change-Id: I21c1b3067e988494ce6f4c6c85c62165801883bf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244083
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35616}
This simplifies the work that happens on the worker thread in
preparation of avoiding having to go to the worker at all.
Bug: webrtc:11993
Change-Id: I13f063bdecce8efdb978ef1976c819019f30e020
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244082
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35610}
This makes things slightly simpler for the time being as surrounding
code is being refactored. This also removes a PostTask which has the
effect of shrinking the window between the Pending/Complete
notifications slightly since there's no additional async task
for the 'complete' step.
Bug: webrtc:11993
Change-Id: Ia86779b21c6f87301f37d763f89ace722e06e563
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244081
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35609}
The matcher layer tolerates MIDs only up to 16, but the parser
polices a limit of 32 (due to users using this in ways that do
not create a matcher).
Tolerate the MID instead of crashing.
Bug: webrtc:12517
Change-Id: I67ac4a7fa53c918b271b5a3020f497c9d60ec6f5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/240521
Reviewed-by: Philipp Hancke <philipp.hancke@googlemail.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35513}
Add implementation of RTC_DCHECK_NOTREACHED equal to the RTC_NOTREACHED.
The new macros will replace the old one when old one's usage will be
removed. The idea of the renaming to provide a clear signal that this
is debug build only macros and will be stripped in the production build.
Bug: webrtc:9065
Change-Id: I4c35d8b03e74a4b3fd1ae75dba2f9c05643101db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237802
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35348}
Reland of commit a743303211b89bbcf4cea438ee797bbbc7b59e80
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
- Mark FindHeaderExtensionByUri without filter argument as deprecated
Bug: webrtc:11713
Change-Id: I52a5ade1b94bc01d1c2a35cb56023684fcaf9982
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219081
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34129}
Pending messages on network thread for MediaChannel, will be dropped
when the MediaChannel object is deleted (without blocking).
Remove MessageHandler inheritance from Channel since Post-ing to the
network thread has been removed from there.
Copy/pasted code for SendRtp/SendRtcp in WebRtcVideoChannel and
WebRtcVoiceMediaChannel consolidated in MediaChannel.
Bug: webrtc:11993
Change-Id: I05320eb7f86b98adba50ca5eb8b76b78f4111263
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217720
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33955}
This CL mostly adds plumbing to get awareness of the network thread
to the media channel classes. Currently this pointer is only used
to DCHECK that `SetInterface` for the `NetworkInterface` pointer, is
called on the network thread. Follow up changes will establish that
most of the methods are called on the network thread and the mutex
in the MediaChannel base class, can be removed.
Most of the changes in the CL are in channel_unittest.cc. They're mostly
around updating the tests to incorporate the network thread in ways
that reflect how the classes are used in production. Another change is
to use accessor methods for the media channel instances instead of
caching potentially dangling pointers.
Bug: webrtc:11993
Change-Id: I8e2ed1bc23724e238554dbce386789d69660f7e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217682
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33951}
The channel classes have stored the negotiated headers but a more
natural place to store them is in the RtpTransceiver class where
RtpHeaderExtension state is managed as well as the implementation of
the only method that depends on the stored state,
HeaderExtensionsNegotiated().
Also adding a TODO for further improvements where we're unnecessarily
storing state in the channel classes for the purposes of the transports.
Bug: webrtc:12726
Change-Id: If36668e3e49782ddeada23ebed126ee2c4935b8c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216691
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33917}
This reverts commit 48a4d33719390b7bcaf8445a1581a00825f67bfb.
Reason for reland:
Relanding the original change but without the modification for
VideoSendStream::GetStats. Essentially there's a TODO there to fix
the downstream issue, which seems to be benign.
Original change's description:
> Revert "Remove Invoke from VideoChannel::FillBitrateInfo."
>
> This reverts commit 1a1795768e1bdb65054ebe15aa238c6edc78dd14.
>
> Reason for revert: Speculative revert (breaks downstream project).
>
> Original change's description:
> > Remove Invoke from VideoChannel::FillBitrateInfo.
> >
> > The method is relied upon by StatsCollector where it was called from the
> > signaling thread in a loop. Now there's at most one invoke (not N).
> >
> > Uncommenting thread checks and removing TODOs in SendStatisticsProxy,
> > VideoSendStream. Updating all related tests that fetched stats from
> > the wrong context.
> >
> > Bug: webrtc:12726
> > Change-Id: Ia7db1afd7e103ec4f9816f5647203c4e2495586e
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216688
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Reviewed-by: Niels Moller <nisse@webrtc.org>
> > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33894}
>
> TBR=ilnik@webrtc.org,nisse@webrtc.org,tommi@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
>
> Change-Id: I2520957cdb33492d187f04320c7416788fd0f820
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:12726
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217240
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33898}
# Not skipping CQ checks because this is a reland.
Bug: webrtc:12726
Change-Id: I41cce3b11a29905cde982c22e82b9b1f5a98e654
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217222
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33902}
The Invoke() isn't necessary as the method is always called on the
correct thread (now enforced with a DCHECK).
Bug: webrtc:12726
Change-Id: I53bbdabc5d6de1316e7cf478d8912e19dd0e45e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216690
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33899}
This reverts commit 1a1795768e1bdb65054ebe15aa238c6edc78dd14.
Reason for revert: Speculative revert (breaks downstream project).
Original change's description:
> Remove Invoke from VideoChannel::FillBitrateInfo.
>
> The method is relied upon by StatsCollector where it was called from the
> signaling thread in a loop. Now there's at most one invoke (not N).
>
> Uncommenting thread checks and removing TODOs in SendStatisticsProxy,
> VideoSendStream. Updating all related tests that fetched stats from
> the wrong context.
>
> Bug: webrtc:12726
> Change-Id: Ia7db1afd7e103ec4f9816f5647203c4e2495586e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216688
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33894}
TBR=ilnik@webrtc.org,nisse@webrtc.org,tommi@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I2520957cdb33492d187f04320c7416788fd0f820
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:12726
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217240
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33898}
The method is relied upon by StatsCollector where it was called from the
signaling thread in a loop. Now there's at most one invoke (not N).
Uncommenting thread checks and removing TODOs in SendStatisticsProxy,
VideoSendStream. Updating all related tests that fetched stats from
the wrong context.
Bug: webrtc:12726
Change-Id: Ia7db1afd7e103ec4f9816f5647203c4e2495586e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216688
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33894}
This changes the notification to a single std::function pointer
instead of being a sigslot::signal1<> collection.
Summary:
* Remove SignalFirstPacketReceived_, the last sigslot member variable.
(still inherits from sigslot::has_slots<>)
* BaseChannel doesn't post to the signaling thread anymore. The only
reason that remains for the signaling_thread_ variable, is for
thread checking.
* Remove BaseChannel's reliance on MessageHandlerAutoCleanup
(still inherits from MessageHandler)
RtpTransceiver is the consumer of this event. That class is also the
class that sits between the PC classes and the channel object, holding
a pointer to the channel and managing calls that come in on the
signaling thread, such as SetChannel. The responsibility of delivering
the first packet received on the signaling thread is now with
RtpTransceiver:
* RtpTransceiver always requires a ChannelManager instance. Previously
this variable was sometimes set, but it's now required.
* Updated tests in rtp_transceiver_unittest.cc to include a
ChannelManager as well as fix them to include call expectations for
mock sender and receivers.
Bug: webrtc:11993, webrtc:11988
Change-Id: If49d6be157cd7599fa6fe3a42cd0a363464e3a74
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215979
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33853}
There's a bit of copy/pasted code in the channel code, which is
making moving network traffic consistently over to the network thread
a bit trickier than it needs to be, so I'm also updating variable
names used in Set[Local|Remote]Content_w to be more explicitly the same
and make it clear that the code is copy/pasted (and future updates can
consolidate more of it).
Also removing some code from the video/voice media channels that's
effectively dead code (vector + registration methods that aren't needed)
Bug: webrtc:12705
Change-Id: I2e14e69fbc489a64fc1e8899aaf1cfc979fe840b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215978
Reviewed-by: Sam Zackrisson <saza@google.com>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33847}
* Changing return value from bool to void since the operation as async
effects anyway.
* Removing the `enabled()` accessor due to potential threading issues
and potential TOCTOU issues. It was only used in one place anyway.
* Applying thread restrictions to member variables.
Bug: none
Change-Id: I51949f5594339952d7b717cfd82f99b532e86b23
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216182
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33830}
* Adds a OnPacketSent callback to MediaChannel, which matches with
MediaChannel::NetworkInterface::SendPacket.
* Moves the OnPacketSent handling to the media channel implementations
(video/voice) and removes the PeerConnection/SdpOfferAnswerHandler
layer from the call path.
* Call::OnSentPacket is called directly from the channels on the network
thread. This eliminates a PostTask to the worker thread for every
audio/video network packet.
* Remove sigslot dependency from MediaChannel (and derived).
Bug: webrtc:11993
Change-Id: I1f79a7aa60f05d47e1882f9be1c9323ea8fac5f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215403
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33777}
BaseChannel adds and removes receive streams on the worker thread
(UpdateRemoteStreams_w) and then posts a task to the network thread to
update the demuxer criteria. Until this happens, OnRtpPacket() keeps
forwarding "recently removed" ssrc packets to the WebRtcVideoChannel.
Furthermore WebRtcVideoChannel::OnPacketReceived() posts task from the
network thread to the worker thread, so even if the demuxer criteria was
instantly updated we would still have an issue of in-flight packets for
old ssrcs arriving late on the worker thread inside WebRtcVideoChannel.
The wrong ssrc could also arrive when the demuxer goes from forwarding
all packets to a single m= section to forwarding to different m=
sections. In this case we get packets with an ssrc for a recently
created m= section and the ssrc was never intended for our channel.
This is a problem because when WebRtcVideoChannel sees an unknown ssrc
it treats it as an unsignalled stream, creating and destroying default
streams which can be very expensive and introduce large delays when lots
of packets are queued up.
This CL addresses the issue with callbacks for when a demuxer criteria
update is pending and when it has completed. During this window of time,
WebRtcVideoChannel will drop packets for unknown ssrcs.
This approach fixes the race without introducing any new locks and
packets belonging to ssrcs that were not removed continue to be
forwarded even if a demuxer criteria update is pending. This should make
a=inactive for 50p receive streams a glitch-free experience.
Bug: webrtc:12258, chromium:1069603
Change-Id: I30d85f53d84e7eddf7d21380fb608631863aad21
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214964
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33757}
This reverts commit a743303211b89bbcf4cea438ee797bbbc7b59e80.
Reason for revert: Breaks downstream tests that attempt to call FindHeaderExtensionByUri with 2 arguments. Could you keep the old 2-argument method declaration and just forward the call to the new 3-argument method with a suitable no-op filter?
Original change's description:
> Fix RTP header extension encryption
>
> Previously, RTP header extensions with encryption had been filtered
> if the encryption had been activated (not the other way around) which
> was likely an unintended logic inversion.
>
> In addition, it ensures that encrypted RTP header extensions are only
> negotiated if RTP header extension encryption is turned on. Formerly,
> which extensions had been negotiated depended on the order in which
> they were inserted, regardless of whether or not header encryption was
> actually enabled, leading to no extensions being sent on the wire.
>
> Further changes:
>
> - If RTP header encryption enabled, prefer encrypted extensions over
> non-encrypted extensions
> - Add most extensions to list of extensions supported for encryption
> - Discard encrypted extensions in a session description in case encryption
> is not supported for that extension
>
> Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
> into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
> header extensions will prevent any RTP packets being sent/received.
>
> Bug: webrtc:11713
> Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Taylor <deadbeef@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33723}
TBR=deadbeef@webrtc.org,terelius@webrtc.org,hta@webrtc.org,lennart.grahl@gmail.com
Change-Id: I7df6b0fa611c6496dccdfb09a65ff33ae4a52b26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11713
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215222
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33727}
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
header extensions will prevent any RTP packets being sent/received.
Bug: webrtc:11713
Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33723}
Also updating SocketOptionsMergedOnSetTransport test code to make the
call to SetRtpTransport from the right context.
Bug: webrtc:12636
Change-Id: I343851bcf8ac663d7559128d12447a9a742786f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213660
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33633}
