Interphone analogique : envoyer deux HookFlash consécutifs.

[Reaper]

Bonjour, ton features.conf/extensions.conf rassemble a ça ?

Currently no. You would need to add logic to the channel driver. Or
use DTMF to initiate the hookflash:

extensions.conf
[globals]
DYNAMIC_FEATURES=>zapflash

features.conf
[applicationmap]
zapflash => *0,callee,flash,()

[Gasel]

Bonjour Reaper,

J'ai trouvé la solution pour les Dynamic Features : comme j'utilise FreePBX comme interface, j'ai mis

[globals]
DYNAMIC_FEATURES=>FlashCmd

dans globals_custom.conf
et

[applicationmap]

FlashCmd => *6,callee,Macro,CmdFlash

dans features_general_custom.conf.
Je l'avais mis dans features_applicationmap_custom.conf, qui semble être sa place logique, mais dans ce cas, il n'est pas pris en compte. Étrange...

EDIT : J'ai compris pourquoi il n'est pas pris en compte. Il ne faut pas spécifier [applicationmap] dans le fichier features_applicationmap_custom.conf. En effet, la section [applicationmap] figure déjà dans le fichier features.conf de FreePBX.

Ma macro :

[macro-CmdFlash]
exten => s,1,Playback(wait-moment)
exten => s,n,Flash()
exten => s,n,Wait(0.2)
exten => s,n,Flash()

En tous cas, je me retrouve dans la même situation que mon précédent post. Dès que le premier flash est envoyé sur la ligne, Asterisk détecte une erreur et raccroche :

  -- SIP/33-0000006c is ringing
    -- SIP/33-0000006c answered DAHDI/2-1
    -- Executing [s@macro-auto-blkvm:1] Set("SIP/33-0000006c", "__MACRO_RESULT=") in new stack
    -- Executing [s@macro-auto-blkvm:2] Macro("SIP/33-0000006c", "blkvm-clr,") in new stack
    -- Executing [s@macro-blkvm-clr:1] Set("SIP/33-0000006c", "SHARED(BLKVM,DAHDI/2-1)=") in new stack
    -- Executing [s@macro-blkvm-clr:2] Set("SIP/33-0000006c", "GOSUB_RETVAL=") in new stack
    -- Executing [s@macro-blkvm-clr:3] MacroExit("SIP/33-0000006c", "") in new stack
    -- Executing [s@macro-auto-blkvm:3] ExecIf("SIP/33-0000006c", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(num))=33)") in new stack
    -- Executing [s@macro-auto-blkvm:4] ExecIf("SIP/33-0000006c", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=Personnel)") in new stack
    --  Feature Found: FlashCmd exten: FlashCmd
    -- Executing [s@macro-CmdFlash:1] Playback("DAHDI/2-1", "wait-moment") in new stack
    -- <DAHDI/2-1> Playing 'wait-moment.gsm' (language 'fr')
    -- Executing [s@macro-CmdFlash:2] Flash("DAHDI/2-1", "") in new stack
    -- Flashed channel DAHDI/2-1
    -- Executing [s@macro-CmdFlash:3] Wait("DAHDI/2-1", "0.2") in new stack
  == Spawn extension (macro-CmdFlash, s, 3) exited non-zero on 'DAHDI/2-1' in macro 'CmdFlash'
    -- Executing [h@macro-dial:1] Macro("DAHDI/2-1", "hangupcall") in new stack
    -- Executing [s@macro-hangupcall:1] GotoIf("DAHDI/2-1", "1?theend") in new stack
    -- Goto (macro-hangupcall,s,3)
    -- Executing [s@macro-hangupcall:3] Hangup("DAHDI/2-1", "") in new stack
  == Spawn extension (macro-hangupcall, s, 3) exited non-zero on 'DAHDI/2-1' in macro 'hangupcall'
  == Spawn extension (macro-dial, h, 1) exited non-zero on 'DAHDI/2-1'
    -- Hanging up on 'DAHDI/2-1'
    -- Hungup 'DAHDI/2-1'
[2012-08-02 17:06:23] WARNING[29393]: chan_dahdi.c:7745 handle_alarms: Detected alarm on channel 2: Red Alarm

Grrrrrr.....
Ma seule issue serait d'empêcher la détection de l'erreur par Asterisk, le temps d'envoyer le second flash. Penses-tu que cela soit possible ?

[Reaper]

[macro-CmdFlash]
exten => s,1,Flash()
exten => s,n,Wait(1)
exten => s,n,Flash()
Fonctionne mieux ?

[Gasel]

Bonjour Reaper,

Malheureusement non. Le premier hookflash entraîne toujours le raccrochage de la ligne, c'est pourquoi j'aurais voulu empêcher Asterisk de raccrocher pour pouvoir envoyer le second hookflash.

Je pense que cette interface de parlophone ne respecte pas les normes en vigueur, mais compte tenu de la disposition des lieux, il est très difficile de la remplacer.

Je précise qu'en branchant un simple téléphone sur cette interface, l'ouverture du portail se fait sans problème, mais on entend effectivement un certain ronflement pendant l'envoi des hookflash.

Existe-il une commande qui rend Asterisk (ou la carte Digium) plus tolérants au non respect des normes ?

[Kriss]

J'imagine que tu as déjà essayé mais au cas où... n'y a t'il aucun moyen de remplacer les hookflash par une autre commande d'ouverture dans le portier ? Je ne suis pas parvenu à trouver de doc dessus mais si ça peut être une autre piste du coup ...

[Gasel]

Hélas non, il n'y a aucun réglage pour la commande d'ouverture et je n'ai pas trouvé le moyen d'empêcher Asterisk de raccrocher dès qu'il détecte l'anomalie et signale une "Red Alarm" sur le canal FXO.
Si je pouvais empêcher le raccroché avant le second hookflash, je pense que le problème serait résolu...