Actually pass the stereo=1 parameter to WebRTC for receiving audio

remoting/protocol/webrtc_transport.cc

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "remoting/protocol/webrtc_transport.h"
 
 #include <string>
 #include <utility>
 #include <vector>
 
@@ skipping 454 matching lines @@
   std::string description_sdp;
   if (!description->ToString(&description_sdp)) {
     LOG(ERROR) << "Failed to serialize description.";
     Close(CHANNEL_CONNECTION_ERROR);
     return;
   }
 
   SdpMessage sdp_message(description_sdp);
   UpdateCodecParameters(&sdp_message, /*incoming=*/false);
   description_sdp = sdp_message.ToString();
+  {

[Sergey Ulanov, 2017/02/21 18:47:03]

remove these braces, I don't think they add anything.

+    webrtc::SdpParseError err;

[Sergey Ulanov, 2017/02/21 18:47:03]

s/err/error/

[kwiberg-chromium, 2017/02/21 21:32:41]

There's already a function argument called error---if I rename this variable
*and* remove the braces, I shadow it without even opening up a new local scope,
which is a hard error. So I can follow either one of your suggestions, but not
both.

My choice would be to keep the braces, since we've just had a demonstration why
limiting the scope of variables can be useful :-) However, my choice would also
be to have the variable named something other than "error", because shadowing
can be confusing. Do you have a favorite name besides "error"?

[Sergey Ulanov, 2017/02/21 21:49:27]

Maybe call it parse_error?
If you keep the braces it would make this code compile, but it may still be
confusing that there are two different |error| variables.

[kwiberg-chromium, 2017/02/21 21:56:54]

Yes. We *need* to have the braces *or* a variable name != "error", but for good
readability we *should* have both. I originally picked "err" because small
scopes mean variable names don't have to be so long and descriptive (because the
definition + all uses are all in those handful of lines).

OK to keep the braces, and call the variable "parse_error"?

[Sergey Ulanov, 2017/02/21 22:31:52]

Sorry I didn't pay full attention to what you wrote previously.
I would prefer to leave the braces out, if only for consistency with other parts
of this function as well as other functions in this file. E.g. the block that
works on |digest| and |digest_base64| below is not enclosed in braces. 
But feel free to keep the braces if you feel strongly about it.

[kwiberg-chromium, 2017/02/21 23:03:31]

I'll go with your preference since this is your code.

+    description.reset(webrtc::CreateSessionDescription(description->type(),
+                                                       description_sdp, &err));
+    if (!description) {
+      LOG(ERROR) << "Failed to parse the session description: "
+                 << err.description << " line: " << err.line;
+      Close(CHANNEL_CONNECTION_ERROR);
+      return;
+    }
+  }
 
   // Format and send the session description to the peer.
   std::unique_ptr<XmlElement> transport_info(
       new XmlElement(QName(kTransportNamespace, "transport"), true));
   XmlElement* offer_tag =
       new XmlElement(QName(kTransportNamespace, "session-description"));
   transport_info->AddElement(offer_tag);
   offer_tag->SetAttr(QName(std::string(), "type"), description->type());
   offer_tag->SetBodyText(description_sdp);
 
@@ skipping 217 matching lines @@
   // the stack and so it must be destroyed later.
   base::ThreadTaskRunnerHandle::Get()->DeleteSoon(
       FROM_HERE, peer_connection_wrapper_.release());
 
   if (error != OK)
     event_handler_->OnWebrtcTransportError(error);
 }
 
 }  // namespace protocol
 }  // namespace remoting