Echos und Störungen ohne Ende

[Raghnarx]

Hallo Allerseits,
ich verzweifle hier gerade an einer Asterisk 1.2.9.1-BRIstuffed-0.3.0-PRE-1q inkl. florz Patch. Ich habe hier folgendes Szenario:

3 HFC Karten, 1. im TE Modus, 2. und 3. im NT Modus an einem Anlagenanschluss.

An der 1. hängt die alte ISDN Anlage mit der ein paar Leute telefonieren, sonst hab ich noch ca. 10 SIP Clients.

Ich habe das Problem, das ich immer wieder extreme echos habe, die so weit gehen das Leute sich 100% so gut wieder hören können wenn sie selber sprechen. Dies passiert sowohl bei eingehenden, als auch bei ausgehenden Anrufen - allerdings anscheinend nur mit Festnetzanschlüssen - wenn ich mit Mobilfunkteilnehmern telefonieren scheint das problem nicht zu bestehen.

In den Log-Dateien sehe ich nichts auffällgies - ab und zu mal ein buffer underrun- bzw. overflow, aber das habe ich bei allen anderen Asterisk installationen auch gehabt, ohne das es wirklich ein Problem gewesen wäre.

Hier mal meine configs

zaptel.conf

#
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#
#
#
loadzone=de
defaultzone=de
#


# hfc-s pci a span definition
# most of the values should be bogus because we are not really zaptel

span=1,0,0,ccs,ami
bchan=1-2
dchan=3

span=2,1,0,ccs,ami
bchan=4-5
dchan=6

span=3,2,0,ccs,ami
bchan=7-8
dchan=9

zapata.conf

; Zapata telephony interface
;
; Configuration file

[channels]
language=de
switchtype = euroisdn

pridialplan = local
prilocaldialplan = local

nationalprefix = 0
internationalprefix = 00

musiconhold=default
overlapdial=yes
usecallerid=yes
hidecallerid=no
;usecallingpres=yes
;callwaitingcallerid=yes
;threewaycalling=yes
transfer=yes
;cancallforward=yes
;callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
qualify=yes
immediate=no

signalling = bri_net_ptmp
context = from-internal
group = 2
channel => 1-2

signalling = bri_cpe
context = from-pstn
group = 1
channel => 4-5

signalling = bri_cpe
context = from-pstn
group = 1
channel => 7-8

Seht ihr irgendwas falsches/auffälliges? Ich verzweifel hier noch

Marc

 

[swaesch]

Du schreibst, du hast die 1. Karte im TE Mode und Karten 2-3 im NT Mode.

Auf der anderen Seite aber hast du in deiner zapata.conf Karte 1 mit

signalling = bri_net_ptmp
context = from-internal

belegt, was als Basismehrgeräteanschluß im NT-Mode betitelt wird.

Karte 2 und 3 mit bri_cpe als Basisanlagenanschluss im TE-Mode

signalling = bri_cpe
context = from-pstn

signalling = bri_cpe
context = from-pstn

bist du dir sicher, dass dies deine zapata.conf ist, die hier am laufen ist??

Oder hast du doch eine andere Konfiguration (1.Karte NT|2-3.Karte TE)???
Spricht dafür, dass du eine Telefonanlage an Karte 1 hängen hast.

 

[Raghnarx]

Ist doch auch korrekt so --- laut der beispielconfig:

; p2mp NT mode (for connecting ISDN phones in point-to-multipoint mode)
; signalling = bri_net_ptmp
Für die erste Karten (intern halt, geht weiter zur Anlage)

; p2p TE mode (for connecting ISDN lines in point-to-point mode)
; signalling = bri_cpe

Für die 2. und 3. Karte die zum Amt gehen (Anlagenanschluss).

Ich habe * zwischen Amt und alter Anlage hängen.

Marc

 

[swaesch]

Hab deinen Beitrag von oben nach unten durch gelesen.

Und dies steht da halt:

3 HFC Karten, 1. im TE Modus, 2. und 3. im NT Modus an einem Anlagenanschluss.

Hast mich ein wenig verwirrt.

Den deine Konfig ist 1. Karte im NT und 2. + 3. Karte im TE.

Zum Echo:

Spiel einwenig mit den Einstellungen:

z.B.

echocancel=yes
echocancelwhenbridged=yes
echotraining=no

oder

echocancel=16 oder 32,64,128,256 yes entspricht Tab-Wert 128 und damit 16ms
echocancelwhenbridged=16 oder 32,64,128,256
echotraining=no

jeder Tab-Wert repräsentiert 0,125ms.


Bei mir hab ich speziell mit analogen DECT Basisstationen Probleme, die eine Telefonverbindung zu anderen analogen Endgeräten im Festnetz aufbauen.

 

[Raghnarx]

Hab deinen Beitrag von oben nach unten durch gelesen.

Und dies steht da halt:



Hast mich ein wenig verwirrt.

Den deine Konfig ist 1. Karte im NT und 2. + 3. Karte im TE.

Sorry, du hast natürlich völlig recht. Siehst du mal wie verwirrt ich schon bin

Marc

 

[torstenkrueger]

Hallo Allerseits,
ich verzweifle hier gerade an einer Asterisk 1.2.9.1-BRIstuffed-0.3.0-PRE-1q inkl. florz Patch. Ich habe hier folgendes Szenario:

3 HFC Karten, 1. im TE Modus, 2. und 3. im NT Modus an einem Anlagenanschluss.

An der 1. hängt die alte ISDN Anlage mit der ein paar Leute telefonieren, sonst hab ich noch ca. 10 SIP Clients.

Ich habe das Problem, das ich immer wieder extreme echos habe, die so weit gehen das Leute sich 100% so gut wieder hören können wenn sie selber sprechen. Dies passiert sowohl bei eingehenden, als auch bei ausgehenden Anrufen - allerdings anscheinend nur mit Festnetzanschlüssen - wenn ich mit Mobilfunkteilnehmern telefonieren scheint das problem nicht zu bestehen.

In den Log-Dateien sehe ich nichts auffällgies - ab und zu mal ein buffer underrun- bzw. overflow, aber das habe ich bei allen anderen Asterisk installationen auch gehabt, ohne das es wirklich ein Problem gewesen wäre.

Hier mal meine configs



zapata.conf

; Zapata telephony interface
;
; Configuration file

[channels]
language=de
switchtype = euroisdn

pridialplan = local
prilocaldialplan = local

nationalprefix = 0
internationalprefix = 00

musiconhold=default
overlapdial=yes
usecallerid=yes
hidecallerid=no
;usecallingpres=yes
;callwaitingcallerid=yes
;threewaycalling=yes
transfer=yes
;cancallforward=yes
;callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
qualify=yes
immediate=no

signalling = bri_net_ptmp
context = from-internal
group = 2
channel => 1-2

signalling = bri_cpe
context = from-pstn
group = 1
channel => 4-5

signalling = bri_cpe
context = from-pstn
group = 1
channel => 7-8

Marc

Ich unterstelle mal, daß Du von den Leuten die an eurer 'alten' Anlage hängen keine Probleme in der Richtung gemeldet bekommst. Des weiteren gehe ich davon aus, daß der Gesprächspartner am anderen Ende selbst kein Echo hört.

In dem Fall solltest Du folgendes tun:
- echocancelwhenbridged=no

Ein von der Gegenseite erzeugtes Echo ist nur dann hörbar wenn die Zeitdifferenz zwischen Originalsignal und dem auf der Gegenseite reflektierten Signal größer als ca. 10-15msec ist. Liegt der Wert darunter nimmst Du das als (angenehmes) Seitenbandsignal wahr. Das ISDN-Netz hat bei einem nationalen Gespräch ca. 4msec Latenz. Durch das Bridgen der ISDN-Kanäle in der Anlage vom Amt zur alten TK-Anlage kommt nicht soviel dazu daß das hörbar wird. für die SIP-Telefone sieht das anders aus. Da hast Du (je nach Einstellung) 30msec Audiodaten in einem RTP-Paket sowie den Overhead für Protokollwandlung etc.. so dass Du sicher über die Hörbarkeitsschwelle kommst. Also braucht es hierfür Echounterdrückung.

echotraining=no
Erfahrungswert von uns ist, dass Du mit echotraining=yes eigentlich nur den Effekt hast, daß die ersten xxx msec vom Anruf abgeschnitten werden, da der Echocanceller ein Testsignal auf die Leitung gibt und versucht einen Startwert für den Cancelalgorithmus zu finden. Ergebnis davon ist, dass Du meistens den Namen Deines Gesprächpartners nicht verstehst und nochmal nachfragst. Ausserdem scheint dies in Asterisk eher auf analoge Anschlüsse ausgelegt zu sein.

Was Du ausprobieren solltest ist in der Datei zconfig.h im Zapata-Ordner als Echocanceller nicht den KB1 sondern den MG2 zu verwenden

 /*
 * Pick your echo canceller: MARK2, MARK3, STEVE, or STEVE2 :)
 *
 */
/* #define ECHO_CAN_STEVE */
/* #define ECHO_CAN_STEVE2 */
/* #define ECHO_CAN_MARK */
/* #define ECHO_CAN_MARK2 */
/* #define ECHO_CAN_MARK3 */
/* #define ECHO_CAN_KB1 */
/* MG2 is a version of KB1 that has some changes to it that are
 * supposed to improve how it performs.  If you have echo problems,
 * try it out! */
#define ECHO_CAN_MG2

Wie in einem anderen Posting hier schon beschrieben sind insbesonders DECT-Geräte immer für ein Echo gut. Dies erscheint logisch:
- Analoger Anschluß mit guter Option für entsprechendes Übersprechen
- zusätzliche DA-AD Wandlung mit Funkstrecke dazwischen was für zusätzliche
Latenz sorgt

Ein billiges DECT-Telefon am Besten an einer ollen Istec-1003 ist m.E. der Beste denkbare Echotestaufbau für kleines Geld.

Hier scheint es mir so, daß die Taillänge (das Zeitfenster das der Echocanceller betrachtet) mit 16msec (128 Taps) nicht ausreichend gross. Du kannst mal ausprobieren hier ein echocancel=256 zu setzen. Wir hatten hiermit vor allem früher als Mark2 noch 'der' Echocanceller in Asterisk war damit jedoch das Problem, dass der Algorithmus dann in manchen Situationen komplett Amok gelaufen ist und sich das Gespräch wie aus dem Weltraum anhörte.

Langer Rede kurzer Sinn:

zconfig.h
#define ECHO_CAN_MG2

zapata.conf
echocancelwhenbridged=no
echotraining=no
echocancel=256
; oder falls die 256 Probleme machen:
echocancel=128

Das gemeine bei der Echothematik ist der Umstand, daß die Anwender wenn sie für das Thema einmal sensibilisiert sind das Gras wachsen hören. Falls die obigen Änderungen nicht den gewünschten Frieden bringen (und Du sonst nicht weiter kommst) würde ich ernsthaft darüber nachdenken eine Karte mit Hardware Echocanceller zu nehmen. Leider unterscheiden sich diese Karten recht deutlich im Preis von den billisch-HFC-Karten die Du aktuell verwendest. Digium hat hier zur Cebit eine m.W. immer noch nicht lieferbare 4-BRI angekündigt und von EICON bekommst Du passende Karten (Diva Server) mit 1-Port bis 4-Port.

Gruss
Torsten

 

[Raghnarx]

Ich unterstelle mal, daß Du von den Leuten die an eurer 'alten' Anlage hängen keine Probleme in der Richtung gemeldet bekommst. Des weiteren gehe ich davon aus, daß der Gesprächspartner am anderen Ende selbst kein Echo hört.

Das wäre schön, aber leider habe ich die Echos auch dort. Sie tauchen bei allen Arten von Clients auf - sowohl SIP Softphones, als auch den ISDN Telefonen an der alten Anlage, und auch an einem SNOM190 das ich einfach mal testweise angeschlossen hatte. Man hört selber manchmal Störgeräusche bzw. Hallen, und manchmal kriegt auch der Anrufer ein Echo, das er selber jedes Gesprochende Wort laut und deutlich zurück bekommt. (In normaler Gesprächslautstärke). Leider tauchen die Störungen sporadisch auf (in ca. 30% aller Fälle)

In dem Fall solltest Du folgendes tun:
- echocancelwhenbridged=no

echotraining=no
Erfahrungswert von uns ist, dass Du mit echotraining=yes eigentlich nur den Effekt hast, daß die ersten xxx msec vom Anruf abgeschnitten werden, da der Echocanceller ein Testsignal auf die Leitung gibt und versucht einen Startwert für den Cancelalgorithmus zu finden. Ergebnis davon ist, dass Du meistens den Namen Deines Gesprächpartners nicht verstehst und nochmal nachfragst. Ausserdem scheint dies in Asterisk eher auf analoge Anschlüsse ausgelegt zu sein.

Was Du ausprobieren solltest ist in der Datei zconfig.h im Zapata-Ordner als Echocanceller nicht den KB1 sondern den MG2 zu verwenden

Das gemeine bei der Echothematik ist der Umstand, daß die Anwender wenn sie für das Thema einmal sensibilisiert sind das Gras wachsen hören. Falls die obigen Änderungen nicht den gewünschten Frieden bringen (und Du sonst nicht weiter kommst) würde ich ernsthaft darüber nachdenken eine Karte mit Hardware Echocanceller zu nehmen. Leider unterscheiden sich diese Karten recht deutlich im Preis von den billisch-HFC-Karten die Du aktuell verwendest. Digium hat hier zur Cebit eine m.W. immer noch nicht lieferbare 4-BRI angekündigt und von EICON bekommst Du passende Karten (Diva Server) mit 1-Port bis 4-Port.

Gruss
Torsten

Danke auf jeden Fall für die ausführliche Erklärung, ich werde einmal testweise mit den Parametern testen, und gucken ob sich etwas ändert.

Ich werde vom Erfolg/Misserfolg berichten.

Marc

 

[amdunlock]

da gebe ich thomaskrueger recht. wenn du eine lösung haben möchtest, die wirklich zuverlässig funktionieren soll, und es kein gemecker geben soll, dann musst du zwingend auf karten mit hardwareechocancel zurückgreifen. wie acuh schon angesprochen die b410p ist noch nicht lieferbar, und weiterhin gibt es seitens digium auch keine meldung. nur im zaptel repository gibt es schon treiberuploads.

Gruß, Oliver

 

[torstenkrueger]

Wobei das auch eine ziemlich subjektive Angelegenheit ist und es wahrscheinlich auch sehr davon abhängt wie oft Du Gespräche mit Partnern hast deren Endgeräte Echos induzieren. Wir haben bei uns im Office z.B. ein Setup mit Sangoma A102U (also ohne HW-EC) und den oben von mir geschilderten EC-Einstellungen im Zaptel-Treiber. Das läuft so gut, dass ich vielleicht einmal im Monat ein Gespräch habe wo ich eine leichte Echofahne höre.

Allerdings haben wir auch Installationen bei Kunden gehabt wo wir das gleiche Setup verbaut haben und es nach kurzer Zeit einen Aufschrei wg. der Echothematik gab. Da hat das ganze damit geendet, dass wir einen Tellabs Echocanceler beim Kunden zusätzlich verbaut haben - anders war das Thema nicht in den Griff zu kriegen.

Um nochmal zu Raghnars eigentlichem Problem zurückzukommen:

Er schreibt:

Das wäre schön, aber leider habe ich die Echos auch dort. Sie tauchen bei allen Arten von Clients auf - sowohl SIP Softphones, als auch den ISDN Telefonen an der alten Anlage, und auch an einem SNOM190 das ich einfach mal testweise angeschlossen hatte. Man hört selber manchmal Störgeräusche bzw. Hallen, und manchmal kriegt auch der Anrufer ein Echo, das er selber jedes Gesprochende Wort laut und deutlich zurück bekommt. (In normaler Gesprächslautstärke). Leider tauchen die Störungen sporadisch auf (in ca. 30% aller Fälle)

Das klassische VOIP-Echo auf Grund erhöhter Latenz dürfte bei Deinen ISDN-Endgeräten eigentlich nicht auftreten. Was für eine Anlage ist das? Wieviele Nebenstellen hängen da dran? Wäre es eine Option die Anlage abzubauen oder nur noch als A/B Wandler für die Faxgeräte zu nutzen und den Anwendern an Stelle dessen SIP-Telefone zu geben? Wäre auch insgesamt mit Blick auf Integration ein wenig netter (Rufumleitung, Besetztlampenfeld an der Vermittlung etc...).

Wenn der Angerufene Störungen/Echos zu hören bekommt liegt das vermutlich an einem amoklaufenden EC. Passiert wie gesagt recht zuverlässig wenn Du beim Mark2 Canceler den Echotail auf 256 oder höher drehst. Ach so, wenn Du in den Zaptel-headern etwas änderst musst Du Zaptel natürlich neu kompilieren. Ich denke aber, dass Du das eh gemacht hast.

 

[Raghnarx]

Da hat das ganze damit geendet, dass wir einen Tellabs chocanceler beim Kunden zusätzlich verbaut haben - anders war das Thema nicht in den Griff zu kriegen.

Ich habe ja auch bereits das gleiche Setup an einer anderen Stelle ganz ohne Probleme am laufen - da läuft es zu 100%. Selbst die HFC Karten sind vom gleichen Hersteller. Wie teuer ist denn so ein Hardware-Echocanceler?

Das klassische VOIP-Echo auf Grund erhöhter Latenz dürfte bei Deinen ISDN-Endgeräten eigentlich nicht auftreten. Was für eine Anlage ist das? Wieviele Nebenstellen hängen da dran? Wäre es eine Option die Anlage abzubauen oder nur noch als A/B Wandler für die Faxgeräte zu nutzen und den Anwendern an Stelle dessen SIP-Telefone zu geben? Wäre auch insgesamt mit Blick auf Integration ein wenig netter (Rufumleitung, Besetztlampenfeld an der Vermittlung etc...).

Wenn der Angerufene Störungen/Echos zu hören bekommt liegt das vermutlich an einem amoklaufenden EC. Passiert wie gesagt recht zuverlässig wenn Du beim Mark2 Canceler den Echotail auf 256 oder höher drehst. Ach so, wenn Du in den Zaptel-headern etwas änderst musst Du Zaptel natürlich neu kompilieren. Ich denke aber, dass Du das eh gemacht hast.

Es handelt sich dabei um eine Gesko Anlage. Aber die alleine ist ja auch nicht das problem, denn sonst hätte ich das Problem ja nicht auch auf dem Snom und den Softphones. (Bei der ISDN Anlage kommt es nur wesentlich stärker). Ich glaube als nächstes versuche ich mal testweise die Anlage an die Amtsleitungen zu hängen (wenn ich die im Anlagenbetrieb ans laufen bekomme) und hänge * an den internen S0 bus.

Und ja, natürlich habe ich das neu compiliert - ich rufe immer die compile.sh auf wenn ich was an den sourcen änder.

Ich habe jetzt testweise mal mISDN und chan_isdn anstelle der bristuff lösung eingesetzt - und da habe ich interessanterweise kein echo. Leider läuft das so instabil das an einen tatsächlichen Einsatz nicht zu denken ist - irgendwer hier im Forum hat bristuff und mISDN verlgichen mit läuffähiger porsche gegen kaputten ferrari. würde inzwischen eher von läuffähige ente vs. golf mit motorschaden reden.

Marc

 

[torstenkrueger]

Dann scheinen sich bei Dir mehrere Problemkreise zu überlagern.
Das 'normale' Voip-Echo kommt wie oben beschrieben zu Stande. Die ISDN-Bridge zu Deiner Gesko-Anlage sollte da kein Echo induzieren. Aber Du schreibst ja auch nicht nur von Echo sondern auch von sonstigen Störungen.
Was für eine Hardware verwendest Du? Hast Du einen SMP-Kernel oder einen Uniprozessor-Kernel? Wie ist die Interruptverteilung der HFC-Karten? Wir haben eigentlich mit Non-SMP Kerneln die besten Erfahrungen gemacht. Ich würde einen Uniprozessorkernel nehmen und im Zweifelsfall bei Intel P4 mal Hyperthreading im Bios abschalten. Falls möglich mal die Steckplätze der Karten tauschen.

Ansonsten: Das Setup erstmal ein wenig simplifizieren. Erstmal nur die Karten zum Amt rein und schauen, dass das mit SIP-Telefon sauber läuft. Hierzu brauchst Du eine Gegenstelle die reproduzierbar Ärger macht (sowas wie oben geschilderte Kombi mit DECT-Telefon und Istec-Anlage.. oder halt einen geduldigen Menschen). Eine Gegenstelle die stressfrei sein sollte dürfte ein Handy sein. Die Mobilfunkbetreiber setzen eh Echounterdrückung ein, da die Laufzeiten im GSM-netz die gleichen Probleme wie bei Voip induzieren.

Die von mir beschriebenen Tellabs Echocanceler dürften Dir nicht weiterhelfen. Wir haben die seinerzeit bei Ebay geschossen - für eigentlich relativ akzeptable 400¤ für zwei Canceller mit jeweils 4x E1 - also 120 Kanäle. Das dumme ist nur, dass diese Dinger aus dem Carrierumfeld kommen, entweder T1 oder E1-Schnittstellen haben (also 24 oder 30 Lines pro Einschub) und meistens im Rudel auftreten (Rack mit 8 Slots). Für Analog findest Du sowas auch noch...
Wir haben das damals gemacht, als es noch keine Digium 411 oder Sangoma a104D gab. Aber das ist wie gesagt alles für den Primärmultiplexanschluß. Für BRI fällt mir als 'amtliche' Lösung im Moment nur die Eicon Diva Server ein. Ebaypreis dafür dürfte so zwischen 300 und 600 ¤ für die 4-Bri sein. Falls Du Dich dafür entscheidest achte darauf, dass es wirklich eine Diva _Server_ ist, manche anderen Eicon Karten werden nicht unterstützt!

 

[dischneider]

Ich habe jetzt testweise mal mISDN und chan_isdn anstelle der bristuff lösung eingesetzt - und da habe ich interessanterweise kein echo. Leider läuft das so instabil das an einen tatsächlichen Einsatz nicht zu denken ist - irgendwer hier im Forum hat bristuff und mISDN verlgichen mit läuffähiger porsche gegen kaputten ferrari. würde inzwischen eher von läuffähige ente vs. golf mit motorschaden reden.

Hmm, also das hatte ich auch - mit einem instabilem mISDN-Treiber (war 0.3.1-rc10 bzw. 0.3.1-rc13) - siehe diesen Thread.

Mit der jetzt von mir genutzten Version (0.3.1-rc15) läuft das Ganze zuverlässig.

Und - Die Echoproblematik habe ich mit
echocancel=64 bzw.
echocancel=32

recht gut hinbekommen (bisher kamen zumindest keine Klagen).

Dirk

 

[JayKa]

Hallo,
meine Zwischenfrage ist sicherlich unter dem Niveau dieser Diskussion und auch leicht OffTopic, aber wo finde ich diese "compile.sh"? Wie läuft das ganze dort dann ab?
JayKa

 

[britzelfix]

@JayKa

Die "compile.sh" befindet sich im Bristuff-Paket. Das Bristuff-Paket kann man
auf der Junghanns Seite http://www.junghanns.net/ herunterladen.

Läuft wie folgt ab: maßgebend sind 2 scripte download.sh und compile.sh
download.sh lädt die benötigten pakete wie asterisk,zaptel,libpri usw.
herunter und wendet die patches an. compile.sh compiliert und installiert die Pakete.

Alles andere im Wiki bzw. Howtos.

Gruß
britzelfix

 

[JayKa]

Ist das compilieren nur für Bristuffeinstellungen nötig, oder immer, wenn ich manuell einträge in den configs vornehme?
Werden einstellungen in der zapata.conf, wie zB echocancel, nur bei installierter ISDN Hardware beachtet, oder gilt das für alle Gespräche? Ich benutze einen externen ISDN-Gateway (Lancom 1823)? Ich habe da nämlich auch oft Echoprobleme auf eigener Seite bei vielen bestimmten Gegenstellen.