Carte Digium: congestion-alarms RED

[capsiz]

Bonjour la communauté,

J'ai deux serveurs Elastix NLX4000 avec chacune une carte TE131/TE133
Je les ai configurés, je pouvais appelé et recevoir des appels à travers une E1. (La ligne est placé sur un seul serveur)
Mais ce matin j'arrive rien ne marche plus.
Dans la console j'ai :

[2016-06-28 06:13:20] WARNING[10307][C-00000000]: app_dial.c:2437 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)
  == Everyone is busy/congested at this time (1:0/1/0)
    -- Executing [s@macro-dialout-trunk:23] NoOp("SIP/8000-00000000", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 34") in new stack

J'ai redémarré les dahdi, asterisk mais rien. Avec la ligne E1 branchée ou pas ,la commande dahdi show status me donne

elx*CLI> dahdi show status
Description                              Alarms  IRQ    bpviol CRC    Fra Codi Options  LBO
Wildcard TE131/TE133 Card 0              BLU/RED 0      0      0      CCS HDB3          0 db (CSU)/0-133 feet (DSX-1)
elx*CLI>

Sans avoir branché la ligne, je devais avoir Alarm OK mais ce n'est ps le cas. Et ce qui est étrange, c'est le même problème avec le second serveur.

Quand je redémarre, et je vais sur l'interface graphique, les canaux sont verts ce qui signifie: Et quand je branche le ligne, canaux virent au rouge, ce qui signife " Canal détecté et utilisé", mais la commande indique toujours Alarms RED. Et quand je branche le ligne, canaux virent au rouge, ce qui signife " Canal détecté et non utilisé"

J'ai vérifié si les cartes étaient détectées par le système, avec dmesg et le fichier /var/log/messages, tout semble ok.

wcte13xp 0000:04:00.0: setting latency timer to 64
wcte13xp 0000:04:00.0: Firmware version: 780019
wcte13xp 0000:04:00.0: FALC version: 5
wcte13xp 0000:04:00.0: Setting up global serial parameters for E1
wcte13xp 0000:04:00.0: Echo cancellation for 32 channels
wcte13xp 0000:04:00.0: Reset octasic
wcte13xp 0000:04:00.0: VPM450: Present and operational servicing 1 span
wcte13xp 0000:04:00.0: Found a Wildcard TE131/TE133 (SN: 1TE133F - DF04151699553 - B1 - 20150422)
dahdi_devices pci:0000:04:00.0: local span 1 is already assigned span 1
wcte13xp 0000:04:00.0: Span configured for CCS/HDB3
wcte13xp 0000:04:00.0: Calling startup (flags is 4099)
wcte13xp 0000:04:00.0: Setting yellow alarm
drbd: initialized. Version: 8.3.15 (api:88/proto:86-97)
drbd: GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build by mockbuild@builder10.centos.org, 2013-03-27 16:01:26
drbd: registered as block device major 147
drbd: minor_table @ 0xffff810129a74a80
wcte13xp 0000:04:00.0: Span configured for CCS/HDB3/CRC4
wcte13xp 0000:04:00.0: Calling startup (flags is 4099)
wcte13xp 0000:04:00.0: AIS alarm detected
wcte13xp 0000:04:00.0: Span configured for CCS/HDB3
wcte13xp 0000:04:00.0: Calling startup (flags is 4099)

/var/log/messages (setting Yellow alarm , je ne sais pas si c'est normal)

Jun 28 12:05:15 elx kernel: wcte13xp 0000:04:00.0: Firmware version: 780019
Jun 28 12:05:15 elx kernel: wcte13xp 0000:04:00.0: FALC version: 5
Jun 28 12:05:15 elx kernel: wcte13xp 0000:04:00.0: Setting up global serial parameters for E1
Jun 28 12:05:15 elx kernel: wcte13xp 0000:04:00.0: Echo cancellation for 32 channels
Jun 28 12:05:15 elx kernel: wcte13xp 0000:04:00.0: Reset octasic
Jun 28 12:05:16 elx kernel: wcte13xp 0000:04:00.0: VPM450: Present and operational servicing 1 span
Jun 28 12:05:16 elx kernel: wcte13xp 0000:04:00.0: Found a Wildcard TE131/TE133 (SN: 1TE133F - DF04151699553 - B1 - 20150422)
Jun 28 12:05:16 elx 'dahdi_handle_device'[2660]: add: /devices/pci0000:00/0000:00:1c.3/0000:04:00.0/pci:0000:04:00.0
Jun 28 12:05:16 elx 'dahdi_handle_device'[2663]: auto_assign_spans=1. Skip /devices/pci0000:00/0000:00:1c.3/0000:04:00.0/pci:0000:04:00.0
Jun 28 12:05:17 elx 'dahdi_span_config'[2676]: add: /devices/pci0000:00/0000:00:1c.3/0000:04:00.0/pci:0000:04:00.0/span-1
Jun 28 12:05:17 elx 'dahdi_span_config'[2684]: auto_assign_spans=1. Skip /devices/pci0000:00/0000:00:1c.3/0000:04:00.0/pci:0000:04:00.0/span-1
Jun 28 12:05:17 elx kernel: dahdi_devices pci:0000:04:00.0: local span 1 is already assigned span 1
Jun 28 12:05:17 elx kernel: wcte13xp 0000:04:00.0: Span configured for CCS/HDB3
Jun 28 12:05:17 elx kernel: wcte13xp 0000:04:00.0: Calling startup (flags is 4099)
Jun 28 12:05:17 elx kernel: wcte13xp 0000:04:00.0: Setting yellow alarm

[capsiz]

J'ai activé le debug pour le PRI et voici ce que j'obtiens

elx*CLI> pri set debug on span 1
Enabled debugging on span 1
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 MDL-ERROR (G): T200 expired N200 times sending SABME in state 5(Awaiting establishment)
PRI Span: 1 Changing from state 5(Awaiting establishment) to 4(TEI assigned)
PRI Span: 1 TEI=0 DL event: Q931_DL_EVENT_DL_RELEASE_IND(3)
PRI Span: 1 SAPI/TEI=0/0 Kick starting link
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 Changing from state 4(TEI assigned) to 5(Awaiting establishment)
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 MDL-ERROR (G): T200 expired N200 times sending SABME in state 5(Awaiting establishment)
PRI Span: 1 Changing from state 5(Awaiting establishment) to 4(TEI assigned)
PRI Span: 1 TEI=0 DL event: Q931_DL_EVENT_DL_RELEASE_IND(3)
PRI Span: 1 SAPI/TEI=0/0 Kick starting link
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 Changing from state 4(TEI assigned) to 5(Awaiting establishment)

[jean]

question bête.... c'est pas les liens ISDN qui sont hs ?

[capsiz]

Les lignes ISDN fonctionnement normalement.
Tout marchait bien. Le lendemain on vient on constate qu'on ne peut pas émettre ou recevoir les appels.
On a fait des tests , les cartes sont détectées par le système mais un dahdi show status, indique que l'Alarms est RED, en principe çà devait être juste OK.

elx*CLI> dahdi show status
Description                              Alarms  IRQ    bpviol CRC    Fra Codi Options  LBO
Wildcard TE131/TE133 Card 0        RED 0      0      0      CCS HDB3          0 db (CSU)/0-133 feet (DSX-1)
elx*CLI>

Apparemment nos cartes ont lâché.Ce qui est bizarre , le problème est arrivé au même moment sur nos 2 serveurs.

[capsiz]

Jean, tu avais raison, le problème venait de l'opérateur. Pourtant quand on les avait contacté, ils nous avaient dit qu’ils n'avaient aucun problème.
merci

[fastm3]

Pourtant quand on les avait contacté, ils nous avaient dit qu’ils n'avaient aucun problème.

Comme c'est touchant cette candeur. :-D

Toujours bien insister des que tu rencontres un soucis et surtout ne pas laisser transpirer le moindre doute.
Quand on a un peu d'experience avec le materiel et config , on sait ce qui doit marcher et c'est plus facile d'etre persuasif. Encore plus quand la config tombe en panne comme toi sans changement.
L'opérateur a de bien meilleurs outils pour voir les defauts de la ligne. Encore faut il qu'il regarde.
Ca reste rare sur les lignes numeriques mais ca arrive.

J'ai deja eu des problemes sur une numeris ou on me dit qu'il n'y a pas de soucis. J'insiste et on me confirme qu'il ne voit pas de soucis. En insistant vraiment fortement, ils me disent de lancer enfin un test apres 24h perdues. Ils reviennent vers moi en m'indiquant que le test s'est bien passé et qu'il n'y a donc vraiment pas de soucis. Sauf que de mon coté, le probleme a été résolu a ce moment la sans rien faire de ma part...Des que l'on arrive a passer le premier niveau de support tel, ca se regle generallement tres vite en numeris ou au moins on a le diagnostic. Encore faut il le passer. Si on peut avoir une gateway avec une config test, un tel numeris test, ca aide aussi à convaincre plus simplement.
Autre sketch meme si on n'en rit pas sur le moment, j'appelle orange en indiquant que le groupement numeris est HS sauf que j'appelle de chez le client avec le trunk sip de backup en presentant la tete de ligne. Mais monsieur, arretez de dire que votre ligne ne marche pas puisque je vois bien que vous appelez de celle-ci...Au bout de 10 minutes d'incomprehension n'arrivant pas a passer ce premier niveau, j'ai rappelé avec mon portable...
Il faut souvent insister pour avoir le bon interlocuteur car les réponses du premier niveau peuvent etre souvent "folkloriques".
Ca peut mieux se passer en fait avec un bon operateur pro meme si celui-ci ne fait que transmettre les infos mises en forme à Orange.
Francois.