Added functions on libjingle API to start and stop the recording of an RtcEventLog.

talk/app/webrtc/peerconnectionfactory.h

Index: talk/app/webrtc/peerconnectionfactory.h
diff --git a/talk/app/webrtc/peerconnectionfactory.h b/talk/app/webrtc/peerconnectionfactory.h
index c5855f452b76cc4be2be35d3e6e7c91c5d0d2ef6..b7edd21040be2f30404e999712cff45c9a1c98c6 100644
--- a/talk/app/webrtc/peerconnectionfactory.h
+++ b/talk/app/webrtc/peerconnectionfactory.h
@@ -79,6 +79,8 @@ class PeerConnectionFactory : public PeerConnectionFactoryInterface {
                        AudioSourceInterface* audio_source) override;
 
   bool StartAecDump(rtc::PlatformFile file) override;
+  bool StartRtcEventLog(rtc::PlatformFile file) override;

[Henrik Grunell WebRTC, 2015/10/02 10:23:42]

Although not ideal, this is afaik the most reasonable place to have this
function.

[terelius, 2015/10/02 12:16:26]

So is there a reason for having the ChannelManager in the factory rather than in
the PeerConnection? Wouldn't it make sense to let the PeerConnection manage its
own channels?

[Henrik Grunell WebRTC, 2015/10/02 12:23:40]

I don't know. I'm not the right person to answer that. :) (It seems to be
outside the scope of this CL too.)

[terelius, 2015/10/02 12:46:34]

Acknowledged.

+  void StopRtcEventLog() override;

[terelius, 2015/10/02 10:07:14]

I'm not very familiar with the PeerConnection and related code, but I assume
that PeerConnectionFactory works like a regular factory which produces
PeerConnections with consistent configurations.

If this is correct, then I don't understand why we have methods to start and
stop logging in the PeerConnectionFactory. Shouldn't it be in PeerConnection
and/or PeerConnectionInterface?

[ivoc, 2015/10/05 14:16:32]

I think one of the problems is that there can be multiple PeerConnections that
correspond to a single VoiceEngine. Also, the start function for AECdump is
located here, so it makes sense to keep them together.

[pthatcher1, 2015/10/06 20:49:09]

But why is this logging tied to the voice engine?  Is it audio-specific?  And do
we really want cross-PeerConnection logging?  It seems like it would make more
sense to log per-Call object and per-PeerConnection.

[ivoc, 2015/10/07 14:27:27]

The current place of the logging object is a temporary solution, we have plans
to move it to Call when the refactoring of VoE is further along. The reason why
VoE is involved is that beside RTP headers we're also logging debug events
inside of the audio coding module. I think for now we can accept that logging
multiple peerconnections can lead to strange logs (identical SSRCs etc). Since
VoE outlives Call, it was easier to put the logging object in VoE, so we don't
have to worry about dangling pointers or shared ownership. 

 
   virtual cricket::ChannelManager* channel_manager();
   virtual rtc::Thread* signaling_thread();