Remove unnecessary RTPHeaderParser, following https://codereview.webrtc.org/2659563002/

webrtc/call/call.cc

Index: webrtc/call/call.cc
diff --git a/webrtc/call/call.cc b/webrtc/call/call.cc
index 37b5c6a4fbf5fef7683d9b6eea3f6e08c1b7fff6..8ada2068d3c01230bc9939aee9ad207ef0e649b6 100644
--- a/webrtc/call/call.cc
+++ b/webrtc/call/call.cc
@@ -207,7 +207,7 @@ class Call : public webrtc::Call,
     // extensions per SSRC instead, which leads to some storage overhead.
     RtpHeaderExtensionMap extensions;
     // Set if the RTCP feedback message needed for send side BWE was negotiated.
-    bool transport_cc;
+    bool transport_cc = false;

[nisse-webrtc, 2017/02/01 14:50:17]

Does style guide suggest always providing default values?

This field ought to always be initialized by the constructor. Use of the default
constructor is an error (but unfortunately it is required because std::map
assignment seems to use the default constructor + assignment operator. If you
know any way to delete the default constructor, that would be nice).

I intentionally left it uninitialized here, since that lets tools like valgrind
and msan detect any improper use of the uninitialized value. Adding a default
value here defeats those tools. 

[the sun, 2017/02/01 15:12:06]

I don't know. It's a habit that has saved me many times though.
That's a good argument, but relies on test coverage and infrastructure to hold.
By always initializing members we will get consistent behavior in the case where
the data type is used in the wrong way, thus making bugs easier to find.

IMO, the only place where it would be a good idea to not initialize members
would be in inner loops.

[nisse-webrtc, 2017/02/02 08:10:11]

Ok.

   };
   std::map<uint32_t, ReceiveRtpConfig> receive_rtp_config_
       GUARDED_BY(receive_crit_);