Paramétrer modem Technicolor pour ma ligne VOIP de chez OVH


Bonjour. J'ai des soucis avec ma VOIP de chez OVH (téléphone Gigaset DX800A branché en ethernet sur le Technicolor).
Voici la config que OVH me recommande de faire. Mais je ne trouve pas comment, et de plus je ne suis pas un technicien. Je comprends mieux quand on me parle en français...;-) :

Voici la configuration recommandée pour votre BOX / Routeur :

Autoriser les connexions vers sip.ovh.fr -> 91.121.129.0/24
La session UDP (Time Session ou Timeout Session) doit être supérieure ou égale à 180 secondes
Le SIP ALG doit être désactivé
Le trafic doit être autorisé pour le protocole SIP sur les ports 5060 et 5962 en UDP
La plage de 30000 à 40000 en UDP également (ports RTP, plages de son)
Baisser le pare feu de la Box de "moyen" à "faible"

Quelqu'un peut-il m'aider ou dois-je m'adresser plus haut chez Technicolor ?

En vous remerciant.

36 commentaires

Niveau d'utilisateur 7
Badge +10
Bonjour,

Je possède le technicolor et un abonnement chez OVH. La seule différence est que j'utilise un téléphone classique branché sur un cisco SPA112. J'ai du configurer mon boitier cisco mais je n'ai rien touché au technicolor.

Je ne suis donc pas sur qu'il faille modifier quelque chose au niveau du modem.

Mais je laisse le soin aux autres utilisateurs OVH avec un téléphone VOIP de donner plus d'infos 🙂
Mon routeur est un Apple Airport Extreme, mais le téléphone est branché directement sur le Technicolor. Devrais-je mettre un Cisco SPA112 entre le Technicolor et mon téléphone en plus ?
Le SPA 112 ne va pas fonctionner. Il n'y a qu'un seul port ethernet. Je dois entrer ET sortir en ethernet.
Même souci que "arpee".
Moi, j'ai des téléphones gigaset que j'utilisais pour ma ligne proximus avant et maintenant sur un spa112 pour ma ligne ovh.
Tout cela fonctionnait parfaitement jusqu'il y a quelques jours.
A voir je ne suis pas seul à avoir du souci avec la combinaison voo/ovh...
A Mustafa: quels réglages pour le spa112?
Personnellement le problème est apparu chez moi depuis le remplacement d'un modem/routeur NETGEAR avec lequel tout fonctionnait parfaitement par le nouveau TECHNICOLOR TC7210, mais affecte également des clients tous azimuts selon l'équipement qu'ils utilisent ce qui m'a permis de solutionner mon problème grâce au partage d'expériences malheureuses...

Fair-Play, je fais donc passer la balle !

Le problème :

• j'appelle vers l'extérieur sans aucune difficulté.
• si la ligne voip reste inactive pendant plus de ??? minutes, elle devient injoignable depuis l'extérieur.
• je compose un numéro bidon vers l'extérieur depuis la ligne voip.
• Bingo ! mon numéro redevient joignable depuis l'extérieur

La cause :

• Le routeur ne maintient apparemment pas le NAT ouvert pour le SPA112 si pas de trafic pendant ??? secondes !

La solution :

• activer UpnP
• activer le "nat keep alive" et "nat mapping" dans les règlages "voice -> line1" du SPA112 via l’interface WEB de ce dernier disponible via un browser WEB à l'adresse IP de ce dernier (login: admin / passw: admin). Ce faisant, le boîtier ne perd plus son NAT et la ligne SIP est toujours joignable depuis l'extérieur ! :D

Problème réglé...
Les ata n'utilisent pas l'UPNP il me semble donc la résolution est due au keep-alive qui fait maintenir la connexion udp au travers du nat du routeur.

L'implémentation de "sip alg" est boguée ou pas selon le firmware/routeur, il serait bien d'avoir un tableau sur un wiki dédié à la téléphonie SIP avec les retours d'utilisateurs expérimentés des implémentations fonctionnelles et mauvaises car tout le monde n'a pas l'expérience pour déboguer les problèmes de téléphonie SIP.
J'ai rien compris...;-)
Et bien en SIP dans les paquets que l'ata ( adaptateur de téléphonie analogique, boitiers comme le spa112 et ht802 pour utiliser un téléphone classique en voip) ou le téléphone sip envoie au fournisseur sip( ovh, 3starsnet, etc) se trouve l'ip de contact qui est celle de l'ata ou du téléphone sip, soit une ip privée donc non joignable par l'internet. Résultat = impossible à joindre depuis l'extérieur vu que ça va probablement mener à une adresse interne chez le correspondant ou le fournisseur.


Le "sip alg" permet de trafiquer(en temps normal un routeur ne devrait pas faire ça, le problème, l’ennemi c'est le nat :D) les paquets SIP pour remplacer votre ip privée par l'ip publique wan afin de permettre les appels entrants d'aboutir. Donc normalement le sip alg devrait rester activé mais comme il arrive assez souvent que son implémentation sur le routeur est boguée, on recommande souvent de le désactiver.

3 liens pour creuser le sujet :

http://www.voip-info.org/wiki/view/Routers+SIP+ALG
https://www.juniper.net/documentation/en_US/junos12.1x46/topics/concept/alg-security-sip-and-nat-understanding.html
https://en.wikipedia.org/wiki/Application-level_gateway

Je lirai celui de juniper tout à l'heure et relirai wikipédia/voip-info car je maitrise ce sujet à moitié mais j'ai déjà vu des exemples de ce que fait le "sip alg".


Concernant le keep-alive il faut savoir que le nat fonctionne grâce à des tables en mémoire qui retiennent les sorties de paquet en attente d'une réception de réponse, après un certain temps défini dans la configuration réseau du routeur, ces tables sont "nettoyées" pour économiser de la mémoire et libérer la place pour d'autres connexions.

La fonction keep-alive des ata permet d'envoyer un paquet udp toutes les xx secondes pour empêcher le routeur d'effacer le maintient de la connexion. Comme elle est maintenue par ses paquets qui forcent le routeur à retenir en mémoire la connexion udp vos appels entrant continuent de fonctionner. Si le routeur effaçait l'entrée parce qu'il y a plus de trafic réseau sur cette connexion établie, comme par défaut il n'accepte pas les paquets extérieurs qui n'ont pas été sollicités, votre appel passe à la trappe.

Il existe un document de l'IETF (internet engineering task force) qui spécifie que tout routeur devrait maintenir au moins pendant 2 minutes en mémoire les connexions udp qui ont été faites mais en pratique ça n'est pas le cas car le matériel des routeurs ne contient pour une partie d'entre eux pas assez de mémoire vive pour le faire.
https://tools.ietf.org/html/rfc4787
"REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5a applies."


Si quelqu'un maitrise vraiment ce sujet qu'il me corrige car je ne suis pas ingénieur, ni administrateur réseau compétent.
Bonjour,

Voici ce que me demande OVH. Comment peut-on régler cela dans le modem Technicolor de VOO ?

- Le SIP ALG doit être désactivé sur la box opérateur
- Tester sans un pare-feu
- La session UDP doit être supérieure à 1800 secondes
- Le trafic les réseaux 91.121.128.0/24 et 91.121.129.0/24 doit être autorisé sur les ports 5060 - 5962 et 5080 en UDP et la plage de 30000 à 40000 en UDP également.
Re Bonjour,

Voici ce que me demande OVH. Comment peut-on régler cela dans le modem Technicolor de VOO ?

- Le SIP ALG doit être désactivé sur la box opérateur
- Tester sans un pare-feu
- La session UDP doit être supérieure à 1800 secondes
- Le trafic les réseaux 91.121.128.0/24 et 91.121.129.0/24 doit être autorisé sur les ports 5060 - 5962 et 5080 en UDP et la plage de 30000 à 40000 en UDP également.
Notre Expert Thibault me fait savoir qu'il pourra essayer dans quelques jours de chez lui... Vous pouvez éventuellement prendre contact avec lui par message privé, mais en temps normal, VOO ne procure pas de support concernant OVH et ce genre de configuration.

J'espère donc plutôt qu'un autre utilisateur saura vous guider 🙂
Notre Expert Thibault me fait savoir qu'il pourra essayer dans quelques jours de chez lui... Vous pouvez éventuellement prendre contact avec lui par message privé, mais en temps normal, VOO ne procure pas de support concernant OVH et ce genre de configuration.

J'espère donc plutôt qu'un autre utilisateur saura vous guider :)


Seulement s'il poste un commentaire sur ce forum...
Niveau d'utilisateur 7
Badge +8
Bonjour arpee,

Je possède le technicolor, un SPA 112 et un téléphone tout à fait classique et hormis le même souci que hhairson, tout est OK de mon côté (et je n’ai rien touché au Technicolor).

Je récupère mon fichier de configuration de mon SPA ce soir, il faudrait voir si vous avez les mêmes informations à ce sujet.
Je vous envoie ça en privé ce soir ou demain.
Badge +1

Je possède le technicolor, un SPA 112 et un téléphone tout à fait classique et hormis le même souci que hhairson, tout est OK de mon côté (et je n’ai rien touché au Technicolor).


C'est à dire que vous avez aussi le : "nat keep alive" et "nat mapping" dans les règlages "voice -> line1" du SPA112 via l’interface WEB qui n'est pas activé????

Perso, même avec les mots de pass admin je n'ai pas accès à l'interface... donc comment savoir si ces paramètres sont Activé????

Par contre pour contrer j'ai attribué un IP fixe via l'adresse MAC du SPA112 et j'ai mis cette adresse IP dans la DMZ..

Jusque maintenant ça fonctionne...
Niveau d'utilisateur 7
Badge +8
Je ne suis pas arrivé à me connecter dessus, mais voici la configuration que j’ai installée il y a au moins deux ans. Et hormis un passage durant 1 ou 2 mois avec le même souci que hhairson, je n’ai rien changé et tout est redevenu normal.

Je ne sais pas si ça va vous aider, mais chez moi, sans rien toucher au modem technicolor, ça marche sans souci.

Paramétrage de ligne sur le SPA112 :
- une fois sur l'interface du téléphone, cliquer sur
"voice" puis "line 1",
- passer les champs avec les valeurs suivantes :
=> line enable : yes
=> proxy : sip.ovh.be
=> use outbound proxy : yes
=> outbound proxy : sip.ovh.be:5962
=> register : 1800

=> display name :
=> user id :
=> password : xxxx (celui de votre ligne)
=> use auth id : yes
=> auth id :
=> Dial Plan : (112S0|100S0|101S0|047[0123456789]xxxxxx|048[23456789]xxxxxx|049[0123456789]xxxxxx|0[123456789]xxxxxxx|00[123459]xxxxxxxxx.)

=> Preferred Codec : G729a
=> Second Preferred Codec: G711u

Allez ensuite dans l'onglet Regional et modifier les paramètre suivant comme indiqué :
- Ring1 Cadence : 2.25(.25/1.6);60(2/3.5)
- Ring Waveform : Sinusoïd
- Ring Frequency : 50
- Ring Voltage : 70
- FXS Port Impedance : 270+750||150nF
- FXS Port Input Gain : 0
- FXS Port Output Gain : 0


Dial Tones : 440@-10;10(*/0/1)
Prompt Tone : 440@-10;10(*/0/1)
Busy Tone : 440@-10;10(.5/.5/1)
Ring Back Tone : 440@-10;*(2/4/1)
Ring 1 Cadence : 2.25(.25/1.6);60(2/3.5)

Ring Waveform : sinusoid
Ring Voltage : 60
Ring Frequency : 50

Time Zone : GMT+1:00
FXS Port input gain : 0
FXS Port Output gain : 0
FXS Port Impedance : 270+750||150nF

Caller ID Method : Bellcore
Caller ID FSK : Bell202
[/h1]
Badge
Personnellement le problème est apparu chez moi depuis le remplacement d'un modem/routeur NETGEAR avec lequel tout fonctionnait parfaitement par le nouveau TECHNICOLOR TC7210, mais affecte également des clients tous azimuts selon l'équipement qu'ils utilisent ce qui m'a permis de solutionner mon problème grâce au partage d'expériences malheureuses...

Fair-Play, je fais donc passer la balle !

Le problème :

• j'appelle vers l'extérieur sans aucune difficulté.
• si la ligne voip reste inactive pendant plus de ??? minutes, elle devient injoignable depuis l'extérieur.
• je compose un numéro bidon vers l'extérieur depuis la ligne voip.
• Bingo ! mon numéro redevient joignable depuis l'extérieur

La cause :

• Le routeur ne maintient apparemment pas le NAT ouvert pour le SPA112 si pas de trafic pendant ??? secondes !

La solution :

• activer UpnP
• activer le "nat keep alive" et "nat mapping" dans les règlages "voice -> line1" du SPA112 via l’interface WEB de ce dernier disponible via un browser WEB à l'adresse IP de ce dernier (login: admin / passw: admin). Ce faisant, le boîtier ne perd plus son NAT et la ligne SIP est toujours joignable depuis l'extérieur ! :D

Problème réglé...


J'ai exactement le même soucis avec un téléphone C610IP ... Je ne trouve pas ce genre de config à modifier dans l'interface web du téléphone.

Quelqu'un aurait une piste?
Je peux confirmer les dires de hhairson quant aux paramétrages du NAT.

Voici ma configuration : téléphone analogique (peu importe la marque) branché en RJ11 sur un boîtier Cisco SPA112, ce dernier branché en RJ45 sur le modem VOO. Compte SIP de chez OVH.

Problème : j'avais un vieux modem Sierra de chez VOO, ma configuration téléphonique marchait sans aucun problème. VOO m'a changé ce Sierra par un TechniColor. Depuis lors plus possible de recevoir des appels entrants. En sortie pas de souci par contre.

Résolution du problème : je n'ai rien changé au niveau du modem Technicolor de VOO, par contre j'ai changé les paramètres NAT sur le boîtier Cisco SPA112. A la seule différence de hhairson, je n'ai donc rien changé sur le modem, Sur la SPA112 => activer le "nat keep alive" et "nat mapping" dans les règlages "voice -> line1".

Merci hhairson !

MatMax
Bonjour,

Je ne parviens pas à utiliser mon boitier VoIP SPA112 avec la box Technicolor et je n'ai pas trouvé de solution dans ce fil. Chez l'autre opérateur (que je viens de quitter) tout fonctionnait pourtant bien avec ce boîtier et sans aucun réglage particulier sur la box (pas nécessaire de rediriger des ports…).

Pour le moment, il me semble que le problème est que le serveur DHCP du Technicolor n'attribue pas une adresse IP au boîtier (il n'apparaît pas dans la liste des clients DHCP). J'ai essayé de lui attribuer une adresse IP fixe, mais ça ne change rien, comme si le router ne "voyait" pas le boîtier. Donc impossible d'y accéder par l'interface web.

J'ai aussi essayé de rediriger les ports indiqués par OVH (5060, 5962, 30000-40000) mais je ne sais pas si je l'ai fait correctement :



Chez Voo, il paraît que ça ne relève pas du service client. Quelqu'un aurait-il une idée pour m'aider ?
Mille excuses pour le dérangement à la communauté, mais le problème est en partie résolu :
en rebranchant le boîtier sur mon ancienne box encore connectée (ouf!) j'ai pu accéder à son interface web et modifier le mode de connexion (DHCP au lieu d'IP fixe).

(En fait, le SPA112 était configuré avec une IP fixe dans le pool IP de l'ancienne box (192.168.1.x), d'où l'impossibilité au serveur DHCP du Technicolor de lui attribuer une IP car son pool IP est différent (192.168.0.x). Personne n'a été capable de me dire ça, ni chez OVH, ni chez Voo… )

Maintenant je peux passer des appels, mais en revanche pas en recevoir. Probablement des réglages à changer encore dans le SPA112 ou la Technicolor, mais lesquels ?… Je vais contacter OVH.

En attendant, si quelqu'un sait…
Suite et fin :
Il ne faut pas mettre de règles NAT dans le router.
La Technicolor version Voo est apte à opérer la téléphonie VoIP SIP d'OVH sans réglages particuliers (du moins si les fonctionnalités SIP sont bien activées par défaut, car ce réglage n'est plus accessible dans l'interface actuelle).

Important pour les abonnés Pr… qui passent chez Voo avec un boîtier SPA112 d'OVH :
Avant de résilier l'ancien abonnement et en se connectant avec l'ancienne box, il faut modifier le mode de connexion du boîtier SPA112 via son interface web (pour connaître son IP il suffit de faire ****112# sur le combiné et une voix la communique). Ensuite soit passer de "IP fixe" à "DHCP", soit attribuer au boîtier une IP fixe dans le pool de la Technicolor qui est différent, comme expliqué plus haut. Mettre les DNS de Voo dans les champs appropriés.

En espérant ne pas avoir trop encombré ce forum et que ces mésaventures pourront apporter des infos utiles aux autres utilisateurs de téléphonie SIP.
(En fait, le SPA112 était configuré avec une IP fixe dans le pool IP de l'ancienne box (192.168.1.x), d'où l'impossibilité au serveur DHCP du Technicolor de lui attribuer une IP car son pool IP est différent (192.168.0.x). Personne n'a été capable de me dire ça, ni chez OVH, ni chez Voo… )
Il est tout à fait possible de configurer le Tecnicolor en 192.168.1.x et garder vos anciennes configuration dès lors.
192.168.0.x est le standard chez VOO
Oui, en effet, mais j'avais vu sur ce fil que ça avait posé problème à un utilisateur (bien qu'en théorie ça ne devrait pas).
Un tuto à ce propos dans les pages assistance de Voo serait bien utile, comme l'avait suggéré Roylion dans ce fil. En tant que client venant de PXS, ça m'aurait épargné du temps et de l'énervement (et du ressenti négatif à l'égard de Voo).
J'étais client Belgacom il y a ... houuuu pas mal d'année. 😙

En passant chez VOO j'ai directement mis le modem VOO en bridge pour garder mon routeur et sa config.
Maintenant avec le TC ... je l'ai configuré comme mon ancien routeur qui est devenu un AP ... trop d'appareils en IP fixe dans 192.168.1.x

En effet, ce serait pas mal un p'ti tuto pour les nouveaux venus avec une autre config que 192.168.0.x + intégrer le modem VOO en bridge pour ceux qui ont un routeur déjà programmé.
Voilà, ça serait bien. Faut dire aussi que n'ai pas été très impressioné par le service technique de Voo… La personne à qui j'ai expliqué le problème n'a pas évoqué à ce problème d'IP de passerelle différent entre Voo et PXS alors que je lui ai dit que je venais de PXS.
Bon, espérons quand même une meilleure satisfaction globale que chez PXS chez qui ce n'est pas la joie quand on a un problème.
Niveau d'utilisateur 7
Badge +12
Bon, espérons quand même une meilleure satisfaction globale que chez PXS chez qui ce n'est pas la joie quand on a un problème.

Ancien client Proximus également, je n'ai jamais eu à me plaindre de mon changement, et pour fréquenter le forum depuis le début de mon aventure voo, je peux dire que les officiels voo font plus que leur boulot pour satisfaire le client.

Cela n'empêche malheureusement pas les cas difficiles ou techniquement compliqués voir insolubles (ils sont très minoritaires mais il serait mal venu de le nier même si la plupart trouve quand même une issue satisfaisante).

Commenter