Faxen funktioniert seit Umstellung auf Telekom VoIP nicht mehr. Sipgate besser?

@frank_aus_wedau Du schreibst ja, Du hast mehrere Anschlüsse / Telefonanlagen usw. Was liegt eigentlich näher einfach einen VoIP Anschluss probeweise an das "Faxsystem" anzuschließen und einfach probieren ob der Versand zufriedenstellend funktioniert. Hier im Forum sind viele Privatanwender oder kleinere Firmen, die eben solch ein Faxvolumen "30 Seiten in einem Sendevorgang" im Normalfall nicht erreichen.

Umstellen auf E-Mail geht nicht? Mein Fax kann z.B. wenn im Adressbuch die E-Mail Adresse hinterlegt ist, einfach eine E-Mail mit einem PDF Angang an den
Empfänger verschicken. Klappt recht gut ...

Zu Deiner Bonusfrage: Das wird Dir nur Dein Provider beantworten können, ob diese MSAN-POTS Anschlüsse noch aktiv vermarket werden. Aber ich denke, irgendwann wird schluss sein. Du erwägst ja selbst, den Anschluss aus Kostengründen aufzugeben. Die Gebühren sollten ja bei der Telekom spürbar steigen.
 
Ich würde auch noch darauf achten, das der Audio Codec mit G.711 aLaw und nichts anderem definiert ist.
Der "Audio-Codec" ist T.38, denn über VoIP überträgst du kein Fax mit einem Sprachanruf.

Wie gesagt, Hausaufgaben machen.

Vielen Dank für diese Info. Also werde ich meinen MSAN-POTS-Anschluss bis zum "Sankt Nimmerleinstag" behalten. Oder eben so lange, wie er noch unterstützt wird.
Solange du ein analoges Fax-Gerät nutzen und die Telekom die Umsetzung auf T.38 erledigen lassen möchtest, ist das eine gangbare Lösung. Zumal du ja über POTS (a/b) eine analogelektrische latenz- und jitter-freie-Verbindung zur Line-Card mit T.38-Firmware hast. Auf der Strecke kann also nichts schiefgehen.

Hier im Forum sind viele Privatanwender oder kleinere Firmen, die eben solch ein Faxvolumen "30 Seiten in einem Sendevorgang" im Normalfall nicht erreichen.
Wenn Faxübertragungen überhaupt abbrechen, egal nach wieviel Seiten, dann hast du einen fehlkonfigurierten Faxanschluß mit einer Übertragungssicherheit von 0 %. Bei einem Abbruch wurde fast immer Sprachanruf versucht, wo die Uhren zwischen Sender und Empfänger dann irgendwann auseinander laufen, sie arbeiten also mit geringfügig unterschiedlicher Samplingrate. Diese Konfiguration ist aber schlicht kaputt und stört die Faxübertragung schon ab der ersten Seite. Die Sprachverständlichkeit stört das natürlich nicht.

Faxübertragung mit G.711 im Sprachkanal funktioniert nur im ISDN, wo die Sample-Clock aller Beteiligten 100 % synchron läuft, da vom Netz vorgegeben. Faxübertragung funktioniert auch in einem vollanalogen leitungsvermittelnden Netz, wo zwischen Sender und Empfänger eine direkte elektrische Verbindung hergestellt wird.
 
  • Like
Reaktionen: frank_aus_wedau
du kannst dein Fax auch an eine Fritzbox anschließen und dort T.38 aktivieren

Fax_T38.JPG
[Edit Novize. Bild gemäß der Forumsregeln auf Vorschau verkleinert]
 
Zuletzt bearbeitet von einem Moderator:
nicht für angeschlossene Faxgeräte.
wie kommst Du darauf?

lt.

Ist es ebenfalls für Externe Faxgeräte notwendig

1 Faxübertragung mit T.38 aktivieren​

Wenn Sie eine Internetrufnummer zum Faxen verwenden, müssen Sie für die Faxübertragung T.38 (Fax over IP) in der FRITZ!Box aktivieren. Bei T.38 erfolgt die Übertragung nicht mit Signaltönen, sondern über ein spezielles Netzwerkprotokoll. Dadurch ist die Übertragung wesentlich unanfälliger für Störungen:
  1. Klicken Sie in der Benutzeroberfläche der FRITZ!Box auf "Telefonie".
  2. Klicken Sie im Menü "Telefonie" auf "Eigene Rufnummern".
  3. Klicken Sie auf die Registerkarte "Anschlusseinstellungen".
  4. Klicken Sie im Abschnitt "Telefonieverbindung" auf "Einstellungen ändern".
  5. Aktivieren Sie die Option "Faxübertragung auch mit T.38".
  6. Klicken Sie zum Speichern der Einstellungen auf "Übernehmen".
 
Nein, das gilt nur für die integrierte Fax-Funktion in der Fritzbox, nicht für angeschlossene Faxgeräte.
das ist falsch siehe

Fax_T38-2.JPG
[Edit Novize. Bild gemäß der Forumsregeln auf Vorschau verkleinert]
 
Zuletzt bearbeitet von einem Moderator:
Ich würde sagen beide Aussagen stimmen, wenn easybell rät dies zu deaktivieren, dann soll das so sein.

Wenn AVM aber hier wohl verallgemeinert und auch nie immer alle Einzelfälle abdecken kann, wird ja auch passend im Fehlerfalldokument auf den Provider verwiesen, welcher dann die bei ihm vorliegenden Rahmenbedingungen dem Kunden mitteilt, welcher dann eben extra für diesen Fall eben T.38 deaktiviert, aber wohl die meisten anderen da eben anders arbeiten, wird dies ebenso "abgefangen"


2 Ereignisprotokoll der FRITZ!Box prüfen​

.....
  • Hinweis:Sie können für den Faxempfang dann entweder eine Rufnummer eines Anbieters verwenden, der T.38 unterstützt oder T.38 wieder deaktivieren. Eventuell sind Faxübertragungen ohne T.38 möglich.
 
1. @frank_aus_wedau Du schreibst ja, Du hast mehrere Anschlüsse / Telefonanlagen usw. Was liegt eigentlich näher einfach einen VoIP Anschluss probeweise an das "Faxsystem" anzuschließen und einfach probieren ob der Versand zufriedenstellend funktioniert.

Den Fax-Versand via VoIP habe ich zur Genüge getestet. Mit "einfachen" VoIP-Anschlüssen ist kein Fax-Versand möglich - zumal ich zu Nachweiszwecken auf ECM angewiesen bin. Ohne ECM kommt zwar was an, das Empfangene ist aber jeweils unter aller Kanone.

Hier im Forum sind viele Privatanwender oder kleinere Firmen, die eben solch ein Faxvolumen "30 Seiten in einem Sendevorgang" im Normalfall nicht erreichen.
Ich bin wirklich nur Privatanwender. Allerdings einer derjenigen, die zum Kreis der Juristen gehören und denen es (vorwiegend in eigenen Angelegenheiten) schwer fällt, sich kurz zu fassen. Ein Manko, dass es sich im Alter (50+) nicht mehr abzugewöhnen lohnt. Die (meist vergebliche) Hoffnung, sein Gegenüber mit Sachargumenten überzeugen zu können, ist in meinen Gewohnheiten leider zu tief verankert. :-(

Umstellen auf E-Mail geht nicht? Mein Fax kann z.B. wenn im Adressbuch die E-Mail Adresse hinterlegt ist, einfach eine E-Mail mit einem PDF Angang an den
Empfänger verschicken. Klappt recht gut ...

Ginge schon. Glücklicherweise gehöre ich zu denjenigen, die sich beizeiten zur Ruhe setzen konnten und es sich leisten können, nicht "rund um die Uhr" erreichbar zu sein. Leider wird im Email-Verkehr eine Reaktion binnen weniger Stunden regelrecht vorausgesetzt. Eine Art gesellschaftlicher Konsens, dem ich mich zu unterwerfen nicht bereit bin.

Trotz allem einen herzlichen Dank für Deine Argumente, die für die Mehrheit der Gesellschaft durchaus zutreffen mögen - auch wenn ich diese Entwicklung persönlich für schädlich halte. Der Mensch ist für den gegenwärtigen Aktionismus rund um die Uhr nicht geschaffen. Die steigende Zahl aus psychischen Gründen Erwerbsgeminderter ist aus meiner Sicht ein Warnzeichen, das nicht ausreichend wahrgenommen wird.

In diesem Sinne LG aus Wedau
Frankie

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

easybell will, dass T.38 in der Fritzbox zum Faxen deaktiviert wird.
Das liegt daran, dass easybell T.38 nicht "aktiv" unterstützt. Faxsendungen im T.38-Protokoll werden lediglich 1:1 durchgeleitet, so dass analoge Faxgeräte auf Empfangsseite nur "Bahnhof" verstehen mit der Folge, dass jegliche Übertragung an gewöhnliche Faxgeräte (T.30) fehlschlagen muss.

DUS.net wirbt aber mit einer aktiven Unterstützung des T.38-Protokolls. Ein solches Angebot beinhaltet aber zwingend, dass in Fällen, in denen sich ein Empfangsgerät im T.30-Protokoll meldet, der Provider des Absenders eine "Übersetzung" der gesendeten T.38-Signale in das T.30-Protokoll gewährleistet. Und eben hier vermute ich eine Fehlfunktion im Bereich von DUS.net.

LG aus Wedau
Frank

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Nein, das gilt nur für die integrierte Fax-Funktion in der Fritzbox, nicht für angeschlossene Faxgeräte.

Ist das tatsächlich so?

Das würde theoretisch einiges erklären. Allerdings nicht den Umstand, dass meine vom analogen Fax gesendeten Dokumente zur Empfängerseite im T.38-Protokoll rausgehen (so jedenfalls die Verbindungsprotokolle von DUS.net).

Falls meine FritzBox (wider Erwarten) nicht in der Lage sein sollte, die analogen Signale meines Faxgeräts in das T.38-Protokoll zu übertragen, verbliebe theoretisch noch die Möglichkeit, VoIP-Provider mit dem Merkmal "QoS" (Quality of Service) zu nutzen. Werbeversprechen dieser Anbieter sagen einen problemlosen Faxversand jedenfalls ausdrücklich zu... was aber nicht viel heißen muss....
 
Zuletzt bearbeitet von einem Moderator:
DUS.net wirbt aber mit einer aktiven Unterstützung des T.38-Protokolls. Ein solches Angebot beinhaltet aber zwingend, dass in Fällen, in denen sich ein Empfangsgerät im T.30-Protokoll meldet, der Provider des Absenders eine "Übersetzung" der gesendeten T.38-Signale in das T.30-Protokoll gewährleistet. Und eben hier vermute ich eine Fehlfunktion im Bereich von DUS.net.

Es gibt nur drei Fälle einer solchen Umsetzung.

1. Das Ziel befindet sich in einem voll analogen Telefonnetz in irgendeinem Entwicklungsland. (Gibt es überhaupt noch Länder mit elektromechanischer Vermittlung?)

Betrachten wir hier mal nicht. Internationaler Faxversand war schon immer "würzig".

2. Das Ziel befindet sich an einem EWSD-Anschluß, entweder als EWSD-POTS-Anschluß oder als EWSD-ISDN-Fax. Eine netzseitige Umsetzung von T.38 wird hier nicht unterstützt, da EWSD Legacy-Hardware ist.

Dieser Fall wird zumindest für die Telekom nächstes Jahr wegfallen, da dann die letzten EWSD abgeschaltet werden. Hier wurde der T.30-Datenstrom früher auch per EWSD-Interconnect übergeben und dann über ein ATM-Netz leitungsvermittelt. In diesem Fall hat oft auch T.30 End2End funktioniert, weil die VoIP-Strecke letztlich nur bis zum VoIP-Anbieter reichte, es also bloß ein verlängerter EWSD-Anschluß mit SIP-Nebenstelle war. (Über einen solchen Anschluß funktionierten einst auch Späßchen wie Einwahl mit V.90-Modem an einem leitungsvermittelten V.90-Host und Übertragung von PCM-kodierten Daten - also so wie man in den späten 90ern am EWSD-POTS ins Internet gegangen ist.)

Über die heute längst üblichen IP-Peerings funktioniert davon natürlich gar nichts mehr. Aber nächstes Jahr sind diese Legacy-Anschlüsse eh vom Tisch. Jeder Analoganschluß, an dem ggf. ein Faxgerät hängt, wird dann ein MSAN-POTS (T.38) sein und jeder ISDN-Anschluß endgültig abgeschaltet. Dann bleiben nur noch winzige Regionalbetreiber mit MSAN-ISDN übrig. Es wird dann mangels EWSD natürlich auch keinerlei EWSD-Peerings mehr geben.

3. Das Ziel befindet sich an einem VoIP-Anschluß, der nicht T.38-fähig ist (reiner Sprachanschluß, kein T.38 in den Codecs).

Fax funktioniert hier grundsätzlich nicht und hat auch nie funktioniert.

Das war's eigentlich schon. Wenn auf deiner Seite T.38 verwendet wird und funktioniert (egal ob per Fritzbox oder anderweitig), hast du alles in deinem Einflußbereich stehende getan. Du kannst nicht jede Faxlösung jedes Empfängers oder Absenders reparieren. Die müssen ihre Hausaufgaben selbst machen.

Als Fazit kann man feststellen, daß die Faxübertragung per T.30 so gut wie tot ist, da das dafür notwendige Telefonnetz inzwischen fast vollständig abgebaut wurde und nicht mehr existiert. Dus.net kann also umsetzen, es nützt nur nicht mehr viel, da außer IP bald nichts mehr anderes existiert.
 
Den Fax-Versand via VoIP habe ich zur Genüge getestet. Mit "einfachen" VoIP-Anschlüssen ist kein Fax-Versand möglich - zumal ich zu Nachweiszwecken auf ECM angewiesen bin. Ohne ECM kommt zwar was an, das Empfangene ist aber jeweils unter aller Kanone.

Hallo Frank,

warum braucht man zu Nachweiszwecken ECM ?? ECM Ist doch "nur" ein Fehlerkorrekturverfahren.

Mach mich schlau :)

Gruß
Michael
 
Die Telekom nutzt beim MSAN-POTS kein T.38, da das Interworking verschiedener T.38 Implementierungen bis heute nicht (zuverlässig) funktioniert und vermutlich auch nie funktionieren wird.
 
Und hier mal eine Theorie, warum Gruppe3-Fax (T.30) jetzt auf dem Abstellgleis ist:

Ursprünglich wurde Fax über analogelektrisch verschaltete Leitungen übertragen. Die Vermittlung erfolgte mechanisch. Dieses Netz wurde dann vom digitalisierten Telefonnetz (EWSD) abgelöst und Gruppe3-Fax sollte eigentlich durch Gruppe4-Fax (ISDN) ersetzt werden. Letzteres passierte jedoch nicht. Statt dessen wurde über POTS/PCM-Wandler per Gruppe3 gefaxt (und auch per Modem gesurft).

Das funktionierte, weil beide Wandler mit dem vom Netz vorgegebenen Takt synchron liefen mit exakt 64.000 Bit/s PCM aLaw. Die Ende-zu-Ende-Verbindung war von der Latenz abgesehen 100 % zeit- und bitsynchron.

Eine VoIP-Box mit einem Faxgerät hat auch einen Wandler, der mit ungefähr 64.000 Bit/s läuft, aber letztlich RTP-Pakete mit T.30 im PCM-aLaw-Audiostrom entweder etwas zu langsam oder etwas zu schnell sendet (z. B. mit 63.999 Bit/s oder 64.001 Bit/s, Abweichung hier bewußt übertrieben). Das stört an einer VoIP-Ende-zu-Ende-Verbindung nicht, da die Bitrate einer RTP-Verbindung nicht konstant sein muß und die RTP-Pakete transparent durchgereicht werden.

Aber sobald ein weiterer PCM-Wandler ins Spiel kommt oder ein EWSD, muß die Bitrate exakt 64.000 Bit/s betragen, sonst läuft der Puffer entweder über oder unter. Und in dem Fall fehlen dann ohne Fehlerkorrektur Zeilen im Fax oder die Übertragung bricht nach 3, 10 oder 30 Seiten einfach ab. Das T.30-Protokoll kommt mit analogen Störungen (Rauschen, Knacken oder Nebensprechen) zurecht, aber nicht mit Fehlern in der Zeitdomäne. Daß das Faxgerät am anderen Ende plötzlich in die Vergangenheit oder Zukunft springt, dafür wurde das analoge Protokoll nicht entwickelt.

Die Telekom nutzt beim MSAN-POTS kein T.38, da das Interworking verschiedener T.38 Implementierungen bis heute nicht (zuverlässig) funktioniert und vermutlich auch nie funktionieren wird
Das war kein technisches Problem, sondern ein Lizenzproblem, daß die Telekom IIRC durch Einwurf kleiner Münzen beim Hersteller der MSAN-Firmware inzwischen beseitigen lassen hat.
 
  • Like
Reaktionen: totalverrückteruser
Das war kein technisches Problem, sondern ein Lizenzproblem, daß die Telekom IIRC durch Einwurf kleiner Münzen beim Hersteller der MSAN-Firmware inzwischen beseitigen lassen hat.
Nein, die Telekom hat sich bewusst für Voice Band Data (V.152) bzw. einfaches G.711passthrough entschieden, weil hier insgesamt die Wahrscheinlichkeit für eine erfolgreiche Faxübertragung am höchsten ist. Hier gibt es zwar tendenziell die Probleme, die du oben beschrieben hast, aber es gibt keine Situationen in denen überhaupt keine Übertragung zu Stande kommt, weil die T.38 Implementierungen nicht kompatibel sind.

T.38 wurde zu einer Zeit entwickelt in dem es nur kleine VoIP-Insel in einer vom TDM-basierten PSTN dominierten Welt gab. Da sprachen dann hauptsächlich die VoIP-Endgeräte T.38 mit dem PSTN-Gateway. Wenn nun die verschiedensten VoIP-Endgeräte direkt miteinander über VoIP kommunizieren und T.38 nutzen sollen, endet das gerne schon mal darin, dass überhaupt nichts übertragen wird.

Dieser Markt ist aber im Grunde tot, das merkt man schon daran, dass es praktisch keine T.38 Version 4 Implementierung gibt. Das höchste der Gefühle ist hier Version 3 bei AudioCodes, aber die meisten Geräte haben nur Version 0 oder maximal 1 implementiert.
 
Hallo zusammen,

Weil dieser Faxanschluss inzwischen (bei abnehmender Quantität) entbehrliche Kosten von > 20 € (je nach Nutzung auch deutlich darüber) auslöst, hatte ich diverse Versuche unternommen, den Faxbetrieb in eine VoIP-Flatrate zu integrieren. Jeweils mit suboptimalem (nett geschrieben) Erfolg.

Lediglich DUS.net bietet über das Protokoll T.38 gleichwertige Qualität - aber auch nur dann. wenn die Gegenstelle T.38 ebenfalls unterstützt. Das T.38<->T.30 Gateway scheint unzuverlässig. Angeblich ist es vorhanden - dessen Funktionalität scheint aber nicht feststellbar. Faxe über DUS.net an rein analoge Geräte gehen regelmäßig in die Hose. Allerdings steht mir insoweit nur noch eine regelmäßige Gegenstelle zur Verfügung.

was für ein Internet-Anschluß wird denn genutzt (z.B. Telekom DSL)? Und welche VoIP-Provider hast Du schon probiert außer DUS.net?

Brauchst Du ECM auch am MSAN-POTS-Anschluß für eine erfolgreiche Fax-Übertragung? Oder klappt das Faxen dort auch ohne ECM? (Du schreibst in einem anderen Posting, daß Du ECM benötigst, allerdings ist mir nicht klar, ob Du das nur auf den Faxversand über VoIP beziehst, oder auch auf Deine aktuelle Lösung mit MSAN-POTS).

An einem Telekom IP-Anschluß (also Telekom-DSL mit Telekom-VoIP) habe ich eigentlich in der Vergangenheit eine relativ hohe Erfolgsquote bei (zugegebenermaßen recht seltenen) Faxübertragungen mit G.711 gehabt. Ich habe sogar schon Tests mit V.90/V.92-Modemeinwahlen an solchen Anschlüssen vorgenommen, die teilweise ziemlich gut funktionierten (normale Geschwindigkeit, nur etwas erhöhte Latenz), teilweise mittelmäßig (Fallback auf V.34 o.ä.), teilweise aber auch gar nicht (kein Modem-Handshake möglich).

Auch bei DUS.net gibt es auf meier Seite kein Problem. Das tritt nur dann auf, wenn die Gegenseite ein analoges Faxgerät nutzt, das T.38 nicht unterstützt. In diesen Fällen kommt über DUS.net oft gar nichts an - nicht mal eine einzige Seite. :-(

Weißt Du, in welchen Netzen (also bei welchen Anbietern) die angerufenen Faxrufnummern liegen? Verbindungen zwischen zwei Nicht-Telekom-Netzen laufen teilweise über ungewöhnliche Routings (weil ein Transit über das Telekom-Netz in ein Drittnetz bei den Interconnection-Tarifen relativ teuer ist), was für die Übertragungsqualität nicht unbedingt förderlich ist.

Unter Umständen kann es sogar helfen, im eigenen Router T.38 abzuschalten, damit dieser erst gar kein Umschalten auf T.38 versucht. Denn es ist nicht garantiert, daß nach einem gescheiterten Umschaltversuch zu T.38 die Verbindung weiter als normaler G.711-Anruf weiterläuft.

Die Telekom hat dort T.38 nachgerüstet. Das heißt, sie werden es von Anfang an gehabt haben, aber bewußt nicht eingeschaltet und die Lizenz dafür bezahlt haben, um Gewinne zu maximieren. Nach genug Beschwerden seitens der Kundschaft ging es dann.

Die Telekom unterstützt zwar seit einiger Zeit T.38, aber meines Wissens bedeutet das nur, daß wenn beide Endpunkte sich auf T.38 einigen, dieser T.38-Datenstrom dann transparent durchgeleitet wird. Das Telekom-Netz bietet aber - soweit mir bekannt - selbst kein Gateway zwischen T.38 und G.711.

Das mag noch zufällig funktionieren, weil ggf. Internetconnect zwischen Telekom und Vodafone für diesen spezifischen Anschluß noch über ISDN läuft. Das wird sich aber in naher Zukunft ändern, denn die Telekom wird demnächst das ISDN auch im Backend gänzlich abschalten. Dann wird sämtlicher Verkehr als IP übergeben. Ohne T.38 geht dann kein einziges Fax mehr durch. [...]

Vodafone unterstützt T.38 an bestimmten Anschlüssen mit bestimmter Hardware. Ist die nicht vorhanden, wird der falsche Sprachcodec ausgehandelt oder Latenz/Jitter stimmt nicht mehr mit ISDN überein, bricht die Faxübertragung zusammen.

Vielleicht verwechsle ich da jetzt was, aber hattest Du im ehemaligen Onlinekosten-Forum nicht mal geschrieben, daß das Wegfallen der Umwandlungen zwischen VoIP und ISDN eher positiv für Faxübertragungen wäre?

Bei Vodafone sollte man genauer beschreiben, welches Vodafone-Netz man genau meint: Das Vodafone-ISDN (D009, ehemals Arcor, da müßte es AFAIK noch ein paar Anschlüsse geben), das Vodafone-VoIP an DSL-Anschlüssen (D056), das ehemalige Kabel-Deutschland-Netz (D191), das ehemalige Unitymedia-Netz (D120) oder das ehemalige Kabel-BW-Netz (D127).

Betrachten wir hier mal nicht. Internationaler Faxversand war schon immer "würzig".

2. Das Ziel befindet sich an einem EWSD-Anschluß, entweder als EWSD-POTS-Anschluß oder als EWSD-ISDN-Fax. Eine netzseitige Umsetzung von T.38 wird hier nicht unterstützt, da EWSD Legacy-Hardware ist.

Dieser Fall wird zumindest für die Telekom nächstes Jahr wegfallen, da dann die letzten EWSD abgeschaltet werden. Hier wurde der T.30-Datenstrom früher auch per EWSD-Interconnect übergeben und dann über ein ATM-Netz leitungsvermittelt. In diesem Fall hat oft auch T.30 End2End funktioniert, weil die VoIP-Strecke letztlich nur bis zum VoIP-Anbieter reichte, es also bloß ein verlängerter EWSD-Anschluß mit SIP-Nebenstelle war. (Über einen solchen Anschluß funktionierten einst auch Späßchen wie Einwahl mit V.90-Modem an einem leitungsvermittelten V.90-Host und Übertragung von PCM-kodierten Daten - also so wie man in den späten 90ern am EWSD-POTS ins Internet gegangen ist.)

Früher gab es auf internationalen Strecken teilweise DCME-Technik (digital circuit multiplication equipment), mit der man Telefonverbindungen komprimiert hat, um mehr Anrufe auf eine teure Seekabel- oder Satellitenleitung quetschen zu können. Und ab Mitte/Ende der 90er Jahre kamen dann schon die ersten Wholesale-Carrier, die internationale Gespräche über VoIP vermittelten (z.B. iBasis war da schon früh mit dabei und ist nach einigen Neuformierungen in der Vergangenheit auch heute noch im Markt aktiv) und teilweise auch von Ex-Monopolisten genutzt wurden. Das korrekte Erkennen und Behandeln von Faxverbindungen war damals schon eine Herausforderung. Erstaunlich, daß man in den langen Jahren bis heute das Problem nicht komplett in den Griff bekommen hat...

Meines Wissens wurde bei der Telekom die Vernetzung von EWSD/S12-System mit SDH realisiert und nicht mit ATM, das war natürlich hinsichtlich Taktgenauigkeit ideal.

Die "VoIP-Inseln" von DSL-Providern in den 2000er Jahren habe ich nicht unbedingt in bester Erinnerung. 1&1 hatte damals doch teilweise DSL + VoIP von verschiedenen Netzbetreibern zusammengepuzzelt (z.B. DSL von der Telekom, VoIP von Telefonica), was hinsichtlich QoS nun nicht gerade ideal ist. Bei Hansenet erinnere ich mich an Router / IADs, die für Voice einen komprimierenden Codec (vermutlich G.729) nutzten, wo man dann mit den passenden Pfeifkünsten (die halbwegs an einen Faxton erinnerten) sich eine bessere Verbindungsqualität "erpfeifen" konnte, da gab es irgendwo sogar mal einen Nutzerbericht dazu.

Sollte ich umziehen... kann ich solchen Anschluss (im selben Ortsnetz unter Beibehaltung der Rufnummer) auch neu beauftragen? Oder führt dann an NGN/VoIP o.ä. kein Weg vorbei?

An manchen Standorten ist MSAN-POTS wohl nicht buchbar (z.B. wegen fehlendem Hauptkabel zu einem Telekom-HVt, denn aus Outdoor-MSANs gibt es die POTS-Anschlüsse meines Wissens nicht).

Irgendwo hatte ich mal gelesen, daß in manchen Gebieten evtl. auch Bestandskunden dieser POTS-Anschlüsse auf DSL-Anschlüsse umgestellt werden. Das sind evtl. Gegenden, wo vielleicht ein Hauptkabel aufgegeben wird oder zu wenige POTS-Anschlüsse nachgefragt werden, als daß sich eine Extra-Linecard für diese lohnen würde... offizielle Angaben zu dem Thema sind mir aber keine bekannt.

warum braucht man zu Nachweiszwecken ECM ?? ECM Ist doch "nur" ein Fehlerkorrekturverfahren.

Bei einer erfolgreichen Faxübertragung *mit* ECM kann man davon ausgehen, daß das Faxdokument korrekt übertragen wurde (also vollständig und lesbar).

Bei einer erfolgreichen Faxübertragung *ohne* ECM gab es zwar keinen Verbindungsabbruch, es können aber dennoch Zeilen fehlen oder verschoben sein, etc. In diesem Fall weiß man also als Absender nur, daß der Empfänger ein Fax bekommen hat, aber nicht, wie dieses bei ihm genau aussieht.

Eine VoIP-Box mit einem Faxgerät hat auch einen Wandler, der mit ungefähr 64.000 Bit/s läuft, aber letztlich RTP-Pakete mit T.30 im PCM-aLaw-Audiostrom entweder etwas zu langsam oder etwas zu schnell sendet (z. B. mit 63.999 Bit/s oder 64.001 Bit/s, Abweichung hier bewußt übertrieben). Das stört an einer VoIP-Ende-zu-Ende-Verbindung nicht, da die Bitrate einer RTP-Verbindung nicht konstant sein muß und die RTP-Pakete transparent durchgereicht werden.

Aber sobald ein weiterer PCM-Wandler ins Spiel kommt oder ein EWSD, muß die Bitrate exakt 64.000 Bit/s betragen, sonst läuft der Puffer entweder über oder unter. Und in dem Fall fehlen dann ohne Fehlerkorrektur Zeilen im Fax oder die Übertragung bricht nach 3, 10 oder 30 Seiten einfach ab.

Das Problem gibt es durchaus auch bei VoIP-zu-VoIP-Verbindungen und kann gerade Fax- und Modemverbindungen stören. Die VoIP-Router an den Endpunkten sollen ja aus dem RTP-Stream ein kontinuierliches Audiosignal erzeugen und nutzen den Jitter Buffer als kleinen Zwischenspeicher. Läuft dieser Speicher leer, muß der Router selbst ein Pseudo-Voice-Signal errechnen - läuft er über, werden irgendwann VoIP-Pakete weggeschmissen. Ein gut konfigurierter Jitter Buffer sollte bei Faxverbindungen statisch(!) sein und eine gewisse Größe haben, dann kann er solche Taktdifferenzen durchaus in einem gewissen Rahmen abfangen.

Nein, die Telekom hat sich bewusst für Voice Band Data (V.152) bzw. einfaches G.711passthrough entschieden, weil hier insgesamt die Wahrscheinlichkeit für eine erfolgreiche Faxübertragung am höchsten ist. Hier gibt es zwar tendenziell die Probleme, die du oben beschrieben hast, aber es gibt keine Situationen in denen überhaupt keine Übertragung zu Stande kommt, weil die T.38 Implementierungen nicht kompatibel sind.

T.38 wurde zu einer Zeit entwickelt in dem es nur kleine VoIP-Insel in einer vom TDM-basierten PSTN dominierten Welt gab. Da sprachen dann hauptsächlich die VoIP-Endgeräte T.38 mit dem PSTN-Gateway. Wenn nun die verschiedensten VoIP-Endgeräte direkt miteinander über VoIP kommunizieren und T.38 nutzen sollen, endet das gerne schon mal darin, dass überhaupt nichts übertragen wird.

Es gab aber schon Fälle bei Telekom-VoIP-Anschlüssen, wo eine Faxverbindung nach einer abgelehnten T.38-Umschaltung nicht wieder als normaler G.711-Anruf weiterlief. Hierzu gab es auch Diskussionen z.B. im legendären Onlinekosten-Forum.

Soweit ich mich erinnere, hatte die Telekom-Plattform da beim Durchreichen des T.38-Re-Invites sofort den RTP-Stream unterbrochen und ihn nach dem Ablehnen des Re-Invites nicht wieder durchgeschaltet. Dabei spielte wohl auch ein nicht ganz korrekt formuliertes SIP-488-Paket der Re-Invite-Ablehnung eine Rolle. Meines Erachtens hätte der RTP-Stream aber gar nicht erst unterbrochen werden dürfen, sondern hätte einfach unverändert weiterlaufen müssen, solange es zu keinem erfolgreichen Re-Invite kommt.

cu talk2chris
 
Nein, die Telekom hat sich bewusst für Voice Band Data (V.152) bzw. einfaches G.711passthrough entschieden, weil hier insgesamt die Wahrscheinlichkeit für eine erfolgreiche Faxübertragung am höchsten ist. Hier gibt es zwar tendenziell die Probleme, die du oben beschrieben hast, aber es gibt keine Situationen in denen überhaupt keine Übertragung zu Stande kommt, weil die T.38 Implementierungen nicht kompatibel sind.
Das ist natürlich tragisch. Denn eigentlich sollten T.38-Faxgeräte einfach per RTP ihre Daten digital übertragen (und zwar am besten mit Wirespeed) und nicht in einem Voice-Kanal herummodulieren, wo es dann ewig dauert, bis alle Seiten übertragen sind.

Allerdings wird vermutlich das gleiche Problem bestehen wie beim Gruppe4-Fax: Über T.30 im Audio-Kanal ist man nie hinausgekommen.

T.38 wurde zu einer Zeit entwickelt in dem es nur kleine VoIP-Insel in einer vom TDM-basierten PSTN dominierten Welt gab. Da sprachen dann hauptsächlich die VoIP-Endgeräte T.38 mit dem PSTN-Gateway. Wenn nun die verschiedensten VoIP-Endgeräte direkt miteinander über VoIP kommunizieren und T.38 nutzen sollen, endet das gerne schon mal darin, dass überhaupt nichts übertragen wird.
Aber genau in diesem Uralt-Szenario brauchte man doch gar kein T.38, denn dort funktioniert doch G.711 VBD am besten, weil's dann doch eh direkt ins PSTN geht.

Bei Vodafone sollte man genauer beschreiben, welches Vodafone-Netz man genau meint
Gemeint waren einige wenige DSL-Easyboxen, die T.38 könnten.

Meines Wissens wurde bei der Telekom die Vernetzung von EWSD/S12-System mit SDH realisiert und nicht mit ATM, das war natürlich hinsichtlich Taktgenauigkeit ideal.
Allerdings ist das auch nur eine Vermutung ins Blaue, daß daran die Abbrüche nach 10 oder 30 Seiten liegen. ADC und DAC laufen eben irgendwann auseinander, wenn sie nicht vom Netz getaktet werden.

Das Problem gibt es durchaus auch bei VoIP-zu-VoIP-Verbindungen und kann gerade Fax- und Modemverbindungen stören.
Das meinte ich ja. Voice Band Data leidet genau darunter, egal ob PSTN im Spiel ist.

Es gab aber schon Fälle bei Telekom-VoIP-Anschlüssen, wo eine Faxverbindung nach einer abgelehnten T.38-Umschaltung nicht wieder als normaler G.711-Anruf weiterlief. Hierzu gab es auch Diskussionen z.B. im legendären Onlinekosten-Forum.
Das sind so Dinge, wo Unternehmen satte monatliche Entgelte für den SIP-Anschluß kassieren und sich dann verhalten wie ein Freemail-Anbieter.
 
Es gab aber schon Fälle bei Telekom-VoIP-Anschlüssen, wo eine Faxverbindung nach einer abgelehnten T.38-Umschaltung nicht wieder als normaler G.711-Anruf weiterlief. Hierzu gab es auch Diskussionen z.B. im legendären Onlinekosten-Forum.

Soweit ich mich erinnere, hatte die Telekom-Plattform da beim Durchreichen des T.38-Re-Invites sofort den RTP-Stream unterbrochen und ihn nach dem Ablehnen des Re-Invites nicht wieder durchgeschaltet. Dabei spielte wohl auch ein nicht ganz korrekt formuliertes SIP-488-Paket der Re-Invite-Ablehnung eine Rolle. Meines Erachtens hätte der RTP-Stream aber gar nicht erst unterbrochen werden dürfen, sondern hätte einfach unverändert weiterlaufen müssen, solange es zu keinem erfolgreichen Re-Invite kommt.

cu talk2chris
Das war natürlich ein Fehlerfall. Hier kamen mehrere Dinge zusammen: Das Fehlerhafte SIP488 und das Verhalten der P-CSCF.
 
Das war natürlich ein Fehlerfall. Hier kamen mehrere Dinge zusammen: Das Fehlerhafte SIP488 und das Verhalten der P-CSCF.

Demnach wurde das Problem inzwischen gelöst? Würde in einem vergleichbaren Fall heute der RTP-Stream auch nach der "fehlerhaften" SIP-488-Antwort wieder durchgeschaltet werden oder würde der RTP-Stream durch den Re-Invite gar nicht mehr unterbrochen werden?

Meines Erachtens wäre die zweite Variante (RTP-Streams werden auch nach Versand des Re-Invites unverändert durchgeleitet solange dieser nicht bestätigt wurde) die bessere und auch standardkonformere - auch mit Blick auf evtl. andere Probleme mit gescheiterten bzw. abgelehnten Re-Invite-Versuchen.

Es gab im onlinekosten.de-Forum ja auch den Fall mit den Faxverbindungen von 1&1-Kunden zu 0800-Rufnummern bei VSE-Net, die ebenfalls Probleme machten, wenn ein T.38-Re-Invite versucht und abgelehnt wurde. Es konnte nach meiner Erinnerung aber leider nicht geklärt werden, woran es lag und ob diese Verbindungen im Transit über die Telekom liefen (von Nicht-Telekom-TNB zu einer 0800 eines anderen Nicht-Telekom-TNB ist die Wahrscheinlichkeit aber m.E. relativ groß). Möglicherweise war da auch irgendeine Kleinigkeit in der SIP-Signalisierung die Ursache. Sowas bei einer Verbindung zu untersuchen, an der mehrere Carrier beteiligt sind, ist oftmals eh schon fast ein Ding der Unmöglichkeit - und wenn einfach irgendwo in der Routingkette der RTP-Stream blockiert wird und man nicht weiß, wo, wird es nicht einfacher... ;-)

cu talk2chris
 
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.