Neue Firmware 7050 ist da (14.03.66)

Status
Für weitere Antworten geschlossen.

BomBastiK

Mitglied
Mitglied seit
2 Okt 2004
Beiträge
353
Punkte für Reaktionen
0
Punkte
0
Und das grosse testen geht los!

Liste der Änderungen in [glow=red:db3dded62e]12[/glow:db3dded62e].03.66 (Das ist hoffentlich nur ein schreibfehler von AVM)
- Sprachqualität verbessert
- Weitere Anbietervorwahlen für die Wahlregeln
- Export/Import der Einstellungen
- CLIP-Verhalten (Analoganschluss) an einzelnen Vermittlungsstellen korrigiert
- Experten-Ansicht: Festnetz-Fallback-Funktion
- Besetzt bei Besetzt mit interner S0-Unterstützung
- Nebenstellen: CLIP - erweiterter Modus
(zusätzliche Anzeige der gewählten Rufnummer pro Anschluss)
- Export/Import der Einstellungen
- Unterstützung für ISDN-Dienstekennung "Daten" am S0-NT
- Liste der Ereignisse jetzt löschbar
- Interoperabilität zu bestimmten ISDN-TK-Anlage optimiert

edit 07:55h:
Bereits 30 Minuten telefoniert ohne Probleme!
 
So ich werd dann mal Tester spielen, ich hab sowieso gerad ne AT Box von AVM da, also kann nicht viel passieren ...

Gruß

sphings


---------------------------------------------------------
edit1

Aufspielen erfolgreich ...
Jetzt kurzer Funktionstest ...


---------------------------------------------------------
edit2

Sicherung der Konfiguration & Rückspielung auf die Box erfolgreich!
Echo bei Handy > Festnetz weiter vorhanden
Echo bei Voip (GMX) > Handy weiter vorhanden
Mehrere Anbietervorwahlen funzt
Clip am analogen Anschluss funktioniert weiterhin (Sinus 701K & CPA720)


Lässt sich aktivieren (obs funzt ka weil kein ISDN)
Weitere Leistungsmerkmale für ISDN-Telefone
Aktivieren Sie die gewünschten Komfort- und Leistungsmerkmale
Ruf abweisen bei besetzt (Busy on busy).
Einkommende Rufe werden abgelehnt, wenn mit der angerufenen MSN bereits ein Gespräch geführt wird.


----------------------------------------------------------
edit3

immer noch dieses doofe Rauschen am Analogen Anschluss bei FN Telefonie ...
 
sphings schrieb:
Echo bei Handy > Festnetz weiter vorhanden
Echo bei Voip (GMX) > Handy weiter vorhanden
Ich kann gar nicht verstehen, dass Du ein Echo hast. Ich habe überhaupt keine Probleme, auch mit der alten Software nicht.
Vielleicht ist es doch so, wie in einem anderen Thread beschrieben, dass es am Fastpath liegt. Fastpath ist ja bei Arcor immer dabei!
Wie sieht es bei anderen aus?
 
BomBastiK schrieb:
sphings schrieb:
Echo bei Handy > Festnetz weiter vorhanden
Echo bei Voip (GMX) > Handy weiter vorhanden
Ich kann gar nicht verstehen, dass Du ein Echo hast. Ich habe überhaupt keine Probleme, auch mit der alten Software nicht.
Vielleicht ist es doch so, wie in einem anderen Thread beschrieben, dass es am Fastpath liegt. Fastpath ist ja bei Arcor immer dabei!
Wie sieht es bei anderen aus?

öhm ich bin aber nicht bei Acor und ich hab kein FP
 
genau deswegen hast Du ja die Probleme....
Ich habe auch Arcor und mit GMX kein Echo...
 
Der größte Unterschied ist doch eigentlich, dass ihr bei Arcor ISDN habt, oder?
 
Wie siehts aus mit Codecs bei der neuen FW?
 
Sorry für OffTopic

Mele schrieb:
Der größte Unterschied ist doch eigentlich, dass ihr bei Arcor ISDN habt, oder?
und das wir Fastpath haben und somit keine Echos bei VoIP, ich denke mal das ist wichtiger. Ich telefoniere nicht über Arcor, ich nutze nur VoIP
 
ISDN-Daten funktioniert hier nicht, mit einen Siemens Gigaset 4075 un einwahl eine ISP. Ich bekomme mit WinXP SP2 einen 651 fehler...

ENUM geht auch nicht ganz gut mit meine .org eintrage.
 
Das einspielen des neuen Update 12.03.66 hat meine FBF 5050 gekilled...

Beim ersten Versuch das neue Update (fritz.box_fon_5050.12.03.66.image) einzuspielen kam ein Fehler alá "nicht erfolgreich - Kernel mismatch".

Beim zweiten Versuch hörte die Info LED nicht auf zu leuchten und ich kam nicht mehr auf die Weboberfläche. Schließlich habe ich nach einer Stunde den Stecker gezogen. Die Box ist jedoch weiterhin nicht erreichbar. Power LED leuchtet, nach kurzer Zeit leuchten alle LEDs einmal kurz, dann wieder nur die Power LED.

Ein Reset ohne Weboberfläche auf Werkseinstellungen gibt es wohl nicht?

Die Hotline von AVM ist dauerbesetzt - ich scheine wohl nicht der Einzige mit Problemen zu sein -

Gruß,
Tin
 
TinTin schrieb:
Das einspielen des neuen Update 12.03.66 hat meine FBF 5050 gekilled...

Beim ersten Versuch das neue Update (fritz.box_fon_5050.12.03.66.image) einzuspielen kam ein Fehler alá "nicht erfolgreich - Kernel mismatch".

Beim zweiten Versuch hörte die Info LED nicht auf zu leuchten und ich kam nicht mehr auf die Weboberfläche. Schließlich habe ich nach einer Stunde den Stecker gezogen. Die Box ist jedoch weiterhin nicht erreichbar. Power LED leuchtet, nach kurzer Zeit leuchten alle LEDs einmal kurz, dann wieder nur die Power LED.

Ein Reset ohne Weboberfläche auf Werkseinstellungen gibt es wohl nicht?

Die Hotline von AVM ist dauerbesetzt - ich scheine wohl nicht der Einzige mit Problemen zu sein -

Gruß,
Tin
Also was ich bei den Updates festgestellt habe ist:
Wenn ich noch irgendein Gerät oder Programm am laufen habe, welches auf das Internet zugreift (z.B. Messenger, P2P, Snom190) dann klappt der Update nicht (Info Leuchte hört nicht auf zu blinken).
Aber hast du es mit der Recover.exe schon versucht?
 
Zum Thema Echo:
siehe hier

Folgendes bitte gründlich lesen.

Ich zitiere mal h26:

H26 schrieb:
Hallo miteinander,

ich lese hier schon eine ganze Weile im Forum mit und habe auch davon sehr profitiert - Danke an alle! Weil das ECHO-Problem hier doch reichlich oft vorkommt und - soweit ich das im Wust überblicke - keine vollständige oder sogar völlig falsche Erklärungen und Vermutungen zu finden sind, möchte ich hier mal mein Wissen darüber beisteuern.


1. Wie entsteht ECHO?

Grundsätzlich gibt es eine Voraussetzung (Laufzeit zwischen Anrufer und Angerufenen) und zwei Ursachen, die je nach Telefonstrecke auch gemeinsam auftreten können:

a) Akustische Kopplung zwischen Hörer und Mikrofon

Praktisch immer vorhanden und daher auch bei reinen ISDN-Verbindungen nicht zu vermeiden. Mehr dazu weiter unten.

b) Elektrische Kopplung an einem analogen Endgerät

Hier werden beide Sprachkanale (hin und rück) über nur zwei Leitungen gemeinsam analog im gleichen Frequenzbereich übertragen. Um die beiden Sprachkreise wieder zu trennen, wird im analogen Endgerät eine Brückenschaltung (genannt Gabelschaltung) verwendet. Diese Brückenschaltung setzt aber bekannte und konstante Leitungs-Wellenwiderstände (das hat mit den ohmischen Widerständen der Leitung nur wenig zu tun!) voraus. Das ist allerdings nicht ganz einfach zu realisieren, so dass man hier keine vollständige Trennung erreichen kann und die Brücke auf einen Kompromiss abgleichen muss.

Das ist aber noch nicht alles: Der DATU (dümmste anzunehmende Telefon-User) hat es nicht so gerne, wenn er sich beim Sprechen nicht selbst im Hörer hören kann. Daher ist eine vollständige Kompensation der beiden Sprechkreise gar nicht wünschenswert und auch nicht realisiert! Das kommt der bei Zweidrahtleitungen ohnehin nicht einfach realisierbaren, vollständigen Trennung aber nur entgegen. Bei älteren Telefonen (z.B. meinem antiken W48) kann man im Telefon den Leitungsabschluss über Jumper verändern und die sog. Rückhördämpfung in geringen Grenzen einstellen und damit das ECHO reduzieren. Ganz unendlich wird sie aber nie!

Das ECHO entsteht nun beim Anrufer, indem das durch die Gabelschaltung beim Angerufenen nicht vollständig unterdrückte, empfangene Sprachsignal des Anrufers den gesamten Weg zum Anrufer wieder zurück läuft. Es hat daher immer die doppelte Verzögerung (hin und rück). Hat der Anrufer selbst eine schlecht kompensierte Gabelschaltung, so kann das Signal bei genügender Signalamplitude auch mehrmals hin und her laufen. Ist die Laufzeit relativ kurz (10ms-Bereich), so ist das ECHO ein Hall; aber im Prinzip ändert das nichts an den weiteren Ausführungen.

Ergänzende Infos hier: http://www.ip-phone-forum.de/forum/viewtopic.php?p=142044#142022


2. Wie kann man ECHO kompensieren?

Für akustische Kopplung gibt es eine "Krückenlösung", die in einigen DECT-Telefonen eingebaut ist. Sie ist zwar recht wirksam, aber meiner Meinung auch reichlich gewöhnungsbedürftig: Einige dieser Telefone regeln die Lautstärke des Hörers einfach etwas herunter, wenn das Mikrofon besprochen wird. Entsteht nun auf der anderen Seite ein ECHO, so hört man es einfach nicht mehr so laut, weil man ja noch spricht und der Hörer gerade etwas leiser ist. Wenn dieser Effekt zu sehr übertrieben wird, ist das Gegensprechen bei diesen Telefonen praktisch unmöglich, weil man erst in einer eigenen Sprechpause die Gegenseite wieder hören kann!

Elektrisch kann man ein ECHO aber auch adaptiv kompensieren. Adaptiv deshalb, weil man weder die Lautstärke, noch die Verzögerungszeit kennt! Man macht das i.d.R. mit einer Art digitalen Filter, bei dem die Koeffizienten variabel sind und eben adaptiv durch einen Iterationsprozess (oder auch schlauer, aber aufwendiger durch Berechnen) so eingestellt werden, dass das empfangene Echosignal durch ein gegenphasiges gleich grosses Signal möglichst vollständig kompensiert wird.

So macht man es übrigens auch bei Satelliten- und Seekabelstrecken. Diese Strecken bringen die zum ECHO erforderliche Verzögerung und am Ende ist - zumindest ausserhalb von der "ISDN-Insel" Deutschland - meist immer ein analoges Telefon mit unvollständiger Gabelschaltung (siehe oben). Im Umkehrschluss kann man folgern, dass bei wirklich reinen (!) ISDN-ISDN-Verbindungen kein (elektrisches) ECHO auftreten kann. Wenn doch, dann ist es höchstwahrscheinlich ein akustisches Problem, bzw. ein ungenügend arbeitender ECHO-Canceler in einem Freisprech-ISDN-Telefon!

Alles braucht - man ahnt es schon - Rechenpower und bei den üblichen 125us Abtastperiode bei 8 bit/Abtastwert einen entsprechend grossen Buffer. Will man z.B. noch bis zu 300ms kompensieren können, so sind das mindestens 300ms/125us = 2400 Byte. Nicht all zu viel, aber es kommen noch einmal mindestens (!) ebensoviele variable Koeffizienten und damit auch Rechenoperationen (Summe von Produkten) dazu, die alle innerhalb von 125us abgearbeitet werden müssen. - Man sieht: Rechenpower wird das Hauptproblem sein. Kein Wunder, denn dazu verwendet man üblicherweise Signalprozessoren und die sind in den Routern wohl kaum zu finden.

Wenn so ein "armer" Controller diesen Job dennoch halbweg erledigen soll, so muss man sich also auf möglichst wenige und einfache Rechenoperationen beschränken. Das führt dann automatisch dazu, dass die Kompensation nicht ganz optimal sein kann und auch noch von der Komplexität des vorgeschalteten CODECs abhängt!


3. Was ganz sicher ziemlich irrelevant ist

* Das Ändern irgend welcher Internet-Einwahlparameter.
* Höhere Up-/Downstreamraten als 128kBit/s.
* Das Bevorzugen irgend eines VoIP-Providers (es sei denn: siehe unten)
* Das Verwenden spezieller Rufnummern (es sei denn: siehe unten)
* Die Frage ob DECT oder nicht (trotz zusätzlichen 10ms Verzögerung/Kanal).
* Die räumliche Trennung von DECT und WLAN (bei mir: 20cm!).
* Das Abschalten von WLAN (ich streame darüber gleichzeitig Musik).
* Dass es nur ein VoIP-Problem ist. (ECHO gibt es auch im Festnetz, aber hier gibt es ECHO-Canceler auf Fernstrecken!)
* Gespräche zu GSM-/UMTS-Netzen (sie verhalten sich wie ISDN).


4. Was ganz sicher ziemlich relevant ist

* Wenn irgendwo zwischen Anrufer und Angerufenen eine analoge Zweidrahtleitung ist.
* Wenn die akustische Kopplung zwischen Hörer und Mikrofon zu hoch ist (ggf. Hörer ausstopfen!).
* Zu hohe Wiedergabelautstärke auf beiden Seiten.
* Freisprechen ist der GAU und eher zu vermeiden (kommt aufs Telefon drauf an).
* Der verwendete CODEC, da hier zusätzliche Laufzeiten dazu kommen, die den ECHO-Canceler im Router überfordern.
* Grundsätzlich ein zu hohes Delay zwischen Anrufer und Angerufenen. (Fastpath kann also was bringen!)


5. Was man kaum abschätzen kann

* Einfluss der Prozessorauslastung im Router durch gleichzeitigen up-/download (ist eher unkritisch).
* Zusätzlich im Router installierte Software (eher kritisch).
* Die Laufzeit der Anbindung des DSL-Providers an das Internet.
* Tageszeitabhängige Laufzeiten der IP-Routen des Internet-Providers.
* Ob der VoIP-Provider nicht doch irgendwo aus Kostengründen bei der Übergabe ins Festnetz eine analoge Zweidrahtstrecke verwendet.
* Ob je nach CODEC noch Platz für eine zusätzliche Echokompensation war und wie gut sie ist (ist immer ein Kompromiss).
* Ob und wann die Router-FW selbstständig die CODECs umschaltet.
* Alles an das ich jetzt nicht gedacht und daher vergessen habe zu erwähnen :lol:


6. Was also optimieren?

* Möglichst ISDN-Telefone verwenden (da sie keine Gabelschaltung haben).
* DECT-ISDN-Telefone sollten unkritisch sein.
* DECT-Analog-Telefone haben oft die oben erwähnte "Krückenlösung".
* Analoge Telefone könnte man elektrisch besser kompensieren. (Vergiß es bei modernen Telefonen!)
* Auf möglichst geringe Laufzeiten achten (betrifft CODEC und ggf. auch ISP, sowie alle Telefon-Vermittlungslaufzeiten)
* Wiedergabelautstärke auf beiden Seiten reduzieren.
* Freisprechen vermeiden oder Luxustelefon verwenden, dass das gut kann! (Es enthält selbst eine Echokompensation.)
* Gespräche von und zu reinen ISDN-Endgeräten via VoIP bevorzugen. (Aber wer kann das schon?)
* Analoge Zweidrahtleitungen und -Endgeräte möglichst vermeiden (da sie eine Gabelschaltung haben)!
* CODEC mit geringster Verzögerung (z.B. G.711a/u ggf. auch noch G.726) benutzen.
* Andere Hardware (z.B. DSP) im Router einsetzen! (Ist aber zu teuer.)
* Firmware natürlich mit Echokompensation verwenden :wink:
* Ach ja: Bei einem Software-Phone (X-Lite usw) ein Headset verwenden, um wenigstens die akustische Koppung zu minimieren.


Bleibt noch eine Frage zu klären: Warum ist SKYPE so gut? - Antwort: Es wird eine sehr effektive Echokompensation haben, denn ein PC ist i.d.R. besser als number-cruncher geeignet als ein Controller in einem Router! :idea: Da spielt es dann keine Rolle mehr, ob am anderen Ende eine ungünstig kompensierte Gabelschaltung in einem analogen Telefon vorhanden ist.

So, ich hoffe das Thema ist mal an dieser Stelle hinreichend dargestellt.

Und als Ergänzung von southy

southy schrieb:
Hallo H26,

Glückwunsch zu Deinem fundierten und gehaltvollen Posting.
Damit die Sache vollständig wird, würde ich aber noch einen weiteren Punkt (zwischen Deinem 1. und 2., ich nenne es mal 1.5) hinzufügen. Das ist zwar für Leute, die sich mit der Materie auskennen, offensichtlich klar, aber für Einsteiger ist es einer der entscheideneden Punkte zum Verständnis:

----------------

1.5 "Aber bisher hatte ich doch auch kein Echo, warum jetzt plötzlich bei Nutzung von VoIP?"
Wie in 1. geschildert, gibt es bei jeder Telefonverbindung ein Echo. Warum ist das bei POTS kein Problem?
Wie "stark" ein Echo wahrgenommen wird, ergibt sich aus:
- der Laufzeit der Signale
- der Amplitude des Signals

Wie gesagt, entsteht ein Echo dadurch, daß ein Signal vom einen Ende der Verbindung zum anderen Ende läuft (so weit, so gut), dort reflektiert wird und die Leitung wieder zurück zum Ausgangsort läuft, wo es dann abgespielt und gehört wird. Das ist immer so, egal ob VoIP oder PSTN.
Das entscheidende ist jetzt, daß der Mensch ein Signal erst dann als Echo wahrnimmt, wenn die Zeit zwischen "in den Hörer sprechen" und "Echo hören" eine bestimmte Größe übersteigt.

Laufzeiten bis zu 50ms werden z.b. allgemein als "gute" Qualität des Gesprächs wahgenommen. Bei Interkontinentalgesprächen tolerieren die Nutzer meist auch längere Laufzeiten.

Bei PSTN ist der größte Teil der Laufzeit durch die physikalische Ausbreitungsgeschwindigkeit der Welle im Kabel gegeben.
Bei VoIP kommt hier etwas ganz entscheidendes dazu:

Die Daten werden am einen Ende in ein IP-Paket gefüllt. Dieses Paket kann erst abgeschickt werden, wenn es voll ist. Das macht, sagen wir mal, 20ms aus vom Start des Signals bis zum "gefülltsein" des Pakets. (soviel Sprache "passt" in das IP-Paket).
Das gleiche an der Gegenstelle rückwärts: erst wenn das Paket ganz eingetroffen ist, wird es bearbeitet und der Inhalt abgespielt. Das sind schonmal 40ms.
Dort wird es reflektiert, wieder in ein IP-Paket gefüllt, übertragen und dann wieder ausgepackt.
Sind wir also bei 80ms.
Dann rechne noch buffer (ein Paket wird nicht sofort abgespielt), IP-Stack, codierung und dekodierung des Signals und drumherum dazu und du kommst auf die Faustregel, daß die Endgeräte alleine locker 120 ms latency erzeugen können.
[Faustregel: one-way latency kann grundsätzlich nie kleiner als 2-3 Pakete sein: ~60ms.] (dadurch erklärt sich auch, warum Fastpath für VoIP durchaus Sinn macht).
Dazu kommt dann noch die physikalische Laufzeit des Signals, IP-Router usw. Auf 150ms zu kommen ist also kein Kunststück.
Und hier sind noch keinerlei erschwerende Umstände wie verlorene Pakete, hoher Netzwertraffik, etc. berücksichtigt.

Also:
- Echo gibt es immer, es wird erst durch die Verzögerung bei der Wiedergabe störend.
- Das fällt beim POTS aufgrund der niedrigen Signallaufzeit nicht weiter auf. Bei VoIP liegt es aber in der Natur der Sache als paketvermittelter Dienst, daß die Laufzeit _wesentlich_ größer ist.

Es ist also nicht verwunderlich, wenn es bei VoIP Echo gibt, sondern eher, wenn es keins gibt: Denn dann ist ein aktiver Echo-canceller am Werk.

-> hier weiter bei H26 Punkt 2.
 
Upgrade meiner 7050 ging problemlos. Das Problem mit den Kurzwahlen wurde behoben, neu ist auch die Anzeige der jeweiligen Anbieterkennung (*12x#) bei Internettelefonie.

Edit:

@radar: Koennten wir hier bitte beim Thema bleiben? Echoprobleme werden schon ausgiebig in anderen Threads diskutiert.
 
@radar
ein Link auf den entsprechenden Thread hätte auch gelangt,
dann müßte man sich nicht durch Seitenlange Quotes durchwühlen um im eingentlichen Threat (Neue Firmware) weiterzulesen

Gruß
Klaus
 
@staubsauger-nono
Der Link hätte leider nicht gelangt wie man an der hier im Thread schon wieder beginnenden Echo-Diskussion sehen kann obwohl in vielen anderen Threads dieses Thema bis zum ..... abgehandelt wurde.

@clueless
Deswegen dieser Versuch die Diskussion zu beenden.
 
BomBastiK schrieb:
Also was ich bei den Updates festgestellt habe ist:
Wenn ich noch irgendein Gerät oder Programm am laufen habe, welches auf das Internet zugreift (z.B. Messenger, P2P, Snom190) dann klappt der Update nicht (Info Leuchte hört nicht auf zu blinken).
Aber hast du es mit der Recover.exe schon versucht?

Nach langem Gefummel mit Recover.exe habe ich sie jetzt ein Glück wiederbeleben können. Dass mit den evtl. bestehenden Internetverbindungen ist interessant und gut zu wissen - dann passiert es hoffentlich beim nächsten Update nicht noch einmal! Danke!

Gruß,
Tin
 
Das Aufspielen hat bei mir ohne Probs geklappt und die Anrufverzögerung ist fast komplett weg, sehr schön soweit.
Auch die CLIP-Informationen werden jetzt in der Anruferliste der FritzBox angezeigt, jedoch NICHT auf mein Telefon weitergeleitet :?
Liegt das jetzt vielleicht wirklich daran das ich ein SMS-fähiges Telefon habe (T-Sinus 514 AB)?? Kann übrigens die SMS-Funktion nicht ausschalten! Hab auch gerade kein anderes Telefon zum probieren hier ...

Gruß,
Dennis

PS: Ist mein erster Beitrag! Tolles Forum, hat mir echt geholfen!!
 
Das mit der CLIP Funktion hab ich jetzt nicht ganz verstanden. Mit Clip ist doch gemeint, dass man die Nummer des Anrufers sieht, richtig?
Das ging bei mir schon seit eh un je. Sowohl am Telefon selbst, als auch auf der FBF werden die Nummern der Anrufer angezeigt, sofern diese vom Anrufer übertragen werden.
Ich habe auch ein SMS fähiges Telefon (Siemens Gigaset SX100). Hast Du ISDN? Ich habe ISDN, vielleicht liegt es ja daran.
 
Status
Für weitere Antworten geschlossen.
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.