[gelöst] Keine vernünftige DTMF Erkennung bei (K)IAX

[swatchy]

Benutze das IAX Softphone KIAX, leider funktioniert die DTMF Erkennung nicht vernünftig. D.h. ab und zu läuft es, die meiste Zeit funktioniert es nicht.
Was genau gemacht werden soll: Habe im in der Datei extensions.conf diese Einträge gemacht:

[globals]
DYNAMIC_FEATURES=blindxfer#automon#atxfer#parkcall
...
[brd]
exten => _1234.,1,Voicemail(10@voicemail)
...
[capi-in]
exten => rufnummer,1,Dial(IAX2/telefon,,tTwWkK)
...

In der Datei iax.conf ist folgendes definiert worden:

[general]
bindport=4569
bindaddr=0.0.0.0
iaxcompat=yes
nochecksums=no
delayreject=yes
amaflags=billing
language=de
mohinterpret=default
mohsuggest=default
disallow=all
jitterbuffer=yes
forcejitterbuffer=no
maxjitterbuffer=800
maxjitterinterps=10
resyncthreshold=1000
tos=ef
autokill=yes
codecpriority=host
rtcachefriends=no
rtupdate=no
rtautoclear=yes
rtignoreregexpire=no

[telefon]
allow=gsm
auth=md5
callerid=Swatchy <telefon>
context=brd
host=dynamic
qualify=yes
qualifysmoothing=yes
secret=telefon
type=friend

Zusätzlich ist die Datei features.conf wie folgt angepasst worden:

...
[featuremap]
blindxfer => #1                 ; Blind transfer  (default is #)
;disconnect => *0                ; Disconnect  (default is *)
automon => *1                   ; One Touch Record a.k.a. Touch Monitor
atxfer => *2                    ; Attended transfer
;parkcall => #72                ; Park call (one step parking)
...

Rufe ich nun von extern über ISDN diesen Teilnehmer an, dann kann man dort auch drangehen, allerdings ist eine Wahl von z.B. *2 und dahinter die Rufnummer (12345), die sich im Context brd befindet, nicht möglich. Es passiert einfach gar nichts.

Hier der Ausschnitt vom Debuggen:

Debugging on new channels is enabled
<< [ TYPE: DTMF Begin (12) SUBCLASS: * (42) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [IAX2/telefon-1]
<< [ TYPE: DTMF End (1) SUBCLASS: * (42) ] [IAX2/telefon-1]

Hat jemand eine Idee woran es liegen kann?

Gruß

Martin

 

[betateilchen]

Es passiert einfach gar nichts.

Das stimmt doch gar nicht - wenn Du Dein Debug anschaust, siehst Du, daß der * korrekt erkannt wird.

Was hast Du denn als DTMF Verfahren in KIAX eingestellt?

 

[swatchy]

Innerhalb des gesamten Zeitraums habe ich aber *212345 eingegeben und nicht nur * wie es dort erkannt wird.
In KIAX habe ich keinen Punkt gefunden der die DTMF Sendung auf Out-Band stellt (RFC2833).
Könnte mir aber vorstellen, dass die Punkte:
NoiseReduction
Automatic Gain Detection
Confort Noise

Probleme machen könnten.

Probiere das Mal aus!

Gruß

Martin

 

[swatchy]

Und tatsächlich die Noise Reduction macht hier Ärger! Ist zwar dann für den Anrufenden ein wenig nervig das Rauschen im Hörer zu haben, jedoch ist es anscheinend nicht anders möglich...

Besten Dank!


Gruß

Martin

 

[betateilchen]

Deine iax.conf ist grundsätzlich ziemlich haarsträubend.

In [general] verbietest Du mit

disallow=all

alle codecs, ohne danach irgendwelche codecs überhaupt freizugeben.

In [telefon] versuchst Du dann ohne ein disallow mit

allow=gsm

einen einzelnen Codec freizugeben

Beide Vorgehen sind so betrachtet ziemlich sinnlos.

Hast Du eigentlich mal geprüft, welcher Codec bei einem Anruf überhaupt verwendet wird?

Als nächstes schreibst Du, daß KIAX die DTMF Töne wohl inband sendet - das würde allerdings voraussetzen, daß die Verbindung zwischen Client und Server breitbandig ist (ulaw oder alaw)

Die Definition des dtmfmode kann ich übrigens in Deiner iax.conf weder in [general] noch in [telefon] finden...

Daß Du es nun auf die Noise Reduction schiebst, mag Dein Problem scheinbar lösen, ich halte diese Einstellung allerdings nicht für die wahre Ursache Deines Problems.

 

[swatchy]

Erst mal vorweg die Frage warum die iax.conf so haarsträubend ist?

Ist es nicht legitim, nur einen Codec zuzulassen? Ich meine erst mal alle zu verbieten und nur einen freizugeben?

Eingestellt sind in den Clients jeweils gsm, somit passt die Konfiguration auch. Außerdem ist ja in der der Parameter codecpriority=host gesetzt, womit ich mich gar nicht mit einem anderen Codec als den gewählten an Asterisk verbinden könnte.

In KIAX habe ich keinen Punkt gefunden der die DTMF Sendung auf Out-Band stellt (RFC2833).

Ich kann in KIAX nichts einstellen wollte ich damit sagen, d.h. ich wollte gerne auf Out-Band stellen, aber es gibt keinen Punkt dafür. Des weiteren weiß ich nicht wie KIAX DTMF behandelt.

Zu dtmfmode: So weit ich weiß gibt es den Parameter dtmfmode in der iax.conf nicht. Siehe http://lists.digium.com/pipermail/asterisk-dev/2006-July/021819.html

Gruß

Martin

 

[betateilchen]

Ok - mit dem dtmfmode hast Du natürlich recht. Da war ich heute nachmittag wohl ein bißchen im Streß. Bei IAX wird DTMF direkt in ein IAX Paket verschnürt, somit gibt es keine unterschiedlichen Übertragungsverfahren. Deshalb findest Du auch keine Einstellmöglichkeit in Deinem Softphone.

Aber: genau dieses Verhalten bestärkt mich eigentlich in meiner Meinung, daß die Noise Reduction nicht wirklich die Ursache für Dein Problem sein soll, denn bei verpackten Daten (dies sollte ja direkt auf dem Softphone passieren) gibt es eigentlich kein Rauschen.

Was das Erlauben/Verbieten von Codecs angeht...

Natürlich ist es legitim, nur einen einzelnen Codec zuzulassen. Aber die normale Vorgehensweise bei Asterisk ist eigentlich die, im [general] mit disallow=all erstmal alle zu verbieten und danach mit einem (oder mehreren) allow=<codec> die gewünschten Codecs zuzulassen.

In den Kontexten der peers ist es eigentlich so, daß Du dort nur aus der Menge der in [general] erlaubten Codecs auswählen kannst.

Beispiel:

[general]
disallow=all
allow=gsm
allow=g729

dann ist es in einem peer Kontext eigentlich nicht möglich,

allow=ulaw

zuzulassen, da nur gsm und g729 zur Verfügung stehen.

Zumindest war das bisher immer so. Und ich kann mich nicht daran erinnern, irgendwo gelesen zu haben, daß sich dieses Verhalten grundlegend geändert haben soll. Aber ich lasse mich natürlich gerne eines Besseren belehren.

 

[swatchy]

So weit ich das Konzept von disallow und allow verstanden habe, wird im general context eine "globale" definition der erlaubten und nicht erlaubten codecs eingetragen. Möchte man nun per peer einen Codec verbieten dann kann dies durch allow geschehen z.B:

[general]
disallow=all
allow=gsm
allow=g729
...

im peer:

disallow=all
allow=g729
...

Als Resultat gilt, dass nur gsm gewählt werden darf.

Ich denke dass man zuerst alle unter general verbietet und dann nur per peer einen freigibt (so wie ich es getan habe).

Ich kann leider keine Quelle hierfür angeben, aber das Beispiel auf diese Site:
http://www.voip-info.org/wiki-Asterisk+config+sip.conf#Example erlaubt im peer mehr (alaw) wie in general definiert wurde:

[general]
context = (own_context in extensions.conf where recive the call )
realm = real.com
bindbort=5060
srvlookup=yes
disallow=all
allow=ulaw
allow=gsm
language=en

trustrpid = yes
sendrpid = yes

register => fromuser@fromdomain:secret@host
register => [email protected]:AAAA@IP

[my_provider]
type=peer
fromuser=XXXX
fromdomain=YYYY.com
canreinvite=no
secret=AAAAA
insecure=very
host= IP
disallow=all
allow=gsm
allow=ulaw
allow=alaw
qulify=yes
nat=no

Gruß

Martin

 

[swatchy]

Habe noch etwas dazu gefunden und zwar in dem Asterisk Buch von OReilly http://www.asteriskdocs.org/modules/tinycontent/index.php?id=11 Seite 210:

allow and disallow (channel)
Specific codecs can be allowed or disallowed, limiting codec use to those preferred
by the system designer. allow and disallow can also be defined on a perchannel
basis. Keep in mind that allow statements in the [general] section will
carry over to each of the channels, unless you reset with a disallow=all. Codec
negotiation is attempted in the order in which the codecs are defined. Best practice
suggests that you define disallow=all, followed by explicit allow statements
for each codec you wish to use. If nothing is defined, allow=all is assumed.
disallow=all
allow=ulaw
allow=gsm
allow=ilbc

Gruß

Martin