Accès Internet 5G Rogers vs téléphone résidentiel Fonto

[gilray]

Bonjour à tous,

Je suis abonné au service téléphonique résidentiel Fongo.

Je viens de m'abonner au Service Internet 5G Résidentiel de Rogers qui fonctionne à merveille SAUF qu'il semble y avoir des interférences avec ma ligne VoIP de Fongo.

Speedtest me donne : 252.96 et 5.45 Mbps sans VPN et impossible d'accéder à Speedtest si mon VPN est actif. Quasi impossible également d'accéder à quelque page web que ce soit si le VPN est actif. Énormément d'interférences également sur ma ligne VoIP depuis que j'ai le 5G.

J'étais auparavant avec eBox (accès via Internet câble) et même si le VPN était actif, la qualité des appels VoIP était OK.

Est-ce que le réseau 5G de Rogers pourrait avoir une certaine incompatibilité avec le VPN de PIA et/ou le VoIP de Fongo ?

Merci pour vos sages commentaires

[Liptonbrisk]

Sorry, I am not fluent in French.
Désolé, je ne parle pas couramment le français. J'utilise Google Traduction.


Le service Téléphone résidentiel Fongo utilise le protocole SIP. C'est un service SIP.

Bien que la 5G offre des vitesses élevées, les connexions sans fil (y compris l'Accès sans fil fixe 5G de Rogers) peuvent avoir une latence (délai) et une gigue (variation du délai) plus élevées ou plus variables par rapport aux connexions filaires stables, telles que le câble (eBox) et surtout la Fibre jusqu'au domicile (FTTH). Les appels SIP sont très sensibles à la fois à la latence et à la gigue ; les incohérences peuvent causer des coupures, une voix robotique et des échos – les « interférences » que vous entendez.

Les connexions sans fil (y compris l'Accès sans fil 5G de Rogers) peuvent également être plus sujettes à la perte de paquets et aux pics de ping, qui dégradent considérablement la qualité des appels et peuvent entraîner des coupures d'appel, que les connexions filaires.

1) Les services SIP dépendent fortement de pings faibles et constants. Encore une fois, les services 5G peuvent être moins fiables à cet égard que les services filaires.

Ping fait communément référence à la latence réseau, et dans ce contexte, il désigne spécifiquement le temps aller-retour nécessaire à un petit morceau de données (un paquet) pour voyager depuis votre ATA Grandstream jusqu'au serveur proxy de Fongo, puis revenir à votre appareil. Plus le ping est faible, moins il y aura de délai dans la communication.

Un ping faible (inférieur à 50 ms) indique une connexion plus rapide et plus réactive avec moins de délai, ce qui est crucial pour les applications en temps réel comme les jeux en ligne, les appels VoIP (SIP, dans ce cas) ou la vidéoconférence. Un ping élevé (supérieur à 200 ms) indique un délai plus notable, ce qui peut entraîner du lag dans les jeux, une mauvaise qualité des appels VoIP ou une réactivité lente dans les applications interactives.

Testez les pings et la gigue (vous voulez peu ou pas de variation entre les pings) vers les serveurs SIP Fongo Home Phone spécifiques que vous prévoyez d'utiliser.

Utilisez WinMTR : https://sourceforge.net/projects/winmtr/. Effectuez environ 200 pings vers chaque serveur.

Mes pings moyens sont les suivants :

sip2.fongo.com 27 ms (sip2.fongo.com est utilisé par les utilisateurs de Fongo Home Phone).

Si vous utilisez un Mac, cette page pourrait vous aider : https://www.reddit.com/r/TagPro/comment ... \_on\_mac/.

Lorsque vous utilisez WinMTR, regardez la dernière ligne. Vérifiez la moyenne (« Average ») et le maximum (« Max ») des pings. WinMTR ne fournit pas de valeur de gigue, mais vous pouvez l’estimer en soustrayant le ping moyen (« Average ») du ping maximum (« Max »). La gigue correspond à la différence entre chaque ping successif. Plus cette différence est grande, plus le problème est important.

Le ping représente le retard ou la latence. Plus votre ping et votre gigue sont faibles, mieux c'est. Vous ne voulez pas de pings élevés ni de gigue excessive (pas de grandes variations entre chaque ping). Si vous obtenez de mauvais résultats (des pings supérieurs à 200 ms) vers un serveur, vous avez un problème.

Exemple de mauvaise gigue : 40, 45, 50, 35, **500**, 40, 30, 45, **700**. C'est une mauvaise gigue.
Vous voulez des pings relativement constants, sans grande variation.

Une des causes possibles de la gigue est l'utilisation de la bande passante par d’autres appareils sur votre réseau local (LAN). C’est pourquoi configurer correctement la QoS (Qualité de Service) pour votre ATA dans votre routeur est toujours une bonne idée. Consultez le point C ici : viewtopic.php?f=8\&t=20199\#p78976.

Une mauvaise gigue peut provoquer de l’audio haché ou des coupures pendant les appels téléphoniques.
Une gigue sévère (ou des pics de ping élevés) peut provoquer des pertes d’appels (et les appels entrants n’arriveront pas pendant un pic de ping). Le ping affecte également la latence des appels.

Je recommande de tester les pings/gigue entre 20 h et 23 h pour voir si la congestion locale est un facteur (c'est souvent la faute de votre FAI).
Le dimanche est le meilleur jour pour tester, car c'est à ce moment-là que la plupart des gens sont chez eux.
Pendant les heures de pointe (20 h - 23 h), les nœuds internet des réseaux câblés peuvent être surchargés, ce qui cause des problèmes de congestion (cela peut aussi arriver avec DSL).

2) Il est tout à fait possible que le service internet 5G de Rogers utilise le CG-NAT (Carrier-Grade Network Address Translation / Traduction d'adresse réseau de niveau opérateur). Cela signifie que vous n'obtenez pas une adresse IP publique unique ; au lieu de cela, vous en partagez une avec d'autres utilisateurs. Certaines implémentations CG-NAT peuvent interférer avec le protocole SIP utilisé par la VoIP, rendant les connexions moins stables.

Normalement, votre ATA Grandstream Fongo, derrière votre routeur domestique, utilise l'adresse IP WAN publique et le port attribués par le NAT de votre routeur domestique. Il inclut cette adresse IP WAN publique dans ses messages SIP afin que les serveurs de Fongo sachent où envoyer les réponses et le média RTP (le flux vocal).

Avec le CG-NAT, il y a une autre couche de NAT effectuée par le FAI (Rogers). L'adresse IP que les serveurs de Fongo voient est l'adresse IP publique partagée du dispositif CG-NAT, et non l'adresse IP publique de votre routeur domestique (qui n'existe pas vraiment dans une configuration CG-NAT). Au lieu d'attribuer une adresse IP publique unique (72.136.xxx.xx) à chaque client, les FAI utiliseront une adresse IP privée (dans la plage 100.64.0.0/10, telle que 100.80.xx.xx) et mapperont plusieurs clients sur une adresse IP publique partagée en utilisant la Traduction d'Adresse Réseau (NAT). Lorsqu'un appareil client initie une connexion, le CG-NAT traduit son IP privée (100.80.xx.xx) en une adresse IP publique partagée (209.121.xx.xx) et attribue un numéro de port unique pour cette session. Ce double NAT rend plus difficile pour les mécanismes de traversée NAT standard de SIP d'établir de manière fiable le chemin de communication correct vers votre appareil spécifique.

Votre routeur domestique et le dispositif CG-NAT créent tous deux des mappages temporaires qui lient une adresse IP/port privé interne à une adresse IP/port public externe. Les dispositifs CG-NAT, gérant les mappages pour de nombreux utilisateurs partageant une seule adresse IP publique, utilisent souvent des délais d'expiration (périodes d'inactivité) très agressifs (courts), en particulier pour UDP (que SIP et RTP utilisent souvent). Si l'ATA Grandstream utilisé par Fongo n'envoie pas de paquets keep-alive (de maintien de connexion) assez fréquemment (je crois cependant qu'il le fait), le dispositif CG-NAT pourrait fermer le mappage, le considérant comme inactif. Lorsque le serveur de Fongo tente de signaler un appel entrant ou d'envoyer des paquets vocaux RTP vers le mappage désormais fermé, ils sont perdus. Cela conduit à des échecs d'enregistrement, à l'incapacité de recevoir des appels ou à des coupures d'appels en cours de conversation.

Une seule adresse IP publique dispose d'un nombre limité de ports disponibles (jusqu'à 65 535 par protocole UDP). Dans un environnement CG-NAT, ces ports sont partagés entre de nombreux utilisateurs. Cette rareté peut entraîner des conflits de ports ou rendre difficile pour le CG-NAT d'attribuer les ports spécifiques que SIP/RTP pourraient préférer ou nécessiter, entravant potentiellement la configuration de la connexion. Bien que SIP puisse utiliser divers ports, une disponibilité restreinte peut être problématique.

Problèmes de SIP ALG au niveau du CG-NAT

Tout comme les routeurs domestiques, les dispositifs CG-NAT à grande échelle utilisés par les FAI peuvent également implémenter une passerelle de niveau applicatif SIP (ALG). Les SIP ALG tentent d'"intelligemment" inspecter et réécrire les paquets SIP pour les aider à traverser le NAT en corrigeant les adresses IP internes intégrées dans les messages. Cependant, les SIP ALG sont notoirement horribles et corrompent souvent les messages SIP de manière inattendue, entraînant des problèmes tels que l'audio unidirectionnel (les paquets RTP sont mal acheminés), l'incapacité à s'enregistrer ou des échecs de configuration d'appel. Un ALG problématique au niveau du CG-NAT affecte de nombreux utilisateurs et ne peut pas être désactivé par l'utilisateur final.

Je ne vais pas fournir de support pour les VPN ici, mais si le CG-NAT est utilisé par Rogers, je soupçonne fortement que c'est la source du problème pour votre service VPN, au moins.

Donc, voici le résumé :

A. La 5G est souvent pire qu'un service internet filaire fiable pour les services SIP.

B. Le CG-NAT devrait être évité, si possible. Je ne suis pas sûr à 100% que vous ayez affaire au CG-NAT, mais il est plausible que ce soit le cas.Contactez votre FAI.

C. Essayez de faire désactiver le SIP ALG dans l'appareil modem/routeur combiné que votre FAI vous fournit (SIP ALG est une fonctionnalité du routeur). Contactez votre FAI si nécessaire. Même si l'option de désactiver le SIP ALG n'est pas disponible pour vous, cela ne signifie pas nécessairement que le SIP ALG n'est pas activé dans l'appareil.

D. Soumettez une demande d'assistance (ticket) : https://support.fongo.com/hc/requests/new. Demandez à Fongo de changer le serveur proxy principal dans votre ATA pour sip2.fongo.com:6060 afin de voir si cela aide.