He pulido un front-end en torno a una API javascript de webRTC/SIP existente y funciona bien, pero descubrí un error en la API subyacente en torno a la espera/reanudación y me obliga a sumergirme en las cosas de WebRTC, lo cual está bien fuera de mi zona de confort.
Tal como está, las llamadas funcionan. Si pongo la llamada en espera, puedo ver que mi RTCPeerConnection tiene un remitente y la pista de ese remitente se vuelve nula. Tengo un RTCRtpTransceiver, y nunca entra en el estado "detenido". El servidor SIP reconoce la espera. Esto se hace con un "removeTrack()" del remitente. Cuando voy a reanudar la llamada, la API llama a "addTrack()" en la conexión entre pares. Lo que sucede es que ahora tengo 2 RTCRtpSenders y 2 RTCRtpTransceivers, y la pista aparece debajo del segundo de cada uno. La experiencia real del usuario es que el audio remoto se reanuda, pero mi micrófono nunca vuelve a la llamada.
Tengo entendido que quiero que mediaStreamTrack se vuelva a conectar al RTCRtpSender original, ¿verdad? Mirando aquí, hay condiciones para reutilizar un remitente pero no está sucediendo; mi lectura del código fuente de la API original hace que parezca que esperan volver a adjuntarse al remitente existente: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/addTrack
Una cosa que intenté hacer fue emitir un "stop ()" al RTCRtpTransceiver, pero eso en realidad hace que la conexión al servidor SIP falle y envía un acuse de recibo de que la retención falló.
No pude llegar a ninguna parte con setStreams, y replaceTrack requeriría hacer un cambio suficiente para hacer que las cosas fueran asincrónicas como para que no quisiera continuar por ese camino todavía.
Admito completamente que las cosas de webRTC están por encima de mi cabeza; agregamos cosas como AD Integration y algunas cosas de DB para almacenar chats/historial de llamadas, pero eliminar un error en la forma en que la API maneja las cosas de WebRTC está un poco fuera de mi alcance.
¿Alguien tiene alguna recomendación sobre cómo manejar esto? Es complicado porque no podemos hacer pública nuestra demostración, pero puedo proporcionar la depuración.
La fuente está aquí, a partir de 406: https://github.com/L1kMakes/sipml5-ng/blob/master/src/tinyMEDIA/src/tmedia_session_jsep.js
La solución fue cambiar a replaceTrack. Necesito limpiar esto un poco, pero este prototipo funciona:
const sender = this.o_pc.getSenders()[0]; const track = This.o_local_stream.getTracks()[0]; sender.replaceTrack(track) .then(() => { console.log("tmedia_session_jsep - resume - Successful Stream Replace!"); }) .catch( e => console.log("tmedia_session_jsep - resume - Error: " + e)); this.o_pc.getTransceivers()[0].direction = "sendrecv";