Soucis détection du raccroché

[tikismoke]

Suite de mon soucis d'ici (http://www.asterisk-france.org/showthread.php/1510-PCI-probleme-tdm410p?p=9983&viewfull=1#post9983)

Donc pour faire simple on dirait qu'Asterisk ne détecte le raccroché coté FXO que lorsque l'on répond coté fxs ou en sip.

Si je ne réponds pas la ligne n'est jamais raccrochée. Pour avoir à nouveau la ligne raccroché, il faut soit que l'appel finisse dans une extension contenant un hangup soit que j'essaie d'initier un appel en sip ou en FXS

Exemple si je réponds en SIP alors que l'appelant à raccroché depuis 30s:


-- Starting simple switch on 'DAHDI/1-1'
-- Executing [s@from-pstn:2] Answer("DAHDI/1-1", "") in new stack
-- Executing [s@from-pstn:3] Wait("DAHDI/1-1", "1") in new stack
-- Executing [s@from-pstn:4] Playback("DAHDI/1-1", "welcome1") in new stack
-- <DAHDI/1-1> Playing 'welcome1.slin' (language 'fr')
-- Executing [s@from-pstn:5] Dial("DAHDI/1-1", "SIP/gtab&SIP/iphone&Dahdi/3,25") in new stack
== Using SIP RTP CoS mark 5
-- Called gtab
== Using SIP RTP CoS mark 5
[2012-01-18 22:10:49] WARNING[7283]: app_dial.c:1747 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown)
-- Called 3
-- DAHDI/3-1 is ringing
-- SIP/gtab-00000000 is ringing
-- DAHDI/3-1 is ringing
-- SIP/gtab-00000000 is ringing
-- DAHDI/3-1 is ringing
-- SIP/gtab-00000000 is ringing
-- DAHDI/3-1 is ringing
-- SIP/gtab-00000000 is ringing
-- DAHDI/3-1 is ringing
-- SIP/gtab-00000000 answered DAHDI/1-1
-- Hungup 'DAHDI/3-1'
-- Executing [h@from-pstn:1] NoOp("DAHDI/1-1", "raccroché") in new stack
== Spawn extension (from-pstn, s, 5) exited non-zero on 'DAHDI/1-1'
-- Hungup 'DAHDI/1-1'

[fastm3]

Part de quelque chose simple et isole bien pour tester le pb:

- Dans ton dialplan , enleve le dial de dahdi/3, mets un timeout enorme pour ne pas etre ennuyé par un raccrochage "timeout".
- enleve le playback.
Teste et verifie que le raccroché se passe bien sur le fxo. Fais tes tests ,configs dahdi sur ce scenario tant que ca ne marche pas.

Note que ensuite pour ce que tu veux faire, il me semblerait plus normal de passer ton welcome a la commande dial histoire de ne pas attendre la fin du message pour commencer a sonner.

Je sens bien un pb pb de detection de raccroché specifique a ton dialplan. On creusera une fois que tu as verifie que ca marche avec le cas le plus simple. ( answer, dial )
Fastm3.

[F6HQZ]

Bonjour,

Attention à la configuration locale (pays/country zone) : si le pays n'est pas le bon, alors les tonalités françaises ne seront pas reconnues et le raccroché ne sera pas détecté.

Cordialement,
Francois

[tikismoke]

Désolé je n'ai pas eu de temps avant maintenant pour reprendre mes essais.

Donc j'ai changé mon dial plan par un truc simple:
Answer
Dial sip

C'est toujours pareil, asterisk garde le FXO ouvert jusqu’à ce que je décroche le sip ou que je refuse l'appel, et du coup la ligne reste occupée.

Starting simple switch on 'DAHDI/1-1'
-- Executing [s@from-pstn:1] Answer("DAHDI/1-1", "") in new stack L'appelant raccroche peu de temps après
-- Executing [s@from-pstn:2] Dial("DAHDI/1-1", "SIP/gtab") in new stack
== Using SIP RTP CoS mark 5
-- Called gtab
-- SIP/gtab-00000007 is ringing
-- Got SIP response 603 "Decline" back from xxx.xxx.xxx.xxx Je refuse l'appel au bout de 2 minutes de sonneries
-- SIP/gtab-00000007 is busy
== Everyone is busy/congested at this time (1:1/0/0)
-- Auto fallthrough, channel 'DAHDI/1-1' status is 'BUSY'
-- Hungup 'DAHDI/1-1'

[tikismoke]

Bonjour,

Attention à la configuration locale (pays/country zone) : si le pays n'est pas le bon, alors les tonalités françaises ne seront pas reconnues et le raccroché ne sera pas détecté.

Cordialement,
Francois

J'ai bien mis fr partout regarde dans le premier sujet.

[tikismoke]

Exemple ou je décroche et l'appelant raccroche en premier, tout va bien.

-- Starting simple switch on 'DAHDI/1-1'
-- Executing [s@from-pstn:1] Answer("DAHDI/1-1", "") in new stack
-- Executing [s@from-pstn:2] Dial("DAHDI/1-1", "SIP/gtab") in new stack
== Using SIP RTP CoS mark 5
-- Called gtab
-- SIP/gtab-00000004 is ringing
-- SIP/gtab-00000004 answered DAHDI/1-1 On discute blablabla puis l'appelant raccroche en premier
== Spawn extension (from-pstn, s, 2) exited non-zero on 'DAHDI/1-1'
-- Hungup 'DAHDI/1-1'

[fastm3]

J'ai bien mis fr partout regarde dans le premier sujet.
Tu n'a jamais confirmé les settings passé au module.
Tu vois bien dans le syslog le register des tone "france" ?
Il faut que je checke ne connaissant plus le message exact.
Le bon coté des choses , c'est que clairement ton 1er scenario est simple et que tu as possibilité maintenant de tester facilement les modifs.
Je te confirme qu'avec la meme carte, la detection de raccroché se passe bien chez moi.
busydetect et busycount semble ne pas etre pris en compte chez toi.
Merci d'indiquer deja le message au chargement du module pour la carte et le contenu de la ligne en parametre passé au module ( /etc/modprobe.d/dahdi )
Fastm3.

[tikismoke]

cat /etc/modprobe.d/dahdi.conf
# You should place any module parameters for your DAHDI modules here
# Example:
#
# options wctdm24xxp latency=6
options wctdm24xxp opermode=FRANCE boostringer=1 fastringer=1


dahdi show channels
Chan Extension Context Language MOH Interpret Blocked State
pseudo default default In Service
1 from-pstn fr default In Service
2 from-pstn fr default In Service
3 from-internal fr default In Service
4 from-internal fr default In Service



Tu vois bien dans le syslog le register des tone "france" ?
Il faut que je checke ne connaissant plus le message exact.
La par contre je ne sais ce que tu veut dire?

Dans tous les cas merci de m'aider.

Je ne comprends vraiment pas pourquoi il faut que je sois en communication pour que le raccrochage soit vu.

[fastm3]

telisk:~# dmesg | grep tone
[ 24.448444] dahdi: Registered tone zone 0 (United States / North America)
[ 24.784145] dahdi: Registered tone zone 2 (France)
telisk:~#
A verifier.

Aussi parce qu'on peut faire pas mal d'erreurs en editant soit meme le fichier des channels. Je te suggere de modifier genconf_parameters, de regenerer ta config dahdi et de l'inclure tel quel plutot que de l'editer toi meme comme tu sembles le faire. Ca ne t'empeche de modifier/ajouter les parametres dans le fichier chan_dahdi.conf

Fastm3.

[tikismoke]

dmesg | grep tone
[196302.113796] dahdi: Registered tone zone 0 (United States / North America)
[196302.222100] dahdi: Registered tone zone 2 (France)
[521929.557626] dahdi: Registered tone zone 0 (United States / North America)
[521929.639958] dahdi: Registered tone zone 2 (France)
[522616.260987] dahdi: Registered tone zone 0 (United States / North America)
[522616.352689] dahdi: Registered tone zone 2 (France)
[525599.874406] dahdi: curzone: ffff88006ee04000, tonezone: 2, curtone: (null), tonep: 0


J'ai bien inclus le dans chandahdi le dahdi.conf comme tu me l'avais dit.

cat /etc/dahdi/genconf_parameters
#
# /etc/dahdi/genconf_parameters
#
# This file contains parameters that affect the
# dahdi_genconf configuration generator.
#
# Syntax:
# * A comment from '#' to end of line
# * Blank lines ignored
# * Whitespace at end of line trimmed
# * Single valued items:
# key <whitespace...> value
# * List valued items:
# key
# <whitespace...>value1
# <whitespace...>value2
# ...
#

# When generating extensions for chan_dahdi.conf or users.conf etc: the
# extension number will be channel_number+base_exten . The default is:
#base_exten 4000
#
# Make FXS (analog phones) extensions answer immediately (sets
# 'immediate = yes' for them in chan_dahdi.conf). Don't enable this before
# you're read documentation about this option.
#fxs_immediate yes
#
# For FXS (analog phones) - use KS or LS? ks is the only method for
# Asterisk to provide disconnect supervision and thus it would normally
# be preferred and is the default.
#fxs_default_start ls
#
# For FXO (analog lines) - use KS or LS? KS is the default and is
# normally the better choice as it allows detecting hang-ups on many
# lines.
#fxo_default_start ls

# Set tone zone values. This is used for playing tones (busy, dial-tone
# and such). The default is 'us'. This sets the value for both loadzone
# and defaultzone in system.conf .
lc_country fr

# The dialplan context into which to send trunks in chan_dahdi.conf or
# users.conf. The default value is:
context_lines from-pstn
#
# The dialplan context into which to send extensions in chan_dahdi.conf or
# users.conf. The default value is:
context_phones from-internal
#
# Two extra contexts for the input ports and output ports of an
# Astribank. Default values are:
#context_input astbank-input
#context_output astbank-output

# A group to put all analog phones in. By default 0, so you can dial to
# the 'first phone available' using Dahdi/g5 .
#group_phones 5
#
# A group in which to put all the channels belonging to some trunk.
# Thus you can dial through "some trunk" using Dahdi/G0/NUMBER
#group_lines 0

# Channels of digital trunk of span N are also added to group 10+N (that
# is: 14 for channels of span 4).

# Do we want to use PtP ('bri') or PtMP ('bri_ptmp') for BRI? PtMP
# allows connecting several CPE devices on the same network device
# (several BRI phones on the same line, kind of like several analog
# phones on the same analog line). However it is generally brings
# unnecessary complexity for a pbx-pbx connection. It is still the
# default as this is normally what you get for a BRI PSTN connection.
#bri_sig_style bri
#
# If this option is set (that is: not remmed-out), BRI NT ports will
# also be set as overlap. This is useful if you want to connect ISDN
# phones.
#brint_overlap

# The echo canceler to use. If you have a hardware echo canceler, just
# leave it be, as this one won't be used anyway.
#
# The default is mg2, but it may change in the future. E.g: a packager
# that bundles a better echo canceler may set it as the default, or
# dahdi_genconf will scan for the "best" echo canceler.
#
#echo_can hpec
echo_can oslec
#echo_can none # to avoid echo canceler altogether

# bri_hardhdlc:
# 'yes' - forces BRI cards to use 'hardhdlc' signalling.
# 'no' - forces BRI cards to use 'dchan' (an alias for 'fcshdlc').
# It is usefull only for dahdi with the bristuff patch.
#
# If it is left out or set to 'auto':
# * Information supplied by the driver is used to decide:
# - Currently implemented for Astribanks.
# - Taken from /sys/bus/xpds/drivers/bri/dchan_hardhdlc.
# * Without this info, falls back to 'hardhdlc'.
#bri_hardhdlc auto

# For MFC/R2 Support: 'R2' will make E1 spans CAS and with the
# 'r2_idle_bits' bit in system.conf . It will also make dahdi_genconf default
# to generating the channels of this card in unicall.conf rather than in
# chan_dahdi.conf . The meaning of this may be extended somehow to support
# R2 through openr2/chan_dahdi later on.
#pri_connection_type R2
#pri_connection_type CAS
#
# Explicitly set the idle bits for E1 CAS (Sample value is the default):
#r2_idle_bits 1101
#
# Set T1 framing type to d4 instead of esf:
#tdm_framing d4
#
# Use E&M on CAS (default is FXS/FXO). If set, E1 spans will be used as
# E&M-E1 and T1 will use the requested type:
#em_signalling em
#em_signalling em_w
#em_signalling featd
#em_signalling featdtmf
#em_signalling featdtmf_ta
#em_signalling featb
#em_signalling fgccama
#em_signalling fgccamamf
#
# pri_termtype contains a list of settings:
# Currently the only setting is for TE or NT (the default is TE). This
# sets two different but normally related configuration items:
#
# A TE span will have *_cpe signalling in Asterisk and will also get
# timing from the remote party.
#
# A NT span will have *_new signalling in Asterisk and will provide
# timing to the remote party.
#
# pri_termtype is a list if span specs and configuration (TE/NT) for
# them. The first spec that matches is used. The matching is of perl
# regular expressions, but with '*' and '?' have their meaning from
# basic regular expressions.
#pri_termtype
# SPAN/2 NT
# SPAN/4 NT
#
#pri_termtype
# SPAN/* NT
#
# Astribanks can be matched by span and also by their:
# LABEL + XPD number:
# this is burned into the Astribank and won't change
# if it's connected via different USB port/hub
# CONNECTOR + XPD number:
# The USB path to which the Astribank is connected.
# Replacing an Astribank and connecting to the same USB port/hub
# would not change this property. However, any change in USB
# wiring (e.g: adding another hub) may alter this.
# NUM (XBUS number) + XPD number:
# The XBUS number. This is not stable and may even change
# between boots.
#
#pri_termtype
# LABEL/usb:INT01216/XPD-0[123] NT
# LABEL/usb:INT00375/XPD-0[123] NT
# CONNECTOR/@usb-0000:00:1d.7-1/XPD-0[123] NT
# CONNECTOR/@usb-0000:00:1d.7-2/XPD-0[123] NT
# NUM/XBUS-01/XPD-0[123] NT
# NUM/XBUS-03/XPD-0[123] NT


cat /etc/asterisk/chan_dahdi.conf
[channels]
language=fr
switchtype=euroisdn
;#signalling=bri_cpe
signalling = bri_cpe_ptmp
pridialplan=unknown
prilocaldialplan=unknown
;pridialplan=local
;prilocaldialplan = dynamic
nationalprefix=0
internationalprefix=00
priindication=outofband
faxdetect=both
overlapdial=yes
immediate=no
resetinterval=never
usecallingpres=yes
echocancel=512
;echotraining=400
language=fr
loadzone=fr
defaultzone=fr
progzone=fr

dtmfmode=inband
toneduration=300
relaxdtmf=yes
busydetect=yes
busycount=3
txgain=10
rxgain=8

;# Flash Operator Panel will parse this file for dahdi trunk buttons
;# AMPLABEL will be used for the display labels on the buttons

;# %c Dahdi Channel number
;# %n Line number
;# %N Line number, but restart counter
;# Example:
;# ;A_MPLABEL:Channel %c - Button %n

;# For Dahdi/* buttons use the following
;# (where x=number of buttons to dislpay)
;# ;A_MPWILDCARDLABEL(x):MyLabel


; include dahdi extensions defined in FreePBX
;#include chan_dahdi_additional.conf


; genere par genconf
#include dahdi-channels.conf

Au passage le fxotune -i fonctionne bien sur les 2 fxo contrairement à ce que j'avais l'autre jour sur le port freebox.


dahdi show channel 1
Channel: 1
File Descriptor: 22
Span: 1
Extension:
Dialing: no
Context: from-pstn
Caller ID:
Calling TON: 0
Caller ID name:
Mailbox: none
Destroy: 0
InAlarm: 0
Signalling Type: FXS Kewlstart
Radio: 0
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Busy Detection: yes
Busy Count: 3
Busy Pattern: 0,0
TDD: no
Relax DTMF: yes
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
DND: no
Echo Cancellation:
512 taps
(unless TDM bridged) currently OFF
Wait for dialtone: 0ms
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Offhook

[tikismoke]

Un nouvel essai me montre que lorsque l'appel arrive dans un dialplan de type WaitExten() et que l'appelant à raccroché celui-ci est bien vue pendant la période d'attente.
Sans passé en timeout de la commande waitexten.

Pour l'instant le raccrochage est vu lorsque l'on est en communication ou si asterisk attend un dtmf.

[tikismoke]

Du coup personne n'a d'idée?

Je tourne pas mal en rond.

Dans tout les cas si je dépasse 7 en txgain ou rxgain ça claque un sifflement monstrueux type larsen dans les oreilles de l'appelant et de l'appelé (même à 200km d'écart :frown: ).

[fastm3]

Humm, j'avais décroché. ;)

Ce que je vois dans ton dahdi show channel, c'est une cadence à 0,0.
Je n'ai pas la meme version que toi ( vieille version de dahdi ) et donc cela n'apparait pas chez moi.
Mais c'est clair que cela n'est pas normal à mon avis, tu devrais voir 500,500.
Peut etre une piste à creuser.
Il existe quelques flags de compil de dahdi qui permettent de voir un peu plus ce qui se passe, va voir chan_dahdi.c .

Autre solution ou plutot aide au diagnostic. Enregistre le channel avec le dialplan ( bon exercice ) , cela te permettra d'ecouter si aprés le racroché, FT envoie bien la bonne tonalité histoire de voir si ca ne serait pas un pb de ligne au lieu d'un pb de detection.

J'ai une vieille version patchée de dahdi que j'utilise tout le temps car ultra stable. Eventuellement, je peux te fournir mon trunk mais creuse deja pourquoi tu n'as pas ta cadence settée a 500,500.

Regarde aussi bien le /var/log/asterisk/full qui contient souvent des infos interessantes.

Fastm3.

[tikismoke]

Désolé de ne reprendre mes tests que maintenant. (Ma nouvelle vie de père de famille perturbe un peu beaucoup mon coté Geek)

J'ai le soucis que ce soit sur la ligne free ou france telecom.

Ce qui me perturbe énormément c'est de ne pas comprendre pourquoi un raccrochage durant une conversation ou un voicemail fonctionne correctement et pas dans un IVR ou pendant un playback.

Asterisk poursuit l'extension mal grès la tonalité de raccroché (qu'il interprète correctement lorsque l'appelant laisse un message ou lors d'une conversation ce qui est déjà mieux). En gros pour le moment ce qui me gène le plus c'est par exemple un erreur de numéro qui fait sonner mon téléphone.

Je poursuis mes investigations mais c'est déprimant.

[fastm3]

Tu as enregistré et tu as bien la tonalité de racroché pendant le playback ?
J'ai la meme carte et je n'ai pas de soucis. Peut etre un pb de ta version de dadhi ?
J'ai une vieille version custo a partir de dahdi 2.2.1. Tu peux recompiler un dahdi de cette branche ?
Si je trouve le temps, j'essaierai de faire un tar de mon source tree ok avec la meme carte et sur lequel j'ai teste la detection raccroché.
Fastm3.

[fastm3]

autre idee plus rapide , recompile juste avec BUSYDETECT_DEBUG
Fastm3.

[tikismoke]

J'ai enregister converti et regarder avec audacity je poste le mp3 demain si vous y voyez un soucis. Jai bien la tonalite raccroche d'enregistrer et pourtant asterisk ne le voie pas.

[tikismoke]

Ca avance, en fait il semblerait qu'il y a des trou lorsque mon téléphone sonne, comme si le fait de sonner à l'intérieur coupait les sonneries externes.

Par contre je n'ai pas pu ajouter le fichier en pièce jointes:


Coté entrant (http://www.2shared.com/file/J596ghvX/myfilename-in.html)

Coté sortant (http://www.2shared.com/audio/ndOhOr4z/myfilename-out.html) avec mon super message d’accueil.

Les trou dans le son de la tonalité raccroché correspondent à la sonnerie disponible de mon téléphone.

C'est bizarre tout de même.

[fastm3]

C'est effectivement curieux que la tonalité s'arrete.
Pb d'alim ? Une idée, tu as essayé sans utiliser les fxs ( pas de dial sur les fxs dans ton dialplan et pas de tel branché dessus )
C'est une ligne de box ?
Fastm3.

[tikismoke]

C'est effectivement curieux que la tonalité s'arrete.
Pb d'alim ? Une idée, tu as essayé sans utiliser les fxs ( pas de dial sur les fxs dans ton dialplan et pas de tel branché dessus )
C'est une ligne de box ?
Fastm3.

Je refai quelques test le we prochain. De memoire sans telephone je n'ai pas essayé.

Le souci apparait sur les deux lignes. Ici c'est un appel d'un demarcheur qur la ligne ft.

[tikismoke]

J'ai essayer:
-Le dial en sip uniquement coté interne, même résultat
-Enlever les fxs de la conf de dahdi idem.

Demain j'essaye en changeant de fxs pour passer sur le 4 et si j'ai le temps sans module physique du tout sur la carte pour voir.

Si quelqu'un à d'autres idées je suis preneur. On dirait que tant que je n'ai pas décroché il y a un mix entre fxo-fxs à chaque fois que la sonnerie retentit sur le téléphone branché au fxs.

Actuellement seul l'appel tout sip détecte bien le raccrochage.

[tikismoke]

3 mois après je n'ai toujours pas trouvé de solution miracle.

Et en plus pendant les soldes il n'y a pas de DECT SIP en promo :(

[fastm3]

Juste pour résumé, si tu décroches et que ensuite le correspondant raccroche, pas de soucis. Le racrochage externe est bien detecté ? Le pb est juste quant on ne decroche pas de ton coté.
Si oui, je pense que j'ai un "workaround" pour toi.

Dans ton contexte dahdi de reception d'appel, ne mets pas de answer ( important ) mais un dial avec une musique d'attente qui sera ton message. Fonctionnellement, ca sera pareil mais je pense que ca devrait aider.
Dis moi si c'est ok.
Fastm3.

[tikismoke]

Juste pour résumé, si tu décroches et que ensuite le correspondant raccroche, pas de soucis. Le racrochage externe est bien detecté ? Le pb est juste quant on ne decroche pas de ton coté.
Si oui, je pense que j'ai un "workaround" pour toi.

Dans ton contexte dahdi de reception d'appel, ne mets pas de answer ( important ) mais un dial avec une musique d'attente qui sera ton message. Fonctionnellement, ca sera pareil mais je pense que ca devrait aider.
Dis moi si c'est ok.
Fastm3.

C'est très bien résumé et en plus ton astuce fonctionne.

Génial je vais pouvoir avancer un peu et arrêter de ma faire appeler arthur :) Comme ça c'est beaucoup plus WAF.
Oui un message d'acceuil ça supprime beaucoup de téléconseiller et du coup ceux-ci raccrochaient.

[fastm3]

C'est très bien résumé et en plus ton astuce fonctionne.

YES !!
Pfff, bravo pour ta perseverance. Bcp aurait abandonné.
Mais bon, oui, ca doit etre un bug de ma carte ou asterisk. Pas le temps de creuser, vu que le workaround est ok
Jamais vu car toujours un dial pour moi. Je l'ai reproduit par hasard et j'ai alors percuté et pensé à toi.
Cheers !!!!!!!!!
Fastm3.

[tikismoke]

YES !!
Pfff, bravo pour ta perseverance. Bcp aurait abandonné.
Fastm3.

Faut dire que bébé grandit, donc on commence à avoir plus de temps :)

Donc la persévérance étant là voilà ou j'en suis:

Si je mets un playback ou un backgrond avant le dial je réitère le même souci.

Je n'ai pas essayé avec musiconhold.

[fastm3]

ben oui, il y a semble t'il un bug...
Comme tu sais que tu n'as pas de soucis avec le dial + moh en premier, utilise ca, non ?
A tester, si apres , un timeout du dial et avec background ou playback , cela fonctionne toujours mais tu as les billes desormais, je pense, pour ecrire un dialplan qui ne perturbe pas la detection du raccroché.
Fastm3.