Lenteur lors des appels sortants

Bonjour,

Je sais que ce n'est pas la bonne solution mais j'ai dû remplacer un pc sur lequel tournait Asterisk 1.6 par une autre machine pour virtualiser le système.

Je suis en Belgique, j'ai hérité de l'installation Asterisk 1.6 qui a été installée en 2010 sur un pc normal (Ubuntu).

Le "serveur" virtuel actuel est connecté aux BA de Belgacom par deux Patton.
Un des patton reçoit les lignes de 4 BA et le second reçoit les lignes des 2 autres BA de Belgacom (Proximus - lignes par groupes de 10) .

Le PC qui faisait office de serveur montrait des signes de vieillesse.

J'ai alors fait installer un nouveau serveur virtuel "Ubuntu" sur nos serveurs équipés depuis peu de VMware et j'y ai installé la version 11.7 d'Asterisk.
Ensuite, faute de connaissance, j'ai copié les fichiers *.conf de la version 1.6 et j'ai écrasé les fichiers qui se trouvaient dans la version 11.7 dans la nouvelle machine virtuelle.

Ca n'a pas trop mal fonctionné, mais :
1) de temps à autres tous ou une grande partie des téléphones (Linksys SPA922) se déconnectent puis reviennent sans que je n'en connaisse la raison.
2) depuis ce matin les appels sortants sont lents à partir de la composition du numéro sur le poste.
En effet, il faut au moins 5 secondes avant d'entendre le premier "tuuut" et voir dans la cli que le patton puis encore 4 secondes avant que mon téléphone portable ne sonne.

Il y a une heure, plus aucun appel ne pouvait être réalisé : pas de tonalité.

Tout ce que je fais, je le fais en ligne de commande.

J'ai donc avant tout, relancé le serveur, (sudo reboot) puis j'ai relancé (débranché re-branché) les deux pattons, puis j'ai relancé (idem) les switches espérant rafraichir le système.

Les appels sortants fonctionnent à nouveau mais sont très lents.

Dans la cli je vois après 4 secondes:
Called SIP/Patton1/le_numero_appelé
puis après encore quelques secondes :
SIP/Patton1-00000169 is ringing
et mon portable se met à sonner.

Dans l'autre sens (Appels entrants)
Lorsque j'appelle de l'extérieur il faut 1 à 2 secondes avant que le SPA922 ne sonne.
Mais le pire, c'est que, pour les lignes qui sont connectées au patton1, si je ne décroche pas le combiné mais que je raccroche depuis mon portable, le téléphone sonne encore pendant plus de 20 secondes avant de comprendre que j'ai raccroché.
Je n'ai pas ce temps d'attente avec les lignes qui sont connectés à l'autre patton.

Je suis disposé à afficher les fichiers extensions, sip et queue.conf si nécessaire.

A vous lire.
Dominique

- les vm ne sont généralement pas recommandées sur asterisk - mais d'après mes lectures, ca cause surtout des voix hachées / pbm audio - et il existe qd meme pas mal d'install qui ne se plaignent pas

- j'ai déjà passé de 1.6 à 11.7 comme tu as fait, il faut juste ensuite regarder les erreurs qui sortent au démarrage d'asterisk et remettre les bons .conf - en pratique, c'est surtout sip.conf et asterisk.conf qu'il faut récupérer de l'ancienne install

- au vu des infos, j'aurais tendance à soupconner l'hyperviseur ou la machine trop chargée - pour mieux comprendre, j'activerais les traces sur la patton (telnet puis
enable
configure
debug context sip-gateway transport detail 1
debug context sip-gateway signaling detail 1
debug ccisdn signaling
debug context sip-gateway error detail 3
)
et les traces sur asterisk, perso, j'aime bien ngrep -t port 5060 and host x.y.z.t (qui montre l'heure)

cela permettra de voir qui traine, mais je pense que la réponse est ton serveur asterisk

Bonjour Jean,

Oulà !
Euh je suis embarrassé, je ne sais pas où il faut taper les commandes que tu proposes.
Je ne connais que les config extensions, sip, asterisk et queue .conf.
Je connais très peu linux, hélas.

J'ai installé sur VM il y a 5 mois.
Il y a encore 3 jours (vendredi dernier) on n'avait pas d'attente, on sortait tout de suite avec l'un et l'autre patton.

Or, je dois ajouter que sur un des deux Patton, les appels sortent sans attendre,ça sonne tout de suite chez le destinataire.

J'ajoute que, lorsque j'ai installé, je n'ai eu que des coupures de toutes les lignes simultanément, pour tous les postes et elles remontaient toutes seules après 1 ou 2 secondes.

Mais, c'est un vrai problème lorsque le grand boss est coupé lors d'un entretien téléphonique.

Dernier détail, voyant cette "lenteur" et suite à quelques recherches, j'ai modifié le sip.conf pour chaque utilisateur :

J'ai remplacé le
nat=yes
par
nat=force_rport,comedia

et qualify=yes
par
qualify=4000
En relisant mes scripts je constate que seuls sont concernés ceux qui sont connecté au Patton1 mais aussi, ce sont ceux qui sont dans un des contextes et connectés à l'un des patton, ceux qui sont dans l'autre contexte n'ont pas de problème.

Tu viens peut-être d'ouvrir une piste que je vais étudier tout de suite.
Merci.
Mais si tu peux me donner quelques détails pour les instructions que tu me proposes, ce sera plus facile pour moi.
Dominique

- mettre à jour le nat=yes est une bonne chose, mais c'est pas ton problème
- le qualify=yes va envoyer des paquets toutes les 60 sec, et si pas de réponse au bout de 2000 ms (ton exemple), la ligne sera considérée injoignable

pour les commandes, il faut aller sur un terminal linux, et lancer
ngrep -t port 5060 and host ipdelapatton
si ngrep n'est pas installé, google...

et sur une autre session, telnet ipdelapatton
puis
enable
configure
debug context sip-gateway transport detail 1
debug context sip-gateway signaling detail 1
debug ccisdn signaling
debug context sip-gateway error detail 3


mais, en conclusion, si tu connais pas asterisk et que tu connais pas linux.... hum.... je te conseillerai de trouver un intégrateur compétent dans ta région !

J.

Bonjour Jean,

J'ai été engagé pour m'occuper de la partie technique de l'endroit où je travaille.
Mon employeur considère que l'informatique reprend la gestion des ordinateurs et d'autres "secteurs" comme la sonorisation d'une salle, l'administration d'un réseau et d'un domaine, la gestion des bases de données, la création et maintenance d'un site internet, la téléphonie, etc.

Si je dois faire appel à un intégrateur dès le premier problème rencontré sous linux, autant donner mon préavis.
Je pense que l'informaticien doit se former constamment vu que ces matières évoluent constamment.
Donc, je cherche des solutions qui me permettent d'améliorer mes compétences.
Par ailleurs, des formations sur Asterisk, ce n'est pas facile à trouver et ils n'organiseront pas une formation rien que pour moi demain.
Or, c'est aujourd'hui que je suis confronté au problème de lenteur.
Mais je m'éloigne du sujet.

Donc, je viens de tester ngrep -t port 5060
Mais ngrep n'est pas installé.
Je vais donc m'y prendre en commençant l'installation de ngrep puis suivre tes pistes.

Tu dis que mettre à jour le nat à yes est une bonne chose.
Or, c'est justement le contraire que je viens de faire !

Il y avait
nat=yes
et maintenant j'ai
nat=force_rport,comedia

idem pour qualify
j'avais qualify =yes

maintenant j'ai
qualify=4000

espérant remédier à ces time out.
Je crois comprendre qu'il faut remettre le nat à yes?

Je vais déjà installer ngrep...
Merci pour ton aide précieuse.
Dominique

Bonjour,

Alors, j'ai installé....

ENsuite lorsque je tape
debug context sip-gateway transport detail 1
une réponse affiche

01:59:04 SIP_TR> [STACK] > stack: SIP/2.0 100 ringing
01:58:39 SIP_TR> [STACK] < stack: SIP/2.0 405 not Allowed
01:58:51 SIP_TR> [STACK] > stack: SIP/2.0 100 Trying
01:58:53 SIP_TR> [STACK] > stack: SIP/2.0 100 Trying
01:58:50 SIP_TR> [STACK] < stack: SIP/2.0 Session Progress
01:59:04 SIP_TR> [STACK] > stack: SIP/2.0 100 ringing
01:59:04 SIP_TR> [STACK] > stack: OPTIONS sipi:Patton1@192.168.1.252:5060 SIP/2.0

Ca avance trop vite, je ne sais pas tout lire et reproduire... :-(

Voici...
Pièce jointe 523
Pièce jointe 525

Pièce jointe 524

salut
je sens dans ton post précédent le blues de l'informaticien isolé... mais aussi sa bonne volonté ! pas de souci....

en fait, oui, il faut remplacer nat=yes par force_rport,comedia (j'étais pas clair)

bon, les traces sont pas mal, tu peux aussi faire un copier/coller sur le site pastebin.com (en anonymisant eventuellement) et envoyer le lien, ca les rend plus lisibles. également, puisque tu as des soucis de délais, c'est pas mal aussi de mettre la patton à l'heure ntp, ainsi que ton serveur, ca permet de comparer les heures

si on regarde:
01:58:39 SIP_TR> [STACK] < stack: SIP/2.0 405 not Allowed
01:58:51 SIP_TR> [STACK] > stack: SIP/2.0 100 Trying
01:58:53 SIP_TR> [STACK] > stack: SIP/2.0 100 Trying
01:58:50 SIP_TR> [STACK] < stack: SIP/2.0 Session Progress
01:59:04 SIP_TR> [STACK] > stack: SIP/2.0 100 ringing
01:59:04 SIP_TR> [STACK] > stack: OPTIONS sipi:Patton1@192.168.1.252:5060 SIP/2.0

le réseau belgacom met 14 secondes à faire sonner le mobile - et généralement, en gsm, on ne renvoie une sonnerie que lorsque le tel sonne effectivement, pas quand on le recherche sur le réseau (paging) - si tu rappelles le meme mobile juste après, il est possible que cela soit plus rapide

en revanche, il n'est pas possible de comparer l'heure de l'INVITE dans les traces SIP et avec la passerelle, car les heures sont différentes - il faudrait juger à la volée et voir si c'est simultané ou pas
pour info, le message option que tu postes correspond au fait que le qualify est actif - en mettant ce param à yes (ou une valeur X), il enverra tous les qualifyfreq millisecondes un message OPTION et attendra une réponse en moins de X millisecondes - si pas de réponse, le peer sera considéré comme injoignable et ne lui enverra pas d'appel

si ce sont les 14 secondes qui genent, c'est normal, sinon précise le souci !

Suite !

Je viens d'apprendre que ce sont les lignes de Belgacom qui sont coupées suite à des travaux effectués dans la rue.:)
Pfffft !

C'est lourd !

Dominique

hehé ! au moins, tu auras commencé à mettre les mains dans asterisk, c'est une petite compensation !