Echo nur auf SIP Telfon

Holg

Neuer User
Mitglied seit
17 Sep 2004
Beiträge
139
Punkte für Reaktionen
0
Punkte
0
Hallo,

Ich habe eine octobri Karte davon sind zwei Anschlüsse mit echocancel=yes und echocancelwhenbridged=yes zur Telekom, sowie 8 Anschlüsse mit echocancel=yes und echocancelwhenbridged=yes im NT Mode nach intern. Mein Problem:

1) Es kommt ein Gespräch von Extern (Telekom) rein, ich nehme es mit meinem SIP Phone (SNOM 360) entgegen. Manchmal (nicht reproduzierbar wann) höre nur ich ein Hall (Echo). Der Anrufer selber merkt nichts. Das Seltsame ist, dass das nur mit dem SIP-Phone passiert, nicht aber mit den anderen internen ISDN-Telefonen.

2) Es kommt ein Gespräch von extern, ich höre kein Hall (Echo), dann will ich auf ein internes ISDN Telefon vermitteln, wenn der internet Teilnehmer mit mir spricht hallt es bei mir (nur bei mir). Diese Erscheinung ist übrigens auch nicht reproduzierbar.

Weiß jemand Rat?
Gibt es auch ein echocancel für SIP-Phones???

Danke für etwaige Tips und Hinweise.
Gruß
Holg
 

psi123

Neuer User
Mitglied seit
25 Okt 2004
Beiträge
28
Punkte für Reaktionen
0
Punkte
0
Habe das selbe Problem in gleicher Konfiguration.
Schiebe die Schuld bisher immer auf die SNOMS....

Christian
 

alex-911

Mitglied
Mitglied seit
6 Aug 2005
Beiträge
261
Punkte für Reaktionen
0
Punkte
0
psi123 schrieb:
Habe das selbe Problem in gleicher Konfiguration.
Schiebe die Schuld bisher immer auf die SNOMS....

Christian
hallo

muss wegen "halblesens" nochmal ran, sorry: ;)
das ist so für 1. nicht ganz richtig. das echo, dass du auf der IP seite hörst, wird auf der anderen seite der verbindung erzeugt.
d.h. dein provider sollte das echo auf dem rückweg zu dir canceln. :)

weiteres problem: die festnetzprovider benutzen im nationalen netz (wohlbemerkt: TDM festnetz) meist keine echocanceller, da die delays hier vernachlässigbar sind.

in diesem fall ist es die BRI karte, die das echo canceln sollte.

gruss
/alex
 
Zuletzt bearbeitet:

psi123

Neuer User
Mitglied seit
25 Okt 2004
Beiträge
28
Punkte für Reaktionen
0
Punkte
0
hmm,
aber ich hab doch auf der ISDN Karte den Echo Canceller aktiviert...
greift der da nicht?
 

alex-911

Mitglied
Mitglied seit
6 Aug 2005
Beiträge
261
Punkte für Reaktionen
0
Punkte
0
ich hab das gefühl, er erwischt das echo nicht mehr, da das delay schon zu gross ist. echo canceller haben je nach hersteller und verwendeter spezifikation unterschiedliche "tail lengths", in denen sie arbeiten.
kann der EC zB max. 64ms und dein echo kommt später, hast du pech gehabt. kann man die länge des ECs auf dieser karte konfigurieren?.

zum 2. punkt von holg: das sieht eben für mich so aus, als sei das delay im lokalen IP netz schon viel gross.

mir fehlt leider die erfahrung mit dieser BRI karte. was ich machen würde:

- das delay im LAN überprüfen
- die EC parameter bzw. die EC funktion überprüfen.

gruss
/alex
 

Holg

Neuer User
Mitglied seit
17 Sep 2004
Beiträge
139
Punkte für Reaktionen
0
Punkte
0
ich hab das gefühl, er erwischt das echo nicht mehr, da das delay schon zu gross ist
Wie meinst du 'er erschwischt das echo nicht mehr'? Versteh dich irgendwie überhaupt nicht :grübel:

Also ich hab das bisher immer so verstanden:

Anruf kommt per ISDN rein -> asterisk prüft ob ein echo vorhanden ist -> echo wird eventuell durch eine echocancel funktion rausgerechnet -> ton wird weitergegeben durchs IP Netz an das SNOM

Vom SNOM zum asterisk sollte es doch eigentlich kein Echo cancel geben, da es sich ja um IP-Pakete handelt. Asterisk leitet doch dann die Sprachpakete (zumindets bei ALAW/ULAW) direkt ohne Umrechnung an die BRI Karte.

Würde mich mal interessieren was passiert, wenn ich beispielsweise GSM als codec nehme und asterisk das ganze umrechnen muss.

Also über Aufklärung wäre ich sehr dankbar ;o)
 

alex-911

Mitglied
Mitglied seit
6 Aug 2005
Beiträge
261
Punkte für Reaktionen
0
Punkte
0
hi

stell dir vor, der echo canceller könnte echos bis zu einer max. verzögerung von zB 24ms erkennen und "rausrechnen". was passiert, wenn das echo 25ms nach dem normalen signal kommt? ;)
sowas kommt heute immer öfter vor, denn immer mehr provider arbeiten mit IP, ohne dass man das als "ISDN kunde" unbedingt bemerken muss. aber im regelfall reichen zB 24ms aus, wenn es sich um reine TDM festnetz verbindungen handelt.


der echo canceller sitzt auf der BRI karte. über das asterisk configfile wird er nur konfiguriert.


strengenommen müssen auch IP phones echo canceln. hier sind aber beide seiten des analog teils (mic, lautsprecher, A/D wandler (DSPs)) vom gleichen hersteller und es sollte nicht zu fehlanpassungen kommen. auf jeden fall müssen ATAs, an die beliebige analogtelefone angeschlossen werden können, echos untedrücken.

GSM gibt zusätzliches encoding und decoding delay :)

im prinzip hast du also völlig recht. ist diese octo karte weit verbreitet? dort würde ich nochmal die konfiguration bzw. die funktion prüfen.
hörst du immer echo aus dem festnetz oder nur zu bestimmten providern?

gruss
/alex
 

Holg

Neuer User
Mitglied seit
17 Sep 2004
Beiträge
139
Punkte für Reaktionen
0
Punkte
0
*paling*

Danke für die Erläuterung. Jetzt hat's geschnackelt.
ist diese octo karte weit verbreitet?
Zumindest gibt es die Karte auch als Quadbri Karte. Der Hersteller ist Junghanns und wenn mich nicht alles täuscht ist das neben beronet/syrrix Karten (so glaub ich) die meist benutzte BRI-Karte im Zusammenhang mit asterisk.

hörst du immer echo aus dem festnetz oder nur zu bestimmten providern?
Ist wie gesagt nicht reproduzierbar, aber soweit ich weiß waren es eigentlich immer Festnetzgespräche.

der echo canceller sitzt auf der BRI karte. über das asterisk configfile wird er nur konfiguriert.
Ich hab diesbezüglich (echo Problematik) vor einiger Zeit schon einmal mit Herrn Junghanns gesprochen. Er meinte damals, dass man auch einen anderen echocancler benutzen kann. So wie ich das (damals) verstanden habe sind die unterschiedlichen Echocancler im bristuff Treiber abgebildet, kann mich da aber natürlich mal wieder täuschen :wink:

Werde mal morgen mit meinem durch dich etwas erweiterten Wissensstand bei junghanns anrufen und nachfragen.

Wenn es dich interessiert, du kannst den bristuff-Treiber unter www.junghanns.net downloaden.

[edit]
Hab gerade mal hier http://www.voip-info.org/wiki/index.php?page=Asterisk+config+zapata.conf geschaut.

Dort steht unter anderem:
echocancel: Disable or enable echo cancellation (default is 'yes'). It is recommended that you do not turn this off. You may specify echocancel as 'yes' (128 taps), 'no' (0 taps, disabled), or a preset number of taps which are one of 16, 32, 64, 128, or 256. Each tap is one sample from the data stream, so on a T1 this will be 1/8000 of a second. Accordingly the number of taps equate to a 2ms, 4ms, 8ms, 16ms or 32ms tail length. Beware that if you set echocancel to a different value, Asterisk will fall back to the default of 128 taps without warning.
echocancel=no
Wie darf ich mir das jetzt vorstellen? Standardmäßig bei echocancel=yes ist der EC auf 128 taps (32 ms) eingestellt? Ich kann ihn aber über echocancel=256 auf 64ms stellen? Und wie ist das mit diesem fallback auf 128, wann fällt er zurück?

Wofür ist eigentlich echocancelwhenbridged bzw. was ist ein bridged call?

Fragen, Fragen, Fragen...
Danke schon einmal für mögliche

Antworten, Antworten, Antworten :wink:

gruß
Holg
 
Zuletzt bearbeitet:

alex-911

Mitglied
Mitglied seit
6 Aug 2005
Beiträge
261
Punkte für Reaktionen
0
Punkte
0
Holg schrieb:
Ich hab diesbezüglich (echo Problematik) vor einiger Zeit schon einmal mit Herrn Junghanns gesprochen. Er meinte damals, dass man auch einen anderen echocancler benutzen kann. So wie ich das (damals) verstanden habe sind die unterschiedlichen Echocancler im bristuff Treiber abgebildet, kann mich da aber natürlich mal wieder täuschen :wink:
hier liegst du richtig und ich hab mal wieder nicht zu ende gedacht ;)


bzgl der taps: bei 128 taps und G.711 müssten es 16ms sein, wen ich mich nicht verrechnet habe. es könnte bei deinem problem also helfen, ihn auf 256 taps zu stellen.

das fallback verstehe ich so: setzt du ihn auf einen unzulässigen wert, zB 155, setzt er sich auf den default 128, und das ohne error oder warnung.

echocancelwhenbridged bezieht sich hier auf reine TDM calls von einen BRI port zum anderen, zB NT port <-> interner port


bridged call: jeder von asterisk vermittelte call wird "gebridged". d.h. die beiden call legs für rufender und gerufener werden verbunden. asterisk bridged zwischen verschieden channeln, worin seine eigentliche stärke liegt.
als beispiel: du callst von einem SIP phone ins festnetz asterisk bridged dafür den call zwischen den channeln SIP und BRI. der parameter vom BRI treiber oben bezieht sich aber nur auf TDM bridges und müsste zum besseren verständnis eigentlich "echocancelwhenTDMbridged" heissen :D

wenn du im asterisk die verbosity auf zB 5 setzt, siehst du, wie jeder call "gebridged" wird. (set verbose 5)


gruss
/alex
 

ike

Aktives Mitglied
Mitglied seit
18 Apr 2005
Beiträge
1,004
Punkte für Reaktionen
0
Punkte
0
alex-911 schrieb:
weiteres problem: die festnetzprovider benutzen im nationalen netz (wohlbemerkt: TDM festnetz) meist keine echocanceller, da die delays hier vernachlässigbar sind.
Gibt es denn Deines Wissens nach CbC-Provider, die Echo-Canceller verwenden? Wir setzen bristuff mit zwei HFC-Karten ein und haben teilweise Echos bei ausgehenden Anrufen - nahezu nie bei ankommenden.

Wenn es jetzt bestimmte CbC-Provider gäbe, die das Echo bekämpfen, wäre ich alle meine Probleme los ;-)

Ich habe schon sämtliche Einstellungen bei bristuff geändert, auch unterschiedliche Echo-Canceller. Ich hoffe jetzt nur noch auf die Finalversion des bristuff-Patches, denn da soll ein Problem mit txgain gelöst sein, was wohl auch Echos verursachen kann.

Evtl. werde ich auch mal sehen, ob ich meinen Chef dazu bringen kann, die kommende 4fach-ISDN-Karte von Digium zu kaufen - die hat einen internen Echo-Canceller in Hardware.

Michael
 

Holg

Neuer User
Mitglied seit
17 Sep 2004
Beiträge
139
Punkte für Reaktionen
0
Punkte
0
hmmmm mit echocancel = 256 ist das ganze ne richtige Katastrophe... da sind dann alle Gespräche nur noch mit echo.

Wie ist das mit echocancelwhenbridged wenn echocancel = no gesetzt wird? Ist das dann automatisch auch deaktiviert und funktioniert das trotzdem?

Wenn ja, dann müßte asterisk doch das Echo bei Gesprächen, die von extern ISDN nach intern ISDN gehen canceln und bei extern - ISDN nach SIP oder OOH323 nicht canceln.

Oder irre ich mich?

Gruß
Holg
 

alex-911

Mitglied
Mitglied seit
6 Aug 2005
Beiträge
261
Punkte für Reaktionen
0
Punkte
0
Holg schrieb:
hmmmm mit echocancel = 256 ist das ganze ne richtige Katastrophe... da sind dann alle Gespräche nur noch mit echo.

Wie ist das mit echocancelwhenbridged wenn echocancel = no gesetzt wird? Ist das dann automatisch auch deaktiviert und funktioniert das trotzdem?

Wenn ja, dann müßte asterisk doch das Echo bei Gesprächen, die von extern ISDN nach intern ISDN gehen canceln und bei extern - ISDN nach SIP oder OOH323 nicht canceln.

Oder irre ich mich?

Gruß
Holg
echocancel = 256: wenn das nicht so klappt wie beschrieben, liegt das vielleicht am treiber...? :)

echocancelwhenbridged: ISDN zu ISDN wird nicht nicht gecanceled. nur sobald ein call leg über IP geht, wird gecanceled. zumindest hab ich es so verstanden ;)

gruss
/alex
 

alex-911

Mitglied
Mitglied seit
6 Aug 2005
Beiträge
261
Punkte für Reaktionen
0
Punkte
0
ike schrieb:
Gibt es denn Deines Wissens nach CbC-Provider, die Echo-Canceller verwenden? Wir setzen bristuff mit zwei HFC-Karten ein und haben teilweise Echos bei ausgehenden Anrufen - nahezu nie bei ankommenden.

normalerweise ist EC nur bei internationalen transit switches enabled. ich kenne keinen CbC provider, der einen transit switch betreibt. d.h. nicht, dass es keinen gäbe...
;)

gruss
/alex
 

mgernoth

Neuer User
Mitglied seit
21 Nov 2004
Beiträge
30
Punkte für Reaktionen
0
Punkte
6
Den KB1-echocanceller in asterisk 1.2 mit 256 Taps zu benutzen ist eine schlechte Idee. Dies fuehrt zu Hall-Effekten, da intern eine Variable ueberlaeuft.
Aktiviere testweise einmal den ECHO_CAN_MG2 in der zaptel/zconfig.h und kommentiere den KB1 aus. Danach zaptel neu bauen und den Kartentreiber und das zaptel-Modul entladen und neu laden.
Sollte dies helfen, dann am besten noch den aktuellen MG2-Patch einspielen, welcher auch in der zaptel SVN-Version enthalten ist. Diesen gibt es fuer zaptel 1.2 hier:
http://www.rmdir.de/~michael/mg2ec-limit-coeff-1.2.diff
Dieser sollte (theoretisch) auch mit deutlich mehr Taps zurechtkommen, dies wird allerdings vom aktuellen zapata.conf-Parser nicht unterstuetzt.

Achja, vor dem testen am besten txgain und rxgain auf 0 setzen.