Enabling rtcp-rsize negotiation and fixing some issues with it.

Enabling rtcp-rsize negotiation and fixing some issues with it.

Sending of reduced size RTCP packets should be enabled only if it's
enabled in the send parameters (which corresponds to the remote description).

Since the RTCPReceiver's RtcpMode isn't used at all, I removed it to ease
confusion.

BUG=webrtc:4868
R=pbos@webrtc.org, pthatcher@google.com, pthatcher@webrtc.org, stefan@webrtc.org

Committed: https://crrev.com/5f0b83b7fb6de95f33f20656e969e0280d72c315
Cr-Commit-Position: refs/heads/master@{#12057}

[Taylor Brandstetter, 2016-02-18 23:18:56]

deadbeef@webrtc.org changed reviewers:
+ pbos@webrtc.org, pthatcher@webrtc.org, stefan@webrtc.org

[Taylor Brandstetter, 2016-02-18 23:18:57]

pthatcher: PTAL at mediasession.cc
stefan: PTAL at rtp_rtcp/*
pbos: PTAL at video_send_stream.cc and webrtcvideoengine2

[pthatcher1, 2016-02-19 07:24:21]

https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
File webrtc/media/engine/webrtcvideoengine2.cc (right):

https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
webrtc/media/engine/webrtcvideoengine2.cc:1149: : webrtc::RtcpMode::kCompound;
I really don't like the idea that the send parameters dictate what the
RtpReceiver does.  RtpSenders and RtpReceivers can be completely independent.  A
PeerConnection may have only RtpReceivers, and no (active) RtpSenders. 
Similarly, ORTC may have only RtpReceivers, and no send parameters.  

Also, the RtcpMode does not only come from the remote description.  It's
possible to send RTCP after having only applied the local description, and it's
possible for the local description to set the mode to reduced-size (when it's
the answer).  While it's true that when the local description is an offer, we
need to wait for the remote answer to know if reduced-size will work, it should
be up to the PeerConnection to convert a remote answer into updated receive
parameters, not the responsibility of the RtpReceiver to use send parameters to
update itself to send different RTCP based on the RtpSenders around it.

Finally, in ORTC, the RtpSender and RtpReceiver has independent parameters for
whether or not they will use reduced-size RTCP, so eventually we have to allow
RtpReceivers to get them independently from their own parameters.

[pbos-webrtc, 2016-02-19 15:57:39]

https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
File webrtc/media/engine/webrtcvideoengine2.cc (right):

https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
webrtc/media/engine/webrtcvideoengine2.cc:1149: : webrtc::RtcpMode::kCompound;
On 2016/02/19 07:24:21, pthatcher1 wrote:
> I really don't like the idea that the send parameters dictate what the
> RtpReceiver does.  RtpSenders and RtpReceivers can be completely independent. 
A
> PeerConnection may have only RtpReceivers, and no (active) RtpSenders. 
> Similarly, ORTC may have only RtpReceivers, and no send parameters.  
> 
> Also, the RtcpMode does not only come from the remote description.  It's
> possible to send RTCP after having only applied the local description, and
it's
> possible for the local description to set the mode to reduced-size (when it's
> the answer).  While it's true that when the local description is an offer, we
> need to wait for the remote answer to know if reduced-size will work, it
should
> be up to the PeerConnection to convert a remote answer into updated receive
> parameters, not the responsibility of the RtpReceiver to use send parameters
to
> update itself to send different RTCP based on the RtpSenders around it.
> 
> Finally, in ORTC, the RtpSender and RtpReceiver has independent parameters for
> whether or not they will use reduced-size RTCP, so eventually we have to allow
> RtpReceivers to get them independently from their own parameters.

But SetRemoteDescription determines whether the sender can understand rsize or
not, right? All receivers send RTCP, so receivers are in that sense senders as
well.

[pthatcher1, 2016-02-19 17:46:07]

On 2016/02/19 15:57:39, pbos-webrtc wrote:
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> File webrtc/media/engine/webrtcvideoengine2.cc (right):
> 
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> webrtc/media/engine/webrtcvideoengine2.cc:1149: : webrtc::RtcpMode::kCompound;
> On 2016/02/19 07:24:21, pthatcher1 wrote:
> > I really don't like the idea that the send parameters dictate what the
> > RtpReceiver does.  RtpSenders and RtpReceivers can be completely
independent. 
> A
> > PeerConnection may have only RtpReceivers, and no (active) RtpSenders. 
> > Similarly, ORTC may have only RtpReceivers, and no send parameters.  
> > 
> > Also, the RtcpMode does not only come from the remote description.  It's
> > possible to send RTCP after having only applied the local description, and
> it's
> > possible for the local description to set the mode to reduced-size (when
it's
> > the answer).  While it's true that when the local description is an offer,
we
> > need to wait for the remote answer to know if reduced-size will work, it
> should
> > be up to the PeerConnection to convert a remote answer into updated receive
> > parameters, not the responsibility of the RtpReceiver to use send parameters
> to
> > update itself to send different RTCP based on the RtpSenders around it.
> > 
> > Finally, in ORTC, the RtpSender and RtpReceiver has independent parameters
for
> > whether or not they will use reduced-size RTCP, so eventually we have to
allow
> > RtpReceivers to get them independently from their own parameters.
> 
> But SetRemoteDescription determines whether the sender can understand rsize or
> not, right? All receivers send RTCP, so receivers are in that sense senders as
> well.

Yes, SetRemoteDescription does determine that.  Which means that when
SetRemoteDescription is called, the PeerConnection can take the remote
description and build updated receiver parameters out of it.  It already does
this to get the receive SSRCs, which are also contained in the remote
description (it's not as simple as "remote == send; local == receive"; both
description contain some send and some receive).

Yes, RtpReceivers sends RTCP.  We could have called them
RtpRecevierAndRtcpSender, but that would have been rather verbose.  But whatever
we call it, it needs to know which RTCP mode to use baed on the parameters
passed to it, not the parameters passed to something else, which may or may not
exist.  We could have called those "parameters for receiving RTP and sending
RTCP", but instead we just called them "receive parameters".

Now, it just happens to be that in a PeerConnection, all RtpSenders and
RtpReceivers of the same m-line will have the same RTCP mode.  But in the
general case (ORTC), that is not necessarily true.  And I think we should avoid
structuring our media code on assumptions of SDP and PeerConnections like that.

[pbos-webrtc, 2016-02-19 18:23:10]

On 2016/02/19 17:46:07, pthatcher1 wrote:
> On 2016/02/19 15:57:39, pbos-webrtc wrote:
> >
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> > File webrtc/media/engine/webrtcvideoengine2.cc (right):
> > 
> >
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> > webrtc/media/engine/webrtcvideoengine2.cc:1149: :
webrtc::RtcpMode::kCompound;
> > On 2016/02/19 07:24:21, pthatcher1 wrote:
> > > I really don't like the idea that the send parameters dictate what the
> > > RtpReceiver does.  RtpSenders and RtpReceivers can be completely
> independent. 
> > A
> > > PeerConnection may have only RtpReceivers, and no (active) RtpSenders. 
> > > Similarly, ORTC may have only RtpReceivers, and no send parameters.  
> > > 
> > > Also, the RtcpMode does not only come from the remote description.  It's
> > > possible to send RTCP after having only applied the local description, and
> > it's
> > > possible for the local description to set the mode to reduced-size (when
> it's
> > > the answer).  While it's true that when the local description is an offer,
> we
> > > need to wait for the remote answer to know if reduced-size will work, it
> > should
> > > be up to the PeerConnection to convert a remote answer into updated
receive
> > > parameters, not the responsibility of the RtpReceiver to use send
parameters
> > to
> > > update itself to send different RTCP based on the RtpSenders around it.
> > > 
> > > Finally, in ORTC, the RtpSender and RtpReceiver has independent parameters
> for
> > > whether or not they will use reduced-size RTCP, so eventually we have to
> allow
> > > RtpReceivers to get them independently from their own parameters.
> > 
> > But SetRemoteDescription determines whether the sender can understand rsize
or
> > not, right? All receivers send RTCP, so receivers are in that sense senders
as
> > well.
> 
> Yes, SetRemoteDescription does determine that.  Which means that when
> SetRemoteDescription is called, the PeerConnection can take the remote
> description and build updated receiver parameters out of it.  It already does
> this to get the receive SSRCs, which are also contained in the remote
> description (it's not as simple as "remote == send; local == receive"; both
> description contain some send and some receive).
> 
> Yes, RtpReceivers sends RTCP.  We could have called them
> RtpRecevierAndRtcpSender, but that would have been rather verbose.  But
whatever
> we call it, it needs to know which RTCP mode to use baed on the parameters
> passed to it, not the parameters passed to something else, which may or may
not
> exist.  We could have called those "parameters for receiving RTP and sending
> RTCP", but instead we just called them "receive parameters".
> 
> Now, it just happens to be that in a PeerConnection, all RtpSenders and
> RtpReceivers of the same m-line will have the same RTCP mode.  But in the
> general case (ORTC), that is not necessarily true.  And I think we should
avoid
> structuring our media code on assumptions of SDP and PeerConnections like
that.

Sounds fine to me, I believe that requires us to split up the feedback
parameters that are set in this CL as well, correct? Can you guys cook up such a
CL? I think most code changes will be above this layer.

[pbos-webrtc, 2016-02-19 18:23:37]

On 2016/02/19 18:23:10, pbos-webrtc wrote:
> On 2016/02/19 17:46:07, pthatcher1 wrote:
> > On 2016/02/19 15:57:39, pbos-webrtc wrote:
> > >
> >
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> > > File webrtc/media/engine/webrtcvideoengine2.cc (right):
> > > 
> > >
> >
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> > > webrtc/media/engine/webrtcvideoengine2.cc:1149: :
> webrtc::RtcpMode::kCompound;
> > > On 2016/02/19 07:24:21, pthatcher1 wrote:
> > > > I really don't like the idea that the send parameters dictate what the
> > > > RtpReceiver does.  RtpSenders and RtpReceivers can be completely
> > independent. 
> > > A
> > > > PeerConnection may have only RtpReceivers, and no (active) RtpSenders. 
> > > > Similarly, ORTC may have only RtpReceivers, and no send parameters.  
> > > > 
> > > > Also, the RtcpMode does not only come from the remote description.  It's
> > > > possible to send RTCP after having only applied the local description,
and
> > > it's
> > > > possible for the local description to set the mode to reduced-size (when
> > it's
> > > > the answer).  While it's true that when the local description is an
offer,
> > we
> > > > need to wait for the remote answer to know if reduced-size will work, it
> > > should
> > > > be up to the PeerConnection to convert a remote answer into updated
> receive
> > > > parameters, not the responsibility of the RtpReceiver to use send
> parameters
> > > to
> > > > update itself to send different RTCP based on the RtpSenders around it.
> > > > 
> > > > Finally, in ORTC, the RtpSender and RtpReceiver has independent
parameters
> > for
> > > > whether or not they will use reduced-size RTCP, so eventually we have to
> > allow
> > > > RtpReceivers to get them independently from their own parameters.
> > > 
> > > But SetRemoteDescription determines whether the sender can understand
rsize
> or
> > > not, right? All receivers send RTCP, so receivers are in that sense
senders
> as
> > > well.
> > 
> > Yes, SetRemoteDescription does determine that.  Which means that when
> > SetRemoteDescription is called, the PeerConnection can take the remote
> > description and build updated receiver parameters out of it.  It already
does
> > this to get the receive SSRCs, which are also contained in the remote
> > description (it's not as simple as "remote == send; local == receive"; both
> > description contain some send and some receive).
> > 
> > Yes, RtpReceivers sends RTCP.  We could have called them
> > RtpRecevierAndRtcpSender, but that would have been rather verbose.  But
> whatever
> > we call it, it needs to know which RTCP mode to use baed on the parameters
> > passed to it, not the parameters passed to something else, which may or may
> not
> > exist.  We could have called those "parameters for receiving RTP and sending
> > RTCP", but instead we just called them "receive parameters".
> > 
> > Now, it just happens to be that in a PeerConnection, all RtpSenders and
> > RtpReceivers of the same m-line will have the same RTCP mode.  But in the
> > general case (ORTC), that is not necessarily true.  And I think we should
> avoid
> > structuring our media code on assumptions of SDP and PeerConnections like
> that.
> 
> Sounds fine to me, I believe that requires us to split up the feedback
> parameters that are set in this CL as well, correct? Can you guys cook up such
a
> CL? I think most code changes will be above this layer.

(That were already configured here before this CL.)

[Taylor Brandstetter, 2016-02-19 21:34:25]

On 2016/02/19 17:46:07, pthatcher1 wrote:
> On 2016/02/19 15:57:39, pbos-webrtc wrote:
> >
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> > File webrtc/media/engine/webrtcvideoengine2.cc (right):
> > 
> >
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> > webrtc/media/engine/webrtcvideoengine2.cc:1149: :
webrtc::RtcpMode::kCompound;
> > On 2016/02/19 07:24:21, pthatcher1 wrote:
> > > I really don't like the idea that the send parameters dictate what the
> > > RtpReceiver does.  RtpSenders and RtpReceivers can be completely
> independent. 
> > A
> > > PeerConnection may have only RtpReceivers, and no (active) RtpSenders. 
> > > Similarly, ORTC may have only RtpReceivers, and no send parameters.  
> > > 
> > > Also, the RtcpMode does not only come from the remote description.  It's
> > > possible to send RTCP after having only applied the local description, and
> > it's
> > > possible for the local description to set the mode to reduced-size (when
> it's
> > > the answer).  While it's true that when the local description is an offer,
> we
> > > need to wait for the remote answer to know if reduced-size will work, it
> > should
> > > be up to the PeerConnection to convert a remote answer into updated
receive
> > > parameters, not the responsibility of the RtpReceiver to use send
parameters
> > to
> > > update itself to send different RTCP based on the RtpSenders around it.
> > > 
> > > Finally, in ORTC, the RtpSender and RtpReceiver has independent parameters
> for
> > > whether or not they will use reduced-size RTCP, so eventually we have to
> allow
> > > RtpReceivers to get them independently from their own parameters.
> > 
> > But SetRemoteDescription determines whether the sender can understand rsize
or
> > not, right? All receivers send RTCP, so receivers are in that sense senders
as
> > well.
> 
> Yes, SetRemoteDescription does determine that.  Which means that when
> SetRemoteDescription is called, the PeerConnection can take the remote
> description and build updated receiver parameters out of it.  It already does
> this to get the receive SSRCs, which are also contained in the remote
> description (it's not as simple as "remote == send; local == receive"; both
> description contain some send and some receive).
> 
> Yes, RtpReceivers sends RTCP.  We could have called them
> RtpRecevierAndRtcpSender, but that would have been rather verbose.  But
whatever
> we call it, it needs to know which RTCP mode to use baed on the parameters
> passed to it, not the parameters passed to something else, which may or may
not
> exist.  We could have called those "parameters for receiving RTP and sending
> RTCP", but instead we just called them "receive parameters".
> 
> Now, it just happens to be that in a PeerConnection, all RtpSenders and
> RtpReceivers of the same m-line will have the same RTCP mode.  But in the
> general case (ORTC), that is not necessarily true.  And I think we should
avoid
> structuring our media code on assumptions of SDP and PeerConnections like
that.

If I understand correctly, your point is that instead of "send parameters" and
"receive parameters", we should have "sender parameters" and "receiver
parameters", in anticipation of the future? The distinction being small, but
important.

That means in BaseChannel, when we get a remote description, we should parse it
into both a SenderParameters and a ReceiverParameters structure. As pbsos says,
we should also construct the feedback parameters here, so that we don't recreate
the receive streams twice.

Since this seems like it could get complicated, can we do it in a separate CL,
and leave a "TODO" in this one?

[pthatcher1, 2016-02-20 08:46:51]

On 2016/02/19 21:34:25, Taylor Brandstetter wrote:
> On 2016/02/19 17:46:07, pthatcher1 wrote:
> > On 2016/02/19 15:57:39, pbos-webrtc wrote:
> > >
> >
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> > > File webrtc/media/engine/webrtcvideoengine2.cc (right):
> > > 
> > >
> >
>
https://codereview.webrtc.org/1713493003/diff/1/webrtc/media/engine/webrtcvid...
> > > webrtc/media/engine/webrtcvideoengine2.cc:1149: :
> webrtc::RtcpMode::kCompound;
> > > On 2016/02/19 07:24:21, pthatcher1 wrote:
> > > > I really don't like the idea that the send parameters dictate what the
> > > > RtpReceiver does.  RtpSenders and RtpReceivers can be completely
> > independent. 
> > > A
> > > > PeerConnection may have only RtpReceivers, and no (active) RtpSenders. 
> > > > Similarly, ORTC may have only RtpReceivers, and no send parameters.  
> > > > 
> > > > Also, the RtcpMode does not only come from the remote description.  It's
> > > > possible to send RTCP after having only applied the local description,
and
> > > it's
> > > > possible for the local description to set the mode to reduced-size (when
> > it's
> > > > the answer).  While it's true that when the local description is an
offer,
> > we
> > > > need to wait for the remote answer to know if reduced-size will work, it
> > > should
> > > > be up to the PeerConnection to convert a remote answer into updated
> receive
> > > > parameters, not the responsibility of the RtpReceiver to use send
> parameters
> > > to
> > > > update itself to send different RTCP based on the RtpSenders around it.
> > > > 
> > > > Finally, in ORTC, the RtpSender and RtpReceiver has independent
parameters
> > for
> > > > whether or not they will use reduced-size RTCP, so eventually we have to
> > allow
> > > > RtpReceivers to get them independently from their own parameters.
> > > 
> > > But SetRemoteDescription determines whether the sender can understand
rsize
> or
> > > not, right? All receivers send RTCP, so receivers are in that sense
senders
> as
> > > well.
> > 
> > Yes, SetRemoteDescription does determine that.  Which means that when
> > SetRemoteDescription is called, the PeerConnection can take the remote
> > description and build updated receiver parameters out of it.  It already
does
> > this to get the receive SSRCs, which are also contained in the remote
> > description (it's not as simple as "remote == send; local == receive"; both
> > description contain some send and some receive).
> > 
> > Yes, RtpReceivers sends RTCP.  We could have called them
> > RtpRecevierAndRtcpSender, but that would have been rather verbose.  But
> whatever
> > we call it, it needs to know which RTCP mode to use baed on the parameters
> > passed to it, not the parameters passed to something else, which may or may
> not
> > exist.  We could have called those "parameters for receiving RTP and sending
> > RTCP", but instead we just called them "receive parameters".
> > 
> > Now, it just happens to be that in a PeerConnection, all RtpSenders and
> > RtpReceivers of the same m-line will have the same RTCP mode.  But in the
> > general case (ORTC), that is not necessarily true.  And I think we should
> avoid
> > structuring our media code on assumptions of SDP and PeerConnections like
> that.
> 
> If I understand correctly, your point is that instead of "send parameters" and
> "receive parameters", we should have "sender parameters" and "receiver
> parameters", in anticipation of the future? The distinction being small, but
> important.

When I wrote the SendParameters and ReceiveParameters, that's what I meant for
them, yes.

> That means in BaseChannel, when we get a remote description, we should parse
it
> into both a SenderParameters and a ReceiverParameters structure. 

Yes.  I never completed this part, which is why the streams/SSRCs are still
added/removed separately from the rest of the parameters, even though they
shouldn't be.

> As pbsos says,
> we should also construct the feedback parameters here, so that we don't
recreate
> the receive streams twice.

Yes, setting the receiver's feedback parameters based on the current send codec
seems wrong also.

> Since this seems like it could get complicated, can we do it in a separate CL,
> and leave a "TODO" in this one?

What would the TODO be?

Would it be "TODO: Move all of the feedback params, including the RTCP mode,
into the receive parameters and use that instead of the send parameters"?

[Taylor Brandstetter, 2016-02-22 20:10:06]

On 2016/02/20 08:46:51, pthatcher1 wrote:
> 
> What would the TODO be?
> 
> Would it be "TODO: Move all of the feedback params, including the RTCP mode,
> into the receive parameters and use that instead of the send parameters"?

That's basically what I had in mind. And also rename
"SendParameters"/"RecvParameters" to "SenderParameters"/"ReceiverParameters".

[pthatcher1, 2016-02-23 23:33:47]

On 2016/02/22 20:10:06, Taylor Brandstetter wrote:
> On 2016/02/20 08:46:51, pthatcher1 wrote:
> > 
> > What would the TODO be?
> > 
> > Would it be "TODO: Move all of the feedback params, including the RTCP mode,
> > into the receive parameters and use that instead of the send parameters"?
> 
> That's basically what I had in mind. And also rename
> "SendParameters"/"RecvParameters" to "SenderParameters"/"ReceiverParameters".

I'm OK with both to those things.

[Taylor Brandstetter, 2016-03-09 22:11:48]

pinging reviewers

[pthatcher, 2016-03-09 23:04:43]

pthatcher@google.com changed reviewers:
+ pthatcher@google.com

[pthatcher, 2016-03-09 23:04:44]

lgtm

[pbos-webrtc, 2016-03-11 20:10:42]

lgtm

[Taylor Brandstetter, 2016-03-16 22:52:59]

Stefan, could you review the files under rtp_rtcp? I'm just removing the
RtcpMode from RtcpReceiver, since it's not used. The receiver can always receive
reduced-size packets, even without being configured to.

[stefan-webrtc, 2016-03-17 12:13:02]

Nice change, lgtm

[pthatcher1, 2016-03-18 22:01:38]

lgtm

[Taylor Brandstetter, 2016-03-18 22:02:18]

Description was changed from

==========
Enabling rtcp-rsize negotiation and fixing some issues with it.

Sending of reduced size RTCP packets should be enabled only if it's
enabled in the send parameters (which corresponds to the remote description).

Since the RTCPReceiver's RtcpMode isn't used at all, I removed it to ease
confusion.

BUG=webrtc:4868
==========

to

==========
Enabling rtcp-rsize negotiation and fixing some issues with it.

Sending of reduced size RTCP packets should be enabled only if it's
enabled in the send parameters (which corresponds to the remote description).

Since the RTCPReceiver's RtcpMode isn't used at all, I removed it to ease
confusion.

BUG=webrtc:4868
R=pbos@webrtc.org, pthatcher@google.com, pthatcher@webrtc.org, stefan@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/5f0b83b7fb6de95f33f20656e...
==========

[Taylor Brandstetter, 2016-03-18 22:02:20]

Committed patchset #4 (id:60001) manually as
5f0b83b7fb6de95f33f20656e969e0280d72c315 (presubmit successful).

[commit-bot: I haz the power, 2016-03-18 22:02:21]

Description was changed from

==========
Enabling rtcp-rsize negotiation and fixing some issues with it.

Sending of reduced size RTCP packets should be enabled only if it's
enabled in the send parameters (which corresponds to the remote description).

Since the RTCPReceiver's RtcpMode isn't used at all, I removed it to ease
confusion.

BUG=webrtc:4868
R=pbos@webrtc.org, pthatcher@google.com, pthatcher@webrtc.org, stefan@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/5f0b83b7fb6de95f33f20656e...
==========

to

==========
Enabling rtcp-rsize negotiation and fixing some issues with it.

Sending of reduced size RTCP packets should be enabled only if it's
enabled in the send parameters (which corresponds to the remote description).

Since the RTCPReceiver's RtcpMode isn't used at all, I removed it to ease
confusion.

BUG=webrtc:4868
R=pbos@webrtc.org, pthatcher@google.com, pthatcher@webrtc.org, stefan@webrtc.org

Committed: https://crrev.com/5f0b83b7fb6de95f33f20656e969e0280d72c315
Cr-Commit-Position: refs/heads/master@{#12057}
==========

[commit-bot: I haz the power, 2016-03-18 22:02:23]

Patchset 4 (id:??) landed as
https://crrev.com/5f0b83b7fb6de95f33f20656e969e0280d72c315
Cr-Commit-Position: refs/heads/master@{#12057}