Create a new preference which disables UDP protocol for WebRTC

chrome/browser/renderer_preferences_util.cc

Index: chrome/browser/renderer_preferences_util.cc
diff --git a/chrome/browser/renderer_preferences_util.cc b/chrome/browser/renderer_preferences_util.cc
index e1127e11b21f4f564a651a86c5554a25a70d47e5..cfdf42bf648982e942c3b09108d7e8ef8f96da3b 100644
--- a/chrome/browser/renderer_preferences_util.cc
+++ b/chrome/browser/renderer_preferences_util.cc
@@ -45,6 +45,8 @@ void UpdateFromSystemSettings(content::RendererPreferences* prefs,
 #if defined(ENABLE_WEBRTC)
   prefs->enable_webrtc_multiple_routes =
       pref_service->GetBoolean(prefs::kWebRTCMultipleRoutesEnabled);
+  prefs->enable_webrtc_udp_transport =
+      pref_service->GetBoolean(prefs::kWebRTCUdpTransportEnabled);

[pthatcher2, 2015/08/25 23:12:34]

I thought we were going to call this something like kWebRTCForceThroughProxy
(default false), so that later if we do have UDP proxies (like RETURN), we could
still have UDP traffic, as long as it went through the proxy.

[guoweis_left_chromium, 2015/08/26 14:43:40]

Whether traffic goes through proxy or not is a decision that chrome owns and
enforces. ForceThroughProxy doesn't seem a right term to me when there is no
proxy configured. When there is RETURN, I would assume it's a configuration of
chrome and WebRTC should be the same and UDP packets just get routed
differently.

[pthatcher2, 2015/08/26 18:25:39]

kWebRTCNonproxiedUdpTransportEnabled would also work

 #endif
 
   double default_zoom_level = 0;