The new type PriorityValue is a strong 16-bit integer matching RFC 8831
requirements that can be built from a Priority enum.
The value is now propagated and used by the SCTP transport, but enabling
the feature still requires a field trial for now.
Bug: webrtc:42225365
Change-Id: I56c9f48744c70999a8c2d01415a08a0b6761df4b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357941
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42695}
This code looked a bit weird before this CL - probably because of old
refactorings.
In JsepTransport constructor, there is a DCHECK assuring that the RTP
DTLS transport is always present, so it can be passed directly to the
SctpTransport constructor, which avoids having the SetDtlsTransport
method in it.
Also, in the SctpTransport constructor, there was code that would set
the SCTP transport state to `kConnecting` if the DTLS transport was
present, but that was dead code, as it was always `nullptr` inside the
constructor before this CL. With this CL, it's always present, and the
SCTP Transport's state will initially always be `kConnecting` now. Which
is a step to deprecating the `kNew` state that doesn't exist in
https://w3c.github.io/webrtc-pc/#dom-rtcsctptransportstate.
One test case was modified, as it didn't test the reality. The test
created a SctpTransport, registered an observer, and added the DTLS
transport, and expected to receive a "statechange" from `kNew` (which is
not a state that exists in the spec) to `kConnecting`. If the test had
tested the opposite ordering - adding the DTLS transport first, and then
adding an observer, it wouldn't have experienced this. And since in
reality (with the implementation of JsepTransport before and
after this CL), it always adds the DTLS transport before any observer is
registered. So it wouldn't ever be fired, outside of tests.
Bug: webrtc:15897
Change-Id: I6ac24e0a331b686eb400fcf388ece50f2ad46a32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345420
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41987}
This code was extracted to make the next following CL easier to review.
This CL simply exposes the getters, setters and callbacks to set the
buffered amount low threshold on a specific SCTP stream. It will be
used in a follow-up CL, but is just boilerplate.
Bug: chromium:40072842
Change-Id: Iccd72208b369ddc252cc5886f6446b9c2ceeb0b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343360
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41943}
Before this change, calling buffered_amount only included what was
buffered on top of what was already buffered in the SCTP socket. With
the defaults, the SCTP socket can buffer up to 2MB of data (that is not
put on the wire) before the additional external bufferering in
SctpDataChannel will be used. The buffering that I am working on
removing completely.
Until it's removed completely, to avoid the issue reported in
crbug.com/41221056, include the bytes buffered in the SCTP socket to
what is returned when calling RTCDataChannel::buffered_amount.
This means that when this value is zero, it can be safe to know that all
bytes have been sent, but not necessarily acknowledged. And calling
close will not discard any messages.
This is a stopgap solution, but as functional as the proper solution
that removes all additional buffering. Follow-up CLs will merely improve
this solution.
Bug: chromium:41221056
Change-Id: I06edd52188d3bf13a17827381a15a4730722685a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342520
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41898}
This test drives the new tools_webrtc/remove_extra_namespace.py tool.
Bug: None
Change-Id: I9b590aa1213e4cace2d64d555f4dafd893f03606
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327021
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41141}
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}
This reverts commit 37ee0f5e594dd772ec6d620b5e5ea8a751b684f0.
Reason for revert: Revert in order to be able to revert https://webrtc-review.googlesource.com/c/src/+/225642
Original change's description:
> Use backticks not vertical bars to denote variables in comments for /pc
>
> Bug: webrtc:12338
> Change-Id: I88cf10afa5fc810b95d2a585ab2e895dcc163b63
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226953
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Artem Titov <titovartem@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34575}
TBR=hta@webrtc.org,titovartem@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I5eddd3a14e1f664bf831e5c294fbc4de5f6a88af
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:12338
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227082
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34577}
This reverts commit 6b143c1c0686519bc9d73223c1350cee286c8d78.
Reason for revert:
Relanding with updated expectations for SctpTransport::Information
based on TransceiverStateSurfacer in Chromium.
Original change's description:
> Revert "Fix unsynchronized access to mid_to_transport_ in JsepTransportController"
>
> This reverts commit 6cd405850467683cf10d05028ea0f644a68a91a4.
>
> Reason for revert: Breaks WebRTC Chromium FYI Bots
>
> First failure:
> https://ci.chromium.org/p/chromium/builders/webrtc.fyi/WebRTC%20Chromium%20FYI%20Android%20Tests%20%28dbg%29%20%28L%20Nexus5%29/1925
>
> Failed tests:
> WebRtcDataBrowserTest.CallWithSctpDataAndMedia
> WebRtcDataBrowserTest.CallWithSctpDataOnly
>
> Original change's description:
> > Fix unsynchronized access to mid_to_transport_ in JsepTransportController
> >
> > * Added several thread checks to JTC to help with programmer errors.
> > * Avoid a few Invokes() to the network thread here and there such
> > as for fetching sctp transport name for getStats(). The transport
> > name is now cached when it changes on the network thread.
> > * JsepTransportController instances now get deleted on the network
> > thread rather than on the signaling thread + issuing an Invoke()
> > in the dtor.
> > * Moved some thread hops from JTC over to PC which is where the problem
> > exists and also (imho) makes it easier to see where hops happen in
> > the PC code.
> > * The sctp transport is now started asynchronously when we push down the
> > media description.
> > * PeerConnection proxy calls GetSctpTransport directly on the network
> > thread instead of to the signaling thread + blocking on the network
> > thread.
> > * The above changes simplified things for webrtc::SctpTransport which
> > allowed for removing locking from that class and delete some code.
> >
> > Bug: webrtc:9987, webrtc:12445
> > Change-Id: Ic89a9426e314e1b93c81751d4f732f05fa448fbc
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205620
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33191}
>
> TBR=tommi@webrtc.org,hta@webrtc.org
>
> Change-Id: I7b2913d5133807589461105cf07eff3e9bb7157e
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:9987
> Bug: webrtc:12445
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206466
> Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
> Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33204}
TBR=tommi@webrtc.org,hta@webrtc.org,guidou@webrtc.org
# Not skipping CQ checks because this is a reland.
Bug: webrtc:9987
Bug: webrtc:12445
Change-Id: Icb205cbac493ed3b881d71ea3af4fb9018701bf4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206560
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33219}
This reverts commit 6cd405850467683cf10d05028ea0f644a68a91a4.
Reason for revert: Breaks WebRTC Chromium FYI Bots
First failure:
https://ci.chromium.org/p/chromium/builders/webrtc.fyi/WebRTC%20Chromium%20FYI%20Android%20Tests%20%28dbg%29%20%28L%20Nexus5%29/1925
Failed tests:
WebRtcDataBrowserTest.CallWithSctpDataAndMedia
WebRtcDataBrowserTest.CallWithSctpDataOnly
Original change's description:
> Fix unsynchronized access to mid_to_transport_ in JsepTransportController
>
> * Added several thread checks to JTC to help with programmer errors.
> * Avoid a few Invokes() to the network thread here and there such
> as for fetching sctp transport name for getStats(). The transport
> name is now cached when it changes on the network thread.
> * JsepTransportController instances now get deleted on the network
> thread rather than on the signaling thread + issuing an Invoke()
> in the dtor.
> * Moved some thread hops from JTC over to PC which is where the problem
> exists and also (imho) makes it easier to see where hops happen in
> the PC code.
> * The sctp transport is now started asynchronously when we push down the
> media description.
> * PeerConnection proxy calls GetSctpTransport directly on the network
> thread instead of to the signaling thread + blocking on the network
> thread.
> * The above changes simplified things for webrtc::SctpTransport which
> allowed for removing locking from that class and delete some code.
>
> Bug: webrtc:9987, webrtc:12445
> Change-Id: Ic89a9426e314e1b93c81751d4f732f05fa448fbc
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205620
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33191}
TBR=tommi@webrtc.org,hta@webrtc.org
Change-Id: I7b2913d5133807589461105cf07eff3e9bb7157e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9987
Bug: webrtc:12445
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/206466
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33204}
* Added several thread checks to JTC to help with programmer errors.
* Avoid a few Invokes() to the network thread here and there such
as for fetching sctp transport name for getStats(). The transport
name is now cached when it changes on the network thread.
* JsepTransportController instances now get deleted on the network
thread rather than on the signaling thread + issuing an Invoke()
in the dtor.
* Moved some thread hops from JTC over to PC which is where the problem
exists and also (imho) makes it easier to see where hops happen in
the PC code.
* The sctp transport is now started asynchronously when we push down the
media description.
* PeerConnection proxy calls GetSctpTransport directly on the network
thread instead of to the signaling thread + blocking on the network
thread.
* The above changes simplified things for webrtc::SctpTransport which
allowed for removing locking from that class and delete some code.
Bug: webrtc:9987, webrtc:12445
Change-Id: Ic89a9426e314e1b93c81751d4f732f05fa448fbc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205620
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33191}
This involves catching another callback from usrsctp.
It also moves the definition of "connected" a little later
in the sequence: From "ready to send data" to the reception
of the SCTP_COMM_UP event.
Bug: chromium:943976
Change-Id: Ib9e1b17d0cc356f19cdfa675159b29bf1efdcb55
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/137435
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28004}
This also refactors some of the code in peerconnection for
handling SCTP transports to be internal to the webrtc::SctpTransport
class, rather than being in peerconnection.
Bug: webrtc:10358, webrtc:10629
Change-Id: I15ecf95c199f56b08909e5a9311d446a412ed162
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/137041
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27960}
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}
