Affichage des résultats 1 à 6 sur 6

Discussion: Carte Digium: congestion-alarms RED

  1. #1
    Membre Junior
    Date d'inscription
    juin 2016
    Messages
    12
    Downloads
    0
    Uploads
    0

    Carte Digium: congestion-alarms RED

    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 :
    Code:
    [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
    Code:
    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.
    Code:
    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)

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

  2. #2
    Membre Junior
    Date d'inscription
    juin 2016
    Messages
    12
    Downloads
    0
    Uploads
    0
    J'ai activé le debug pour le PRI et voici ce que j'obtiens

    Code:
    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)

  3. #3
    Membre Senior
    Date d'inscription
    septembre 2010
    Localisation
    Where the sun shines
    Messages
    1 418
    Downloads
    0
    Uploads
    0
    question bête.... c'est pas les liens ISDN qui sont hs ?

  4. #4
    Membre Junior
    Date d'inscription
    juin 2016
    Messages
    12
    Downloads
    0
    Uploads
    0
    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.

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

  5. #5
    Membre Junior
    Date d'inscription
    juin 2016
    Messages
    12
    Downloads
    0
    Uploads
    0
    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

  6. #6
    Asterisk Fan Avatar de fastm3
    Date d'inscription
    août 2010
    Localisation
    Corbeil Essonnes (91)
    Messages
    1 302
    Downloads
    1
    Uploads
    1
    Citation Envoyé par capsiz Voir le message
    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.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •