--- a/media/webrtc/signaling/src/media-conduit/VideoConduit.cpp
+++ b/media/webrtc/signaling/src/media-conduit/VideoConduit.cpp
@@ -1207,33 +1207,35 @@ WebrtcVideoConduit::ConfigureRecvMediaCo
     mRecvStreamConfig.rtp.keyframe_method = kf_request_method;
 
     if (use_fec) {
       mRecvStreamConfig.rtp.fec.ulpfec_payload_type = ulpfec_payload_type;
       mRecvStreamConfig.rtp.fec.red_payload_type = red_payload_type;
       mRecvStreamConfig.rtp.fec.red_rtx_payload_type = -1;
     }
 
+    // SetRemoteSSRC should have populated this already
+    mRecvSSRC = mRecvStreamConfig.rtp.remote_ssrc;
+
     // XXX ugh! same SSRC==0 problem that webrtc.org has
     if (mRecvSSRC == 0) {
       // Handle un-signalled SSRCs by creating a random one and then when it actually gets set,
       // we'll destroy and recreate.  Simpler than trying to unwind all the logic that assumes
       // the receive stream is created and started when we ConfigureRecvMediaCodecs()
       unsigned int ssrc;
       do {
         SECStatus rv = PK11_GenerateRandom(reinterpret_cast<unsigned char*>(&ssrc), sizeof(ssrc));
         if (rv != SECSuccess) {
           return kMediaConduitUnknownError;
         }
       } while (ssrc == 0); // webrtc.org code has fits if you select an SSRC of 0
 
       mRecvStreamConfig.rtp.remote_ssrc = ssrc;
+      mRecvSSRC = ssrc;
     }
-    // Either set via SetRemoteSSRC, or temp one we created.
-    mRecvSSRC = mRecvStreamConfig.rtp.remote_ssrc;
 
     // 0 isn't allowed.  Would be best to ask for a random SSRC from the
     // RTP code.  Would need to call rtp_sender.cc -- GenerateNewSSRC(),
     // which isn't exposed.  It's called on collision, or when we decide to
     // send.  it should be called on receiver creation.  Here, we're
     // generating the SSRC value - but this causes ssrc_forced in set in
     // rtp_sender, which locks us into the SSRC - even a collision won't
     // change it!!!