Así que he estado buscando una manera de integrar webRTC en un sitio que estoy creando, pero quiero hacerlo en un alojamiento compartido. Encontré este repositorio en GitHub por nielsbaloe y ha sido de gran ayuda para obtener una conexión básica.
Este es el código que creo que es responsable de agregar el par: (index.html en el repositorio, línea)
function icecandidate(localStream) { pc = new RTCPeerConnection(configuration); pc.onicecandidate = function (event) { if (event.candidate) { publish('client-candidate', event.candidate); } }; try { pc.addStream(localStream); }catch(e){ var tracks = localStream.getTracks(); for(var i=0;i<tracks.length;i++){ pc.addTrack(tracks[i], localStream); } } pc.ontrack = function (e) { document.getElementById('remoteVideo').style.display="block"; document.getElementById('localVideo').style.display="none"; remoteVideo.srcObject = e.streams[0]; }; }Ahora, la lucha a la que me enfrento es agregar la funcionalidad de la sala, y tal vez la capacidad de tener más de dos pares concurrentes presentes al mismo tiempo. Hice algunos experimentos, pero en vano. Sé que para la funcionalidad de la sala, tengo que jugar en el php, así que al menos me gustaría descubrir cómo hacer posible más de 1 par.
Hasta donde yo sé, no hay forma de reutilizar la misma RTCPeerConnection para múltiples pares, por lo que tendrá que hacer lo mismo que 1 a 1 pero entre cada par de un grupo.
En cuanto a la señalización, es bastante simple, es más o menos así:
Cliente A -> [Oferta] -> Servidor -> [Oferta] -> Cliente B -> [Respuesta] -> Servidor -> [Respuesta] -> Cliente A
No hay necesariamente una necesidad de NodeJS o WebSocket. La razón por la que la mayoría de la gente lo elige es porque el último eslabón de esta cadena (Servidor -> Cliente A) requiere una conexión iniciada por el servidor. Pero eso se puede sustituir con técnicas alternativas como el sondeo (largo). O, en el caso de PHP, puede usar implementaciones de websocket como Bloatless o Aerys
Para implementar la funcionalidad de la sala, deberá implementar lo siguiente:
Variante A (mediante sondeo):
Un punto final para lanzar ofertas, por ejemplo, POST /rooms/{id}
Un punto final para buscar regularmente nuevas ofertas, por ejemplo, GET /rooms/{id}
Variante B (con websockets)
En ambos casos, es posible que desee crear varias ofertas por adelantado para agruparlas desde el servidor o crear dinámicamente otras nuevas, pero, lo más importante, asegúrese de no conectar a los mismos pares dos veces, de lo contrario terminará con un bucle. Para evitarlo, solo proporcione a cada usuario una cadena generada aleatoriamente para identificarse y enviarla entre las ofertas.
Hay soluciones llave en mano disponibles si no quiere seguir esta ruta, pero tenga cuidado y verifique si puede usar sus propios servidores TURN con ellas. Una tendencia común que he notado es que hay muchos proveedores de soluciones WebRTC que lo atraen con su simplicidad pero luego lo bloquean con sus propios servidores TURN por los que es posible que tenga que pagar una factura bastante alta más adelante.