Plötzliche Anrufunterbrechungen bei CAPI-Telefonaten

gmer

Neuer User
Mitglied seit
26 Aug 2006
Beiträge
11
Punkte für Reaktionen
0
Punkte
0
Hallo!

Habe vor kurzem einen neuen Asterisk aufgesetzt und bis auf das folgende Problem läuft auch alles bestens.

Konfiguration:
DELL-Server SC1425
EICON Diva BRI-2M (Treiber von EICON mit CAPI2.0) an österreichischem Anlagenanschluß
Debian "Etch"
Asterisk 1.4
aktuelle chan_capi.
Endgeräte sind GXP-2000 von Grandstream (mit aktuellster Firmware)

Problem:
Telefonate (egal ob eingehend/ausgehend) werden so wie gewünscht vermittelt. Nach ca. 3 Minuten bricht dann das Gespräch ab, wobei der externe Teilnehmer kurz vorher komische Geräusche (ähnlich Faxtönen?!?) hört. Während dieser Zeit hört man am SIP-Endgerät noch alles perfekt. Dann plötzlich bricht die Verbindung ab.

Logfile:
Habe folgendes aus dem Logfile isolieren können (Rufnummern sind als 12345 dargestellt):

Code:
[Jan 8 14:31:36] VERBOSE[11688] logger.c: -- CAPI queue frame:Control (4) SUBCLASS: Busy (5) ] [ISDN1#01]
[Jan 8 14:31:36] DEBUG[12550] channel.c: Got a FRAME_CONTROL (5) frame on channel CAPI/ISDN1/12345-3b
[Jan 8 14:31:36] DEBUG[12550] channel.c: Bridge stops bridging channels SIP/99-081f61c0 and CAPI/ISDN1/12345-3b
[Jan 8 14:31:36] VERBOSE[12550] logger.c: -- ISDN1#01: activehangingup (cause=16) for PLCI=0x301
[Jan 8 14:31:36] VERBOSE[12550] logger.c: == Spawn extension (macro-dialout-trunk, s, 27) exited non-zero on 'SIP/99-081f61c0' in macro 'dialout-trunk'
[Jan 8 14:31:36] VERBOSE[12550] logger.c: == Spawn extension (macro-dialout-trunk, s, 27) exited non-zero on 'SIP/99-081f61c0'
[Jan 8 14:31:36] VERBOSE[12550] logger.c: -- Executing [h@macro-dialout-trunk:1] Macro("SIP/99-081f61c0", "hangupcall") in new stack
[Jan 8 14:31:36] VERBOSE[12550] logger.c: -- Executing [s@macro-hangupcall:1] ResetCDR("SIP/99-081f61c0", "w") in new stack
[Jan 8 14:31:36] VERBOSE[12550] logger.c: -- Executing [s@macro-hangupcall:2] NoCDR("SIP/99-081f61c0", "") in new stack
[Jan 8 14:31:36] NOTICE[12550] cdr.c: CDR on channel 'SIP/99-081f61c0' not posted
[Jan 8 14:31:36] NOTICE[12550] cdr.c: CDR on channel 'SIP/99-081f61c0' lacks end
[Jan 8 14:31:36] DEBUG[12550] pbx.c: Expression result is '1'
[Jan 8 14:31:36] VERBOSE[12550] logger.c: -- Executing [s@macro-hangupcall:3] GotoIf("SIP/99-081f61c0", "1?skiprg") in new stack
[Jan 8 14:31:36] VERBOSE[12550] logger.c: -- Goto (macro-hangupcall,s,6)
[Jan 8 14:31:36] DEBUG[12550] pbx.c: Expression result is '1'
[Jan 8 14:31:36] VERBOSE[12550] logger.c: -- Executing [s@macro-hangupcall:6] GotoIf("SIP/99-081f61c0", "1?theend") in new stack
[Jan 8 14:31:36] VERBOSE[12550] logger.c: -- Goto (macro-hangupcall,s,9)
[Jan 8 14:31:36] VERBOSE[12550] logger.c: -- Executing [s@macro-hangupcall:9] Wait("SIP/99-081f61c0", "5") in new stack
[Jan 8 14:31:36] VERBOSE[11688] logger.c: == ISDN1#01: Interface cleanup PLCI=0x301

Konfiguration:
Die capi.conf in /etc/asterisk sieht wie folgt aus:

Code:
;
; CAPI config
;
;

; general section

[general]
nationalprefix=0
internationalprefix=00
rxgain=0.8
txgain=0.8
language=de

[ISDN1]                 
ntmode=no
isdnmode=did
msn=12345             
incomingmsn=*
controller=1
group=1
prefix=0
softdtmf=off
relaxdtmf=on
faxdetect=off
accountcode=
context=from-pstn
holdtype=local
immediate=yes
echocancel=yes
echocancelold=yes
callgroup=1
pickupgroup=1
language=de
allow=all
devices=2

Es funktioniert wirklich alles - eingehende Anrufe werden richtig durchgestellt, ausgehende funktionieren perfekt => nur nach ca. 3 Minuten kommt es eben immer zu diesen ominösen "Tönen" auf Seiten des externen Teilnehmers mit darauf folgendem Disconnect.

Wäre sehr dankbar, wenn irgend jemand Hilfe anzubieten hätte.

Mfg,

gmer
 
Nachtrag

Fast vergessen:
Kernel:
Code:
Linux logorrhoe 2.6.17.7 #2 SMP Fri Jan 5 01:04:27 CET 2007 i686 GNU/Linux

chan_capi:
Aktuellste SVN-Version (TRUNK rev.405)
 
gmer schrieb:
chan_capi:
Aktuellste SVN-Version (TRUNK rev.405)
Deine capi.conf weist nicht alle Parameter auf, du solltest mal die "neuen" mit einbauen.
Ich vermute mal das "Fax-toene=DTMF-toene"
Ein paar Ideen dazu:
1) dtmf auf der capi Seite mittels Software versuchen
2) dtmf auf der sip Seite umstellen (inband, rfc...)
3) vermutlich erlaubst du im dialstring das der caller bzw. callee das Gespraech parken, vermitteln oder sonstwas tun darf. Nimm das mal raus, da spielt dann dtmf auch mit.
Bitte nicht alles gleichzeitig aendern ;)
 
So, letztenendlich dürfte es sich doch nicht um ein Problem vom * oder der chan_capi handeln (habe zwar vom * die 1.2er und von der chan-capi die 0.7er-stable installiert) - mit einem "älteren" GXP-2000 mit älterer Firmware gibt es keine Probleme.

Jetzt stehe ich allerdings vor folgendem Problem:
Bei Anrufen, die über ISDN reinkommen/rausgehen, ist für den externen ISDN-Teilnehmer die Qualität bestens (mal abgesehen von ein bissl rauschen ab und zu, aber nichts, was man merkt, wenn man nicht ganz genau hinhört) - nur für die internen SIP-Geräte passt es nicht. Weder an den Grandstream-Geräten (GXP und BT101) noch an einem C450IP von Siemens.

Hauptmängel:
* externer Teilnehmer ist nur sehr leise zu hören
* teilweise leichtes, teilweise sehr großes Echo

echocancel habe ich in der capi.conf für die DIVA aktiviert (mit "yes"), rx/txgain habe ich sowohl mit 0.8 als auch mit 1.0 probiert. Hat hier irgendjemand eine Idee?

Mfg,
gmer
 
Hi Hi,

also ich hatte das gleiche Problem, habe also nach Tagen und etliche stunden mit Google und Foren, nach dem Parameter Rx/Tx gesicht und gedreht. Ohne erfolg.Nach Div. Treiber ups and downs auch kein erfolg. Habe mich dann entschlossen misdn einzusetzen, und nun klappt das mit dem Rx/Tx. Echo ist auch verschwunden. Vermute also das das der CAPI ist.

gruß
cpuvampier
 
An chan-capi kann das nicht liegen, da hier (gerade bei gain 1.0) keine Veraenderung der Sprachdaten vorgenommen wird.
mISDN ist hier nicht benutzbar, da mISDN keinen support fuer die aktiven Eicon Karten hat. Ich denke es ist eine Einstellung des DIVAS Treibers.
Welche Version benutzt du?
Wenn es eine neuere Version ist, solltest du
echocancelold=no
machen. relaxdtmf sollte auch nicht eingeschaltet sein, denn die Eicon Karten koennen selbst DTMF erkennen und brauchen keine Softwareunterstuetzung.

Armin
 
Hallo,

leider keine Ahnung, wie ich genau herausfinde, was derzeit läuft. Hab mal das startup log unten angefügt.

relaxdtmf und echocancelold hab ich aus, allerdings hat sich keinerlei verbesserung/verschlechterung ergeben.

hat da noch irgend jemand eine idee?

gmer

Code:
0:0000:035 - Instance(0)=0x8026a000 image_start=0x80000000, shared_memory=0xa0001000 card=60
    0:0000:000 - Diva Server BRI-2M 2.0 (2620)
    0:0000:000 - Protocol: 'TE_DMLT, Build 106-112, Protocol 6.03(V16) 105-2 [F#00FF]'
    0:0000:000 - DSP task 6: DIVA Server BRI 2M Kernel Version 1.00 Build 106-648
    0:0000:000 - DSP task 100: HSCX Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 104: HSCXBR Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 110: PIAFSD Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 200: V.110 Kernel Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 201: V.110 Overlay (600) Version 1.00 Build 106-648
    0:0000:000 - DSP task 202: V.110 Overlay (1200) Version 1.00 Build 106-648
    0:0000:000 - DSP task 203: V.110 Overlay (1200/75) Version 1.00 Build 106-648
    0:0000:000 - DSP task 204: V.110 Overlay (75/1200) Version 1.00 Build 106-648
    0:0000:000 - DSP task 205: V.110 Overlay (2400) Version 1.00 Build 106-648
    0:0000:000 - DSP task 206: V.110 Overlay (4800,9600,19200,38400) Version 1.00 Build 106-648
    0:0000:000 - DSP task 207: V.110 Overlay (7200,14400,28800) Version 1.00 Build 106-648
    0:0000:000 - DSP task 208: V.110 Overlay (12000,24000) Version 1.00 Build 106-648
    0:0000:000 - DSP task 209: V.110 Overlay (48000) Version 1.00 Build 106-648
    0:0000:000 - DSP task 210: V.110 Overlay (56000) Version 1.00 Build 106-648
    0:0000:000 - DSP task 504: VOICEBR Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 510: DTMF Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 512: DTMFBR Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 520: SIG Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 532: TONEBR Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 542: MEASBR Task Version 1.00 Build 106-648
    0:0000:000 - DSP task 552: LECBR Task Version 1.00 Build 106-648
    0:0000:001 - DSP task 590: Conferencing Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 600: TIKRNL81.F34 Task Version 1.00 Build 106-648
    0:0000:001 - DSP task 624: SIG Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 604: FSK OWN Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 607: V8.F34 Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 608: INFO Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 609: V.34 Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 622: INFOH.F34 Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 623: HV34.F34 Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 610: DIAL/FSK/FAX.F34 Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 611: DIAL.F34 Partial Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 612: FSKFAX.F34 Partial Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 613: FAX.F34 Partial Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 614: V.22/V.32 LEC Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 615: V.32 Partial Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 618: V.90 DPCM Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 619: V.90 APCM Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 625: V.22FC Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 629: V.22bis FC Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 627: V.29FC Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 620: V.18 OWN-LK Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 621: V.OWN Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 702: VKRNLBR.SEC Task Version 1.00 Build 106-648
    0:0000:001 - DSP task 703: G.711 Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 704: RTP G.711/G.726 Overlay Version 1.00 Build 106-648
    0:0000:001 - DSP task 706: RTP GSM Overlay Version 1.00 Build 106-648
    0:0000:001 - Conf: DLI21st=1,MWIREG=1,ECTA=1,ECTF=1
    0:0000:001 - Conf: S2=1,Tei=1,NT2=1,Perm=0,WDog=0,LowCh=0,L1Hunt=0x0
    0:0000:001 - Conf: Loop=0,DidLen=0,Law=1,nosig=0,AlertTO=0xffff,PDisc=0
    0:0000:001 - Conf: Prot=1,PVer=0,NT=0,Lim=0,RTone=0,L2_Links=1
    0:0000:001 - Conf: XConn=0/2
    0:0000:001 - SN:3294-0 0
 
Welches Treiber Paket verwendest Du? Oder den Standard aus dem Kernel?

Du solltest updaten, entweder bei Eicon ein RPM/DEB laden, oder bei uns den V3 Treiber: ftp.melware.net

Armin
 
Hallo!

So, habe jetzt den aktuellsten Treiber von melware.net installiert. Die Qualität ist dadurch um einiges besser geworden.

Allerdings rauscht es ein bisschen im Hintergrund (auf beiden Seiten - kann das evtl. an der eher langen - ca. 8m - Leitung vom NTBA zum Server liegen?) und bei einzelnen Tönen wirkt es so, als würde man sie ins Telefon "hineinblasen".

Die Lautstärke hat sich nur ansatzweise gebessert. Es ist jetzt zwar lauter als vorher, aber wirklich sehr gut ist sie noch nicht. Gibt es hier evtl. irgendwo eine Einstellung?

Mfg,
gmer
 
Also das kann nicht an der Leitung liegen, wir sprechen hier ja von einem digitalen Anschluss...
Wenn du bei gain 1.0 eingestellt hast und auch kein echosquelsh eingeschaltet hast, dann gibt es hier keine weiteren Einstellungen. Ich vermute eher, dass diese Problem von deinem Endgeraet kommen, denn die Sprachdaten werden von chan-capi und Asterisk hier nur 'weitergegeben'. Oder hast du einen 'schlechten' codec eingestellt?

Armin
 
Bei den Endgeräten habe ich alle möglichen Einstellungen durchprobiert. Am "besten" funktioniert es mit dem BudgeTone101 - da hab ich folgende Codecs: PCMU,PCMA,G723,G729,G726-32. Aber auch hier ist - wie eben auf allen Endgeräten - ein Rauschen zu hören. Auf den anderen Geräten habe ich ähnliche Einstellungen, allerdings teilweise zu Testzwecken etwas "verdreht"

Habe jetzt übrigens bemerkt, dass das rauschen schon kommt, sobald der Asterisk "drangeht" (sprich: Warteschleife, ...) - also BEVOR zum Endgerät verbunden wird.

Ist es hier hilfreich, evtl. mit den gain bzw echosquelch und echotail zu "experimentieren"?

gmer
 
echosquelch kann ich nicht empfehlen, eher echotail. Aber ein rauschen kommt eigentlich nicht vom echo-cancel.
Kannst ja mal testweise echo-cancel abschalten und dann nochmal mit der Warte schleife testen. Wenn es hier auch rauscht, hat das nichts mit dem echo-cancel zu tun (wovon ich ausgehe).
Es gibt eigentlich keine Moeglichkeit wo bei der digitalen Verbindung ein Rauschen reinkommt. Die Endgeraete (A/D Wandler, Mikro,...) sind hier meist das Problem.

Armin
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.