Refactoring that removes P2PTransport and DtlsTransport classes.

Relanding: Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None

Committed: https://crrev.com/49f34fdd237914f1ef3af8a28acb2db8bceecda6
Cr-Commit-Position: refs/heads/master@{#15453}

[pthatcher1, 2016-11-30 01:34:35]

pthatcher@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[pthatcher1, 2016-11-30 01:34:36]

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport.h
File webrtc/p2p/base/transport.h (right):

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
webrtc/p2p/base/transport.h:254: // JSEP. Each transport consists of DTLS and
ICE transport channels for RTP
I was hoping we could just delete this class.  But this comment makes me think
that we could instead just move this to the PeerConnection implementation (along
with channel.cc) instead of being a part of the network code and
TransportController.  

For example, we could call this thing a PeerConnectionTransport or a
JsepTransport.  I wish I could call it an RtpTransport, but then it would be
awkward for the data channels to use.  

Then the TransportController could just be in charge of creating, ref counting,
and destroying P2pTransportChannels, DtlsTransportChannels, and (soon)
RawUdpTransportChannels.  That would be much more simple.

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
webrtc/p2p/base/transport.h:379: ChannelMap channels_;
While we're in here, I've always thought this map was kind of weird, since it
will only have at most 2 things in it, since we only ever use a maximum of 2
components. It could just be channel_ and rtcp_channel_.

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
File webrtc/p2p/base/transportcontroller.h (right):

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
webrtc/p2p/base/transportcontroller.h:158: TransportChannelImpl* ice);
Why don't we just change TransportController and the BaseChannel to call these
instead of CreateTransportChannel_n?

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
webrtc/p2p/base/transportcontroller.h:165: struct RefCountedChannel {
Would it make more sense to have a RefCounted<T> with a
RefCounted<P2pTransportChannel> and RefCounted<DtlsTransportChannel>?

[Taylor Brandstetter, 2016-11-30 20:31:39]

I agree with most the refactoring you're suggesting, but I'd prefer to do it in
separate CLs. I feel that doing too many things in one CL tends to confuse the
git history, makes the CL harder to land, and increases the likelihood of
needing to roll the CL back.

I do think we can come up with a more descriptive name than Transport though; I
was expecting you'd have some suggestions. I was already thinking JsepTransport,
so let's go with that.

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport.h
File webrtc/p2p/base/transport.h (right):

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
webrtc/p2p/base/transport.h:254: // JSEP. Each transport consists of DTLS and
ICE transport channels for RTP
On 2016/11/30 01:34:35, pthatcher1 wrote:
> I was hoping we could just delete this class.  But this comment makes me think
> that we could instead just move this to the PeerConnection implementation
(along
> with channel.cc) instead of being a part of the network code and
> TransportController.  

Maybe we'll do that eventually. But right now, TransportController is the thing
responsible for applying transport descriptions, and I don't want to change that
in this CL.

> For example, we could call this thing a PeerConnectionTransport or a
> JsepTransport.  I wish I could call it an RtpTransport, but then it would be
> awkward for the data channels to use.  

JsepTransport, SdpTransport, PeerConnectionTransport, etc. would all be sensible
names. I don't think RtpTransport would. This class doesn't do anything
RTP-specific, and I had already planned to introduce an RtpTransport object that
was completely independent of SDP.

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
webrtc/p2p/base/transport.h:379: ChannelMap channels_;
On 2016/11/30 01:34:35, pthatcher1 wrote:
> While we're in here, I've always thought this map was kind of weird, since it
> will only have at most 2 things in it, since we only ever use a maximum of 2
> components. It could just be channel_ and rtcp_channel_.  

I can change that in a separate CL, but I don't think it belongs in this CL.

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
File webrtc/p2p/base/transportcontroller.h (right):

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
webrtc/p2p/base/transportcontroller.h:158: TransportChannelImpl* ice);
On 2016/11/30 01:34:35, pthatcher1 wrote:
> Why don't we just change TransportController and the BaseChannel to call these
> instead of CreateTransportChannel_n?

TransportController already does call these. As for BaseChannel, I'd prefer to
address that in a follow-up CL.

https://codereview.webrtc.org/2517883002/diff/60001/webrtc/p2p/base/transport...
webrtc/p2p/base/transportcontroller.h:165: struct RefCountedChannel {
On 2016/11/30 01:34:35, pthatcher1 wrote:
> Would it make more sense to have a RefCounted<T> with a
> RefCounted<P2pTransportChannel> and RefCounted<DtlsTransportChannel>?

Maybe. But again, I don't think it's necessary for this CL.

[Taylor Brandstetter, 2016-12-01 02:42:13]

Description was changed from

==========
Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None
==========

to

==========
Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None
==========

[pthatcher1, 2016-12-01 23:18:53]

I see your point about putting off some of the refactoring.  This CL as-is is a
step in the right direction.

The two big things I'm not sure about are:
1.  Having JsepTransport in p2p/.  I understand that will be temporary.  I'd be
happy with some TODOs.

2.  The way you changed storing a TransportChannelImpl into storing 2.  I think
it would be cleaner to store one DtlsTransportChannel that has a .ice() on it. 
If we need a hacky temporary thing, we could just have .ice() return a
TransportChannelImpl.  On a DtlsTransportChannel, it would return the
P2pTransportChannel.  On the P2pTransportChannel, it would return itself.

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/dtlstrans...
File webrtc/p2p/base/dtlstransportchannel_unittest.cc (right):

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/dtlstrans...
webrtc/p2p/base/dtlstransportchannel_unittest.cc:86: new
cricket::JsepTransport("dtls content name", certificate_));
Now that we call this thing a JsepTransport (which is an appropriate name), it
now makes sense to at least have a "TODO: Remove dependency on JsepTransport",
because we need to make a DtlsTransportChannel and its test independent of JSEP.

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/faketrans...
File webrtc/p2p/base/faketransportcontroller.h (right):

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/faketrans...
webrtc/p2p/base/faketransportcontroller.h:20: #include
"webrtc/p2p/base/jseptransport.h"
JsepTransport is never used in this CL.  Can you make it more clear what this
header is needed for?

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
File webrtc/p2p/base/jseptransport.h (right):

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:255: // (and possibly RTCP, if rtcp-mux isn't
used).
Now that we call this thing a JsepTransport (which is an appropriate name), it
now makes sense to at least have a "TODO: Move out of the network code and into
the PeerConnection code and make TransportController independent of the
JsepTransport".

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:261: JsepTransport(const std::string& name,
Should we just call this a MID at this point?

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:271: TransportChannelImpl* ice,
Why are these even TransportChannelImpls?  Why not just skip straight to
DtlsTransportChannel and P2pTransportChannel?  Is it so we can have fake ones?

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:340: TransportChannelImpl* ice;
If the DtlsTransportChannel had a .ice() on it, wouldn't storing the
DtlsTransportChannel be sufficient?  That might be cleaner.  Plus, it matches
ORTC.

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/transport...
File webrtc/p2p/base/transportcontroller.h (right):

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/transport...
webrtc/p2p/base/transportcontroller.h:164: // how many external objects
(BaseChannels) reference each channel.
Again, if we know that what we produce is a DtlsTransportChannel, why not just
that and have .ice() on it?  Then you just need to put the DtlsTransportChannel
in the RefCountedChannel.

[Taylor Brandstetter, 2016-12-02 01:12:36]

On 2016/12/01 23:18:53, pthatcher1 wrote:
> I see your point about putting off some of the refactoring.  This CL as-is is
a
> step in the right direction.
> 
> The two big things I'm not sure about are:
> 1.  Having JsepTransport in p2p/.  I understand that will be temporary.  I'd
be
> happy with some TODOs.

I added a TODO. Keep in mind, this has always been an issue, it's now just more
obvious because we're giving the class a more descriptive name.

Question: Where should code go that's used by both WebRTC and ORTC, and doesn't
belong in p2p? For example, RtpSender (in its final refactored state, where it's
not just a proxy to PeerConnection/WebRtcSession). Do we need a new submodule?
 
> 2.  The way you changed storing a TransportChannelImpl into storing 2.  I
think
> it would be cleaner to store one DtlsTransportChannel that has a .ice() on it.

> If we need a hacky temporary thing, we could just have .ice() return a
> TransportChannelImpl.  On a DtlsTransportChannel, it would return the
> P2pTransportChannel.  On the P2pTransportChannel, it would return itself.

I considered that, but for some reason thought we needed to support a
DtlsTransportChannel on top of something other than ICE. If that's not the case,
I'd be happy to go with your suggestion, that's what I was going to do
initially.

[Taylor Brandstetter, 2016-12-02 01:17:28]

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/dtlstrans...
File webrtc/p2p/base/dtlstransportchannel_unittest.cc (right):

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/dtlstrans...
webrtc/p2p/base/dtlstransportchannel_unittest.cc:86: new
cricket::JsepTransport("dtls content name", certificate_));
On 2016/12/01 23:18:53, pthatcher1 wrote:
> Now that we call this thing a JsepTransport (which is an appropriate name), it
> now makes sense to at least have a "TODO: Remove dependency on JsepTransport",
> because we need to make a DtlsTransportChannel and its test independent of
JSEP.

Done.

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/faketrans...
File webrtc/p2p/base/faketransportcontroller.h (right):

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/faketrans...
webrtc/p2p/base/faketransportcontroller.h:20: #include
"webrtc/p2p/base/jseptransport.h"
On 2016/12/01 23:18:53, pthatcher1 wrote:
> JsepTransport is never used in this CL.  Can you make it more clear what this
> header is needed for?

Turns out it isn't needed any more (nice).

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
File webrtc/p2p/base/jseptransport.h (right):

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:255: // (and possibly RTCP, if rtcp-mux isn't
used).
On 2016/12/01 23:18:53, pthatcher1 wrote:
> Now that we call this thing a JsepTransport (which is an appropriate name), it
> now makes sense to at least have a "TODO: Move out of the network code and
into
> the PeerConnection code and make TransportController independent of the
> JsepTransport".

I thought it was more likely that TransportController would go in /pc/, and not
be used by ORTC at all (it's similar to the ORTC RTCIceTransportController only
in name). We can discuss that later; for now I'll add the first part of that
TODO.

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:261: JsepTransport(const std::string& name,
On 2016/12/01 23:18:53, pthatcher1 wrote:
> Should we just call this a MID at this point?  

Sure.

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:271: TransportChannelImpl* ice,
On 2016/12/01 23:18:53, pthatcher1 wrote:
> Why are these even TransportChannelImpls?  Why not just skip straight to
> DtlsTransportChannel and P2pTransportChannel?  Is it so we can have fake ones?


Yep. I expect the next CL (that makes Dtls/P2PTransportChannel no longer inherit
from TransportChannelImpl) will change this.

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:340: TransportChannelImpl* ice;
On 2016/12/01 23:18:53, pthatcher1 wrote:
> If the DtlsTransportChannel had a .ice() on it, wouldn't storing the
> DtlsTransportChannel be sufficient?  That might be cleaner.  Plus, it matches
> ORTC.

I had that idea initially. But I thought at some point we were planning to
support a DTLS channel with something besides ICE underneath it. Are we not?

[Taylor Brandstetter, 2016-12-03 21:07:14]

Ok, JsepTransport now no longer takes a pair of channels, it just takes the DTLS
channel and assumes it can get to the ICE channel from that in the future.

I still have the ICE channel in RefCountedChannel, because TransportController
is the owner of the ICE channel, not DtlsTransportChannelWrapper. And you may
disagree with that, but if we do change it, it should be in a separate CL, since
DtlsTransportChannelWrapper has never owned the ICE channel before.

I also realized GetStats can't be const because of a bunch of things that should
be const but aren't, going all the way down to BoringSSL. Should this be fixed?
Yes, but in a separate CL. Notice a trend?

[pthatcher1, 2016-12-05 23:32:06]

lgtm

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
File webrtc/p2p/base/jseptransport.h (right):

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:255: // (and possibly RTCP, if rtcp-mux isn't
used).
On 2016/12/02 01:17:28, Taylor Brandstetter wrote:
> On 2016/12/01 23:18:53, pthatcher1 wrote:
> > Now that we call this thing a JsepTransport (which is an appropriate name),
it
> > now makes sense to at least have a "TODO: Move out of the network code and
> into
> > the PeerConnection code and make TransportController independent of the
> > JsepTransport".
> 
> I thought it was more likely that TransportController would go in /pc/, and
not
> be used by ORTC at all (it's similar to the ORTC RTCIceTransportController
only
> in name). We can discuss that later; for now I'll add the first part of that
> TODO.

TransportController part of PC?  Oh, I hadn't thought of it that way.   Hmm...
that might work.  Let's discuss that later.

https://codereview.webrtc.org/2517883002/diff/80001/webrtc/p2p/base/jseptrans...
webrtc/p2p/base/jseptransport.h:340: TransportChannelImpl* ice;
On 2016/12/02 01:17:28, Taylor Brandstetter wrote:
> On 2016/12/01 23:18:53, pthatcher1 wrote:
> > If the DtlsTransportChannel had a .ice() on it, wouldn't storing the
> > DtlsTransportChannel be sufficient?  That might be cleaner.  Plus, it
matches
> > ORTC.
> 
> I had that idea initially. But I thought at some point we were planning to
> support a DTLS channel with something besides ICE underneath it. Are we not?

Yes we are.  But we can do that in a future CL :).

[Taylor Brandstetter, 2016-12-06 19:41:32]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2016-12-06 19:41:36]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-12-06 19:50:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-06 19:50:30]

Try jobs failed on following builders:
  linux_rel on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_rel/builds/20971)
  linux_tsan2 on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_tsan2/builds/17727)
  win_rel on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/win_rel/builds/20808)

[Taylor Brandstetter, 2016-12-06 22:13:34]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-12-06 22:13:35]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2517883002/#ps150001 (title:
"Fixing typo.")

[commit-bot: I haz the power, 2016-12-06 22:13:39]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-12-06 22:56:17]

CQ is committing da patch.

Bot data: {"patchset_id": 150001, "attempt_start_ts": 1481062414605000,
"parent_rev": "8c6cc799940b6f3cb977ed58e6f86ceb54557a4a", "commit_rev":
"ddb890c4cbcf66bf95997b5e711eb62ed8ed34b9"}

[commit-bot: I haz the power, 2016-12-06 22:56:21]

Description was changed from

==========
Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None
==========

to

==========
Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None
==========

[commit-bot: I haz the power, 2016-12-06 22:56:21]

Committed patchset #9 (id:150001)

[commit-bot: I haz the power, 2016-12-06 22:56:32]

Description was changed from

==========
Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None
==========

to

==========
Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None

Committed: https://crrev.com/bd28681d02dee8c185aeb39207e8154f0ad14a37
Cr-Commit-Position: refs/heads/master@{#15450}
==========

[commit-bot: I haz the power, 2016-12-06 22:56:33]

Patchset 9 (id:??) landed as
https://crrev.com/bd28681d02dee8c185aeb39207e8154f0ad14a37
Cr-Commit-Position: refs/heads/master@{#15450}

[Taylor Brandstetter, 2016-12-06 23:28:38]

A revert of this CL (patchset #9 id:150001) has been created in
https://codereview.webrtc.org/2553043004/ by deadbeef@webrtc.org.

The reason for reverting is: Deletion of transport.h broke downstream builds.

Going to reland with transport.h containing enums/etc..

[Taylor Brandstetter, 2016-12-06 23:57:35]

Description was changed from

==========
Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None

Committed: https://crrev.com/bd28681d02dee8c185aeb39207e8154f0ad14a37
Cr-Commit-Position: refs/heads/master@{#15450}
==========

to

==========
Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None

Committed: https://crrev.com/bd28681d02dee8c185aeb39207e8154f0ad14a37
Cr-Commit-Position: refs/heads/master@{#15450}
==========

[Taylor Brandstetter, 2016-12-06 23:58:29]

Description was changed from

==========
Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None

Committed: https://crrev.com/bd28681d02dee8c185aeb39207e8154f0ad14a37
Cr-Commit-Position: refs/heads/master@{#15450}
==========

to

==========
Relanding: Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None
==========

[Taylor Brandstetter, 2016-12-06 23:59:11]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-12-06 23:59:11]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2517883002/#ps170001 (title:
"Adding stub transport.h file for backwards compat.")

[commit-bot: I haz the power, 2016-12-06 23:59:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-12-07 00:22:06]

CQ is committing da patch.

Bot data: {"patchset_id": 170001, "attempt_start_ts": 1481068751100200,
"parent_rev": "fdc0bee1c6f964f31436da79d4d5434a80fe33c8", "commit_rev":
"b2beec00c621cc28f4b254c94cdc8ae165c52dd6"}

[commit-bot: I haz the power, 2016-12-07 00:22:09]

Description was changed from

==========
Relanding: Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None
==========

to

==========
Relanding: Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None
==========

[commit-bot: I haz the power, 2016-12-07 00:22:10]

Committed patchset #10 (id:170001)

[commit-bot: I haz the power, 2016-12-07 00:22:14]

Description was changed from

==========
Relanding: Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None
==========

to

==========
Relanding: Refactoring that removes P2PTransport and DtlsTransport classes.

Their base class, Transport, still exists, but it now has a more specific
role: a helper class that applies TransportDescriptions. And is renamed
to JsepTransport as a result.

TransportController is now the entity primarily responsible for managing
TransportChannels. It also starts storing pointers to the DTLS and ICE
chanels separately, which will make it easier to remove
TransportChannel/TransportChannelImpl in a subsequent CL.

BUG=None

Committed: https://crrev.com/49f34fdd237914f1ef3af8a28acb2db8bceecda6
Cr-Commit-Position: refs/heads/master@{#15453}
==========

[commit-bot: I haz the power, 2016-12-07 00:22:15]

Patchset 10 (id:??) landed as
https://crrev.com/49f34fdd237914f1ef3af8a28acb2db8bceecda6
Cr-Commit-Position: refs/heads/master@{#15453}