crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
14.04.2020 18:21
Hallo.
ich weiß leider nicht, ob ich hier richtig bin, und ob mir hier jemand weiterhelfen kann.
Wir hatten vor kurzem die Umstellung von 50 auf 100 VDSL und seit ungefähr dieser Zeit funktioniert unser im Drucker integriertes Fax nicht mehr. Wir können zwar Faxe empfangen, aber senden funktioniert nicht mehr.
Es erscheint dann "Fehler 388" Während der Faxübertragung ist ein Kommunikationsfehler aufgetreten.
Zuerst dachten wir, das unser Drucken den Geist aufgibt und haben einen Neuen geholt, aber nun wieder das gleiche Problem.
Es handelt sich um einen HP OfficeJet 5200.
Als Speedport haben wir von telekom das W 724V Type B.
An der gleichen Leitung/Nummer ist auch noch ein Telefon mit AB angeschlossen.
Bis jetzt hat immer alles super funktioniert.
Hab auch schon versucht, das Telefon in die Faxleitung einzustecken, funktioniert einwandfrei.
Was kann ich noch machen.
Vielen Dank für die Hilfe.
LG
Gabriele
Gelöst! Gehe zu Lösung.
12.06.2020 08:42
gagg2408 schrieb: Also erstmal vielen Dank für die schnelle Lieferung des Routers.
Wir haben ihn gestern angeschlossen, und was soll ich sagen, das faxen hat funktioniert. Hoffentlich war das kein Zufall ;-))
Wenn ich gewusst hätte, das es so einfach ist, und wir nur den Router tauschen müssen, hätte ich hier nicht so einen "Aufstand" gemacht.
Vielen herzlichen Dank Stefan, das du drangeblieben bist, und uns geholfen hast.
Leider hatten wir zuvor bei diesem Problem telefonisch bei der Telekom schon angefragt, und da hat es nicht / keinem interessiert. Es wurde nur die Leitung getestet und für gut gehalten.
Also erstmal vielen Dank für die schnelle Lieferung des Routers.
Wir haben ihn gestern angeschlossen, und was soll ich sagen, das faxen hat funktioniert. Hoffentlich war das kein Zufall ;-))
Wenn ich gewusst hätte, das es so einfach ist, und wir nur den Router tauschen müssen, hätte ich hier nicht so einen "Aufstand" gemacht.
Vielen herzlichen Dank Stefan, das du drangeblieben bist, und uns geholfen hast.
Leider hatten wir zuvor bei diesem Problem telefonisch bei der Telekom schon angefragt, und da hat es nicht / keinem interessiert. Es wurde nur die Leitung getestet und für gut gehalten.
Unbekannter Weise möchte ich mich bei Dir herzlich Bedanken. Du hattest immer ein offenes Ohr, warst meist der Erste, der geantwortet hat, hast die zweimal die Arbeit gemacht, den Speedport Mitschnitt zu analisieren, hast mit genaueste Beschreibungen geschickt, wie ich diesen Mitschnitt mache, speichere und ihn dir zur Verfügung stelle.
Bist immer dran geblieben und hast versucht mir/uns zu helfen.
Keine Ahnung was ich noch alles schreiben soll.
Vielen, vielen herzlichen Dank.
Liebe Grüße
gagg2408
14.04.2020 18:24
@gagg2408hast Du mal an der Übertragungsgeschwindigkeit " gschraubt"? stell es mal auf 9600
14.04.2020 19:08 Zuletzt bearbeitet: 14.04.2020 19:12 durch den Autor
Wurde auch die Fehlerkorrektur des HP 5200 deaktiviert?
Was passiert, wenn dem Faxgerät eine eigene Rufnummer zugeordet wird - für ein- und ausgehende
Faxe?
Firmwareversion des HP 5200 aktuell - 08.290.2?
Firmwareversion des verwendeten Speedports?
Habe gerade mit dem "virtuellen Agenten" von HP gechattet - mit folgendem Ergebnis:
"386, 387, 388, 389, 390, 391, 392, 393, 394, 395: Zu starkes Rauschen in der Telefonleitung verhindert eine gültige Verbindung zwischen den Faxgeräten. Versuchen Sie, erneut zu faxen, wenn die Qualität der Telefonleitung besser ist."
Heißt im Klartext: Entweder Qualität der Verbindung schlecht - oder falsche Faxparameter eingestellt, z.B.
n i c h t 9600 Baud und / oder ECM-Korrektur nicht deaktiviert.
14.04.2020 20:41
Zusätzlich könnte man auch noch mit oder ohne der Verwendung von T.38 testen, falls sich das im Faxgerät einstellen lässt.
14.04.2020 22:25
14.04.2020 22:27
15.04.2020 08:41
Möglicherweise kann dir der weiterhelfen, wo dir das Gerät verkauft hat.
Andernfalls, wenn du Online gekauft hast, bist du möglicherweise noch in der Rückgabefrist. Das würde ich in deinem Fall in Anspruch nehmen und ein anderes Gerät beim PC-Spezi um die Ecke kaufen, mit Installation bzw. Inbetriebnahme.
15.04.2020 11:44 Zuletzt bearbeitet: 15.04.2020 11:48 durch den Autor
Hallo zusammen,
um das Problem näher eingrenzen zu können, wären folgende Informationen hilfreich:
1.) wurde im Rahmen der Umstellung von VDSL 50 zu VDSL 100 irgendetwas an der Installation geändert?
2.) handelt es sich bei beiden Multifunktionsgeräten um einen HP Officejet 5200 oder war das erste Gerät ein anderes Modell (falls ja: welches)?
3.) Wurde der jetzige HP Officejet 5200 mit dem Telefonkabel angeschlossen, das dem Gerät beilag oder wurde ein schon vorhandenes Kabel verwendet? Aufgrund unterschiedlicher Belegungen in den Steckern sollte man immer das Original-Kabel verwenden!
4.) Da von "Telefon an gleicher Leitung" die Rede ist: Ich nehme an, daß das Telefon und der Officejet jeweils an einem der beiden Telefon-Steckplätze am Speedport angeschlossen sind? Oder gibt es noch eine separate Telefondose, an der beide Geräte hängen?
5.) Wenn Telefon + Officejet jeweils direkt am Speedport angeschlossen sind: Wurde die Buchse, an der der Officejet hängt, im Speedport-Menü als "Fax" konfiguriert? Siehe hierzu diese Anleitung für den Speedport W724V B auf Seite 115.
6.) In dieser Anleitung für den HP Officejet 5200 werden ab S. 41 verschiedene Arten des Faxversandes beschrieben. Welche wurde bislang genutzt? Hier mal das Verfahren "Senden einer Faxnachricht mit Wahlüberwachung" testen. Zu Beginn muß da der Wählton zu hören sein und die Wahl der einzelnen Ziffern durch den Officejet. Die Ziffern sollten dabei als Töne gesendet werden und nicht als "Klackerimpulse" (Wähltyp muß auf "Tonwahl" stehen, vgl. S. 55 der Anleitung).
7.) Wenn wie unter 6.) Wählton und die Wahl der einzelnen Ziffern zu hören sind: Kann man auch noch den Fax-Pfeifton der Gegenstelle hören, wenn diese die Verbindung annimmt? Wie lange etwa dauert es dann noch bis zum Verbindungsabbruch?
8.) Wenn man im Speedport-Menü eingeloggt ist, kann man unter http://speedport.ip/hidden/hidden_index.stm ein verstecktes Unter-Menü mit erweiterten Informationen aufrufen. Irgendwo dort müßten Angaben zu den Fehlerraten der DSL-Strecke stehen (vermutlich mit Begriffen wie "CRC error", "FEC error", "HEC error", etc. gekennzeichnet). Da wäre es interessant, ob dort (insbesondere im Upstream) hohe Werte stehen. Am besten einfach die Werte rauskopieren und hier einfügen.
cu talk
15.04.2020 13:48
15.04.2020 14:15
Hallo zusammen,
gut, damit kann man zumindest schon mal sagen, daß der Officejet beim Wählen "eine Leitung bekommt" und wohl auch die Gegenseite "hören" kann.
Den genannten DNS-Fehlern würde ich keine große Bedeutung beimessen. Es geht mir mehr um die DSL-Statusdaten - dafür habe ich noch einen anderen Link gefunden: Nach erfolgtem Einloggen in den Speedport in einem neuen Browserfenster folgende Adresse aufrufen: http://speedport.ip/hidden/dsl_hidden_status.stm
Welche Werte stehen dort (jeweils für Upstream und Downstream) bei:
- Acutal Data Rate
- Attainable Data Rate
- SNR margin
sowie bei
- CRC Error Count
- HEC Error Count
- FEC Error Count
cu talk
15.04.2020 14:25
15.04.2020 15:24 Zuletzt bearbeitet: 15.04.2020 15:35 durch den Autor
Hallo,
die Datenrate im Upstream (also auf der Stecke vom Anschluß ins Netz) ist zwar etwas eingeschränkt, aber der Signal-Rausch-Abstand (SNR) ist gut.
Zu den Fehlerwerten (... error count): Diese dürften sich auf den Zeitraum seit dem letzten Neustart des Routers beziehen. Falls der Router schon seit Wochen duchläuft und die 14 CRC-Fehler über einen längeren Zeitraum angesammelt wurden, dürfte das in Ordnung sein. Falls der Router erst unmittelbar vor dieser Abfrage neu gestartet worden wäre, wären 14 CRC-Fehler in einem ganz kurzen Zeitraum (wenige Minuten oder Stunden) aber evtl. etwas auffällig. Wann ist denn der letzte Neustart erfolgt?
Man könnte noch testen, ob die Probleme beim Faxversand auch auftreten, wenn man das Fax mal an die andere TAE-Buchse (dort wo jetzt wohl das Telefon drin steckt) anstöpselt. Falls vorhanden, könnte man auch noch ein anderes Telefonkabel zwischen Officejet und Speedport testen (um zu testen, ob die Steckerbelegung dort stimmt, müßte man aber auf das Vorhandensein von Wählton, Freizeichen, etc. beim Verbindungsaufbau achten).
Tritt das Problem beim Fax-Versand eigentlich zu verschiedenen Anschlüssen auf oder nur zu einer bestimmten Faxnummer? Ist bekannt, bei welchem Anbieter die betroffene(n) Rufnummer(n) geschaltet sind?
Und um nochmal auf meine ursprünglichen Fragen zurückzukommen: Wurde die Buchse, an der der Officejet hängt, im Speedport-Menü als "Fax" konfiguriert? Siehe hierzu die Anleitung für den Speedport W724V B auf Seite 115.
cu talk
15.04.2020 18:02
16.04.2020 15:12 Zuletzt bearbeitet: 16.04.2020 15:14 durch den Autor
Hallo,
die ganze Sache ist etwas rätselhaft. Wir sind jetzt ein paar wichtige Punkte durchgegangen, aber bislang leider ohne Ergebnis. Anhand der bislang bekannten Informationen glaube ich aber im Moment nicht an ein Problem beim Officejet.
Es wäre interessant, mal den Datenverkehr einer solchen nicht funktionierenden Fax-Verbindung mitzuschneiden. Damit man sehen kann, was da genau "auf der Leitung" passiert.
Ich kann Dir mal beschreiben, wie das funktioniert und wie Du mir einen solchen Paketmitschnitt zukommen lassen kannst - dafür sollte man aber schon etwas computeraffin sein, denn es sind einige Schritte notwendig.
Das Ganze müßte so funktionieren:
1.) In das Menü des "Speedport W724 V Typ B" einloggen.
2.) Nach erfolgreichem Login in einem neuen Browser-Fenster folgende Adresse öffnen: http://speedport.ip/wan_util.stm
3.) Dort müßte nach meinen Infos ein "Diagnostic utility" zu finden sein. Bei "WAN packet capture" läßt sich mit "Begin" ein Mitschnitt des Speedport-Datenverkehr starten. Die Datei, die der Browser nun herunterladen will, so abspeichern, daß man sie auch wieder gut wiederfindet und wiedererkennen kann.
4.) Während des Mitschnittes versuchen, mit dem Officejet ein Fax zu versenden (so wie bei den bisherigen Versuchen auch). Solange der Mitschnitt läuft, sollte kein weiterer Datenverkehr über den Anschluß laufen. Also nicht im Internet-Surfen, keine E-Mails abfragen, keine Livestreams, etc., sondern nur diese Faxverbindung!
5.) Wenn die Faxverbindung vermutlich wieder erfolglos beendet ist, im oben genannten Menü mit "End" den Mitschnitt stoppen.
6.) Die so entstandene Mitschnitt-Datei bei einem Cloudspeicher-/Filehoster-Dienst hochladen, z.B. bei Magenta Cloud, Google Drive, etc. (je nachdem, ob bzw. bei welchem solchen Dienst Ihr einen Account habt). Falls Ihr bislang keinen Cloudspeicher/Filehoster nutzt: Der Dienst www.mediafire.com müßte meines Wissens sogar ohne Account nutzbar sein.
7.) Nach dem Upload bei einem solchen Speicherdienst müßte ein Link / eine Adresse angegeben werden (evtl. über eine "Share"-Funktion o.ä.), über die andere Nutzer auf die hochgeladene Datei zugreifen können. Diesen Link bzw. diese Adresse kopieren.
8.) Den Link zu dieser Datei nicht hier in die öffentliche Diskussion reinsetzen, sondern mir über eine private Forennachricht zuschicken (bei diesem Beitrag oben auf meinen blauen Nutzernamen klicken und dann auf das magentafarbene Feld "Nachricht senden" klicken. Dann öffnet sich das Fenster für eine private Nachricht.)
Ich kann mir diesen Paketmitschnitt dann mal etwas näher anschauen, das kann aber evtl. 1-2 Tage dauern. Zudem kann ich keine Garantie übernehmen, daß ich in dem Mitschnitt etwas erkennen kann. Ich bin selbst kein Telekom-Mitarbeiter, habe aber schon manche Probleme mit VoIP / SIP untersucht und oftmals auch in den Griff bekommen. Ein solcher Mitschnitt kann aber auch für die Telekom hilfreich sein, falls dort noch ein Störungs-Ticket eröffnet wird.
cu talk
16.04.2020 15:54
18.04.2020 11:59
Hallo,
@gagg2408 schrieb:
Wir haben jetzt probiert, einem Freund ein Fax zu schicken, das hat funktioniert.
Wenn mein Mann aber in die Arbeit faxen will, geht es nicht, das komische ist aber, da die Firme mehrere Aussendienstmitarbeiter hat, bei den anderen funktioniert es einwandfrei.
Du weißt nicht zufällig, bei welchem Anbieter der Freund, die Außendienstmitarbeter und die Firma jeweils sind?
Auf jeden Fall ein interessantes Thema, da geht es evtl. um das Zusammenspiel verschiedener Netze bzw. Anbieter.
Falls Du einen Mitschnitt erfolgreich erstellt hast und/oder irgendwelche Fragen dazu hast, einfach melden.
cu talk
18.04.2020 13:05
20.04.2020 19:42
21.04.2020 07:30
21.04.2020 11:52 Zuletzt bearbeitet: 21.04.2020 11:53 durch den Autor
Hallo zusammen,
@gagg2408 schrieb:
In der Firma wissen sie von dem Problem, und haben es auch schon weitergeleitet( telekom).
Das Problem, das faxe nicht gesendet/ empfangen werden können, ist laut Chefin erst aufgetreten, als die Umstellung von analogem Anschluss auf einen IP Anschluss war.
Ich kann an dieser Stelle nur nochmal mein Angebot erneuern, mir einen von Dir erstellten Paketmitschnitt einer solchen gescheiterten Faxverbindung einmal näher anzuschauen (die Anleitung hierfür hatte ich bereits hier in der Diskussion gepostet, falls noch Fragen dazu sind, einfach melden).
Es läßt sich nicht garantieren, daß sich der Fehler hiermit finden läßt, aber man könnte ihn vielleicht immerhin etwas genauer eingrenzen.
cu talk
21.04.2020 17:55 Zuletzt bearbeitet: 21.04.2020 17:58 durch den Autor
Hallo zusammen,
@gagg2408: Vielen Dank für das Erstellen und Bereitstellen des Mitschnitts! Ich habe ihn inzwischen analysiert und interessante Auffälligkeiten gefunden.
Schauen wir uns mal gemeinsam eine "Call Flow"-Analyse an, die ich mit Wireshark erstellt habe:
Diese Grafik zeigt im Wesentlichen folgende Details (die Zeitangaben links sind Sekunden seit dem Start des Paketmitschnitts):
- bei 116.831765 übermittelt der Speedport seinen Anrufwunsch ans Netz
- bei 117.041193 bekommt er vom Netz die Bestätigung, daß dieses versucht, die Verbindung aufzubauen ("trying")
- bei 117.302895 "klingelt" es beim Angerufenen ("ringing")
- bei 124.117035 startet der eingehende RTP-Datenstrom (also quasi der "ankommende Tonkanal") und bei 124.130279 wird das Zustandekommen des Anrufes vom Netz gemeldet. Dies wird vom Speedport wiederum bei 124.198113 bestätigt, der kurz daraufhin bei 124.222686 auch den ausgehenden RTP-Datenstrom (der "abgehende Tonkanal") aufbaut.
Zu diesem Zeitpunkt ist also die Verbindung zum Zielteilnehmer erfolgreich zustandegekommen. Im RTP-Stream ist auch zu hören, daß das Zielfax seinen charakteristischen Faxton aussendet.
Dies führt dann allerdings dazu, daß irgendwo auf der Verbindungsstrecke (evtl. vom Netz, von einem Carrier-Gateway oder vom Router auf der Gegenseite?) versucht wird, die Verbindung vom normalen Sprachübertragungsstandard G.711 auf den speziellen Faxübertragungsstandard T.38 umzuschalten. Dies geschieht bei 126.933758 mit einem erneuten INVITE (auch als Re-INVITE bezeichnet).
Der Speedport lehnt bei 126.975478 diese angefragte Umschaltung auf T.38 ab und wiederholt diese Ablehnung in den folgenden 32 Sekunden mehrfach, bis schließlich bei 158.923729 die Verbindung vom Netz oder der Gegenseite beendet wird, was schließlich vom Speedport bei 158.928930 bestätigt wird.
Zwischenfazit: Die Verbindung kommt zunächst korrekt mit dem Sprachstandard G.711 zustande (hierüber können in der Regel auch Faxe übertragen werden, das ist also kein Fehler). Es ist auch in Ordnung, daß eine an der Verbindung beteiligte Komponente versucht, die Verbindung auf T.38 umzuschalten. Und ist es auch völlig korrekt, daß der Speedport die T.38-Umschaltung verweigert (der Speedport W724 V Typ B soll ja wohl gar kein T.38 können).
Jetzt kommt der entscheidende Punkt: Es ist nicht in Ordnung, daß der eingehende RTP-Stream praktisch zeitgleich zu diesem Re-INVITE abbricht! Der "Call Flow" zeigt bereits, daß der eingehende RTP-Stream (siehe bei 124.117035) nur 135 Pakete lang ist, also 2,68 Sekunden lang dauert. Danach ist die Verbindung "stumm" / die Leitung "tot" und bleibt noch etwa 32 Sekunden ohne Tonübertragung offen. Im Paketmitschnitt selbst sind in diesem Zeitraum keine ankommenden Pakete (egal ob RTP, T.38 o.ä.) zu sehen, bis dann schließlich mit einem "BYE" die Verbindung beendet wird.
Was den abgehenden RTP-Stream angeht, interpretiert die mir vorliegende Wireshark-Version die vom Speedport ausgehenden Daten nach dem T.38-Reinvite offenbar als T.38-Pakete. Deshalb im obigen "Call Flow" auch die Angabe von angeblich nur 136 ausgehenden RTP-Paketen. Meiner Ansicht nach ist dies aber eine Fehlinterpretation. Alle vermeintlichen T.38-Pakete werden als "malformed" bezeichnet. Außerdem ist bei den RTCP-Paketen erkennbar, daß die Anzahl der verschickten RTP-Pakete auch nach dem abgelehnten Re-Invite immer weiter hochgezählt wird. Demnach wird der ausgehende RTP-Stream wohl aufrecht erhalten. Zumal wäre es auch ungewöhnlich, wenn der Speedport T.38 ablehnen und dann dennoch auf T.38 umschalten würde. Man darf also auch Wireshark nicht alles blind glauben...!
Fazit: Das Hauptproblem sehe ich hier im Abbrechen des eingehenden RTP-Datenstroms (also dem Signal, das von der Gegenseite kommt). Das halte ich für einen Fehler, denn beide RTP-Streams dürften erst nach einer erfolgreichen Umschaltung zu T.38 beendet werden, vgl. auch Punkt 4.2.4.3 (Fax and Modem) der Telekom-eigenen Richtlinie 1TR114.
Es stellen sich daher verschiedene Fragen, die man mal näher untersuchen sollte. Eventuell kann da die Netztechnik der Telekom helfen?
1.) "Wer" versucht, die Verbindung auf T.38 umzuschalten? Die Telekom VoIP-Plattform soll sich angeblich bei T.38 transparent verhalten, also diesen Standard nur durchleiten, wenn eine Endseite dies wünscht. Geht die Umschaltung also evtl. vom Router o.ä. auf der Zielseite aus? Ist die Zielrufnummer wirklich bei der Telekom geschaltet, oder evtl. bei einem anderen Anbieter? Kann ggf. von einem Gateway zwischen der Telekom und einem anderen Anbieter die Umschaltung ausgehen? Ist das Phänomen evtl. davon abhängig, über welche SIP-/RTP-Server die Verbindung verläuft?
2.) Wieso bricht der eingehende RTP-Stream ab? Dieser Stream dürfte ja erst bei einer erfolgreichen Umschaltung auf T.38 beendet werden. Verhält sich die Telekom-Plattform da tatsächlich transparent oder kann es sein, daß das Telekom-Netz durch ein transparent durchgeleitetes T.38-Re-INVITE auf SIP-Ebene daraufhin den RTP-Stream selbst beendet? Hier sollte auf den Telekom-Servern überprüft werden, ob der eingehende RTP-Stream bereits dort fehlt.
3.) Es gab schon mal eine Diskussion über gescheiterte Faxverbindungen, bei denen ein Umschaltversuch auf T.38 scheitert und zeitgleich der eingehende RTP-Stream abbricht, siehe dazu dieses Thema bei onlinekosten.de. Damals ging es um eine Verbindung von 1&1/Versatel zu einer 0800-Rufnummer bei VSE-Net, die über die Telekom als Transit-Carrier lief. Aufgrund der damals vielen beteiligten Seiten konnte das Problem damals nicht gelöst werden. Falls bei einem Telekom-VoIP-Server ein Fehler vorliegen sollte, könnte es sich evtl. in beiden Fällen um ein vergleichbares Problem (T.38-Re-INVITE verursacht fälschlicherweise einen RTP-Abbruch) handeln?
Zusammenfassung:
Angesichts der vorliegenden Daten bitte ich das @Telekom-hilft-Team um das Eröffnen eines Störungstickets. Bei den gestörten Faxverbindungen wird irgendwo im Netz oder auf der angerufenen Seite im Rahmen eines T.38-Re-Invites der RTP-Datenstrom zum anrufenenden Nutzer hin abgebrochen, obwohl der Re-Invite vom anrufenden Speedport abgelehnt wird. Die Frage ist, wo dies erfolgt.
@gagg2408 kann den Paketmitschnitt einer gestörten Faxverbindung bereitstellen. Es kann jedoch sein, daß ein Analysetool wie Wireshark diesen Mitschnitt als "damaged or corrupt" bezeichnet und nur einen Teil der mitgeschnittenen Daten darstellt (wo dann ausgerechnet die SIP-/RTP-Daten fehlen). In diesem Fall muß der Mitschnitt mit einem Tool wie pcapfix repariert werden. Auf Wunsch kann ich eine reparierte und auf die wesentlichen Daten gekürzte Version des genannten Mitschnitt selbst bereitstellen. Ebenfalls wäre zu beachten, daß Wireshark evtl. die vom Speedport nach dem abgelehnten Re-Invite ausgehenden Daten fälschlicherweise als T.38-
Daten interpretiert (meines Erachtens wird hier aber einfach der ausgehende RTP-Stream fortgesetzt, vgl. die Zähler in den RTCP Sender Reports).
Es kann gerne auf diesen Thread und meine Analyse verwiesen werden. Informationen über den weiteren Verlauf dieses Falls bitte auch hier ins Forum oder per PN an mich.
cu talk
23.04.2020 21:13
23.04.2020 22:30
23.04.2020 22:59
24.04.2020 07:05
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.