web-dev-qa-db-fra.com

L'astérisque donne "Strict RTP "apprentissage" et pas d'audio pour Chrome WebRTC mais fonctionne dans Firefox

J'ai expérimenté WebRTC avec un serveur Asterisk (version 13.18) sur le même réseau local que mon ordinateur. J'ai configuré l'extension Asterisk 6003 pour répondre et lire automatiquement un certain fichier son notoire chaque fois qu'il est composé, puis j'ai confirmé que cela fonctionnait avec le client de téléphone logiciel Ekiga.

J'ai ensuite pu le faire fonctionner également dans Firefox en suivant les étapes suivantes:

  • Ouverture du site de démonstration en ligne https://www.doubango.org/sipml5/call.htm?svn=252
  • Ouverture de l'écran du mode expert
  • Cochez la case "Désactiver la vidéo".
  • Saisi [] pour le champ "Serveurs ICE" (parce que je suis sur un réseau local sans NAT impliqué, je n'ai pas besoin de STUN ni de TURN, bien que ICE soit activé dans ma configuration Asterisk)
  • Entré mon "URL du serveur Websocket" valeur de wss://asterisk-ci.test:8089/ws
  • Cliquez sur Enregistrer, puis revenez à la page de démonstration.
  • Entrez les informations sur le serveur astérisque dans la section "Enregistrement" de la page de démonstration et cliquez sur "Connexion", confirmant que le statut "Connecté" s'affiche.
  • Entré le poste 6003 dans la case "Contrôle d'appel" et cliqué sur "Appeler".

Dans Firefox, cela fonctionne très bien - le fichier audio m’est lu au cours de l’appel.

Dans Google Chrome (dernière version 65), aucun son n'est joué, mais à part cela, tout semble devoir fonctionner. En particulier:

  • Le client sipML5 affiche "En appel" et l'interface utilisateur indique l'appel en cours.
  • Aucune erreur dans la console Javascript.
  • Le trafic SIP dans les cadres Websocket de l’onglet Réseau a l’air agréable et semble correspondre à ce que Firefox fait.
  • La page chrome://webrtc-internals indique une grande quantité de trafic entrant. En particulier, le graphique des données sur le canal audio apparaît cohérent avec un fichier son affiché ici.

J'ai essayé de configurer un exemple d'application à l'aide de SIP.js et d'obtenir exactement les mêmes résultats, ce qui confirme que ce n'est pas un problème avec sipML5, mais plutôt quelque chose au sujet de ma configuration Asterisk et de ses interactions avec Google Chrome.

Je me suis connecté à Asterisk via asterisk -vvvvvr pour voir quels messages de débogage pourraient me montrer, et il semble y avoir des différences importantes entre Firefox en fonctionnement et Chrome inutilisé. Voici ce que je vois dans Firefox lors de la connexion, puis de l'appel:

== WebSocket connection from '192.168.99.123:40190' for protocol 'sip' accepted using version '13'
  -- Registered SIP '1061' at 192.168.99.123:40190
== DTLS ECDH initialized (automatic), faster PFS enabled
== Using SIP RTP CoS mark 5
     > 0x7f79f800dba0 -- Strict RTP learning after remote address set to: 192.168.99.123:32807
  -- Executing [6003@users:1] Answer("SIP/1061-00000007", "") in new stack
     > 0x7f79f800dba0 -- Strict RTP learning after ICE completion
     > 0x7f79f800dba0 -- Strict RTP switching to RTP target address 192.168.99.123:32807 as source
  -- Executing [6003@users:2] Playback("SIP/1061-00000007", "auto-playback") in new stack
  -- <SIP/1061-00000007> Playing 'auto-playback.slin' (language 'en')
     > 0x7f79f800dba0 -- Strict RTP learning complete - Locking on source address 192.168.99.123:32807
  -- Executing [6003@users:3] Hangup("SIP/1061-00000006", "") in new stack

Mais le résultat est très différent lors de la connexion à Google Chrome:

== WebSocket connection from '192.168.99.123:52868' for protocol 'sip' accepted using version '13'
  -- Registered SIP '1061' at 192.168.99.123:52868
== DTLS ECDH initialized (automatic), faster PFS enabled
== Using SIP RTP CoS mark 5
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 127.0.0.1:9
  -- Executing [6003@users:1] Answer("SIP/1061-00000008", "") in new stack
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303
  -- Executing [6003@users:2] Playback("SIP/1061-00000008", "auto-playback") in new stack
  -- <SIP/1061-00000008> Playing 'auto-playback.slin' (language 'en')
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303
     > 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303

Le message 0x7f79fc00c710 -- Strict RTP learning after remote address set to: 192.168.99.123:39303 se répète ensuite à l'infini pendant toute la durée de l'appel.

En plus de la répétition de ce message, je remarque que sur Firefox, le message d'origine "Strict RTP learning" a l'adresse correcte, alors que sur Google Chrome, il a 127.0.0.1:9. Le 127.0.0.1 et l'utilisation du port 9 sont intéressants, bien que je ne sois pas sûr de savoir quoi en faire. Google Chrome masque-t-il votre adresse IP d'une manière qui dérange avec Asterisk?

Fait intéressant, lorsque je tente la même chose en utilisant un exemple SIP.js, j’obtiens exactement le même résultat (fonctionne sur Firefox, se connecte mais n’a pas de son sur Chrome) avec le même résultat de débogage dans Asterisk, sauf que l’adresse initiale est 0.0.0.0:9 au lieu de 127.0.0.1:9.

Quoi qu'il en soit, je ne suis pas sûr des prochaines étapes à franchir, alors toute aide serait la bienvenue.

EDIT: Comme suggéré, je posterai les journaux SDP. Voici ce que je reçois pour le fonctionnement de Firefox:

Local SDP (Offer)
v=0
o=mozilla...THIS_IS_SDPARTA-59.0.2 7697709853700369104 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 BD:03:D7:1A:FB:F7:A3:BE:D0:F9:22:65:80:7B:FE:78:1C:17:01:17:99:57:A4:40:49:0D:EF:AA:AA:91:63:2C
a=group:BUNDLE sdparta_0
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 52547 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 192.168.99.123
a=candidate:0 1 UDP 2122252543 192.168.99.123 52547 typ Host
a=candidate:1 1 TCP 2105524479 192.168.99.123 9 typ Host tcptype active
a=candidate:0 2 UDP 2122252542 192.168.99.123 33797 typ Host
a=candidate:1 2 TCP 2105524478 192.168.99.123 9 typ Host tcptype active
a=sendrecv
a=end-of-candidates
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:63350c71006d1daf78366efc8d05347f
a=ice-ufrag:e92ccf7b
a=mid:sdparta_0
a=msid:{8a0a921d-b591-41b5-94e7-647b9b40cd06} {78e4a3a8-628f-4e09-a05a-fa6edb3022be}
a=rtcp:33797 IN IP4 192.168.99.123
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:actpass
a=ssrc:1153204890 cname:{9de8930f-bf76-48e0-a9c9-4c15f6914409}
Remote SDP (Answer)
v=0
o=root 477460967 477460967 IN IP4 172.30.8.8
s=-
t=0 0
a=sendrecv
m=audio 18666 RTP/SAVPF 0 8 101
c=IN IP4 172.30.8.8
a=candidate:Hac1e0808 1 UDP 2130706431 172.30.8.8 18666 typ Host
a=candidate:Hac1e0808 2 UDP 2130706430 172.30.8.8 18667 typ Host
a=sendrecv
a=fingerprint:sha-256 75:D2:BE:77:B6:8E:1B:4E:F9:BF:FB:34:54:2D:05:31:F6:97:C5:34:F3:D9:65:BE:FC:C6:E4:5C:1A:5E:11:E7
a=fmtp:101 0-16
a=ice-pwd:1e0f3ac370cce57d7c978ecb57ae23d9
a=ice-ufrag:7189ea580175062f339a9fe84ed6ecae
a=maxptime:150
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:active

Et voici ce que je vois de Chrome, qui ne fonctionne pas, qui ressemble également à SDP mais qui est tellement différent de celui que je vois, par exemple Je ne vois même pas mon adresse IP dans aucun des résultats:

> createOfferOnSuccess
type: offer, sdp: v=0
o=- 3202047122122577027 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:kQT+
a=ice-pwd:6BgMZ48o3m7PMPFXY7AZvfdb
a=ice-options:trickle
a=fingerprint:sha-256 59:9F:B3:53:89:64:3A:3F:03:1B:32:8F:97:9B:6E:A1:33:B8:05:DD:92:87:3C:1C:CA:A3:83:28:8D:2C:98:FE
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:3990625320 cname:R43Nh5Jptx9sDbOE
a=ssrc:3990625320 msid:C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU c42217e8-19c2-4d94-a392-d4166d00eb22
a=ssrc:3990625320 mslabel:C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU
a=ssrc:3990625320 label:c42217e8-19c2-4d94-a392-d4166d00eb22

> setLocalDescription
type: offer, sdp: v=0
o=- 3202047122122577027 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:kQT+
a=ice-pwd:6BgMZ48o3m7PMPFXY7AZvfdb
a=ice-options:trickle
a=fingerprint:sha-256 59:9F:B3:53:89:64:3A:3F:03:1B:32:8F:97:9B:6E:A1:33:B8:05:DD:92:87:3C:1C:CA:A3:83:28:8D:2C:98:FE
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:3990625320 cname:R43Nh5Jptx9sDbOE
a=ssrc:3990625320 msid:C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU c42217e8-19c2-4d94-a392-d4166d00eb22
a=ssrc:3990625320 mslabel:C0FThsSoaGKxFOoR8Fnptw8vJWdbuN4K2DeU
a=ssrc:3990625320 label:c42217e8-19c2-4d94-a392-d4166d00eb22

> setRemoteDescription
type: answer, sdp: v=0
o=root 2070370846 2070370846 IN IP4 172.30.8.8
s=Asterisk PBX certified/13.18-cert2
c=IN IP4 172.30.8.8
t=0 0
m=audio 13528 RTP/SAVPF 0 8 126
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=maxptime:150
a=ice-ufrag:4c551f814a951c5e6f74e5c225c5e160
a=ice-pwd:7877be1235781d443361467a70b33c12
a=candidate:Hac1e0808 1 UDP 2130706431 172.30.8.8 13528 typ Host
a=candidate:Hac1e0808 2 UDP 2130706430 172.30.8.8 13529 typ Host
a=connection:new
a=setup:active
a=fingerprint:SHA-256 75:D2:BE:77:B6:8E:1B:4E:F9:BF:FB:34:54:2D:05:31:F6:97:C5:34:F3:D9:65:BE:FC:C6:E4:5C:1A:5E:11:E7
a=rtcp-mux
a=sendrecv

Et au cas où cela vous aiderait, voici l'ensemble complet des événements enregistrés lors de la configuration et de la lecture de l'appel:

addStream
createOffer
negotiationneeded
createOfferOnSuccess
setLocalDescription
signalingstatechange
setLocalDescriptionOnSuccess
icegatheringstatechange
icegatheringstatechange
setRemoteDescription
signalingstatechange
iceconnectionstatechange
onAddStream
setRemoteDescriptionOnSuccess

FURTHER EDIT: Après avoir examiné quelques documents SDP et examiné mes propres journaux SDP ci-dessus, la principale chose que je vois qui diffère et explique probablement le fonctionnement de Firefox et Chrome non, c’est que Firefox possède la ligne.

c=IN IP4 192.168.99.123

qui est bien mon adresse IP, alors que Chrome a la ligne

c=IN IP4 0.0.0.0

J'ai essayé d'exécuter Chrome à partir d'un terminal pour capturer toute sortie de débogage imprimée à l'écran, à l'exception de ce que je vois dans chrome: // webrtc-internals et j'ai constaté que ce message était affiché plusieurs fois par seconde:

ERROR:dtlstransport.cc(557)] Jingle:DtlsTransport[audio|1|__]: Received non-DTLS packet before DTLS complete.

J'ai lu plusieurs résultats de recherche Google à propos de cette erreur, mais je n'ai trouvé aucun moyen de remédier à la situation. Cependant, cela semble peut-être lié. Si un ou plusieurs paquets UDP se trouvaient au mauvais endroit, alors même si la plupart des paquets audio étaient correctement envoyés, ils ne seraient jamais décodés et nous verrions beaucoup de données entrer mais aucun son ne serait réellement joué. C'est bien ce que je vois.

Je vais creuser un peu plus pour voir quels paramètres je peux modifier pour que Chrome envoie le même type d'informations que Firefox est en train d'envoyer, ou pour qu'Asterisk fasse ce qu'il faut pour les deux. En attendant, j'ouvre une prime sur cette question, car toute aide supplémentaire et suggestions seront grandement appréciées.

google-chromewebrtcasterisksip
5
Eli Courtwright

Effacez votre cache Chrome, en particulier les cookies et les fichiers en cache. 

aller à chrome://net-internals/#dns

 enter image description here

cliquez sur le cache Clear Host

Tels que vérifier si le prélecture DNS est désactivé ou non chrome://dns

Si le prefetching DNS n'est pas désactivé => vous pouvez voir les tableaux.

Et redémarré chrome.

dns-prefetching

4
sameera lakshitha

La seule différence que j'ai observée est que Strict RTP learning complete est arrivé pour chrome.
Et il n'y a pas de candidats dans Chrome, l'offre peut donc être dans ICE Candidates Negotiation. Sans renifleur de réseau, identifier le problème est un peu difficile.

Lisez les bases du SDP ici: https://webrtchacks.com/sdp-anatomy/

Essayez de jouer avec le mode stricttrtp.
ice_support = yes
rtcp_mux = yes

1
Ajay

Il se peut que chrome soit ignore vos hôtes locaux. Si vous êtes dans Ubuntu, cela devrait être le fichier/etc/hosts.

Ainsi, votre domaine "asterisk-ci.test" local n'est pas résolu en "192.168.99.123".

Essayez de vider le cache de l’hôte de chrome:

  1. Accédez à chrome: // net-internals/# dns sur votre navigateur Chrome.
  2. Appuyez sur Vider le cache de l'hôte.

Pour tester cela, essayez de saisir la valeur "Entrez" URL du serveur Websocket "de wss: //192.168.99.123: 8089/ws". Donc, vous utilisez directement l'adresse IP locale.

Références

L'hôte local ne fonctionne pas dans Chrome, 127.0.0.1 ne fonctionne pas

Pourquoi Chromium contourne-t-il/etc/hosts et dnsmasq

Edit: effacez également les pools de sockets en visitant "chrome: // net-internals/# sockets" en chrome et en cliquant sur "Flush Socket Pools". 

comment effacer le cache DNS en chrome

Vous pouvez également essayer de désactiver "Protégez vous et votre appareil des sites dangereux" dans les préférences avancées de Chrome. ( answer at su stackexchange )

1
Jannes Botis