We're receiving SCTP messages one chunk at a time. The sender is supposed to set the MSG_EOR bit on the last chunk of a message. A crash (RTC_CHECK) happened when the sender started a new message without indicating the end of the previous message. This is likely due to an SCTP implementation that doesn't (correctly) support the MSG_EOR bit.
This change, rather than calling RTC_CHECK, delivers partial messages when SID is (unexpectedly) changed, which is what happened before we paid attention to the MSG_EOR bit ourselves.
TBR=pthatcher@webrtc.org
Bug: chromium:884926
Change-Id: I18c773bb60ae724b735a83933eedd030f6360a3c
Reviewed-on: https://webrtc-review.googlesource.com/c/103023
Commit-Queue: Jeroen de Borst <jeroendb@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24935}
Running clang-format with chromium's style guide.
The goal is n-fold:
* providing consistency and readability (that's what code guidelines are for)
* preventing noise with presubmit checks and git cl format
* building on the previous point: making it easier to automatically fix format issues
* you name it
Please consider using git-hyper-blame to ignore this commit.
Bug: webrtc:9340
Change-Id: I694567c4cdf8cee2860958cfe82bfaf25848bb87
Reviewed-on: https://webrtc-review.googlesource.com/81185
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23660}
The proper closing procedure is:
1. Alice resets outgoing stream.
2. Bob receives incoming stream reset, resets his outgoing stream.
3. Alice receives incoming stream reset; channel closed!
4. Bob receives acknowledgement of reset; channel closed!
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.7
However, up until now we've been sending both an incoming and outgoing reset
from the side initiating the closing procedure, and doing nothing on the remote
side.
This means that if you call "Close" and the remote endpoint is using an old
version of WebRTC, the channel's state will be stuck at "closing" since the
remote endpoint won't send a reset. Which is already what happens when Firefox
is talking to Chrome.
This CL also fixes an issue where the DataChannel's state prematurely went to
"closed" before the closing procedure was complete. Which could result in a
new DataChannel attempting to re-use the ID and failing.
TBR=magjed@webrtc.org
Bug: chromium:449934, webrtc:4453
Change-Id: Ic1ba813e46538c6c65868961aae6a9780d68a5e2
Reviewed-on: https://webrtc-review.googlesource.com/79061
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23478}
Reject the local/remote description trying to change the pre-negotiated
BUNDLE tag.
Reject an answer containing a BUNDLE group that's not a subset of the offered group.
Reject an offer/answer with a BUNDLE group containing a MID that no m= section has.
Reject an answer removes an m= section from an established BUNDLE group without
rejecting it.
Bug: chromium:827917
Change-Id: If334eefb00b1c1c1e24f9afba0cb00b5867f5590
Reviewed-on: https://webrtc-review.googlesource.com/67190
Commit-Queue: Zhi Huang <zhihuang@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22813}
With the latest usrsctp roll, the MTU value you provide is the space
avaiable for chunks in the packet. We previously specified this to be the
MTU for the entire SCTP packet, so we were logging errors when the SCTP
packets were 12 bytes larger than expected (the size of the SCTP header).
This fix updates our MTU specified to account for the SCTP header size
as well.
Bug: webrtc:9082
Change-Id: Id3bfa839d4e7662230111ebbdf33bd81ccdc7cf4
Reviewed-on: https://webrtc-review.googlesource.com/66943
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22754}
In previous implementation, the SctpTransport always assumes the
DtlsTransport underneath is non-null, which is not true after switching
to new JsepTransportController model.
This CL adds nullptr when connecting/disconnecting the SctpTransport with
the DtlsTransport.
The "channel" related methods and variables are also renamed.
Bug: chromium:827917, chromium:828220
Change-Id: I95aa2900d23b0885f45500e2c53def771abdccad
Reviewed-on: https://webrtc-review.googlesource.com/66160
Commit-Queue: Zhi Huang <zhihuang@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22700}
Specifically, I'm moving
safe_compare.h
safe_conversions.h
safe_minmax.h
They shouldn't be part of the API, and moving them to an appropriate
subdirectory of rtc_base/ is a good way to keep track of that.
BUG=webrtc:8445
Change-Id: I458531aeb30bcf4291c4bec3bf22a2fffbf054ff
Reviewed-on: https://webrtc-review.googlesource.com/20860
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20829}
This is pretty useful if you need to debug an SCTP issue. SCTP goes
over DTLS, which is encrypted, which means you need a private key
in order to decrypt a normal packet capture. We don't log this key,
for understandable reasons. So the alternative is to turn on SCTP
verbose logging, then turn the text log into a pcap file.
NOTRY=True
TBR=zhihuang@webrtc.org
Bug: None
Change-Id: If3380d7953ea829b3ae9945326d3c820ce7cc6a3
Reviewed-on: https://webrtc-review.googlesource.com/14561
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20380}
This is the same thing we're doing for usrsctp. Before this CL, the
first SrtpSession to call SetKey would initialize libsrtp, and
ChannelManager's destructor would deinitialize it. This works for an
application that only uses one instance of ChannelManager simultaneously
(or one instance of PeerConnectionFactory), but not one that uses
multiple.
Now, libsrtp is effectively reference-counted, with the first
SrtpSession to take a reference initializing it, and the last to remove
its reference deinitializing it.
This issue was discovered recently due to a change that resulted in
using srtp_update. Without using that method, the issue went unnoticed;
maybe srtp_protect/srtp_unprotect don't require initialization?
Bug: webrtc:8388
Change-Id: If1329360f0b469e454810e62e9b5acfbd4cba100
Reviewed-on: https://webrtc-review.googlesource.com/9000
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#20262}
In order to eliminate the WebRTC Subtree mirror in Chromium,
WebRTC is moving the content of the src/webrtc directory up
to the src/ directory.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
TBR=tommi@webrtc.org
Bug: chromium:611808
Change-Id: Iac59c5b51b950f174119565bac87955a7994bc38
Reviewed-on: https://webrtc-review.googlesource.com/1560
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19845}
