Un Poly CCX 500 (firmware 7.1.3.0991) affiche « No internet. Emergency calls aren’t supported » et ne passe plus d’appels ? Suivez ce guide pas‑à‑pas pour diagnostiquer la cause (réseau, heure/certificats, licence, firmware) et rétablir rapidement la téléphonie Teams.
Vue d’ensemble
Le message « No internet. Emergency calls aren’t supported » indique que le téléphone ne parvient pas à établir une session sécurisée avec les services Microsoft Teams. Sur un parc, il arrive fréquemment qu’un seul CCX 500 soit affecté : c’est un indice fort d’un problème ponctuel (port/switch, VLAN, profil de provisioning, heure ou certificats côté appareil, compte ou licence) et non d’une panne générale du réseau ou des services Microsoft.
Ce guide combine des vérifications locales rapides, une méthodologie de diagnostic réseau, des contrôles de comptes/licences et des actions curatives (mise à jour, ré‑initialisation). Il est conçu pour être exécuté par un administrateur poste, réseau ou Microsoft 365/Teams.
Résumé opérationnel — actions prioritaires
- Isoler le réseau : changer de câble Ethernet, de port PoE/switch et (si possible) de VLAN de test → vérifier si l’erreur disparaît.
- Valider l’adressage : s’assurer que le DHCP fournit IP, passerelle, DNS fonctionnels et que la résolution DNS des domaines Microsoft/Teams réussit.
- Contrôler l’heure : synchronisation NTP correcte (écart < 5 minutes). Une horloge fausse invalide les certificats TLS.
- Essayer un autre compte : connexion avec un compte Teams Phone connu pour fonctionner afin de distinguer problème matériel vs. compte.
- Mettre à jour : appliquer la dernière version stable/LTS du firmware CCX (les branches 8.x corrigent divers cas de connectivité).
- Si persistant : factory reset, re-provisionnement propre, puis escalade au support Microsoft via l’administrateur global 365.
Tableau de réponses & pistes de solution
| Axe | Actions proposées |
|---|---|
| Support Microsoft 365 | L’administrateur global Microsoft 365 ouvre un ticket auprès du support Microsoft pour prise en main à distance. Si l’abonnement est géré par un revendeur, c’est lui qui initie la demande. |
| Vérifications réseau de base | Tester le câble Ethernet, le port PoE/switch et le VLAN (contrôle d’accès, QoS). Confirmer que le DHCP fournit adresse IP, DNS, passerelle valides ; vérifier que les DNS résolvent les domaines Microsoft/Teams. S’assurer qu’aucun proxy/pare‑feu ne bloque les ports requis (HTTPS 443, médias UDP 3478‑3481, NTP 123, DNS 53). |
| Heure & certificats | Vérifier la synchronisation NTP. Une date/heure incorrecte invalide les certificats TLS et empêche la connexion. |
| Mises à jour et ré‑initialisation | Mettre le firmware à jour (branche 8.x ou dernière LTS). Effectuer un factory reset, puis appliquer un profil de configuration propre depuis Teams Admin Center ou via provisioning. |
| Comptes & licences | Confirmer que l’utilisateur possède une licence Teams Phone et que le compte n’est pas désactivé dans Azure AD/Entra. Tester avec un autre compte fonctionnel pour isoler l’origine. |
| Diagnostics intégrés | Depuis Settings › Status › Network Diagnostics, exécuter un ping vers microsoft.com. Consulter les journaux (menu Logging) et exporter le .tar pour le support. |
Comprendre l’erreur sur CCX 500
Le CCX 500 en édition Teams utilise principalement HTTPS/TLS et du WebRTC (médias via STUN/TURN en UDP 3478‑3481). Le message d’indisponibilité Internet s’affiche lorsque :
- Le téléphone n’obtient pas d’IP valide (DHCP) ou la passerelle ne route pas vers Internet.
- Le DNS ne résout pas correctement les domaines Microsoft (ex.
*.teams.microsoft.com,login.microsoftonline.com). - Un pare‑feu/proxy bloque les sorties requises (443/TCP et 3478‑3481/UDP en particulier).
- L’horloge du téléphone est inexacte, rendant la chaîne de certificats TLS non valide.
- Le firmware n’intègre pas les derniers certificats racine/chaînes intermédiaires attendus par les services (cas observé sur des versions anciennes).
Check‑list réseau détaillée
VLAN, LLDP/CDP et port PoE
- VLAN de voix : confirmer que le port est bien placé dans le VLAN voix attendu (statique, LLDP‑MED ou politique NAC).
- Port‑security / MAB / 802.1X : si le téléphone a changé de prise, une règle peut bloquer la nouvelle adresse MAC. Demander au réseau de clear l’entrée ou de mettre le port en mode ouvert pour le test.
- Budget PoE : un déficit d’alimentation peut provoquer un comportement instable. Le CCX 500 consomme typiquement < 13 W ; vérifier l’état inline power du port. À des fins d’essai, utiliser un adaptateur secteur 5 V/3 A.
Adressage et résolution
- Depuis le CCX 500, vérifier l’IP, la passerelle et les DNS dans Settings › Status › Network.
- Tester un ping vers la passerelle puis vers
microsoft.com. L’échec local (passerelle) pointe vers le LAN/VLAN ; l’échec externe avec succès local indique un filtrage egress/DNS. - DHCP : s’assurer que le bail inclut des DNS d’entreprise ou publics qui résolvent bien les domaines Microsoft. Éviter des DNS filtrants qui interceptent
*.microsoft.com.
Ouvertures pare‑feu/proxy minimales
| Service | Protocole/Ports | Objet |
|---|---|---|
| Signalisation/Services Teams | TCP 443 (sortant) | Auth, API, signalisation et téléchargement de configuration |
| Médias (STUN/TURN) | UDP 3478‑3481 (sortant) | Audio/vidéo (WebRTC) |
| DNS | UDP/TCP 53 | Résolution des domaines Microsoft/Teams |
| NTP | UDP 123 | Synchronisation de l’heure (indispensable à TLS) |
| HTTP | TCP 80 | Téléchargement de mises à jour/redirections occasionnelles |
Éviter d’imposer un proxy d’authentification interactive aux périphériques CCX 500. Si un proxy est obligatoire, prévoir une règle d’exemption ou une authentification machine transparente.
Heure, NTP et certificats TLS
Un décalage d’horloge de quelques minutes suffit à invalider les certificats côté appareil. Procédure :
- Dans Settings › General › Time, vérifier la date/heure et le fuseau. Corriger manuellement si besoin, puis activer la synchronisation NTP.
- Autoriser NTP UDP 123 vers un serveur approuvé (ex.
time.windows.comou NTP interne). - Si après correction, la connexion fonctionne : pérenniser via le DHCP (Option NTP) ou politique de provisioning.
Certificats racines/intermédiaires : des firmwares anciens ne contiennent pas toujours les derniers certificats requis (ex. chaînes émettrices DigiCert). La mise à jour du firmware est la voie la plus simple. À défaut, importer le certificat racine manquant via l’interface d’administration, puis redémarrer le téléphone.
Mises à jour, profils et ré‑initialisation
Mise à jour du firmware
- Depuis Teams Admin Center : Teams devices › Phones, sélectionner le CCX 500, appliquer la dernière version recommandée (branche 8.x/LTS) et redémarrer pendant une fenêtre de maintenance.
- Via provisioning : pointer le téléphone vers votre serveur de provisioning (ou service de gestion de périphériques) pour télécharger le package signé.
Bonnes pratiques : planifier l’upgrade sur un réseau non filtré, interdire la mise en veille pendant l’opération, et vérifier l’espace disponible avant d’initier le téléchargement.
Ré‑initialisation usine (factory reset)
À utiliser si les symptômes persistent après mise à jour et contrôles réseau. Deux approches :
- Depuis l’interface locale : Settings › Device Administration › Reset to Factory (mot de passe administrateur requis), puis reprovisionnement via Teams Admin Center ou votre serveur.
- Depuis l’interface web de l’appareil : accéder à l’IP du téléphone depuis le LAN d’administration, se connecter en compte admin, lancer le Factory Reset.
Après le reset, laissez l’appareil terminer toutes ses phases (obtention d’IP, synchronisation NTP, téléchargement de certificats/paquets, et enregistrement Teams). Évitez d’interrompre l’alimentation.
Comptes, licences et politiques Teams
Un CCX non licencié ou lié à un compte désactivé ne pourra ni s’enregistrer ni passer d’appels. Vérifications essentielles :
- Licence : l’utilisateur ou le compte de salle doit disposer d’une licence Teams Phone ou équivalent.
- État du compte : compte activé (AccountEnabled = True), non bloqué, authentification fonctionnelle (MFA, conditions d’accès).
- Politiques Teams : vérifier que les politiques d’appareils/phones ne bloquent pas l’inscription ou les fonctionnalités d’appels.
Exemples de commandes d’audit (PowerShell)
# Modules modernes (Microsoft Graph)
# Se connecter avec des droits d'annuaire adaptés
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All","Organization.Read.All"
# Vérifier l'état du compte
Get-MgUser -UserId [utilisateur@domaine.tld](mailto:utilisateur@domaine.tld) | Select DisplayName,AccountEnabled,UserPrincipalName
# Lister les licences (SKU)
Get-MgUserLicenseDetail -UserId [utilisateur@domaine.tld](mailto:utilisateur@domaine.tld) | Select -ExpandProperty SkuPartNumber Si la licence Teams Phone (ou bundle équivalent) est absente, l’affecter et patienter la propagation. Tester ensuite la connexion sur le CCX.
Diagnostics intégrés du CCX 500
- Network Diagnostics : Settings › Status › Network Diagnostics → Ping passerelle, DNS,
microsoft.com. - Logging : activer le niveau adapté (info/debug), reproduire l’incident, puis exporter le
.tar. Transmettre au support en mentionnant l’heure exacte et le fuseau. - Packet capture (si disponible) : capture brève (30‑60 s) sur la tentative de connexion. Vérifier absence de 443/TCP sortant, de 3478‑3481/UDP, ou erreurs TLS.
Information complémentaire utile
- Alimentation séparée : si le switch alimente plusieurs CCX 500, un budget PoE insuffisant peut couper l’accès d’un seul poste ; tester avec un adaptateur secteur 5 V/3 A.
- Certificat racine manquant : certains firmwares anciens n’embarquent pas les derniers certificats DigiCert requis par Teams. La mise à jour ou l’import du certificat racine corrige souvent la connexion.
- Clonage MAC / Port Security : si le téléphone a été déplacé, une règle de sécurité du switch peut bloquer la nouvelle adresse MAC. Demandez au réseau de clear l’entrée ou de désactiver temporairement la sécurité du port.
Arbre de décision — identifier vite la cause
| Symptôme | Cause probable | Action corrective |
|---|---|---|
| Pas d’IP / IP 169.254.x.x | DHCP/VLAN indisponible | Vérifier VLAN, DHCP et câblage ; tester autre port. |
| IP OK, ping passerelle OK, ping externe KO | Filtrage egress/Proxy/DNS | Ouvrir 443/TCP, 3478‑3481/UDP ; corriger DNS/proxy. |
| Connexion intermittente, reboot aléatoire | PoE limite/instable | Libérer du budget PoE ; tester alimentation externe. |
| Erreur persistante après réseau OK | Heure erronée / certificats TLS | Activer NTP 123/UDP, corriger l’horloge, importer chaînes. |
| Un seul utilisateur affecté | Licence manquante ou compte bloqué | Affecter licence Teams Phone ; réactiver le compte. |
| Après mise à jour, toujours KO | Profil corrompu | Factory reset, nouveau provisioning propre. |
Scénarios fréquents et correctifs ciblés
Déplacement de poste
Après déménagement, un téléphone peut hériter d’un VLAN/port‑security différents. Solution : effacer l’entrée MAC sur le switch, désactiver provisoirement la sécurité du port, confirmer LLDP‑MED, et revalider le DHCP.
Firmware 7.1.3.0991 obsolète
Cette version est antérieure à plusieurs améliorations de connectivité Teams. Recommandation : planifier un passage vers la dernière release 8.x ou LTS validée par votre organisation, puis redémarrer. Vérifier ensuite l’horloge et la chaîne de certificats.
Proxy d’entreprise imposé
Les CCX 500 ne gèrent pas toujours l’authentification interactive des proxies. Mettre en place une exception d’authentification pour l’IP/MAC du téléphone, ou un accès direct vers les FQDN Microsoft nécessaires.
DNS filtrant / inspection TLS
Des solutions de filtrage DNS ou d’inspection TLS mal configurées peuvent empêcher la résolution ou altérer la négociation. Bypass pour tests, puis créer des règles spécifiques respectant la validation de certificats.
Procédure structurée pas‑à‑pas
- Photographier l’écran d’erreur (horodaté) et noter l’IP du téléphone si disponible.
- Basculer le port sur un switch/prise connus sains, avec un autre câble Cat5e/6.
- Contrôler l’adressage sur le CCX : IP/passerelle/DNS. Tester ping passerelle puis
microsoft.com. - Vérifier l’heure : activer NTP, régler manuellement si écart > 5 min, autoriser UDP 123.
- Tester un autre compte Teams Phone sur ce même appareil. Si OK : souci de licence/compte. Si KO : matériel/firmware/réseau.
- Mettre à jour le firmware depuis Teams Admin Center ou via provisioning, puis redémarrer.
- Factory reset et reprovisionnement propre si le problème persiste.
- Exporter les logs et ouvrir un ticket via l’administrateur global Microsoft 365.
Vérifications côté infrastructure réseau
- Switch : show power inline (budget PoE), show lldp neighbors (annonce LLDP‑MED), show port‑security / états err‑disable.
- DHCP : bail livré, durée, options (DNS, NTP), absence de conflits d’IP.
- Pare‑feu/UTM : règles egress pour 443/TCP et 3478‑3481/UDP, pas d’inspection TLS cassante sur les flux de signalisation, exceptions proxy si nécessaire.
- DNS : résolution correcte des FQDN Microsoft (Teams, login, Graph). Latence raisonnable (< 50 ms) sur les résolutions internes.
Bonnes pratiques de provisioning
- Gérer les CCX via un service central (Teams Admin Center, plateforme de gestion d’appareils) pour pousser firmwares, certificats et paramètres réseau de manière cohérente.
- Éviter les profils contradictoires (ex. proxy forcé + exception locale).
- Documenter un runbook d’escalade : contact réseau, sécurité, M365, puis Microsoft.
Contrôles post‑remédiation
- Passer un appel test vers un numéro externe et vérifier l’audio bilatéral.
- Ouvrir l’onglet Qualité des appels (Call analytics) pour confirmer l’établissement des médias et l’absence de pertes anormales.
- Redémarrer le téléphone une fois et confirmer la persistance de la correction (pas de régression au boot).
FAQ — questions courantes
Pourquoi un seul appareil est concerné ?
Parce qu’un facteur local (port/switch, port‑security, câble, firmware ou profil) est en cause. Les services cloud n’affectent pas un seul terminal de manière isolée dans la plupart des cas.
Peut‑on ignorer l’UDP 3478‑3481 ?
Non. Sans ces ports, l’établissement des médias (voix) échoue souvent même si la connexion Teams semble faite.
Faut‑il toujours réinitialiser ?
Non. Commencer par réseau/heure/licences. N’utiliser le factory reset qu’après mise à jour et quand la piste profil corrompu est probable.
Modèle d’escalade vers Microsoft
- Description courte : « CCX 500 — message No internet. Emergency calls aren’t supported — un seul appareil affecté »
- Actions déjà tentées : câble/port/VLAN, NTP, DNS, ouverture 443/TCP & 3478‑3481/UDP, mise à jour firmware, factory reset, test avec autre compte.
- Pièces jointes : logs
.tar, captures d’écran, heure exacte des tests, adresses IP/FQDN testés.
Conclusion
En suivant cette approche structurée (réseau de base, heure/certificats, mise à jour/ré‑initialisation, contrôle des licences et diagnostics intégrés), vous obtenez rapidement un diagnostic fiable et, dans l’immense majorité des cas, le rétablissement des appels sur le CCX 500 affecté. Si l’incident persiste après ces étapes, l’ouverture de ticket via l’administrateur global Microsoft 365 permettra au support Microsoft d’analyser les journaux et d’identifier précisément le point de blocage.