Properly handle different transports having different SSL roles.

talk/session/media/mediasession.h

Index: talk/session/media/mediasession.h
diff --git a/talk/session/media/mediasession.h b/talk/session/media/mediasession.h
index 8a7f4ccf06758db5453b84c43bfadc1f2dceddd6..d95b2ba0169cce50d511b1b98d935a7cf585d73d 100644
--- a/talk/session/media/mediasession.h
+++ b/talk/session/media/mediasession.h
@@ -144,7 +144,9 @@ struct MediaSessionOptions {
   // bps. -1 == auto.
   int video_bandwidth;
   int data_bandwidth;
-  TransportOptions transport_options;
+  TransportOptions audio_transport_options;
+  TransportOptions video_transport_options;
+  TransportOptions data_transport_options;

[pthatcher1, 2015/12/11 03:16:09]

At first pass, this feels ugly, especially if we want to move to having Unified
Plan and having multiple audio, video, and data transports.  If anything, this
should be a vector of (transport_name, transport_options).

It also feels ugly for the bundle case, where there aren't separate audio,
video, and data transports.  

Could you try with a vector/map approach and see where that heads?


I also have been reluctant to approve https://codereview.webrtc.org/1453813005/
for the same reason, but I hadn't yet thought of a good way to approach it.  I
think a vector/map of options keyed by transport name is a good thing to try.

[Taylor Brandstetter, 2015/12/11 18:40:02]

I had the same thought. But my reasons for not doing a map were:

* It would be inconsistent with the current form of MediaSessionOptions (we
already have recv_audio/recv_video, video_bandwidth/data_bandwidth, etc.)
* It seems like it would be really messy to get the content name propagated to
the right places with the current status of our code.

But I'll try, and see where it heads.

 
   struct Stream {
     Stream(MediaType type,