Timeout à l'enregistrement sur SIP.OVH.FR

Bonjour,

J'ai un serveur freepbx avec asterisk 1.6 qui tourne depuis pas loin de 2 ans sur sip.ovh.net sans soucis.

J'ai 2 connexions adsl, une orange (ip dynamique) et une OVH (ip fixe)

Depuis maintenant 1 mois, plus de connexion à sip.ovh.net, timeout à l'enregistrement.

Je n'arrivait d’ailleurs plus à pinger sip.ovh.net du tout, que ce soit depuis orange ou OVH

J'ouvre un ticket, on me suggère en 1er lieu de passer sur sip.ovh.fr, meilleur serveur, mieux sécurisé, plus d'options...

Je m’exécute, je constate que je ping bien sip.ovh.fr, que ce soit depuis orange ou OVH, donc rassuré, je modifie ma config... et aucun enregistrement...

Par défaut la voip est sur orange, je test sur OVH, et là bim, ça fonctionne, je repasse sur orange, timeout...

Je n'ai mis en place aucune protection particulière, j'ai simplement changé de serveur sip.

Le service technique ne semble pas prendre en compte mon problème et m'envoie un message bateau et inutile tous les 2 jours...

Citation:

---

[Nov 4 10:50:41] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #1)
[Nov 4 10:51:01] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #2)
[Nov 4 10:51:21] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #3)
[Nov 4 10:51:41] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #4)
[Nov 4 10:52:01] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #5)
[Nov 4 10:52:21] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #6)
[Nov 4 10:52:41] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #7)
[Nov 4 10:53:01] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #8)
[Nov 4 10:53:21] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #9)
[Nov 4 10:53:41] NOTICE[23919] chan_sip.c: -- Registration for '0033972XXXXXX@sip.ovh.fr' timed out, trying again (Attempt #10)

---

un extrait de trame SIP :

Citation:

---

---
[Nov 4 09:31:56] NOTICE[23919] chan_sip.c: -- Registration for 'MON_NUMERO@sip.ovh.fr' timed out, trying again (Attempt #15899)
[Nov 4 09:31:56] VERBOSE[23919] chan_sip.c: REGISTER 11 headers, 0 lines
[Nov 4 09:31:56] VERBOSE[23919] chan_sip.c: Reliably Transmitting (NAT) to 91.121.129.20:5060:
REGISTER sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP IP_PUBLIQUE_ORANGE:5060;branch=z9hG4bK4361b7ca;rpo rt
Max-Forwards: 70
From: <sip:MON_NUMERO@sip.ovh.fr>;tag=as0ee3f332
To: <sip:MON_NUMERO@sip.ovh.fr>
Call-ID: 28952f44389e1cac4f7693816a1812c4@127.0.0.1
CSeq: 16001 REGISTER
User-Agent: FPBX-2.9.0(1.6.2.6)
Expires: 120
Contact: <sip:s@IP_PUBLIQUE_ORANGE>
Content-Length: 0


---
[Nov 4 09:31:56] VERBOSE[23919] chan_sip.c: Really destroying SIP dialog '28952f44389e1cac4f7693816a1812c4@127.0.0.1' Method: REGISTER
[Nov 4 09:31:57] VERBOSE[23919] chan_sip.c: Retransmitting #1 (NAT) to 91.121.129.20:5060:
REGISTER sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP IP_PUBLIQUE_ORANGE:5060;branch=z9hG4bK4361b7ca;rpo rt
Max-Forwards: 70
From: <sip:MON_NUMERO@sip.ovh.fr>;tag=as0ee3f332
To: <sip:MON_NUMERO@sip.ovh.fr>
Call-ID: 28952f44389e1cac4f7693816a1812c4@127.0.0.1
CSeq: 16001 REGISTER
User-Agent: FPBX-2.9.0(1.6.2.6)
Expires: 120
Contact: <sip:s@IP_PUBLIQUE_ORANGE>
Content-Length: 0


---
[Nov 4 09:31:57] VERBOSE[23919] chan_sip.c: Reliably Transmitting (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP IP_PUBLIQUE_ORANGE:5060;branch=z9hG4bK19468cca;rpo rt
Max-Forwards: 70
From: "Unknown" <sip:Unknown@IP_PUBLIQUE_ORANGE>;tag=as1b07133c
To: <sip:sip.ovh.fr>
Contact: <sip:Unknown@IP_PUBLIQUE_ORANGE>
Call-ID: 3b5031c6491ece1038d301be735ff2be@IP_PUBLIQUE_ORANG E
CSeq: 102 OPTIONS
User-Agent: FPBX-2.9.0(1.6.2.6)
Date: Mon, 04 Nov 2013 08:31:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0


---
[Nov 4 09:31:58] VERBOSE[23919] chan_sip.c: Retransmitting #2 (NAT) to 91.121.129.20:5060:
REGISTER sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP IP_PUBLIQUE_ORANGE:5060;branch=z9hG4bK4361b7ca;rpo rt
Max-Forwards: 70
From: <sip:MON_NUMERO@sip.ovh.fr>;tag=as0ee3f332
To: <sip:MON_NUMERO@sip.ovh.fr>
Call-ID: 28952f44389e1cac4f7693816a1812c4@127.0.0.1
CSeq: 16001 REGISTER
User-Agent: FPBX-2.9.0(1.6.2.6)
Expires: 120
Contact: <sip:s@IP_PUBLIQUE_ORANGE>
Content-Length: 0


---
[Nov 4 09:31:58] VERBOSE[23919] chan_sip.c: Retransmitting #1 (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP IP_PUBLIQUE_ORANGE:5060;branch=z9hG4bK19468cca;rpo rt
Max-Forwards: 70
From: "Unknown" <sip:Unknown@IP_PUBLIQUE_ORANGE>;tag=as1b07133c
To: <sip:sip.ovh.fr>
Contact: <sip:Unknown@IP_PUBLIQUE_ORANGE>
Call-ID: 3b5031c6491ece1038d301be735ff2be@IP_PUBLIQUE_ORANG E
CSeq: 102 OPTIONS
User-Agent: FPBX-2.9.0(1.6.2.6)
Date: Mon, 04 Nov 2013 08:31:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0


---
[Nov 4 09:31:59] VERBOSE[23919] chan_sip.c: Retransmitting #2 (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP IP_PUBLIQUE_ORANGE:5060;branch=z9hG4bK19468cca;rpo rt
Max-Forwards: 70
From: "Unknown" <sip:Unknown@IP_PUBLIQUE_ORANGE>;tag=as1b07133c
To: <sip:sip.ovh.fr>
Contact: <sip:Unknown@IP_PUBLIQUE_ORANGE>
Call-ID: 3b5031c6491ece1038d301be735ff2be@IP_PUBLIQUE_ORANG E
CSeq: 102 OPTIONS
User-Agent: FPBX-2.9.0(1.6.2.6)
Date: Mon, 04 Nov 2013 08:31:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0


---
[Nov 4 09:32:00] VERBOSE[23919] chan_sip.c: Retransmitting #3 (NAT) to 91.121.129.20:5060:
REGISTER sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP IP_PUBLIQUE_ORANGE:5060;branch=z9hG4bK4361b7ca;rpo rt
Max-Forwards: 70
From: <sip:MON_NUMERO@sip.ovh.fr>;tag=as0ee3f332
To: <sip:MON_NUMERO@sip.ovh.fr>
Call-ID: 28952f44389e1cac4f7693816a1812c4@127.0.0.1
CSeq: 16001 REGISTER
User-Agent: FPBX-2.9.0(1.6.2.6)
Expires: 120
Contact: <sip:s@IP_PUBLIQUE_ORANGE>
Content-Length: 0


---
[Nov 4 09:32:00] VERBOSE[23919] chan_sip.c: Retransmitting #3 (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP IP_PUBLIQUE_ORANGE:5060;branch=z9hG4bK19468cca;rpo rt
Max-Forwards: 70
From: "Unknown" <sip:Unknown@IP_PUBLIQUE_ORANGE>;tag=as1b07133c
To: <sip:sip.ovh.fr>
Contact: <sip:Unknown@IP_PUBLIQUE_ORANGE>
Call-ID: 3b5031c6491ece1038d301be735ff2be@IP_PUBLIQUE_ORANG E
CSeq: 102 OPTIONS
User-Agent: FPBX-2.9.0(1.6.2.6)
Date: Mon, 04 Nov 2013 08:31:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0


---

---

J'ai tenté de jouer avec les "minexpiry" d'après cette discussion sans résultat.

Puisque ça marchait très bien jusque là je ne sais pas trop où regarder...

Pour info, la config du trunk :

Citation:

---

type=peer
qualify=yes
host=sip.ovh.fr
language=fr
insecure=very
defaultuser=MON_NUMERO
secret=MON_MOT_DE_PASSE
nat=yes
canreinvite=no
dtmfmode=auto
video=no
context=custom-get-did-ovh

---

J'avais le paramètre "insecure = port,invite" précédemment sans résultat

Puisque ça fonctionne depuis mon adresse IP OVH, la différence vient soit de mon routeur qui gère différemment les 2 liens adsl (ça marchait avant, je n'ai constaté aucune différence) soit du comportement du serveur vis à vis des 2 adresses différentes. Y a-t-il une restriction en place par défaut qui ne laisserait passer que les adresse OVH ? (si c'était le cas j'espère que le support me l'aurais dit dès le départ...)

J'ai tenté de mettre mon ip orange dans les adresses de confiance pour la restriction, aucune différence de comportement, j'ai toujours un timeout, comme si le serveur refusait de répondre sur ces IP

J'ai testé avec Zoiper : test réussi depuis l'IP orange.

Pour résumé :

enregistrement asterisk sur IP OVH : ok
enregistrement asterisk sur IP Orange : Nok
enregistrement softphone sur IP Orange : ok

Le routeur fonctionne donc correctement que ce soit sur la ligne OVH ou la ligne Orange
Le paramétrage asterisk est validé par l'enregistrement depuis l'IP OVH
sip.ovh.fr accèpte bien mes connexions depuis l'IP Orange

Le problème vient donc de l'enregistrement du trunk avec asterisk, depuis l'IP orange...
Ça me parait bizarre...

Des pistes à proposer ?

si ca marche depuis zoiper depuis le meme lan (mais un autre pc ?), ca exclut à mon sens orange & ovh. j'essaierai de faire des traceroute et catpures wireshark depuis les deux machines (zoiper & asterisk) et comparer

bonjour,

dans le sip.conf tu as bien externip = ton ip orange?
pas de firewall sur l'asterisk?

Bonjour et merci pour votre participation ;)

externip pointe sur un dns dynamique (ip dynamique oblige) mais je pense que ce paramètre n'a aucune importance pour l'enregistrement car quand je teste avec le lien OVH mais avec externip pointant sur orange, l’enregistrement se passe correctement. Quoiqu'il en soit, il est à jour avec le lien Orange.

Ça marche depuis Zoiper effectivement depuis un autre PC, ce test m'a permis de valider le lien Orange (routage compris)
Ça marche avec le même serveur mais en passant par le lien OVH, les différences sont l'IP externe, et éventuellement le paramétrage du routeur dualwan, mais j'ai beau tout passer en revu je ne vois aucun paramétrage spécifique, pas de différence entre Orange ou OVH si ce n'est la priorité des routes, pas de différences entre le serveur asterisk et le PC en test avec Zoiper.

Les traceroutes marchent bien, reste la capture réseau, à tout hazard, une ligne de commande avec tcpdump pour regarder de façon précise ce qui nous intéresse ? je ne pense pas avoir accès aux trames depuis mon PC (switch grands public entre le serveur et mon pc)

Pas de firewall, juste le routeur qui fait du NAT, mais pas de différence de toute façon entre les 2 liens.

Merci

En regardant les trames capturés avec tcpdump depuis le serveur freepbx, tant que je suis sur le lien orange, aucune réponse d'OVH, dès que je passe sur le lien OVH, j'ai une réponse...

je ne vois pas la différence entre entre les 2 cas dans les trames.

Les trames de Zoiper sont trop différentes.

Bon, j'avance, j'ai mis la même configuration IP sur mon PC, pas de réponse... Problème de réseau donc, va falloir que je fouille un peu plus.

En fait j'ai 2 sous réseaux, un pour la data et l'autre pour la voip, chacun étant routé sur un lien xdsl différent (en fait à terme j'aurai 2 réseaux physiquement séparés, switch grand public = pas de vlan).

Le serveur asterisk a 2 IP (2 cartes réseau) une sur le lan data (pour l'accès à l'administration par les pc entre autre) et une sur le lan voip pour les téléphones jusqu'au routeur et le lien xdsl dédié.

En changeant les adresses IP du serveur ça roule, je ne comprends pas pourquoi car je n'ai aucune règle spécifique à cette adresse précisément...

Au passage, OVH rejette les communication avec un user-agent de type freepbx (mais pas le registration), les appels passent en le remplaçant par celui d'un hardphone ou softphone (vieil abonnement avant l'apparition de l'offre "sip trunk", asterisk n'est plus autorisé sur les autres abonnements)

Tiens intéressant comme info ... Pour le contrer il suffit de changer le user-agent dans le chan sip et de mettre celui qui est reconnu par OVH. Pourquoi ils ont fait cela ?

Pour exemple : dans la section general il suffit de changer useragent= par ce que vous voulez.

Citation:

---

Envoyé par UncleBuzz

Bon, j'avance, j'ai mis la même configuration IP sur mon PC, pas de réponse... Problème de réseau donc, va falloir que je fouille un peu plus.

En fait j'ai 2 sous réseaux, un pour la data et l'autre pour la voip, chacun étant routé sur un lien xdsl différent (en fait à terme j'aurai 2 réseaux physiquement séparés, switch grand public = pas de vlan).

Le serveur asterisk a 2 IP (2 cartes réseau) une sur le lan data (pour l'accès à l'administration par les pc entre autre) et une sur le lan voip pour les téléphones jusqu'au routeur et le lien xdsl dédié.

En changeant les adresses IP du serveur ça roule, je ne comprends pas pourquoi car je n'ai aucune règle spécifique à cette adresse précisément...

---

peut etre dans ce cas que asterisk choisit la mauvaise interface en sortie. vérifie avec tcpdump. je crois que la logique pour choisir le nic est qu'asterisk recherche une carte avec @ et masques correspondants à l'ip ou envoyer, sinon, il compare avec localnet.

Non ce n'est pas lié à asterisk mais à ma config réseau, quand je mets l'ip du serveur asterisk à mon PC, et uniquement celle-ci, mon softphone n'obtient plus de réponse à ses demande d'enregistrement, donc c'est probablement un soucis de routage avec cette adresse IP, sauf que je suis incapable d'en trouver la raison, je n'ai aucune règle de routage spécifique à cette adresse, et la nouvelle adresse IP est sur le même sous-réseau et fonctionne correctement.

Mon localnet de toute façon pointe bien vers le sous réseau VOIP.

Pour ovh et asterisk, ce n'est pas très clair, les conditions particulière des comptes SIP indique tolérer asterisk comme client pour peu qu'il soit bien configuré et sécurisé, les conditions particulières des offres plug'n phone interdisent asterisk.

Allez savoir comment se classe les offres actuelles, qui sont des lignes SIP, avec prêt de téléphone (non obligatoire)... En tout cas, avec le user-agent standard de freepbx j'avais un beau retour SIP unauthorized pour un appel sortant, j'ai mis celui d'un téléphone astraa et hop, la même communication passe sans soucis.

Au passage, petite question sur le SIP d'OVH, asterisk envoi une trame de type OPTIONS avec certaines info (Zoiper les envoie directement dans al trame de REGISTRATION) mais le serveur SIP OVH semble ne pas connaitre le terme OPTION :

Citation:

---

[Nov 5 10:29:32] VERBOSE[1016] chan_sip.c: Reliably Transmitting (NAT) to 91.121.129.20:5060:
OPTIONS sip:sip.ovh.fr SIP/2.0
Via: SIP/2.0/UDP XX.XX.XX.XX:5060;branch=z9hG4bK5fe767f1;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@XX.XX.XX.XX>;tag=as18034ad2
To: <sip:sip.ovh.fr>
Contact: <sip:Unknown@XX.XX.XX.XX>
Call-ID: 2cdca2e827d6233726cd8e4b7a7f3a75@XX.XX.XX.XX
CSeq: 102 OPTIONS
User-Agent: Aastra 6730i/2.6.0.1007
Date: Tue, 05 Nov 2013 09:29:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0

---

Citation:

---

[Nov 5 10:29:32] VERBOSE[1016] chan_sip.c:
<--- SIP read from UDP:91.121.129.20:5060 --->
SIP/2.0 501 Not Implemented
Call-ID: 2cdca2e827d6233726cd8e4b7a7f3a75@XX.XX.XX.XX
CSeq: 102 OPTIONS
From: "Unknown" <sip:Unknown@XX.XX.XX.XX>;tag=as18034ad2
To: <sip:sip.ovh.fr>;tag=00-25727-47d888c5-0bea85925
Via: SIP/2.0/UDP XX.XX.XX.XX:5060;received=XX.XX.XX.XX;rport=55822; branch=z9hG4bK5fe767f1
Content-Length: 0

---

Aucun risque de dysfonctionnement ?

Pour le coup du useragent, fausse info, j'ai de nouveau des appels rejetés avec le useragent aastra :

Citation:

---

[Nov 5 11:42:11] WARNING[1016] chan_sip.c: Received response: "Forbidden" from '"0033972XXXXXX" <sip:0033972XXXXXX@83.XXX.XXX.XXX>;tag=as036f96b d'

---

EDIT:

suivi de :

Citation:

---

[Nov 5 11:50:39] WARNING[1016] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '0033972XXXXXX' to 'sip.ovh.fr'

---

Erreur qu'on retrouve couramment sur le forum d'OVH, bug provenant d'OVH...

Bonjour,

Pour moi le problème se situe sur ton Routeur de la connection Orange.

Tu as des REGISTER qui partent mais aucune réponse, soit il arrive au routeur Orange et ils ne sont pas routé vers OVH, soit c'est le retour d'OVH qui n'est pas natté vers ton IPBX.

Le deuxième hypothèse est plus probable.

Est-ce une Livebox ? si oui c'est pas vraiment étonnant , c'est loin d'ètre un bon routeur à mon avis.

Cordialement

Citation:

---

Envoyé par UncleBuzz

Au passage, petite question sur le SIP d'OVH, asterisk envoi une trame de type OPTIONS avec certaines info (Zoiper les envoie directement dans al trame de REGISTRATION) mais le serveur SIP OVH semble ne pas connaitre le terme OPTION :

Aucun risque de dysfonctionnement ?

---

non, dans ce cas, l'option ne sert qu'à mesurer le temps que mettent les paquets à faire l'aller retour, (paramètre qualify) - si tu veux supprimer ca, il te suffit de mettre qualify=no dans le peer / sip.conf

Citation:

---

Envoyé par jean

non, dans ce cas, l'option ne sert qu'à mesurer le temps que mettent les paquets à faire l'aller retour, (paramètre qualify) - si tu veux supprimer ca, il te suffit de mettre qualify=no dans le peer / sip.conf

---

Surtout pas ! Le qualify ne sert pas seulement à mesurer le temps que mettent les paquets à faire l'aller retour, mais aussi (et surtout) à entretenir le conntrack du NAT pour que la connexion UDP du SIP reste toujours active, ce qui est nécessaire quand asterisk est derrière un serveur NAT et qu'il n'y a pas de redirection du port 5060.

La réponse "501 Not Implemented" à ta requête OPTIONS est tout à fait normale, pas d'inquiétude à avoir sur ce point.

Concernant le qualify, ovh conseille de le mettre seulement sur une ligne pour ceux qui ont plusieurs lignes. Mais bon, en fait, leur infra en ce moment debordé et ne supporte pas/plus la charge. Ca semble etre la raison des erreurs d'identifications et ca semble pourquoi il demande de ne plus mettre ou limiter les qualify.
Ils indique qu'il gere le keep alive et que le qualify ne serait pas/plus necessaire.
Pour moi il l'est me permettant de faire un sip reload automatique en cas de probleme de leur coté.
Le support ovh de toutes facons quelque soit le probleme a toujours demande d'abord de migrer sur le .fr. Mais en fait, ceux qui sont restés ( comme moi sur des vielles installs ) sur le net ont globalement moins de pb ( en tout cas sur ce point )
Pour regler leur probleme de charge, ils ont annoncé avoir mis des règles de firewall en place. Du coup, celui avec un register timeout trop court ou autre critere pas du tout clairement public, on peut potentiellement etre dans l'impossibilité de joindre leur serveur sip. Complétement stupide au lieu d'envoyer au pire une erreur sip explicite mais bon...
En ce moment, les erreurs proviennent de l'infra ovh et il est donc inutile d'essayer de resoudre cela de son coté...
On peut tenter du cote du support mais cela absorbe bien trop d'energie.
Ils ont annoncé la mise en place de nouvelles infras permettant de diminuer la charge par infra et reglant normalement les pbs rencontres en ce moment. Je n'ai pas suivi pour savoir si cela a ete fait ou si cela sera fait bientot.
Francois.

Chez moi c'est inutilisable, je peux passer 1 appel après un sip reload, après, je me tape du forbidden... Donc il me faut un sip reload après chaque appel...

Dans ton extension "h" tu mets un bout de dialplan avec system qui fait un reload ... Bon ok je sors ;-)

Bonjour,

le support a fini par me répondre :

Code:

---

Le REGISTER a été effectué via le port 35657 or l'INVITE a été envoyé par le port 59155 c'est pourquoi vous avez eu le retour 403 not registered.

Les appels doivent passer par la même session / port que le REGISTER

---

A quel niveau dois-je intervenir pour régler ça ? c'est un problème d'asterisk ? freepbx ? du routeur ?

En regardant mes trames SIP, je vois que le port change à chaque trame OPTION envoyée...

D'où le fait que je puisse lancer des appels dans la 1ere minute, dès que le port change, je me fais jeté...

Une idée d'où vient le soucis ? le qualify=yes est bien sensé maintenir la session ouverte, alors comment se fait-il que chaque paquet est envoyé sur une nouvelle session et donc un nouveau port ?

Comment puis-je passer l'envoie de trame OPTION toutes les 30 secondes pour faire un test ?

pour moi, c'est le routeur, mais un ngrep sur ta machine permettra de vérifier cela.

pour augmenter la fréquence des options, je pense qu'un qualifyfreq=30 doit faire l'affaire

aussi, as tu vu ce thread ?
http://www.asterisk-france.org/showt...vh-r%C3%A9solu

Bonjour,

je n'ai pas encore fait de capture réseau, mais déjà depuis que j'ai mis le qualifyfreq=30 le port est toujours le même, il ne change même pas entre 2 REGISTER ou un rechargement complet d' asterisk.

A voir dans le temps mais ça semble suffire pour maintenir la session ouverte sur le même port. En tout cas c'est effectivement au niveau du routeur que ça se joue... Dans l'idéal il me semble qu'il faudrait un script qui relance un REGISTER si le port venait à changer, car cela revient à se déconnecter du trunk sans qu'asterisk ne s'en rende compte...

Merci !

Sinon oui j'avais vu le topic indiqué.

Bonjour,

ça marche presque, ça marche bien jusqu'au moment où mes téléphones en local se réenregistrent, ça retarde l'envoi de la trame OPTIONS qui part au bout de ~45sec et donc, nouveau port utilisé.

Je vais raccourcir le délais, mais l'idéal serait de faire un script. Une idée d'où regarder ? obligé de garder le debug sur le sip.ovh.fr (ça va gonfler les logs) ? En plus il faut un script pour mettre à jour le script afin d'inclure mon ip publique qui est dynamique pour dissocier dans les logs les différends endroit ou le port peut être afficher...

En tout cas on se rapproche d'un fonctionnement correct !

Merci

je pense que le soucis vient du routeur - certains changent le port lors du nattage/denattage.

qu'est ce que c'est comme routeur ?

c'est un routeur bintec RS120

Je n'ai trouvé aucune option sur la durée de vie des sessions udp, j'ai descendu le qualifyfreq à 15 secondes, du coup je "spam" ovh mais je devrais tenir bon avec ce paramétrage.

reste que si le port devais changer à un moment donné, je n'ai pas de moyen de le détecter pour le moment.