J'ai passé des semaines à rechercher le problème où je pouvais ouvrir des équipes mais je ne pouvais pas rejoindre les réunions. Je pouvais faire des appels ad-hoc avec d'autres membres de l'équipe mais les réunions se coupaient au bout de 5 à 10 secondes avec le message d'erreur "Oh là là! Votre appel a été interrompu. Veuillez réessayer."
Réponse
Trop de publicités?
Il y avait un bug dans mon routeur (et dans les routeurs d'autres collègues de différents fournisseurs) qui doublait les ports.
la résolution était de configurer une redirection de port en utilisant les règles suivantes :
Teams Audio : UDP 50000-50019
Teams Video : UDP 50020-50039
Teams Sharing : UDP 50040-50059
voici les détails complets de l'explication du problème :
• À partir des fichiers journaux des médias pour les appels fonctionnels et non fonctionnels, les vérifications de connectivité ne se terminent pas toujours. Initialement, dans les cas de fonctionnement et de non-fonctionnement, le client reçoit une réponse de l'IP du MP (Processeur de Médias) directement comme indiqué ci-dessous Fonctionnement
tc::icemachine::IceMachineImpl::ProcessReceive 13:41:20.835 18208 TL_INFO [19ABA2EF970] : ICEMCHN #0 ProcessReceive() PipeInfo{UDP, Local:10.10.10.0:50006, PalBasedPipe} PipeData{IceData, Encap: Turn, {IP:}, Peer:104.209.195.0:50232, {010100342112a442b3...}}
Non fonctionnement
tc::icemachine::IceMachineImpl::ProcessReceive 13:40:59.885 18208 TL_INFO [19ABA832A20] : ICEMCHN #0 ProcessReceive() PipeInfo{UDP, Local:10.10.10.0:50002, PalBasedPipe} PipeData{IceData, Encap: None, {IP:}, Peer:104.209.192.0:51402, {000100542112a4423f...}}
Cependant, dans l'appel fonctionnel, l'IP de l'hôte n'est pas promue et cela fonctionne via l'IP relais sur 3480
ICEMCHN Pairs Dump : Échec de IceCandidatePair{ P:0x7efffdfefdfffbfc L:IceCandidate{F:1 Rtp:{HostUDP, {IP:10.10.10.0:50006}, base:10.10.10.0:50006, rel:10.10.10.0:50006, bw:0, p:0x7efffdfe, pipe:UDP}, Rtcp:{Mux}} R:IceCandidate{D, F:1 Rtp:{StunUDP, {IP:104.209.195.0:50232}, base:, rel:, bw:0, p:0x7efffdfe, pipe:None}, Rtcp:{Mux}} DL:,}
ICEMCHN Pairs Dump : Réussi IceCandidatePair{ P:0x0afff5fefdfffbfc L:IceCandidate{D, F:5 Rtp:{TurnUDP, {IP:52.114.188.0:3480, ID:{864350ac4fd269e1}}, base:10.10.10.0:50006, rel:108.168.97.0:50006, bw:0, p:0x0afff5fe, pipe:UDP}, Rtcp:{Mux}} R:IceCandidate{D, F:1 Rtp:{StunUDP, {IP:104.209.195.0:50232}, base:, rel:, bw:0, p:0x7efffdfe, pipe:None}, Rtcp:{Mux}} DL:52.114.188.0:3480,52.114.188.0:3480}
Dans les journaux de non fonctionnement, il n'y a pas de réponse pour la paire hôte et cela ne parvient pas non plus à échouer sur le chemin de secours TL_WARN [19ABA832A20] : ICEMCHN #0, Le chemin de secours n'est pas trouvé
Après discussion avec le groupe de produits, nous avons découvert que 1. Le client envoie un paquet de vérification de connectivité au MP pour la modalité audio, le port source est 50006, le port de destination est 53176 Le MP le reçoit, le port source mappé est 1026 2. Le client envoie un paquet de vérification de connectivité au MP pour la modalité vidéo, le port source est 50032, le port de destination est 57270 Le MP le reçoit, le port source mappé est 1026 3. Le client envoie un paquet de vérification de connectivité au MP pour la modalité de partage d'application, le port source est 50052, le port de destination est 59746 Le MP le reçoit, le port source mappé est 1026
Le NAT utilise donc le même port source pour plusieurs ports sources et destinations différents. Au fur et à mesure que l'appel progresse, le client envoie plus de paquets de vérification de connectivité au MP et ne reçoit pas de réponses pour l'audio et la vidéo; lorsque la modalité audio échoue, c'est pourquoi il abandonne l'appel. Cependant, d'après les journaux du MP, je peux dire que le MP reçoit effectivement ces demandes et y répond.
Dans les traces wireshark, j'ai pu voir une demande envoyée de l'IP du client à l'IP du processeur de médias comme ci-dessous 6052 37.667639 10.10.10.110 137.116.60.197 STUN 150 Requête de liaison utilisateur: nz22:7IQN Protocole Internet Version 4, Src : 10.10.10.110, Dest. : 137.116.60.197 Protocole de Datagramme d'Utilisateur, Port Src : 50006, Port Dest. : 53176
Et la réponse envoyée est redirigée vers une IP différente par le NAT comme ci-dessous
6065 37.733923 137.116.60.197 10.10.10.110 STUN 114 Réussite de la réponse de liaison ADRESSE-MAPPEE-XOR: 108.168.97.86:1026 Protocole Internet Version 4, Src : 137.116.60.197, Dest. : 10.10.10.110 Protocole de Datagramme d'Utilisateur, Port Src : 53176, Port Dest : 50058 ADRESSE-MAPPEE-XOR: 108.168.97.86:1026
D'après le trafic ci-dessus, il est clair que le trafic envoyé par le MP est routé vers le NAT (108.168.97.86:1026) et modifie le port source. Le NAT ne maintient pas correctement les mappages, et redirige tous les paquets reçus sur le port 1026 vers le même port source, probablement 50052, la modalité qui a fonctionné. 50052 reçoit probablement tout ce qui arrive à 1026, et c'est pourquoi je vois des traces de paquets abandonnés, car il reçoit des paquets qui devraient vraiment aller à 50032 ou 50006.
Sur la base de nos recherches et analyses, il semble que ce soit les mappages NAT. Comme le montrent les traces wireshark, le NAT redirige tous les paquets reçus sur le port 1026 vers le même port source, probablement 50052 qui est utilisé pour le partage d'application et dans les journaux je pouvais voir la modalité de partage d'application réussie qui a fonctionné. Le problème est que le NAT ne sépare pas les chemins. Il en résulte que le trafic des 3 ports du serveur finit par aller au même port privé, 50052 dans ce cas.
Le NAT peut choisir de donner à ces ports privés des ports publics séparés, ou il peut choisir de donner à ces ports privés le même port public, comme il le fait ici. les deux façons sont valables. la chose est que si vous décidez de réutiliser le même port public, alors la seule façon de savoir quel est le bon port privé pour rediriger le trafic est de suivre quel est la destination du trafic ou d'où il provient, ce que le NAT ne fait peut-être pas ici. La première chose que le client teams fait à partir de ce port source (c'est-à-dire 50006) est d'envoyer du trafic d'allocation à son relais. Il s'agit du premier paquet de médias sortants que le NAT verra. Souvent, les NAT essaieront de donner à ce trafic le même port public que le port privé et, en fait, ce NAT semble le faire - le port que le relais a vu sur le NAT était le même que le port privé de 50006 (tout comme pour la vidéo et le partage d'application). 1026 n'est entré en jeu que lorsque le NAT a vu des paquets du même port source destinés à des destinations différentes - dans ce cas le MP. Ainsi, le premier paquet de 50006, destiné au relais, a reçu le port public 50006 par le NAT. Cependant, un paquet du même port privé destiné au MP (différente IP et port que le relais) a obtenu le port source NAT 1026. Le serveur essaie en fait d'envoyer un paquet directement à l'IP de l'ordinateur, mais cette IP est une IP privée et donc ce paquet n'atteindra jamais la machine. Le serveur essaie également d'envoyer un paquet à l'adresse IP publique que le client a envoyée dans son offre. Cela se produit généralement avant que le client ne soit prêt à recevoir le paquet cependant, et donc la plupart des NAT rejettent ces paquets.
