Interphone analogique : envoyer deux HookFlash consécutifs.

Version imprimable

28/07/2012, 09h26
Gasel

Interphone analogique : envoyer deux HookFlash consécutifs.
Bonjour à tous,

Ceci est mon premier message sur le forum, mais je vous lis depuis quelque temps déjà et j'ai pu résoudre beaucoup de difficultés grâce à vous.

Pourtant, je bute sur un problème un peu spécial :
Ma configuration est la suivante :
- Distribution FreePBX 32 bits
- Asterisk 1.8.7.1
- Carte Digium TDM410P 2 FXO 2 FXS
- Dahdi 2.5.0.1
- Base Siemens C590 ip Ethernet+FXO pour avoir 3 canaux de réception
- Interphone analogique Avisis de Avidsen relié sur un FXO
Lorsqu'on est en communication avec l'interphone, si l'on souhaite ouvrir le portail, il faut envoyer deux HookFlash (touche R) consécutifs sur la ligne FXO.
Or, Asterisk intercepte systématiquement la touche R, envoie la musique d'attente au correspondant et me donne la tonalité pour me permettre de transférer l'appel !!!
J'ai essayé de régler les paramètres de transfert d'appel et de Hook Flash dans les paramètres VoIP avancés du C590IP, sans succès.
Je n'ai pas trouvé non plus comment désactiver l'interception de la touche R dans Astérisk.
J'ai essayé aussi d'utiliser les Dynamic Features, en configurant une combinaison du style *6, mais dans la CLI, un message indique que cette fonction ne peut être utilisée que sur un canal SIP (et non analogique comme pour l'interphone).

Pouvez-vous m'aider ? Je vous en remercie par avance.
29/07/2012, 13h22
Reaper

Citation:

J'ai essayé de régler les paramètres de transfert d'appel et de Hook Flash dans les paramètres VoIP avancés du C590IP, sans succès.

Bonjour, vous avez un téléphone DECT siemens ? Si c'est la cas la touche R est remplacé par la fonctionnalité de transfert par défaut. vous pouvez changer ce comportement sur l'interface web de la borne.

Si ça ne fonctionne toujours pas, il faut déjà être certain que le flash est bien envoyé par votre borne, et non REFER (transfert)
Pouvez vous le vérifier ?
30/07/2012, 17h59
Gasel

Bonjour Reaper,

La borne est un Siemens C590IP.
Dans les paramètres VoIP avancés, configurés en RFC 2833 (seule case cochée), le champ "Utilisez la touche R pour initier le transfert d'appel avec le protocole SIP" est à non et "Transférer l'appel en raccrochant" à oui.
L'interphone est sur le port FXO DAHDI/2-1 et la réponse se fait sur le port FXS DAHDI/3-1.
Dans le CLI, j'ai les messages suivants (le premier appui sur R se fait à 14:00:49 et j'obtiens la tonalité d'attente, le second appui sur R se fait à 14:00:51 et je récupère le correspondant sur l'interphone) :

Code:

[2012-07-30 14:00:29] VERBOSE[9894] app_dial.c: -- DAHDI/3-1 is ringing [2012-07-30 14:00:31] VERBOSE[9894] app_dial.c: -- DAHDI/3-1 answered DAHDI/2-1 [2012-07-30 14:00:31] VERBOSE[9894] pbx.c: -- Executing [s@macro-auto-blkvm:1] Set("DAHDI/3-1", "__MACRO_RESULT=") in new stack [2012-07-30 14:00:31] VERBOSE[9894] pbx.c: -- Executing [s@macro-auto-blkvm:2] Macro("DAHDI/3-1", "blkvm-clr,") in new stack [2012-07-30 14:00:31] VERBOSE[9894] pbx.c: -- Executing [s@macro-blkvm-clr:1] Set("DAHDI/3-1", "SHARED(BLKVM,DAHDI/2-1)=") in new stack [2012-07-30 14:00:31] VERBOSE[9894] pbx.c: -- Executing [s@macro-blkvm-clr:2] Set("DAHDI/3-1", "GOSUB_RETVAL=") in new stack [2012-07-30 14:00:31] VERBOSE[9894] pbx.c: -- Executing [s@macro-blkvm-clr:3] MacroExit("DAHDI/3-1", "") in new stack [2012-07-30 14:00:31] VERBOSE[9894] pbx.c: -- Executing [s@macro-auto-blkvm:3] ExecIf("DAHDI/3-1", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(num))=3)") in new stack [2012-07-30 14:00:31] VERBOSE[9894] pbx.c: -- Executing [s@macro-auto-blkvm:4] ExecIf("DAHDI/3-1", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=)") in new stack [2012-07-30 14:00:49] VERBOSE[9894] sig_analog.c: -- Started three way call on channel 3 [2012-07-30 14:00:49] VERBOSE[9894] res_musiconhold.c: -- Started music on hold, class 'default', on DAHDI/2-1 [2012-07-30 14:00:49] VERBOSE[9905] sig_analog.c: -- Starting simple switch on 'DAHDI/3-2' [2012-07-30 14:00:51] VERBOSE[9905] sig_analog.c: -- Dumping incomplete call on DAHDI/3-1 [2012-07-30 14:00:51] VERBOSE[9894] res_musiconhold.c: -- Stopped music on hold on DAHDI/2-1 [2012-07-30 14:00:51] VERBOSE[9905] sig_analog.c: -- Hanging up on 'DAHDI/3-2' [2012-07-30 14:00:51] VERBOSE[9905] chan_dahdi.c: -- Hungup 'DAHDI/3-2' [2012-07-30 14:01:02] VERBOSE[9894] pbx.c: -- Executing [h@macro-dial:1] Macro("DAHDI/2-1", "hangupcall") in new stack [2012-07-30 14:01:02] VERBOSE[9894] pbx.c: -- Executing [s@macro-hangupcall:1] GotoIf("DAHDI/2-1", "1?theend") in new stack [2012-07-30 14:01:02] VERBOSE[9894] pbx.c: -- Goto (macro-hangupcall,s,3) [2012-07-30 14:01:02] VERBOSE[9894] pbx.c: -- Executing [s@macro-hangupcall:3] Hangup("DAHDI/2-1", "") in new stack [2012-07-30 14:01:02] VERBOSE[9894] app_macro.c: == Spawn extension (macro-hangupcall, s, 3) exited non-zero on 'DAHDI/2-1' in macro 'hangupcall' [2012-07-30 14:01:02] VERBOSE[9894] features.c: == Spawn extension (macro-dial, h, 1) exited non-zero on 'DAHDI/2-1' [2012-07-30 14:01:02] VERBOSE[9894] sig_analog.c: -- Hanging up on 'DAHDI/3-1' [2012-07-30 14:01:02] VERBOSE[9894] chan_dahdi.c: -- Hungup 'DAHDI/3-1' [2012-07-30 14:01:02] VERBOSE[9894] app_macro.c: == Spawn extension (macro-dial, s, 38) exited non-zero on 'DAHDI/2-1' in macro 'dial' [2012-07-30 14:01:02] VERBOSE[9894] pbx.c: == Spawn extension (ext-group, 602, 13) exited non-zero on 'DAHDI/2-1' [2012-07-30 14:01:02] VERBOSE[9894] sig_analog.c: -- Hanging up on 'DAHDI/2-1' [2012-07-30 14:01:02] VERBOSE[9894] chan_dahdi.c: -- Hungup 'DAHDI/2-1'

Donc, il semble bien que le flash envoyé par la borne est intercepté et traité par la fonction REFER d'Asterisk.

Si je reçois l'appel sur une extension SIP et non DAHDI, le comportement est différent. Il me demande de numéroter une extension pour initier un transfert :

Code:

[2012-07-30 17:31:14] VERBOSE[13025] app_dial.c: -- SIP/33-0000009c is ringing [2012-07-30 17:31:16] VERBOSE[13025] app_dial.c: -- SIP/33-0000009c answered DAHDI/2-1 [2012-07-30 17:31:16] VERBOSE[13025] pbx.c: -- Executing [s@macro-auto-blkvm:1] Set("SIP/33-0000009c", "__MACRO_RESULT=") in new stack [2012-07-30 17:31:16] VERBOSE[13025] pbx.c: -- Executing [s@macro-auto-blkvm:2] Macro("SIP/33-0000009c", "blkvm-clr,") in new stack [2012-07-30 17:31:16] VERBOSE[13025] pbx.c: -- Executing [s@macro-blkvm-clr:1] Set("SIP/33-0000009c", "SHARED(BLKVM,DAHDI/2-1)=") in new stack [2012-07-30 17:31:16] VERBOSE[13025] pbx.c: -- Executing [s@macro-blkvm-clr:2] Set("SIP/33-0000009c", "GOSUB_RETVAL=") in new stack [2012-07-30 17:31:16] VERBOSE[13025] pbx.c: -- Executing [s@macro-blkvm-clr:3] MacroExit("SIP/33-0000009c", "") in new stack [2012-07-30 17:31:16] VERBOSE[13025] pbx.c: -- Executing [s@macro-auto-blkvm:3] ExecIf("SIP/33-0000009c", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(num))=33)") in new stack [2012-07-30 17:31:16] VERBOSE[13025] pbx.c: -- Executing [s@macro-auto-blkvm:4] ExecIf("SIP/33-0000009c", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=Personnel)") in new stack [2012-07-30 17:31:26] NOTICE[13025] res_rtp_asterisk.c: Unknown RTP codec 127 received from '192.168.0.252:5048' [2012-07-30 17:31:26] NOTICE[13025] res_rtp_asterisk.c: Unknown RTP codec 127 received from '192.168.0.252:5048' [2012-07-30 17:31:26] NOTICE[13025] res_rtp_asterisk.c: Unknown RTP codec 127 received from '192.168.0.252:5048' [2012-07-30 17:31:26] NOTICE[13025] res_rtp_asterisk.c: Unknown RTP codec 127 received from '192.168.0.252:5048' [2012-07-30 17:31:26] NOTICE[13025] res_rtp_asterisk.c: Unknown RTP codec 127 received from '192.168.0.252:5048' [2012-07-30 17:31:26] VERBOSE[13025] res_musiconhold.c: -- Started music on hold, class 'default', on DAHDI/2-1 [2012-07-30 17:31:26] VERBOSE[13025] file.c: -- <SIP/33-0000009c> Playing 'pbx-transfer.gsm' (language 'fr') [2012-07-30 17:31:26] NOTICE[13025] res_rtp_asterisk.c: Unknown RTP codec 127 received from '192.168.0.252:5048' [2012-07-30 17:31:26] NOTICE[13025] res_rtp_asterisk.c: Unknown RTP codec 127 received from '192.168.0.252:5048' [2012-07-30 17:31:30] WARNING[13025] features.c: No digits dialed for atxfer. [2012-07-30 17:31:30] VERBOSE[13025] file.c: -- <SIP/33-0000009c> Playing 'pbx-invalid.gsm' (language 'fr') [2012-07-30 17:31:34] VERBOSE[13025] res_musiconhold.c: -- Stopped music on hold on DAHDI/2-1

Mon problème reste entier. J'ai essayé de nombreuses combinaisons sur la borne C590 IP mais il semble qu'Asterisk intercepte systématiquement la touche R.

Comment faire pour changer ce comportement sur l'interface web de la borne ?
31/07/2012, 00h14
Reaper

Bonjour, regarde coté config dahdi ici http://www.voip-info.org/wiki/view/A...han_dahdi.conf

Citation:

; Whether or not to enable call waiting on internal extensions
; With this set to 'yes', busy extensions will hear the call-waiting
; tone, and can use hook-flash to switch between callers. The Dial()
; app will not return the "BUSY" result for extensions.
;
;callwaiting=yes

Citation:

; Support three-way calling
;
;threewaycalling=yes
;
; For FXS ports (either direct analog or over T1/E1):
; Support flash-hook call transfer (requires three way calling)
; Also enables call parking (overrides the 'canpark' parameter)
;
; For digital ports using ISDN PRI protocols:
; Support switch-side transfer (called 2BCT, RLT or other names)
; This setting must be enabled on both ports involved, and the
; 'facilityenable' setting must also be enabled to allow sending
; the transfer to the ISDN switch, since it sent in a FACILITY
; message.
;
;transfer=yes

Regarde cote dynamic feature également.
http://www.mentby.com/Group/asterisk...-asterisk.html configurer un dynamic feature dessus ?
02/08/2012, 08h09
Gasel

Bonjour Reaper,

Léger progrès, puisque je peux envoyer un hook flash, mais Asterisk détecte une erreur et raccroche aussitôt (Ring/Off-hook in strange state 6 on channel 2) :

Code:

[2012-07-31 09:24:03] VERBOSE[30006] app_dial.c: -- DAHDI/3-1 is ringing [2012-07-31 09:24:04] VERBOSE[30006] app_dial.c: -- DAHDI/3-1 answered DAHDI/2-1 [2012-07-31 09:24:04] VERBOSE[30006] pbx.c: -- Executing [s@macro-auto-blkvm:1] Set("DAHDI/3-1", "__MACRO_RESULT=") in new stack [2012-07-31 09:24:04] VERBOSE[30006] pbx.c: -- Executing [s@macro-auto-blkvm:2] Macro("DAHDI/3-1", "blkvm-clr,") in new stack [2012-07-31 09:24:04] VERBOSE[30006] pbx.c: -- Executing [s@macro-blkvm-clr:1] Set("DAHDI/3-1", "SHARED(BLKVM,DAHDI/2-1)=") in new stack [2012-07-31 09:24:04] VERBOSE[30006] pbx.c: -- Executing [s@macro-blkvm-clr:2] Set("DAHDI/3-1", "GOSUB_RETVAL=") in new stack [2012-07-31 09:24:04] VERBOSE[30006] pbx.c: -- Executing [s@macro-blkvm-clr:3] MacroExit("DAHDI/3-1", "") in new stack [2012-07-31 09:24:04] VERBOSE[30006] pbx.c: -- Executing [s@macro-auto-blkvm:3] ExecIf("DAHDI/3-1", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(num))=3)") in new stack [2012-07-31 09:24:04] VERBOSE[30006] pbx.c: -- Executing [s@macro-auto-blkvm:4] ExecIf("DAHDI/3-1", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=)") in new stack [2012-07-31 09:24:15] WARNING[30006] sig_analog.c: Ring/Off-hook in strange state 6 on channel 2 [2012-07-31 09:24:16] VERBOSE[30006] pbx.c: -- Executing [h@macro-dial:1] Macro("DAHDI/2-1", "hangupcall") in new stack [2012-07-31 09:24:16] VERBOSE[30006] pbx.c: -- Executing [s@macro-hangupcall:1] GotoIf("DAHDI/2-1", "1?theend") in new stack [2012-07-31 09:24:16] VERBOSE[30006] pbx.c: -- Goto (macro-hangupcall,s,3) [2012-07-31 09:24:16] VERBOSE[30006] pbx.c: -- Executing [s@macro-hangupcall:3] Hangup("DAHDI/2-1", "") in new stack [2012-07-31 09:24:16] VERBOSE[30006] app_macro.c: == Spawn extension (macro-hangupcall, s, 3) exited non-zero on 'DAHDI/2-1' in macro 'hangupcall' [2012-07-31 09:24:16] VERBOSE[30006] features.c: == Spawn extension (macro-dial, h, 1) exited non-zero on 'DAHDI/2-1' [2012-07-31 09:24:16] VERBOSE[30006] sig_analog.c: -- Hanging up on 'DAHDI/3-1' [2012-07-31 09:24:16] VERBOSE[30006] chan_dahdi.c: -- Hungup 'DAHDI/3-1' [2012-07-31 09:24:16] VERBOSE[30006] app_macro.c: == Spawn extension (macro-dial, s, 38) exited non-zero on 'DAHDI/2-1' in macro 'dial' [2012-07-31 09:24:16] VERBOSE[30006] pbx.c: == Spawn extension (ext-group, 602, 13) exited non-zero on 'DAHDI/2-1' [2012-07-31 09:24:16] VERBOSE[30006] sig_analog.c: -- Hanging up on 'DAHDI/2-1' [2012-07-31 09:24:16] VERBOSE[30006] chan_dahdi.c: -- Hungup 'DAHDI/2-1' [2012-07-31 09:24:17] WARNING[29393] chan_dahdi.c: Detected alarm on channel 2: Red Alarm

Y-aurait-il un moyen d'empêcher Asterisk de raccrocher pour envoyer un second hookflash ?

Pour les dynamic features, je n'arrive pas à capturer la combinaison de touches. Elle figure pourtant bien dans features show :

Code:

# asterisk -rx "features show" Builtin Feature Default Current --------------- ------- ------- Pickup *8 *8 Blind Transfer # ## Attended Transfer A One Touch Monitor *1 Disconnect Call * ** Park Call One Touch MixMonitor Dynamic Feature Default Current --------------- ------- ------- FlashCmd no def *6 Feature Groups: --------------- (none) Call parking (Parking lot: default) ------------ Parking extension : 700 Parking context : parkedcalls Parked call extensions: 701-750 Parkingtime : 45000 ms MusicOnHold class : default Enabled : Yes

Quand je tape *6 en communication, rien ne se passe et rien ne s'affiche dans la CLI...

En tous cas, merci de ton aide !
02/08/2012, 10h41
Reaper

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

Citation:

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,()
02/08/2012, 17h17
Gasel

Bonjour Reaper,

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

Code:

[globals] DYNAMIC_FEATURES=>FlashCmd

dans globals_custom.conf
et

Code:

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

Code:

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

Code:

-- 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 ?
03/08/2012, 15h51
Reaper

[macro-CmdFlash]
exten => s,1,Flash()
exten => s,n,Wait(1)
exten => s,n,Flash()
Fonctionne mieux ?
04/08/2012, 08h50
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 :) ?
27/08/2012, 11h21
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 ...
27/08/2012, 11h58
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...