Tengo dos compañeros que envían video a través de WebRTC. Los pares usan la negociación perfecta en paralelo, lo que significa que en algunos casos un par puede hacer una oferta y luego desecharla y usar la oferta del otro par en su lugar. Por alguna razón, cuando esto sucede, una vez que la conexión se abre de verdad y este par recibe una pista de medios, la pista ya "finaliza" inmediatamente y no se puede usar.

He simplificado esto a una reproducción mínima:

 const rtc1 = new RTCPeerConnection(); const rtc2 = new RTCPeerConnection(); rtc1.ontrack = ({ track }) => { console.log('rtc1 got track:', track.readyState); }; rtc2.ontrack = ({ track }) => { console.log('rtc2 got track:', track.readyState); }; stream = await navigator.mediaDevices.getUserMedia({ video: true }); rtc2.addTrack(stream.getTracks()[0], stream); rtc1.addTrack(stream.getTracks()[0], stream); // These two lines break everything: o = await rtc2.createOffer(); await rtc2.setLocalDescription(o); // --- o = await rtc1.createOffer(); await rtc1.setLocalDescription(o); await rtc2.setRemoteDescription(o) a = await rtc2.createAnswer(); await rtc2.setLocalDescription(a); await rtc1.setRemoteDescription(a);

Creo que esto debería configurar una conexión WebRTC con una transmisión de video SendRecv en ambas direcciones, para que imprima got track: live dos veces.

Desafortunadamente, en realidad esto imprime:

 rtc2 got track: ended rtc1 got track: live

Es decir, la pista de ontrack ya está 'terminada' cuando se activa la devolución de llamada en la pista. RTC2 nunca recibe una pista de medios de trabajo. ¿Por qué?

Estoy probando esto en el último Chrome: 100.0.4896.75.

Comentar las dos líneas marcadas arriba que crean una oferta no utilizada resuelve esto. En ese caso, ambas pistas están live como se esperaba. Sin embargo, parece que esa oferta no debería ser un problema, y con el patrón de configuración de "negociación perfecta" recomendado oficialmente (o algo similar), este tipo de ofertas no utilizadas parecen inevitables.