Wire up transport sequence number / send time callbacks to webrtc via libjingle.

webrtc/base/asyncpacketsocket.h

Index: webrtc/base/asyncpacketsocket.h
diff --git a/webrtc/base/asyncpacketsocket.h b/webrtc/base/asyncpacketsocket.h
index f0c221da1dec3fd4014be539224366d507fcac23..9b37594475a3a3640cbeef04a7c2e157d37decb2 100644
--- a/webrtc/base/asyncpacketsocket.h
+++ b/webrtc/base/asyncpacketsocket.h
@@ -34,10 +34,12 @@ struct PacketTimeUpdateParams {
 // This structure holds meta information for the packet which is about to send
 // over network.
 struct PacketOptions {
-  PacketOptions() : dscp(DSCP_NO_CHANGE) {}
-  explicit PacketOptions(DiffServCodePoint dscp) : dscp(dscp) {}
+  PacketOptions() : dscp(DSCP_NO_CHANGE), transport_sequence_number(-1) {}
+  PacketOptions(DiffServCodePoint dscp)
+      : dscp(dscp), transport_sequence_number(-1) {}
 
   DiffServCodePoint dscp;
+  int32 transport_sequence_number;  // 16 bits, -1 represents "not set".

[pthatcher1, 2015/09/25 23:24:58]

I'm not to excited about something so RTP-specific being jammed into the lowest
level of our network code.  But I think we could make this more generic. 
Basically all you want is a way to know which packet was sent which means you
want a value in the PacketOptions that matches the value in the SentPacket.  In
that case, let's try this:

1.  Call this "packet_id".
2.  Put the SentPacket struct right below this one, also with "packet_id".

[stefan-webrtc, 2015/09/28 12:10:50]

I could call it packet_id. I'm not sure that's a lot more generic than
packet_sequence_number though? And a sequence number implies that it is also
incremented by one for every packet, which might be good to know.

[pthatcher1, 2015/09/28 23:58:40]

It's more generic because the layer that's doing the delivery has no notion of
"sequence" and once you put "sequence" in the name, you have to define what a
"sequence" is at this layer of the code.  So I think we should remove the word
"sequence".  

Similarly, if we put "transport" in the name, we have to define what a
"transport" is.  So I think we should remove "transport" from the name also.

This layer just needs a way to say "packet X was delivered", with some day to
identify "X".  If we remove "sequence" and "transport", we are left with just
"number", which doesn't say what the number is for.  What is it for?  It
identifies the packet.  So, perhaps "packet_number".  But I think "packet_id"
sounds slightly better.
If we ever come to a point where we wanted more meaning in value, then we could
rename it to match the new meaning.  But for now, it's just an ID.


However, if you feel like we will have multiple sequences going to the same
socket, then it would make sense to have a transport_id and a
transport_sequence_number, because then we could define "transport" and
"sequence" with something meaningful.

[stefan-webrtc, 2015/10/02 13:29:12]

I'm convinced. Fixed.

   PacketTimeUpdateParams packet_time_params;
 };
 
@@ -61,6 +63,16 @@ inline PacketTime CreatePacketTime(int64 not_before) {
   return PacketTime(TimeMicros(), not_before);
 }
 
+struct SentPacket {
+  SentPacket() : transport_sequence_number(-1), send_time_ms(-1) {}
+  SentPacket(int32 transport_sequence_number, int64 send_time_ms)
+      : transport_sequence_number(transport_sequence_number),
+        send_time_ms(send_time_ms) {}
+
+  int32 transport_sequence_number;
+  int64 send_time_ms;
+};
+
 // Provides the ability to receive packets asynchronously. Sends are not
 // buffered since it is acceptable to drop packets under high load.
 class AsyncPacketSocket : public sigslot::has_slots<> {
@@ -109,6 +121,9 @@ class AsyncPacketSocket : public sigslot::has_slots<> {
                    const SocketAddress&,
                    const PacketTime&> SignalReadPacket;
 
+  // Emitted each time a packet is sent.
+  sigslot::signal2<AsyncPacketSocket*, const SentPacket&> SignalPacketSent;

[pthatcher1, 2015/09/25 23:24:57]

I don't actually see this implemented anywhere.  Does that come later?

[stefan-webrtc, 2015/09/28 12:10:50]

It's implemented in Chromium here: https://codereview.chromium.org/1345583004/

Other platforms don't really need this since a send timestamp set at the webrtc
layer roughly corresponds to when the send socket gets the packet.

+
   // Emitted when the socket is currently able to send.
   sigslot::signal1<AsyncPacketSocket*> SignalReadyToSend;