With this, RtpSender and RtpReceiver will always return an SSRC if one
is available. Also, attempts to change the SSRC with SetParameters will
fail, rather than silently doing nothing.
BUG=webrtc:6888
Review-Url: https://codereview.webrtc.org/2567333004
Cr-Commit-Position: refs/heads/master@{#15939}
The src/remoting/protocol/channel_socket_adapter_unittest.cc will use this class
instead of creating its own MockTransportChannel which subclasses the TransportChannel.
This will make it easier to switch the base class of P2PTransportChannel from
TransportChannel to IceTransportInternal.
BUG=webrtc:6951
Review-Url: https://codereview.webrtc.org/2610663003
Cr-Commit-Position: refs/heads/master@{#15922}
Reason for revert:
This CL is breaking a chromium.webrtc.fyi: https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Builder/builds/226
I am trying to reproduce the issue on my local machine and I will try to re-land the CL later.
Original issue's description:
> Fixing package-boundary violation with srjar_deps
>
> Without the usage of the srcjar_deps attribute we were not able to
> include .java files from other packages without violating the package
> boundary contraint.
>
> As an example, in this CL the target "libjingle_peerconnection_java" was
> directly including .java files from another packages in its "java_files"
> attribute.
>
> Using srcjar_deps we are able to declare the dependency of the target
> avoiding to create hidden dependencies in the codebase.
>
> This is not fixing the webrtc:6356 bug directly but it is a first step to
> include ThreadUtils classes in libjingle_peerconnection_client_java.jar
> again.
>
> It seems also to be related to the chromium:648244 bug. This can be solved
> if we can find a way to perform srcjar generation in the android_library
> target without changing the semantic of the target.
>
> BUG=webrtc:6356
>
> Review-Url: https://codereview.webrtc.org/2610823002
> Cr-Commit-Position: refs/heads/master@{#15914}
> Committed: 10a76592a7TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6356
Review-Url: https://codereview.webrtc.org/2617533005
Cr-Commit-Position: refs/heads/master@{#15915}
Without the usage of the srcjar_deps attribute we were not able to
include .java files from other packages without violating the package
boundary contraint.
As an example, in this CL the target "libjingle_peerconnection_java" was
directly including .java files from another packages in its "java_files"
attribute.
Using srcjar_deps we are able to declare the dependency of the target
avoiding to create hidden dependencies in the codebase.
This is not fixing the webrtc:6356 bug directly but it is a first step to
include ThreadUtils classes in libjingle_peerconnection_client_java.jar
again.
It seems also to be related to the chromium:648244 bug. This can be solved
if we can find a way to perform srcjar generation in the android_library
target without changing the semantic of the target.
BUG=webrtc:6356
Review-Url: https://codereview.webrtc.org/2610823002
Cr-Commit-Position: refs/heads/master@{#15914}
Reason for revert:
Breaks Chromium FYI bots.
tommi, please let me land this (I forgot to run them).
Original issue's description:
> Remove webrtc/libjingle/{xmllite,xmpp} as it's dead code.
>
> These sources have now been imported into Chromium's
> src/third_party/libjingle_xmpp.
>
> BUG=webrtc:5539
> NOTRY=True
>
> Review-Url: https://codereview.webrtc.org/2617443003
> Cr-Commit-Position: refs/heads/master@{#15910}
> Committed: 1670b1fe6bTBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5539
Review-Url: https://codereview.webrtc.org/2618633003
Cr-Commit-Position: refs/heads/master@{#15911}
These sources have now been imported into Chromium's
src/third_party/libjingle_xmpp.
BUG=webrtc:5539
NOTRY=True
Review-Url: https://codereview.webrtc.org/2617443003
Cr-Commit-Position: refs/heads/master@{#15910}
Reason for revert:
Hitting DCHECK in chromium's WebrtcTransportTest.TerminateDataChannel and WebrtcTransportTest.DataStreamLate. Will investigate and reland.
Original issue's description:
> Separating SCTP code from BaseChannel/MediaChannel.
>
> The BaseChannel code is geared around RTP; the presence of media engines,
> send and receive streams, SRTP, SDP directional attribute negotiation, etc.
> It doesn't make sense to use it for SCTP as well. This separation should make
> future work both on BaseChannel and the SCTP code paths easier.
>
> SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
> directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
> doesn't get confused with webrtc::DataChannel any more.
>
> Beyond just moving code around, some consequences of this CL:
> - We'll now stop using the worker thread for SCTP. Packets will be
> processed right on the network thread instead.
> - The SDP directional attribute is ignored, as it's supposed to be.
>
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2564333002
> Cr-Commit-Position: refs/heads/master@{#15906}
> Committed: 67b3bbe639TBR=pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2614813003
Cr-Commit-Position: refs/heads/master@{#15908}
The BaseChannel code is geared around RTP; the presence of media engines,
send and receive streams, SRTP, SDP directional attribute negotiation, etc.
It doesn't make sense to use it for SCTP as well. This separation should make
future work both on BaseChannel and the SCTP code paths easier.
SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
doesn't get confused with webrtc::DataChannel any more.
Beyond just moving code around, some consequences of this CL:
- We'll now stop using the worker thread for SCTP. Packets will be
processed right on the network thread instead.
- The SDP directional attribute is ignored, as it's supposed to be.
BUG=None
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Commit-Position: refs/heads/master@{#15906}
Instead of having to specify a bitrate and how many packets to use,
the BitrateProber will now use the bitrate to calculate how many
bytes it will use to probe that bitrate instead.
For now, |kMinProbeDurationMs| is set to 15 ms which means that probing
at 1900 kbps will result in 1900/8*0.015 = 3.5 kB used. Since we can
expect packets to be smaller at the beginning of a stream (500 to 700
bytes) this will result in 7 to 5 packets sent for that bitrate, and
should work very similar to how the current initial probing works.
A minimum of 5 packets are always sent.
BUG=webrtc:6822
Review-Url: https://codereview.webrtc.org/2609113003
Cr-Commit-Position: refs/heads/master@{#15899}
This should reduce/eliminate the amount of manual cleanup users
have to do to sync past 177567c518b121731e507e9b9c4049c4dc96e4c8 (#15754).
This is essentially a stripped down version of
526248779a/setup_links.py
which only does the link cleaning + adds removal of the links db.
BUG=webrtc:5006
NOTRY=True
Review-Url: https://codereview.webrtc.org/2603203002
Cr-Commit-Position: refs/heads/master@{#15897}
This will make it easier for some downstream projects to control whether
or not to set ENABLE_EXTERNAL_AUTH, via the GN variable.
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2608673002
Cr-Commit-Position: refs/heads/master@{#15894}
