Chat vidéo WebRTC avec Ajax au lieu de WebSocket: Possible?

Il y a six mois, j'ai pu réussir le code de mon propre serveur WebSocket script en PHP. Grâce à cela, j'ai été capable de mettre en place un WebRTC service de vidéo chat sur mon hôte local. J'ai été très heureux jusqu'à ce que j'ai réalisé que, pour le déployer, j'avais besoin d'un serveur web qui m'a donné accès aux sockets.

Malheureusement, aucun d'hébergement web partagé permet à pour les prises et tous les serveurs web qui offrent des sockets sont chers. Alors que pas une solution efficace sur une grande échelle, pour l'amour de la création d'une démo pour montrer aux gens, je veux changer la méthode de signalisation de WebSocket à Ajax afin que je puisse montrer WebRTC service de vidéo chat que j'ai fait.

À cette fin, j'ai essayé de coder quelque chose depuis quelques jours, mais n'ont pas eu de succès en obtenant le WebRTC pairs pour capturer des uns et des autres vidéo.

À l'instant, quand un client se connecte sur le script, j'utilise de l'Ajax pour envoyer une demande à un script PHP qui vérifie si il y a d'autres utilisateurs actifs dans la DB. Si non, le script crée ensuite une offre, et des lieux de l'offre de la DB. Après cela, le client interroge un distinct script PHP à chaque seconde pour vérifier une réponse à partir d'un autre client qui se connecte au script.

Après cela, je puis vous connecter à l'script à partir d'un autre client, qui interroge le même script PHP et de la DB, qui se rend alors compte qu'un utilisateur actif (de la première connexion) a déjà publié une offre, le deuxième, le client acquiert et des décors pour la télécommande description. Le deuxième client crée ensuite une réponse, qui est placé dans la DB.

À ce point, le premier client (qui est d'interrogation de la DB à chaque seconde) détecte que la réponse est présente et que des ensembles de réponse à distance description pour le premier client. Malheureusement, même après avoir réussi à faire tout ça, de l'autre client de la vidéo n'est pas à éclater.

Donc voilà où j'en suis confus et trois (multipart) questions:

1), j'ai pensé que, après tant de clients à définir leurs locaux description, puis envoyé locaux de la description à l'autre client et l'autre client qui a reçu la description de la télécommande description de l'onaddstream événement était censé le feu, me permettant ainsi de l'affichage de la vidéo à distance. Cependant, ce n'est pas le cas. Ça marchait bien avant, quand j'ai utilisé WebSocket, mais cela ne fonctionne pas du tout avec Ajax pures. Est-il quelque chose en particulier, je suis absent? A WebRTC spec changé radicalement au cours des six derniers mois? J'ai essayé de regarder le WebRTC specs, mais je ne vois pas de changements majeurs.

2) Après frustré de ne pas arriver à des choses à travailler avec l'Ajax, je suis retourné à mon WebSocket version et l'a chargé sur mon hôte local. Je n'ai pas changé le code à tous, depuis la dernière utilisation (ce qui a bien fonctionné il y a six mois), mais maintenant, quand j'essaie de l'utiliser, parfois ça marche et parfois ça ne marche pas. Parfois, j'ai des erreurs liées à l'impossibilité de définir le local et/ou distant descriptions. Qu'est-ce cela? Il y a eu des changements aux spécifications qui serait l'origine de ce problème? À cet égard, même si je ne peux pas obtenir de la télécommande vidéos de pop-up avec l'Ajax version, j'ai été en écho à beaucoup de choses à la console, et il semble comme avec l'Ajax version ainsi, parfois, le local et à distance des descriptions pour les deux clients sont correctement mis en place, et parfois, les erreurs se produit lorsque vous tentez de définir la locale/à distance des descriptions pour quelque raison que ce soit, même si je suis en cours d'exécution exactement le même script à chaque fois sans aucun changement. J'utilise la dernière version de Chrome, et je commence à me demander si il y a un bug ou quelque chose.

3) Est le onicecandidate gestionnaire d'événements nécessaires pour établir une connexion? Mon hypothèse était que les pairs pourrait établir une connexion avec simplement une offre valide et la réponse, et que le onicecandidate événement a été utiliser pour fournir d'autres routes, etc., ce qui pourrait conduire à une meilleure qualité de connexion (mais ne sont pas obligatoires). Suis-je tort? Si le onicecandidate info est nécessaire, comment me recommandez-vous gérer cela avec Ajax comme la signalisation méthode?

Je sais que beaucoup d'informations et beaucoup de questions, mais toutes les informations/connaissances que n'importe qui peut offrir serait très apprécié. J'ai été frapper ma tête contre mon bureau depuis quelques jours à essayer de comprendre cela, et rien n'est de donner un sens.

source d'informationauteur HartleySan

  1. 11

    Mon premier conseil au sujet de votre application. de travail/pas de travail, de façon sporadique, c'est de regarder en ligne en cours de travail mises en œuvre. Il y a beaucoup de WebRTC démos sur les Internets.

    AJAX

    Sur AJAX: pourquoi ne serait-il pas de travail? Je suis actuellement en train de travailler sur la même chose que vous, et il fonctionne très bien chaque fois que (je ne peut pas divulguer la source pour le moment). Les Clients sont en constante interrogation du serveur à intervalles réguliers et qu'ils peuvent envoyer SDP descriptions/GLACE candidats à un autre client de cette façon. Le serveur agit comme un simple pont (c'est la base de la signalisation).

    Être il WebSocket, AJAX ou IPoACaussi longtemps que vous le transfert à l'autre client tout ce qu'il faut (et au bon moment, plus sur cela plus tard), cela devrait fonctionner. J'ai même fait une démonstration où vous manuellement copier/coller la description SDP et de la GLACE candidats à l'aide de zones de texte et cliquez sur les boutons pour aller de l'avant dans le processus de signalisation et que, bien sûr, a bien fonctionné aussi.

    GLACE candidats

    Maintenant: oui, vous avez besoin de la GLACE de candidats. Regardez un exemple de SDP offre morceau je viens générées à l'aide de createOffer sur Chrome 27:

    v=0
o=- 3866099361 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8
m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:l8Qu31Vu4VG5YApS
a=ice-pwd:TpyQ5iESUH4HvYGE4ay8JUhe
a=ice-options:google-ice
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bC5YSe2xCmui0wSxUHWKIi9INbZ2y0VrO1swoZbl
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:1976175890 cname:/+lKYsttecoiyiu5
a=ssrc:1976175890 msid:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8 9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8a0
a=ssrc:1976175890 mslabel:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8
a=ssrc:1976175890 label:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8a0
m=video 1 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:l8Qu31Vu4VG5YApS
a=ice-pwd:TpyQ5iESUH4HvYGE4ay8JUhe
a=ice-options:google-ice
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=sendrecv
a=mid:video
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bC5YSe2xCmui0wSxUHWKIi9INbZ2y0VrO1swoZbl
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack 
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3452335690 cname:/+lKYsttecoiyiu5
a=ssrc:3452335690 msid:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8 9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8v0
a=ssrc:3452335690 mslabel:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8
a=ssrc:3452335690 label:9kTlKaNe1exIs6JgEFYfXlu6E5f4B5R3I2D8v0

    Ne vous voyez quelque chose qui pourrait aider un autre client de se connecter à ma machine? Je ne le pense pas. Le but de toute cette GLACE mécanisme est de rassembler connexion candidats (local, comme 192.168.1.15"public" (l'adresse IP publique attribuée par votre FAI) à l'aide d'ÉTOURDISSEMENT si vous êtes derrière un NAT qui n'est pas symétrique, ou de VIRAGE de la symétrie des NATs).

    Lors de la réception de celles de la GLACE candidats, l'autre par les pairs va les commander à l'aide de certaines des mesures prédéfinies pour établir les priorités et puis le problème des tests de connexion de trouver un bon candidat. Merci donc de partager entre eux: les autres par les pairs a besoin d'eux (et vous avez besoin de son trop).

    Voici donc quelques une de mes GLACES des candidats:

    a=candidate:303249700 1 udp 2113937151 192.168.50.238 43806 typ host generation 0
a=candidate:303249700 2 udp 2113937151 192.168.50.238 43806 typ host generation 0
a=candidate:1552991700 1 tcp 1509957375 192.168.50.238 35630 typ host generation 0

    Maintenant ceux qui sont en béton (quoique seulement local, parce que je n'ai pas la configuration de la CCF par les pairs connexion avec un STUN URL) des moyens pour l'autre par les pairs pour se connecter à ma machine.

    WebRTC signalisation conseils

    Il y a quelques astuces intéressantes sur le fond de cette page. Je honnestly ne pouvait pas vous dire pourquoi vous devriez suivre ces ou pourquoi ils existent en premier lieu, mais je ne les suivent et n'avait pas de problèmes de signalisation. Ici, ils sont:

    1. Pour répondeur: ne JAMAIS ajouter de la GLACE candidats jusqu'à ce que les pairs génère/crée réponse SDP
    2. Arrêter d'ajouter de la GLACE candidats quand les flux à distance commence à couler
    3. De ne pas créer de pairs connexion pour répondeur jusqu'à ce que vous obtenez l'offre SDP

    Vous pouvez gérer tous que du côté client, en ayant une WebRTC finis de l'état de la machine. Veuillez voir la page référencé pour comprendre ce qu'il entend par flux à distance commence à couler.

    Essayez de partager la GLACE candidats et les ajouter à l'opposé et au moins suivre les conseils de #1 et #3, et votre application devrait fonctionner à nouveau.

    De signalisation de communication

    Vous demandé comment faire pour transférer une GLACE candidat à partir d'un poste à un autre dans le cas de la GLACE de candidats important de l'action (ils sont). Pour partager des choses en utilisant AJAX, quelles qu'elles soient, vous pouvez utiliser les boîtes aux lettres. Je crois que vous êtes déjà en plaçant ce qui est dû pour un client dans la base de données.

    Chaque fois qu'un de ses pairs, a besoin d'envoyer quelque chose à un autre, et de l'envoyer le plus tôt possible (à l'aide d'AJAX). Sur le côté serveur, la place cette "mail" dans la destination boîte aux lettres du client. Quand un pair (périodiquement) interroge le serveur pour les nouveaux mails, donner tous ses nouveaux mails.

    Lorsqu'un SDP offre est créée, la GLACE, les candidats sont rapidement généré. Tous ceux qui GLACE les candidats et le SDP description sera probablement obtenir dans la boîte aux lettres de destination dans un délai de quelques millisecondes. Il y a de bonnes chances que la destination des pairs sondage devez tout à la fois. Même si de la GLACE candidat arrive en retard, son prochain scrutin sera l'obtenir.

  2. 2

    Ce n'est pas vraiment répondre à vos questions, mais pour un serveur de signalisation, vous voudrez peut-être jeter un oeil à Socket.io (sur le Nœud). J'ai écrit un codelab expliquant comment le configurer:bitbucket.org/webrtc/codelab. C'est très simple: l'exemple complet est ici: la signalisation en code serveur est d'environ 50 lignes.

    SimpleWebRTC exécute le Signalmaster serveur, qui utilise les Socket.io.

    (Robert Nyman a écrit un bon post de blog expliquant cela.)

    Une autre option est d'utiliser XHR avec la Google API de voie, comme par le apprtc.appspot.com exemple: code ici.

  3. 2

    Aucun moyen d'envoyer des messages devraient travailler de manière équivalente. Il peut aider à garder à l'esprit que, ne sont que 4 de base, les messages que vous souhaitez échanger:

    1. de notification de l'un de ses pairs, a rejoint (ou à gauche)
    2. une offre de message ==> SetRemoteDescription avec elle, puis faire une réponse & envoyer
    3. un message de réponse ===> SetRemoteDescription avec elle
    4. une glace candidat envoyé à partir de l'autre par les pairs ==> appel addIceCandidate avec elle

    La glace candidate chose est la partie étrange. Aussi, le candidat de l'objet contient des drôles de personnages, de sorte que lorsque vous l'envoyer, URI de l'encoder. En Coffeescript, le mien ressemble à quelque chose comme:

    peer_connection.onicecandidate = (e) ->
send { 
line_index: e.candidate.sdpMLineIndex
candidate: encodeURIComponent(e.candidate.candidate) }

    eepp la réponse est bonne, mais il contient quelques conseils je ne pense pas correct. Plus précisément, ces 3 conseils, je crois, sont tous incorrect:

    • Pour répondeur: ne JAMAIS ajouter de la GLACE jusqu'à ce que les candidats que par les pairs
      génère/crée réponse SDP
    • Arrêter d'ajouter de la GLACE candidats lors de la distance
      stream commence à couler
    • De ne pas créer de pairs connexion pour répondeur jusqu'
      vous obtenez l'offre SDP

    Ici est une séquence d'évènements que j'ai aujourd'hui (Février 2014) en Chrome. C'est pour un cas simplifié où les pairs 1 va diffuser de la vidéo par les pairs 2.

    1. Configuré d'une certaine façon pour les pairs pour échanger des messages. (La variance dans la façon dont les gens à accomplir ce est ce qui le rend différent WebRTC exemples de code donc incommensurables, malheureusement. Mais mentalement, et dans votre organisation du code, essayez de séparer cette logique du reste.)
    2. Sur chaque côté, de configurer les gestionnaires de messages pour les important les messages de signalisation. Vous pouvez les configurer et de les laisser en place. Il y a 4 messages essentiels pour gérer & envoyer:
      • autres pairs rejoint
      • une glace candidat envoyé de l'autre côté ==> appel addIceCandidate avec elle
      • une offre de message ==> SetRemoteDescription avec elle, puis faire une réponse & envoyer
      • un message de réponse ===> SetRemoteDescription avec elle
    3. Sur chaque côté, de créer un nouveau peerconnection objet et de fixer des gestionnaires d'événements pour les événements importants: onicecandidate, onremovestream, onaddstream, etc.
      • glace candidat ===> envoyer de l'autre côté
      • flux ajoutée ===> de l'attacher à un élément vidéo de sorte que vous pouvez le voir, il
    4. Lorsque les deux pairs sont présents et tous les gestionnaires sont en place, peer 1 reçoit un message de déclenchement d'un certain type pour commencer la capture vidéo (à l'aide de la getUserMedia appel)
    5. Une fois getUserMedia réussit, c'est un flux. Appel addStream sur le peer 1 par des pairs de l'objet de connexion.
    6. Alors-et seulement alors-peer 1 fait une offre
    7. En raison de l'gestionnaires nous avons mis en place à l'étape 2, peer 2 obtient ceci et envoie une réponse
    8. Simultanément avec cela (et un peu obscurément), les pairs objet de connexion commence à produire de la glace candidats. Ils obtiennent le va-et-vient entre les deux pairs et manipulés (étapes 2 & 3 ci-dessus)
    9. Streaming commence par lui-même, de manière opaque, comme un résultat de 2 conditions:
      • offre/réponse de change
      • glace candidats ont reçu, échangé, et a ajouté

    Je n'ai pas trouvé un moyen d'ajouter de la vidéo après l'étape 9. Lorsque je veux changer quelque chose, je reviens à l'étape 3.