title: Using WebRTC to view video in a remote browser, local browser never gets ontrack event
body: <p>I'm trying to place a webRTC "call" from a browser that doesn't have an active video stream to a browser that does. The idea is to allow the originating browser to view the webcam of the receiving browser. </p>
  
  <p><strong>Edit</strong>: My particular application calls <em>only</em> for one way video. Audio streams are not involved. </p>
  
  <p>By <em>call</em> I mean a point-to-point connection with just two endpoints.</p>
  
  <p>The call gets set up properly; the offer / answer and candidate-exchange protocols function correctly.</p>
  
  <p>But the originating browser's <code>RTCPeerConnection.ontrack</code> event handler never gets called to announce the video track from the browser receiving the call.</p>
  
  <p>Flipping originator and receiver works: If I originate the call from the browser <em>with</em> the video track -- that is, get that browser's RTCPeerConnection object to generate the <code>offer</code> object -- he browser without the local video stream DOES get the ontrack event.</p>
  
  <p>This happens with all combinations of Google Chrome and Firefox on the two ends of the connection. (Chrome 58.0.3029.110 64-bit, Firefox 53.0.2)</p>
  
  <p>Sone older documentation mentions <code>OfferToREceiveVideo</code> as an option for the <code>pc.createOffer()</code> method.  But I'm not sure that works. Newer documentation doesn't mention it. At any rate, including or omitting it doesn't seem to matter.</p>
  
  <pre><code>var offerOptions = {OfferToReceiveVideo: true, 
                      mandatory: {OfferToReceiveVideo: true}};
  
  localPeerConnection.createOffer ( offerOptions )
      .then(
          function ( offer ) {
            localPeerConnection.setLocalDescription( offer );
            // send the offer to the far end via signaling server
  
          } )
      .catch(
          function ( error ) {
            trace( "error in createOffer", error );
          } );
  </code></pre>
  
  <p><strong>Edit</strong> I have also tried this version of the options object, with the same (negative) result.</p>
  
  <pre><code>var offerOptions = {offerToReceiveVideo: true};
  </code></pre>
  
  <p>and</p>
  
  <pre><code>var offerOptions = {offerToReceiveVideo: true, offerToReceiveAudio: false};
  </code></pre>
  
  <p>without success.</p>
  
  <p>Is there some limitation about asymmetric video-only webRTC connections that I don't understand?  Is there something I have to do to trick an originating RTCPeerConnection object into recognizing an incoming video stream?</p>
  
  <p>I have a workaround: adding a "request" transaction to signaling, to allow the videoless browser to say "call me" to the video-capable browser. But I'm hoping for something more elegant.</p>