The const-ref result of .str() must be copied into the returned
value, whereas the result of .Release() can be moved.
Bug: webrtc:374845009
Change-Id: I3abc98be30ce9947127c7664f5ffa6846b772ea2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366480
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43288}
A similar function was defined in rtc_base/openssl_adapter. Moving it from net/dcsctp/common/ to rtc_base/strings/. I'm planning to use StrJoin in a video codec test (a follow-up change).
Bug: webrtc:14852
Change-Id: Ie657c03e7f9fb52c189c127af6f66ec505b512ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327322
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41166}
MID is a RFC8260 property on an I-DATA chunk, replacing the SSN property
on the DATA chunk in non-interleaved message. The MID stands for
"Message Identifier", and it was frequently named "message_id" in the
source code, but sometimes "mid". To be consistent and using the same
terminology as is most common in the RFC, use "mid" everywhere.
This was triggered by the need to introduce yet another "message
identifier" - but for now, this is just a refacotring CL.
Bug: None
Change-Id: I9cca898d9f3a2f162d6f2e4508ec1b4bc8d7308f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322500
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40876}
If a FORWARD-TSN contains an ordered skipped stream with a large TSN
but with a too small SSN, it can result in messages being assembled
that should've been skipped. Typically:
Receive DATA, ordered, complete, TSN=10, SID=1, SSN=0
- will be delivered.
Receive DATA, ordered, complete, TSN=43, SID=1, SSN=7
- will stay in queue, due to missing SSN=1,2,3,4,5,6.
Receive FORWARD-TSN, TSN=44, SSN=6
- is invalid, as the SSN should've been 7 or higher.
However, as the TSN isn't used for removing messages in ordered streams,
but just the SSN, the SSN=7 isn't removed but instead will be delivered
as it's the next following SSN after 6. This will trigger internal
consistency checks as a chunk with TSN=43 will be delivered when the
current cumulative TSN is set to 44, which is greater.
This was found when fuzzing, and can only be provoked by a client that
is intentionally misbehaving. Before this fix, there was no harm done,
but it failed consistency checks which fuzzers have enabled. When
bug 13799 was fixed (in a previous commit), this allowed the fuzzers to
find it faster.
Bug: webrtc:13799
Change-Id: I830ef189476e227e1dbe08157d34f96ad6453e30
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/254240
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36157}
This avoids copying the payload at all. Future CL will change the
transport.
In performance tests, memcpy was visible in the performance profiles
prior to this change.
Bug: webrtc:12943
Change-Id: I507a1a316165db748e73cf0d58c1be62cc76a2d2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236346
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35428}
It's useful for other parts of WebRTC and there is no real reason why
it should be located in net/dcsctp.
Bug: None
Change-Id: Iccaed4e943e21ddaea8603182d693114b2da9f6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232606
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35055}
Reporting the duplicate TSNs is a SHOULD in the RFC, and using the
duplicate TNSs is a MAY, and in reality I haven't seen an implementation
use it yet. However, it's good for debugging and for stats generation.
Bug: webrtc:12614
Change-Id: I1cc3f86961a8d289708cbf50d98dedfd25077955
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219462
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34053}
Adding strong types went a little too far as these two types represent
the same sequence number. A "request sequence number" is a number, that
- when responded to - will be used as "response sequence number".
Having them separate added confusion and just a lot of type-casting.
Bug: webrtc:12614
Change-Id: I4636ea8f2252023a2d5a9b7033763e1978b1812e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214130
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33789}
Quite a large commit, but mostly trivial. It adds all the (in dcSCTP)
supported parameters, error causes and chunks as an object model, with
serializers and deserializers. They are verified with packet captures
where available, that have been captured with Wireshark against a
reference implementation.
This _could_ be split in parameter/ as one commit, error_cause/ in the
following, and chunk/ as the third, but as each chunk/parameter is
completely isolated from the other, reviewing it should be linear with
the number of chunks/parameters and having them in more commits wouldn't
change that, taken all those three commits into account.
Bug: webrtc:12614
Change-Id: Ie83c9a22cae6e3a39e35ef26fd532837a6387a08
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213347
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33625}
