[WORKAROUND] Willkürliche DTMF Töne in Gesprächen (tlw. talkoff)

[HobbyStern]

Ich hole es nochmals aus dem keller --> Wer sich mit diesem Problem (ungewollte DTMF Töne in Gesprächen) noch rumschlägt - der mache doch bitte einmal mit :

System-HW
Kernel-Vers
Asterisk-Vers
Zaptel?-Vers
ISDN-Treiber+Vers
MusiconHold+Vers
Extras?
Logfile DTMF+passend zum DTMF Ton das Verbose ggf. einen echten DEBUG

Es wäre nett von euch wenn wir das ein bisschen zusammenpacken könnten, ich würde dem ganzen langsam wirklich gerne mal den Gar aus machen.

System-HW
- Asus Board mit 3.0GhzAthlonXP, 512MB, Digium Wildcard TDM40B, 2 x HFC ISDN PCI von Acer
Kernel-Vers
- 2.6.15-1 (AMD)
Asterisk-Vers
- 1.2.12.1
Zaptel?-Vers
- 1.2.9
ISDN-Treiber+Vers
- mISDN 0.3.1 RC23
MusiconHold+Vers
- madplay in 0.15.2b-3.1
Extras?
- die DIGIUM Karte halt, ansonsten noch eine MySQL DB+Apache, das wars auch schon
Logfile DTMF+passend zum DTMF Ton das Verbose ggf. einen echten DEBUG

DTMF Log

Nov  6 10:07:52 DTMF[23133] channel.c: SIP/pbx1-0827ee10 : *
Nov  6 10:14:42 DTMF[23288] channel.c: mISDN/2-1 : 8

Verbose meldet nur das ein DTMF Signalisiert wurde und zB bei "*"
das der "Bridgen des Kanals" gescheitert ist ?! Wie dem auch sei, nach einem Sternchen ist das Gespräch fakto beendet und das NERVT!

Sip Debugging hat schon etwas mehr gebracht :

Nov  6 10:35:54 DEBUG[23792] channel.c: Got DTMF on channel  (SIP/40-0825b3c8) 
Nov  6 10:35:54 DEBUG[23792] channel.c: Bridge stops bridging channels  SIP/40-0825b3c8 and SIP/pbx1-08273ef8 
Nov  6 10:35:54 DEBUG[23792] res_features.c: Feature interpret:  chan=SIP/40-0825b3c8, peer=SIP/pbx1-08273ef8, sense=1, features=18 
Nov  6 10:35:54 DEBUG[23792] res_features.c: Set time limit to 500      Nov  6 10:35:55 DEBUG[23792] channel.c: Nobody there, continuing...       Nov  6 10:35:58 DEBUG[23792] channel.c: Bridge stops because we're  zombie or need a soft hangup: c0=SIP/40-0825b3c8, c1=SIP/pbx1-08273ef8,  flags: No,Yes,No,No 
Nov  6 10:35:58 DEBUG[23792] channel.c: Bridge stops bridging channels  SIP/40-0825b3c8 and SIP/pbx1-08273ef8 
Nov  6 10:35:58 DEBUG[23792] res_features.c: Timed out for feature!         Nov  6 10:35:58 DEBUG[23792] channel.c: Hanging up channel  'SIP/pbx1-08273ef8' 
Nov  6 10:35:58 DEBUG[23792] chan_sip.c: Hangup call SIP/pbx1-08273ef8,  SIP callid [EMAIL="[email protected]"][email protected][/EMAIL]) 
Nov  6 10:35:58 DEBUG[23792] chan_sip.c:  update_call_counter(02088480499) - decrement call limit counter 
Nov  6 10:35:58 DEBUG[23792] app_dial.c: Exiting with DIALSTATUS=ANSWER. 
Nov  6 10:35:58 DEBUG[23792] pbx.c: Spawn extension (voip_wahl,_X.,6)  exited non-zero on 'SIP/40-0825b3c8'

Man beachte "DTMF" ..

ich hoffe das hier noch mehrere dieses Prozedre schreiben können !

Grüsse, Stefan

 

[HobbyStern]

Geben wir dem Problem einen Namen : TALKOFF

Nachtrag :

Infos, Infos, Infos für die Leute die hier ggf. Folgen :

Geben wir dem Problem einen Namen : TALKOFF

Some more info:

TALKOFF is the wrong recognition of DTMF component in human voice as
true DTMF signal. This is an unavoidable factor since human voice always
contain valid DTMF combination. Fortunately, presence of these valid
DTMF components are unsteady. Unlike real DTMF generated from a
touch-tone keyboard, these 'human' DTMF cannot maintain on a constant
combination. So they can be isolated by DELAY discrimination. If a
decoded DTMF signal can stay on constantly for certain duration which
exceed those normal period experienced in human voice, then it can be
identified as a real DTMF command.

Geben wir diesen Namen in Google ein wirds interessant :

http://www.dslreports.com/forum/remark,9151528 (Definitionsthread TALKOFF)


Eine Lösung :
http://www.asteriskguru.com/archives/view-next-topic-vt73692.html?view=next

This hit it right on the head - the tdm card was sharing irq with the
nvidia and yukon lan adapters. What a pain it was to get them off - had
to trial and error the position of my raid card and tdm card and disable
everything. I think its fine now, could not reproduce the problem
tonight. To anyone experiencing issues like this make sure you check
irq sharing. I have been dealing with this for quite some time, and
getting the tdm card on its own irq, it is now working correctly and
quietly on an ASUS mobo.

Thanks again guys!!!!!!!!!!!!!!!

Eine weitere (einfache) Lösung :

relaxdtmf=no (Standard) setzen, anscheinedn hatte der Herr yes gesetzt ?! :?

Ein Workaround :

dtmfthreshold=<0-4000> (je höher , desto weniger DTMF wird genommen)


Aber dann hörts auch schon wieder auf...

 

[HobbyStern]

Es geht weiter, weitere lösungsansätze sind :

Versuch:
DTMF Modus von RFC2833 auf INBAND ändern, Info ist auch eine gute Idee, jedoch inkompatibel mit dem Asterisk Voicemail System und daher für mich unbrauchbar.

Erfolg :
Unwahrscheinlich bei mir, da ja auch ZAP und mISDN Kanäle btroffen sind ist es recht unwahrscheinlich das ich Abhilfe durch das Ändern des Modusses der SIP Kanäle besorgen kann ... also, Idee beiseite.

Versuch:
Hardware probleme ausschliessen, s.h. nachprüfen ob Karten denselben IRQ belegen, das kann recht schnell passieren (gerade ASUS liest man in diesem Zusammenhang oft) wenn Karten auf einem geteilten Slot eingesetzt werden.
Bei mir ist genau dies der Fall - und wie der Teufel es will ist die "ZAPKarte" mit einer meiner HFC Karten auf einem Bereich (IRQ193) ...
(Herauszufinden mit lspci -v)

Erfolg:
Abzuwarten, heute Abend nach Feierabend wird getauscht.

Soweit....
Grüsse, Stefan

 

[HobbyStern]

Auch der Tausch der doppelt belegten IRQs (geteilte PCI Steckplätze - bei mir warens 1&5 und 2&6) hat nicht geholfen.

Weiterhin bemerkt mein Logfile fleissig auftretende DTMF Töne

Ich habe in der *-Mailingliste nach Rat gesucht, allerdings wird dort nur auf talkoff verwiesen und auf eben den o.g. dtmfthreshold..was mich nicht wirklich weiter bringt.

Hat jemand Rat ? Ideen ? Erfahrung ?

 

[HobbyStern]

DIE Lösung ist die DTMF Schwelle anzuheben, s.h. die Schwelle ab welcher Asterisk einen DTMF Ton erkennt.

Haken an der Sache, das ganze kann man mW nur unter mISDN und Zaptel - bei zweiterem ist es auch nicht machbar da die Variable schlichtweg fehlt, in mISDN setzt man in die misdn-init.conf ein dtmftreshold=xyz (0-400) ein und die Sache ist ausgestanden, jedoch hilft das nicht bei SIP/IAX/ZAP Kanälen.

Grüsse, Stefan

 

[tomster]

Hmm... Hab dein Problem eigentlich bislang nicht nachvollziehen können, und es beflissentlich überlesen. Aber ich hab neulich auch diese Erfahrung gemacht. Ebenfalls mit einer FBF. Allerdings nur mit 1 von insgesamt 3, die am Asterisk angemeldet sind. Und diese eine ist gerade die, an der nur ein analoges Telefon angeschlossen ist weil FBF 7140SL. Das angeschlossene Telefon ist ein relativ schwindliges Siemens Gigaset A110. Bei dem kann man natürlich gar nix einstellen, vor allem im Bezug auf DTMF-Verhalten.
Ich werde am WE vielleicht Mal ein anderes analoges Telefon mitnehmen und es mit dem Probieren (ist die FBF in unserer Skihütte). Ausserdem warte ich noch auf mein Austauschgerät, weil ich eigentlich eine FBF 7140 (ohne SL) bestellt hatte.

Bei den 2 anderen FBF's (7170) gibt es diese DTMF-Töne gar nicht. Gespräche sind einwandfrei.

Ich berichte dir, was sich ergibt

 

[HobbyStern]

Hi,

mein ganzes Workaround hat es mir hier ermöglicht das Problem eigentlich als erledigt zu betrachten, es sind weder DTMF Töne zu hören - noch zu loggen, von daher mache ich drei dicke Kreuze, ich glaube wir haben uns schoneinmal über die Meinung(en) zu FBF'en ausgetippt ( ) - wie dem auch sei - wenn es nur eine ist kannst Du ja ggf. für die Nachwelt etwas herausfiltern warum dem so ist, es ist schon seltsam und für mich als "Hobby TK Anlagenbauer" schwer nachzuvollziehen inwiefern talkoff soetwas erzeugen kann und inwiefern es ggf. an verwandter Hardware liegt.

Achja :

Hab ich dein Problem eigentlich bislang [...] beflissentlich überlesen

:lach: Irgendwann kriegt´s jeden mal :lach:

Grüsse, Stefan

 

[tomster]

Nun ja, dass sich das Problem erledigt hat, hab ich ehrlich gesagt nicht herausgelesen.

..jedoch hilft das nicht bei SIP/IAX/ZAP Kanälen..

Aber ich muss ehrlich gestehen, dass ich jetzt gar nicht mehr weiß, ob das Problem nicht wirklich ausschließlich bei Verbindungen aufgetreten ist, die zwar SIP-mäßig von der FBF auf den Asterisk gestartet, letztendlich aber von letzterem via mISDN terminiert wurden. Ich klatsch gleich Mal den "dtmftreshold=yxz" (meinen Englischkenntnissen nach fehlt da ein "h" nach dem 2. "t") rein. Schaun mer Mal, sagt der Kaiser.

So long
TOM

 

[HobbyStern]

Gute Englischkenntnisse - das fehlende "h" hatte ich auch schon bei crich bemerkt - Antwort war in etwa so das der code schon greschrieben ist..

Zurück zum Thema.
Das Problem hatte sich insofern nicht gänzlich erledigt - insofern ich es immernoch beobachte - da ich ja eigentlich immer noch das workaround betreibe..jedoch wie geschrieben, seit einiger Zeit ist es nicht mehr reproduzierbar.

Ggf. kannst Du Deine Beobachtungen mal einbringen..

Grüsse, Stefan

 

[fant]

Ich habe das Problem auch bei IAX-Verbindungen, ISDN (Zaptel-NT und CAPI) und SIP gehabt. Es zieht sich durch alle Dienste.

Die Tips von HobbyStern habe ich aber noch nicht umgesetzt. Bin z.Z. ein wenig im Stress...

Hawedieehre.
Fant

 

[jackfritt]

Hier mal ein log wie es bei 1.4.2 aussieht. Da steht immerhin noch die länge drin.
Unten dann wieder 1.2.17.

[Apr 17 09:54:13] DTMF[25291] channel.c: DTMF end '9' received on SIP/19-b67bb788, duration 4122880 ms
[Apr 17 09:54:13] DTMF[25291] channel.c: DTMF end '8' received on SIP/19-b67bb788, duration 160 ms
[Apr 17 09:54:14] DTMF[25291] channel.c: DTMF end '0' received on SIP/19-b67bb788, duration 160 ms
[Apr 17 09:54:15] DTMF[25291] channel.c: DTMF end '4' received on SIP/19-b67bb788, duration 160 ms
[Apr 17 09:54:16] DTMF[25291] channel.c: DTMF end '7' received on SIP/19-b67bb788, duration 160 ms
[Apr 17 09:54:17] DTMF[25291] channel.c: DTMF end '7' received on SIP/19-b67bb788, duration 160 ms
[Apr 17 10:52:55] DTMF[957] channel.c: DTMF end '5' received on mISDN/2-u1, duration 0 ms
[Apr 17 10:59:36] DTMF[1852] channel.c: DTMF end '*' received on mISDN/8-u3, duration 0 ms
[Apr 17 11:00:13] DTMF[1852] channel.c: DTMF end '2' received on mISDN/8-u3, duration 0 ms
[Apr 17 11:00:13] DTMF[1852] channel.c: DTMF end '2' received on mISDN/8-u3, duration 0 ms
[Apr 17 11:01:28] DTMF[5800] channel.c: DTMF end '9' received on mISDN/8-u3, duration 0 ms
[Apr 17 11:03:20] DTMF[17275] channel.c: DTMF end '9' received on mISDN/1-u9, duration 0 ms
[Apr 17 11:03:51] DTMF[17275] channel.c: DTMF end '9' received on mISDN/1-u9, duration 0 ms
[Apr 17 11:57:33] DTMF[15891] channel.c: DTMF end '4' received on mISDN/3-u45, duration 0 ms
Apr 17 13:34:43 DTMF[6708] channel.c: SIP/21-0839de78 : A
Apr 17 13:34:59 DTMF[6815] channel.c: SIP/12-0831f0b8 : 1
Apr 17 13:35:06 DTMF[6815] channel.c: SIP/12-0831f0b8 : 1

Gruss,

Jörg

 

[HobbyStern]

Naja, gut, anhand der Länge lässt sich ggf. ausmachen wer das Ding gesandt hat ....

Ist das "*" denn "gewollt ?

Grüsse, Stefan

 

[jackfritt]

dtmf ist bei uns überhaupt nicht gewollt. Wir machen GAR nix damit. Noch nich mal die T-Box steuern. Also ich kann behaupten das mit 90% Sicherheit niemand auf irgendeine Taste drückt. Weder auf Kundenseite (misdn) noch auf Firmenseite (SIP)

Ich denke das das aus Asterisk selbst kommt. Das hat weniger mit misdn etc. zu tun. Denn es ist ja auf beiden channels sporadisch zu sehen. Heute morgen hatte ich auch schon wieder 2 * auf der SIP Seite.Gut das es keine Funktion hat


Gruss,

Jörg

 

[HobbyStern]

Das die Funktionalität "tot" ist, ist dann wirlich ein Segen.

Wie magst Du weiter vorgehen ?

Ich kann bis heute - nach all dem ganzen Gesuche - immer noch nichts verwertbares in Richtung "Die Lösung" vorweisen - und ich habe darin viel Zeit investiert.

Sicher ist allerdings das Du es softwaretechnisch nicht beheben kannst, jedenfalls ist mir in dieser Weise keine vollkommene Lösung bekannt, man kann es minimieren, ja, mehr aber mW nicht.

Schön wäre wenn Du auch etwas von Deinem System und den Komponenten schreiben könntest, ggf. finden wir so mal langsa mehr Gemeinsamkeiten...:

Das Workaround sieht so aus :

-> System (AstVersion, Zaptel?, ISDN (Bri/misdn?)?, Hardware (grob))

-> Loggen der DTMF Töne
-> logger.conf um "<dateinamenachbelieben> => verbose" bereichern
-> Bekanntgeben des Codecs
-> Bekanntgeben der Signalisierung (inband/outband/rfc)
-> Auswerten des Logs
-> Auf welchem Kanal tritt es aus ?
-> Was passiert dann auf der Asterisk CLI ?

Es wäre eine grosse Hilfe das ganze mal von mehreren Leuten zu erfahren !

Möglich wäre natürlich auch das es bei euch sehr hohe Stimmen gibt, die können ggf. einen DTMF Ton auslösen, allerdings wäre es ein reiner Zufall das auf allen Kanälen und dauernd zu erleben.

Schreib mal was Du Dir vorgenommen hast / was Du überhaupt tun willst...

Grüsse, Stefan

 

[jackfritt]

System-HW
AMD Athlon(tm) XP 2800+ nForce2 Chipsatz

Kernel-Vers
Linux version 2.6.18-rc4
Asterisk-Vers
1.2.17 u. 1.4.2
ISDN-Treiber+Vers
misdn-1.1.2, chan-misdn RC21-30, chan-misdn für 1.4.2
MusiconHold+Vers
Musiconhold über madplay


Hohe Stimmen könnten dazu beitragen. Unsere Sekretärin weiss schon bescheid. Einige Mitarbeiter berichten Sie hätten keine Töne gehört obwohl
im LOG ein DTMF steht. Komisch oder ? Also evtl sind die Töne dann so kurz
oder es ist gar keiner aufgetreten. Ich lasse auf jeden Fall heute mal das DTMF log offen und frage direkt mal jeden Mitarbeiter ob er Töne gehört hat.

Das Dumme ist. Ich brauche das irgendwann mal. Und ich habe schonmal mit
dtmfmode=
rumgespielt. Allerdings verstehe ich nich so recht wo man das überall reinschreiben muss damit es einheitlich funktioniert. Denn in misdn.conf
ist es nicht erlaubt.

Ich denke da is von Entwicklerseite noch einiges zu tun.

Übrigens ist es bei mir so, das im LOG nicht das Telefon gemeint ist was den TON produziert sondern das Telefon was den DTMF TON erkennt. (Ok asterisk erkennt das )

Wenn sich bei mir 2 Personen über SIP Telefone unterhalten und jemand erzeugt einen DTMF Ton dann wird dieser auf der anderen Seite abgeschnitten und nur ganz kurz gehört. Also lange DTMF Töne werden einfach abgeschnitten immer auf die gleiche länge. ("Gehörtechnisch" gesprochen.)

Leider bekomme ich die Töne nicht bei misdn raus. Aber Asterisk reagiert schon darauf. Nur bei der Gegenstelle hört man nix.

Ich werde auf jeden Fall weiter am Ball bleiben. Aber leider ist zzt. pickup meine Hauptbaustelle


Gruss,

Jörg

 

[fant]

Bei mir hier tritt das Problem immer wieder sogar bei völliger Stille auf. Ich dachte auch, daß vielleicht der Anrufer DTMF-Töne singt, aber das ist mal wieder nicht reproduzierbar.

Ich nutze dummerweise die Raute zur Weiterleitung, habe also immer mal wieder komische Effekte.

Hawedieehre.
Fant

(habe heute dicke Finger...;-))

 

[HobbyStern]

Schön das man nicht alleine ist, nicht wahr ?!

Einige Mitarbeiter berichten Sie hätten keine Töne gehört obwohl
im LOG ein DTMF steht.

Es ist auch hier so das ich eigentlich die produzierten Töne selten höre, ich denke das es darauf ankommt wo diese entstehen.

Interessant ist das Du auch einen AMD nutzt, das würde meine These untermauern das es damit etwas zu tun hat - der "Ami" mit dem DTMF Problem berichtete das er auf seinem Testsystem mit exakt gleichem Aufbau, allerdings ein P4, diese Töne nicht registrieren könne.

Mit den dtmfmode habe ich zu Anfang "gespielt", es ist jedoch keine wesentliche besserung aufgetreten, auch der codec scheint belanglos zu sein, mit alaw und rfc2833 lebt es sich IMHO am besten.

Unter mISDN kann man die dtmfthreshold Variable nutzen um die Erkennung zu drosseln, ein Wert von 400 hat hier den mISDN Kanal aus dem "Logger" genommen, was soviel heissen soll wie : "mISDN wird nicht mehr als DTMF Störenfried angezeigt".

Unter Zaptel wäre dies auch möglich, allerdings ist die "Variable" dort nicht variabel sondern im Code versteckt und für mich nicht variierbar.

@fant

Nutzt Du auch einen AMD ? Welchen MOH Player hast Du bei Dir im Einsatz ?
(Ich hatte ganz vergessen das wir schon einmal "dieEhrehatten" :lach: darüber zu diskutieren...)

Ich weiss ehrlich gesagt nicht wirklich mehr wo ich die Suche beginnen soll.

Google hilft mit "talkoff" auch nur zu den bereits angesprochenen Punkten weiter.


Grüsse, Stefan

 

[fant]

@HobbyStern
Ich nutze einen PIII-1Ghz von Fujitsu-Siemens, also keine AMD-Hardware beim Asterisken.

Wär ja auch zu schön gewesen...;-) Aber wenn Du mir einen AMD schenken möchtest, also, da könnten wir schon...

Hawedieehre.
Fant

 

[jackfritt]

Unter mISDN kann man die dtmfthreshold Variable nutzen um die Erkennung zu drosseln, ein Wert von 400 hat hier den mISDN Kanal aus dem "Logger" genommen, was soviel heissen soll wie : "mISDN wird nicht mehr als DTMF Störenfried angezeigt".

dtmfthreshold oder dtmftreshold in der misdn-init.conf ?

Ich habe jetz
dtmftreshold=4000
in der misdn-init.conf und heute morgen im LOG :

[Apr 19 08:02:53] DTMF[19056] channel.c: DTMF end '1' received on mISDN/1-u8, duration 0 ms

/EDIT

Ich sehe gerade im Quellcode das ich das falsch geschrieben habe. Ok werde das mal anpassen.

/EDIT


Gruss,

Jörg

 

[jackfritt]

Habe gerade zufällig einen Kollegen neben mir stehen gehabt der mit einem Mitarbeiter über Handy telefonierte.
SIP->Asterisk->misdn->Handy T-D1

Kollege am anderen Ende meldete sich mit Frauenstimme und blödelte in höherer Stimme rum. Im LOG:

[Apr 19 08:27:16] DTMF[19056] channel.c: DTMF end '6' received on mISDN/1-u25, duration 0 ms
[Apr 19 08:27:17] DTMF[19056] channel.c: DTMF end '*' received on mISDN/1-u25, duration 0 ms
[Apr 19 08:28:00] DTMF[19056] channel.c: DTMF end 'A' received on mISDN/1-u25, duration 0 ms
[Apr 19 08:28:01] DTMF[19056] channel.c: DTMF end '5' received on mISDN/1-u25, duration 0 ms
[Apr 19 08:28:05] DTMF[19056] channel.c: DTMF end '4' received on mISDN/1-u25, duration 0 ms

Keiner von beiden hörte Töne. Angeblich aber Unterbrechungen. Wenn man der duration glauben kann dann könnte das die Unterbrechung sein.

Also es gibt Talkoff und das auch mit Asterisk-Trunk Revision r61667M.
Da wirds wohl noch einiges an Arbeit geben bis das so gut läuft wie im alten ISDN Netz mit herkömmlicher Technik