Timeout à l'enregistrement sur SIP.OVH.FR

[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 :

[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

[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 ?

[UncleBuzz]

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

[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 :

[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...

[Ipconnect]

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

[jean]

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

[sixela]

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.

[fastm3]

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.

[UncleBuzz]

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...

[quintana]

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

[UncleBuzz]

Bonjour,

le support a fini par me répondre :

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 ?

[jean]

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