Simulcast is disabled if the RIDs are not negotiated.
This change addresses the scenario in which RIDs are negotiated but
support for the RID extension is not negotiated.
In such cases, the RID extension cannot be used, so support for
simulcast should be turned off, as if RIDs were not negotiated.
A similar case can be made for MIDs, however MIDs are not explicitly
specified in simulcast. RIDs are only guaranteed to be unique within
a media section so it would seem that MIDs should be required.
However, applications supply RID values and can guarantee their
uniqueness, so unlike RIDs, the use of MIDs is not enforced as mandatory.
Bug: webrtc:10075
Change-Id: Ic1b27878ea152eaee43a38bbfda11144307766fe
Reviewed-on: https://webrtc-review.googlesource.com/c/125176
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26934}
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}
The current Key Frame request system doesn't take into account failed
decryptions and this can lead to WebRTC spamming new key frame requests when
the issue is actually in the decryptor layer. To prevent this if frame
decryption is required for the PeerConnection key frame requests will not be
sent at 200ms intervals but will wait until the stream is decryptable before
utilizing this logic.
Bug: webrtc:10330
Change-Id: I188a21dfd142dec6175d9def95f39a2bc517017c
Reviewed-on: https://webrtc-review.googlesource.com/c/123414
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26931}
This prepares for future cleanup of how RtpTransportControllerSend is
used.
Bug: webrtc:10365
Change-Id: Idefc7e60f83819627c83b397949c8434d93491b3
Reviewed-on: https://webrtc-review.googlesource.com/c/124783
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26923}
This is a partial cleanup there is more work to do here. Essentially I am just
moving things from static to anonymous namespaces and reordering things to
make more sense. I have removed some old microsoft compiler warning
supressions which I believe are not required anymore.
After this BIO should be refactored to use proper style.
Bug: webrtc:9860
Change-Id: I8419be002d8f412dd89f37f3b865794792ccf559
Reviewed-on: https://webrtc-review.googlesource.com/c/120863
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26912}
This is a stop-gap fix when empty frame is send, the channel_send.cc:69
check is triggered.
We can add support for sending empty frames in media transport (it
wouldn't be backward compatible) and at this point it's not clear
whether we need empty frames in audio path.
(no tests because there are no channel_send_*test* and this is not a final solution anyway)
Bug: webrtc:9719
Change-Id: Ib1e1da91eff670ac5b139700c51575c53f707529
Reviewed-on: https://webrtc-review.googlesource.com/c/124761
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26904}
Previously, if more than one packet is extracted in a GetAudio call then
an incorrect number of samples will be reported.
Bug: webrtc:10363
Change-Id: Ia1bcc87a0e0082060e4f746d37a4008735eec6b3
Reviewed-on: https://webrtc-review.googlesource.com/c/124829
Reviewed-by: Minyue Li <minyue@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26903}
This fixes a build error on C++17 mode due to missing #include, plus
adds a presubmit check to prevent further breakage.
Bug: chromium:752720
Change-Id: I5c7d1dca0079dfe7a042650402e6f7ae28a797ba
Reviewed-on: https://webrtc-review.googlesource.com/c/124940
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26898}
There has been some crashes due to frames having illegal sizes, most
likely 0x0. Probably these frames are created as a workaround for
something.
It would be best to stop 0x0 frames from being created in the first
place, but a reasonable quick fix is to just not draw those frames.
Bug: webrtc:10367
Change-Id: Ib93057c4de7285773c99614b4e7d9bd4b099c4dc
Reviewed-on: https://webrtc-review.googlesource.com/c/124988
Commit-Queue: Paulina Hensman <phensman@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26897}
This is a reland of 05d43c6f7fe497fed0f2c8714e2042dd07a86df2
The original CL got reverted because Chrome did not support IsQuitting() which
triggered a NOTREACHED() inside of a DCHECK. With
https://chromium-review.googlesource.com/c/chromium/src/+/1491620
it is safe to reland this CL.
The only changes between this and the original patch set is that this is now
rebased on top of https://webrtc-review.googlesource.com/c/src/+/124701, i.e.
rtc::PostMessageWithFunctor() has been replaced by rtc::Thread::PostTask().
Original change's description:
> Fix getStats() freeze bug affecting Chromium but not WebRTC standalone.
>
> PeerConnection::Close() is, per-spec, a blocking operation.
> Unfortunately, PeerConnection is implemented to own resources used by
> the network thread, and Close() - on the signaling thread - destroys
> these resources. As such, tasks run in parallel like getStats() get into
> race conditions with Close() unless synchronized. The mechanism in-place
> is RTCStatsCollector::WaitForPendingRequest(), it waits until the
> network thread is done with the in-parallel stats request.
>
> Prior to this CL, this was implemented by performing
> rtc::Thread::ProcessMessages() in a loop until the network thread had
> posted a task on the signaling thread to say that it was done which
> would then get processed by ProcessMessages(). In WebRTC this works, and
> the test is RTCStatsIntegrationTest.GetsStatsWhileClosingPeerConnection.
>
> But because Chromium's thread wrapper does no support
> ProcessMessages(), calling getStats() followed by close() in Chrome
> resulted in waiting forever (https://crbug.com/850907).
>
> In this CL, the process messages loop is removed. Instead, the shared
> resources are guarded by an rtc::Event. WaitForPendingRequest() still
> blocks the signaling thread, but only while shared resources are in use
> by the network thread. After this CL, calling WaitForPendingRequest() no
> longer has any unexpected side-effects since it no longer processes
> other messages that might have been posted on the thread.
>
> The resource ownership and threading model of WebRTC deserves to be
> revisited, but this fixes a common Chromium crash without redesigning
> PeerConnection, in a way that does not cause more blocking than what
> the other PeerConnection methods are already doing.
>
> Note: An alternative to using rtc::Event is to use resource locks and
> to not perform the stats collection on the network thread if the
> request was cancelled before the start of processing, but this has very
> little benefit in terms of performance: once the network thread starts
> collecting the stats, it would use the lock until collection is
> completed, blocking the signaling thread trying to acquire that lock
> anyway. This defeats the purpose and is a riskier change, since
> cancelling partial collection in this inherently racy edge-case would
> have observable differences from the returned stats, which may cause
> more regressions.
>
> Bug: chromium:850907
> Change-Id: Idceeee0bddc0c9d5518b58a2b263abb2bbf47cff
> Reviewed-on: https://webrtc-review.googlesource.com/c/121567
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#26707}
TBR=steveanton@webrtc.org
Bug: chromium:850907
Change-Id: I5be7f69f0de65ff1120e4926fbf904def97ea9c0
Reviewed-on: https://webrtc-review.googlesource.com/c/124781
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26896}
This method allows asynchronously posting tasks, in the form of
functors to be invoked, on the thread represented by rtc::Thread.
This CL removes PostMessageWithFunctor(), putting the implementation of
it directly into rtc::Thread::PostTask(), and moves & updates the test
coverage to thread_unittest.cc.
Bug: webrtc:10294, webrtc:10293
Change-Id: Ic6cc3e2533a4f7aaff141aff28e9bb3908ee3c96
Reviewed-on: https://webrtc-review.googlesource.com/c/124701
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26894}
To correctly send media from Bob to Alice, when Alice is calling Bob
we have to add transceivers for Bob's media to Alice first, because
it is forbidden to add new media sections into answer in Unified Plan,
so Alice's offer have to contain media sections for Bob's media tracks.
Bug: webrtc:10138
Change-Id: I8a5f19aa5ed6051a981472d5c79493362365f587
Reviewed-on: https://webrtc-review.googlesource.com/c/124492
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26892}
This CL adds a temporary flag for specifying that the legacy AEC2 should
be used.
Bug: webrtc:10366
Change-Id: Ie3edaa1560cdc1282b62242beb67aa6fee7f2841
Reviewed-on: https://webrtc-review.googlesource.com/c/124980
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26891}
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}
This replaces the use of command-line flags with the use of a config
struct. This makes it easier for non command-line applications to use
the NetEqTestFactory to run simulations.
Bug: webrtc:10337
Change-Id: I24533bf206e70e12db9af8d9675769c1ff7c7d48
Reviewed-on: https://webrtc-review.googlesource.com/c/123600
Reviewed-by: Pablo Barrera González <barrerap@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26887}
Introduce test case name for proper metrics reporting across different
parts of framework.
Bug: webrtc:10138
Change-Id: I7c501413ca2f2ee40314d988855dec0c28381c47
Reviewed-on: https://webrtc-review.googlesource.com/c/124740
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26886}
