Adding test for unordered, fragmented SCTP message delivery.

webrtc/media/sctp/sctpdataengine.cc

Index: webrtc/media/sctp/sctpdataengine.cc
diff --git a/webrtc/media/sctp/sctpdataengine.cc b/webrtc/media/sctp/sctpdataengine.cc
index fa70ab16affdeb2401dbcab10e8927f94cc538c0..b229673e29068666b198ff49a5f414f8a003f120 100644
--- a/webrtc/media/sctp/sctpdataengine.cc
+++ b/webrtc/media/sctp/sctpdataengine.cc
@@ -32,6 +32,10 @@ namespace cricket {
 // The biggest SCTP packet.  Starting from a 'safe' wire MTU value of 1280,
 // take off 80 bytes for DTLS/TURN/TCP/IP overhead.
 static const size_t kSctpMtu = 1200;
+// usrsctp seems to interpret the MTU we give it strangely -- it seems to
+// give us back packets bigger than that MTU, if only by a fixed amount.
+// This is that amount that we've observed.
+const int kSctpOverhead = 80;

[honghaiz3, 2016/08/10 19:25:42]

Make it static if it is not used outside of this file. 

It would be nicer if we can get 80 from the usrsctp header file. 
Is it the size of a certain struct there?
OK to leave it as is if it cannot be found easily. 

[Taylor Brandstetter, 2016/08/10 20:55:05]

I went to investigate where the 80 is coming from, but I found that the real
issue is that the MTU we set is being completely ignored. We just didn't notice
because 1200+80 = 1280 is the default MTU. So the mysterious 80 additional bytes
were just the difference between the ignored value we set and the one that's
actually used.

I fixed this by changing where the setsockopt is called and adding the necessary
address parameter. Maybe this should go in a separate CL, though, since it's
really independent from adding this test.

Also... Maybe it's wrong that we were trying to disable MTU discovery in the
first place. https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 says
it MUST be supported. Peter, do you know anything about this?

 
 // The size of the SCTP association send buffer.  256kB, the usrsctp default.
 static const int kSendBufferSize = 262144;
@@ -477,7 +481,7 @@ bool SctpDataMediaChannel::OpenSctpSocket() {
   sctp_paddrparams params = {{0}};
   params.spp_assoc_id = 0;
   params.spp_flags = SPP_PMTUD_DISABLE;
-  params.spp_pathmtu = kSctpMtu;
+  params.spp_pathmtu = kSctpMtu - kSctpOverhead;
   if (usrsctp_setsockopt(sock_, IPPROTO_SCTP, SCTP_PEER_ADDR_PARAMS, &params,
       sizeof(params))) {
     LOG_ERRNO(LS_ERROR) << debug_name_
@@ -1002,15 +1006,11 @@ bool SctpDataMediaChannel::SetRecvCodecs(const std::vector<DataCodec>& codecs) {
 
 void SctpDataMediaChannel::OnPacketFromSctpToNetwork(
     rtc::CopyOnWriteBuffer* buffer) {
-  // usrsctp seems to interpret the MTU we give it strangely -- it seems to
-  // give us back packets bigger than that MTU, if only by a fixed amount.
-  // This is that amount that we've observed.
-  const int kSctpOverhead = 76;
-  if (buffer->size() > (kSctpOverhead + kSctpMtu)) {
+  if (buffer->size() > (kSctpMtu)) {
     LOG(LS_ERROR) << debug_name_ << "->OnPacketFromSctpToNetwork(...): "
                   << "SCTP seems to have made a packet that is bigger "
                   << "than its official MTU: " << buffer->size()
-                  << " vs max of " << kSctpMtu
+                  << " vs max of " << kSctpMtu - kSctpOverhead
                   << " even after adding " << kSctpOverhead
                   << " extra SCTP overhead";
   }