VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen fehl

Forum zu LANCOM Systems VoIP Router/Gateways und zur LANCOM VoIP Option

Moderator: Lancom-Systems Moderatoren

Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von Koppelfeld »

Jirka hat geschrieben:Unabhängig von dem, was Ihr jetzt sagt, gibt es hier doch ein Problem. Ein Problem was gefixt werden sollte. Denn irgendwas macht der LANCOM-VCM falsch. Und das will ich jetzt geklärt haben.
Das ehrt Dich, klärt aber andererseits auch das Rätsel, weshalb Du noch kein Angebot von LANCOM bekommen hast als Testingenieur.
Koppelfeld hat geschrieben:Ich sehe mich dem Kunden gegenüber verantwortlich und will ihm damit eine einfache, zuverlässige Umgebung an die Hand geben. Dabei ist mir dieses "praeter necessitate" sehr wichtig. NIEMALS komplizierter als unbedingt nötig.
Verdammte Sauzucht. 'praeter' geht mit dem Akkusativ und 'sine' mit dem Ablativ, also entweder 'sine necessitate' oder 'praeter necessitatem'. Peinlich, peinlich. Ich schiebe es auf das Alter.
Wie schon geschrieben, der Kunde hat 350 Faxe am Tag.
Abweichend von Dr. Einsteins Erfahrung:
Mit den 'professionellen' ATA-Gateways von Patton, Audiocodes und Grandstream (ab GXW4216) gibt es deutlich weniger bis keine Probleme mit Faxen.
Mittlerweile ist der LANCOM da rausgeflogen, also nicht ganz, steht noch im Schrank. Aber die Faxe macht jetzt irgendso eine teure Box
asterisk <--> iaxmodem <--> hylafax. Auf einem ordentlichen Stück Blech. Du kannst nicht eine "nice-to-have" - Nebenfunktion einer kleinen Pipibox für professionelle Anwendungen mißbrauchen.
Was meinst Du, wie ein gewisser Herr von Lancom in Ohnmacht fiel, als ich ihm erzählt habe, daß wir an einem 17xx - Gerät eine fette AS/400 mit Faxinterface hängen haben, die eine gute halbe Million kostet (bei IBM keine Kunst). "Ja - ich weiß aber nicht, ob wir für sowas haften können", war die verschreckte Entgegnung.

Das Geld für die teure Box hättest Du selbst verdienen können. Und Dein Renommé bewahrt.
Das, was hier unter Fachleuten anerkannt wird, legt ein Endkunde als Schwäche und mangelnde Qualifikation aus.
Im Januar darf ich ein Faxgerät über WLAN anbinden. Da graut mir jetzt schon vor. Da wollte ich, um das mit dem unkalkulierbare WLAN in den Griff zu bekommen, auch auf T.38 setzen. Mit G.711 würde ich mir das da nicht trauen.
Wenn ein normaler Kunde ankommen würde, würde ich das natürlich ablehnen. Der Kunde kennt mich aber persönlich und daher kann ich da nicht einfach nein sagen.
GERADE DANN kannst Du 'nein' sagen und eine Alternative bereitstellen, beispielsweise Faxserver auf einer VM, welches per lpr das "Faxgerät" als Drucker befeuert. Das Wesen der Dinge ist ihr Schein !
Wenn ich nicht schon öfter einen "Ossi" in der Hand gehabt hätte, würde ich auch gar nichts verstehen...
Du sagst es. Anstatt "one laptop per child" wäre "one scope per child" das, was wir bräuchten. Und zwar ein cathode ray scope. DA war uns der Klassenfeind in der DDR haushoch überlegen: In Projektwochen bauten sich Schüler der EOSsen ihre Oszilloskope selbst. Das habe ich selbst gesehen, als es diese herrliche Mauer noch gab. Und über das Fachwissen kann man nur staunen. Die Zonis schafften ja auch im EIGENBAU einen SECAM/PAL - Konverter. Mein einziger Trost damals: Die AF139 kamen aus dem Westen.
Aber was machen wir Idioten? Legen dem Nachwuchs ein schwules Eifon unter den Tannebaum oder einen PC. Versiegelte Technik, gedacht, um zu sedieren und nicht um anzuregen.
Und dann der soziale Aspekt - da begrapschen minderjährige Smartphonebenutzer eine wehrlose behinderte Frau im Rollstuhl und legen die gefilmte Heldentat bei "facebook" ab. Also ganz im Ernst:
Volljährigkeit wieder auf 21 anheben, Internet- und Smartphoneverbot für Minderjährige. DAS schafft Sozial- und Technikkompetenz.
Aber ich will den Moderator nicht auf die Palme bringen.
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: VCM: T.38-Aushandlung schlägt fehl wegen falscher Call-S

Beitrag von MoinMoin »

Moin Jirka!

Immer diese Monsterpostings. Da ist man ja ewig beschäftigt, alles überflüssige aus der Antwort zu löschen.
;-)
Jirka hat geschrieben: Meiner Meinung nach ist in absteigender Wahrscheinlichkeit irgendwas mit folgenden Angaben faul:
1) m=image 15070 udptl t38 101
Hier stört mich die 101 am Ende.
2) a=ptime:20
Kann/muss man einem T.38-Protokoll den Zeitumfang von 20 ms vorschreiben? Die Pakete kommen alle 20 ms, ja, aber sie enthalten ja nun nicht 20 ms Sprachdaten.
3) a=rtpmap:101 telephone-event/8000\r\n
4) a=fmtp:101 0-15\r\n
Beides zusammen: ja sollen jetzt DTMF-Töne oder Faxe übermittelt werden? Ist das überhaupt vereinbar?
Sieht in der Tat etwas merkwürdig aus. Hatte ich bisher übersehen. Wir werden das diskutieren.

Ciao, Georg
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: VCM: T.38-Aushandlung schlägt fehl, Ursache bisher unbek

Beitrag von MoinMoin »

Moin Jirka!

Wir haben das Verhalten als Bug eingetütet, da es so zumindest sinnlos ist.

Kannst du nachsehen, ob das Verhalten mit der Version, bei der das T.38-ReInvte noch funktioniert hat, schon so war?

Ciao, Georg
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM: T.38-Aushandlung schlägt fehl, Ursache bisher unbek

Beitrag von Jirka »

Hallo zusammen, hallo Georg

so, mein T.38-Tag ist vorüber (seit 15 Uhr, vom Abendbrot abgesehen, nur T.38 gemacht), hier die Ergebnisse, der aktuelle Stand der Dinge.

Beim Kunden ist bis zur abschließenden Klärung incl. Tests erst mal alles wieder abgebaut. Ich kann mir aber die SIP-Leitung nehmen und außerhalb der Geschäftszeiten damit Tests machen.

Was ich schon die ganze Woche vorhatte, aber zeitlich nicht mehr auf die Reihe bekommen habe: Ich habe jetzt einen Testaufbau! Da kann man jetzt bis zum Umfallen testen ohne irgendwelche Prozesse durcheinander zu bringen oder in den Arbeitszeiten eingeschränkt zu sein. Denn von meinem anfänglichen Wunsch, dass der Bug in einer Woche gefixt sein wird, musste ich mich ja so langsam verabschieden, weil es immer komplexer und unübersichtlicher wurde und das Fehlverhalten eben offensichtlich nicht auf Anhieb sichtbar ist.

Hier die Zugangsdaten zum T.38-Test-LANCOM:
IP: 31.16.16.77
Passwort: Das Passwort ist Dein Nachname, also der Nachname von Dir, Georg.
Du kannst alles machen, neu starten, Firmware wechseln, Konfig ändern... Wenn ich mal was teste/vorübergehend ändere, kann es sein, dass FLASH NO aktiv ist, das evt. beachten.
Hinter dem LANCOM hängt eine FRITZ!Box mit integriertem Faxempfang (kriege ich dann als E-Mail).
Protokolle (vom Standard abweichender Port in Klammern): Telnet über SSL, SSH (622), SNMPv3, HTTPS
Die Faxnummer des LANCOMs lautet: 03834 318643

Ich habe bei meinen Tests heute immer Faxe an den Testaufbau geschickt, bzw. versucht zu schicken, jedoch nicht vom Testaufbau versucht Faxe zu verschicken. Das könnte man aber später noch nachholen.
Ich habe weiterhin alte Beta-Firmwares aus alten Sicherungen wiederhergestellt und mit bestimmt 15 verschiedenen Firmwares getestet. Leider alles erfolglos. Irgendwann kamen mir Zweifel auf, was denn im Testaufbau anders ist als beim Kunden neulich. Na ja, der Provider. Im LANCOM ist jetzt eine 1&1-SIP-Leitung eingetragen. Ich sende aber auch über 1&1. Daher konnte ich jetzt machen was ich wollte, ich habe überhaupt kein Fax mehr rausbekommen (also mit T.38, ohne ging). Bis mir dann mal der Gedanke kam, na gut, dann musst Du jetzt auf der Sendeseite, also bei meinem eigenen LANCOM, auch die Firmware ändern. Und zack, gingen auch die Faxe rüber. Ich bin bei mir also auf die 9.24-RU3 gegangen und dann im Testaufbau schrittweise hoch von der 9.24-RU3. Die letzte Beta, wo im Testaufbau noch Faxe ankamen, war die 9.24.0196. Die nächste Firmware, die ich habe, war dann die 9.24.0212-RU4. Dazwischen gab es für uns glaube ich keine Betas. Und die RU4 ging dann, wie ja auch schon im letzten Posting geschrieben, nicht mehr.

Wir haben hier im Detail zwei T.38-Probleme. Zum einen, das bisher auffälligste, dass die T.38-Aushandlung fehl schlägt ("488 Not Acceptable Here"). Das kommt aber nicht bei allen Providern, 1&1 lässt sich z. B. die fraglichen SDP-Angaben gefallen, bzw. ignoriert sie einfach. Aber zusätzlich zu diesem Problem gibt es noch ein zweites. Das habe ich in den letzten Postings bisher undefiniert angegeben, z. B. schrieb ich "Warum es mit der RU3 geht und mit der RU4 nicht, ist mir leider noch unklar.". Und das ist es mir immer noch!!! Soll heißen in beiden Fällen sieht (glaube ich, ich kann nicht mehr gucken) der Trace gleich aus, aber in dem einen Fall, also mit 9.24.0196 kommt das Fax an, mit der 9.24.0212-RU4 aber nicht mehr. D. h. hier muss doch irgendwas geändert worden sein, was Einfluss auf das T.38 nimmt. Und zwar auf T.38-Ebene oder Port-Ebene oder was weiß ich, das habe ich mir jetzt auch nicht näher angeschaut. Man könnte im Fehlerfall ja noch mal einen kompletten Wireshark-Trace vor und hinter dem LANCOM machen, vielleicht gehen da ja irgendwo Pakete verloren? Fällt Dir vielleicht auf/kannst Du nachschauen, was seinerzeit am Code geändert wurde und dafür Grund sein kann, dass es T.38 quasi gar nicht mehr tut? Überhaupt nicht? Das ist ja auch das Ergebnis der vorigen Postings, das zweite T.38-Re-INVITE ging soweit durch und wurde akzeptiert, aber es ging trotzdem kein Fax durch, keine Zeile.

Das mit meinem eigenen Faxeingang war also ein guter Ansatz und führte zu dem Zeitpunkt seitdem sich das Problem quasi unbemerkt eingeschlichen hat. Leider wird mir jetzt auch langsam klar, warum es bei meinem Groß-Faxkunden mit 350 Faxen pro Tag statt besser mit jeder Firmware immer schlimmer wurde. Der hatte auch Ende März glaube ich Umstellung auf VoIP und dann hatten wir zwei LANCOMs hintereinander nur für Fax, ein 1783 und ein 1781 mit LANCAPI, der per ISDN am 1783 war. Nachdem dann ja eine Angestellte nur noch dafür abgestellt war, die nicht abgesendeten Faxe per Post zu verschicken und das zwei Monate lang, kam dann ja die andere Box. Und seitdem ist LANCOM raus. Glaube die Box hat 2.000 EUR gekostet. Die Kosten der Mitarbeiterin weiß ich nicht, die hätte vielleicht auch für Nichtstun ihr Geld bekommen. Wie auch immer habe ich seinerzeit aber auch in die Release-Notes geschaut. Und da steht nichts von Fax oder T.38. Anscheinend wurde da aber doch was geändert. Es ärgert mich, dass ich damals nicht auch mal wieder konsequent rückwärts gegangen bin mit der Firmware. Mit älteren Firmwares als der RU4 wären dann alle Faxe, wo die Gegenseite T.38 angeboten hat, rausgegangen.

Soweit erst mal. Nö, die Frage war ja noch offen:
MoinMoin hat geschrieben:Kannst du nachsehen, ob das Verhalten mit der Version, bei der das T.38-ReInvte noch funktioniert hat, schon so war?
Ja, also Du meinst, ob diese komischen Angaben da im SDP auch schon waren? Ja, das waren sie. Und trotzdem funktionierte es da. Inzwischen wissen wir ja, dass das zwei unabhängige Probleme sind.

Vielen Dank und viele Grüße,
Jirka

Hier die Traces vom Testaufbau mit der letzten noch funktionierenden und der ersten nicht mehr funktionierenden Firmware:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen fehl

Beitrag von Jirka »

Ich habe noch mal zwei Wireshark-Traces auf LAN-Seite gemacht. Man sieht definitiv Unterschiede. Zweimal ein Port unreachable im nicht funktionierenden Fall, das hatte ich schon vor 2 Wochen gesehen, dem aber keine große Bedeutung beigemessen, weil es ja nicht öfter kommt und anschließend ja Pakete durchgehen. Und dann sieht man im eigentlichen T.38-Protokoll, dass der LANCOM da der FRITZ!Box nur Nullen sendet. Wie schon im letzten Posting vermutet, kommt man hier also mit einem SIP-Packet- und Callmanager-Trace nicht weiter, deswegen hier diese beiden Traces. Irgendwie scheint der LANCOM also in den eigentlichen T.38-Traffic einzugreifen oder Probleme mit den Ports zu haben.

Schade übrigens, dass man in WEBconfig keinen Wireshark-Trace kombiniert über LAN-1 und ADSL/VDSL/DSL machen kann. Dann könnte man sich in LAN-2 setzen und darüber ALLES, also WAN-seitig und LAN-seitig aufzeichnen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von Jirka »

Und hier noch die Box, womit die Faxe bei meinem Groß-Faxkunden problemlos laufen (Fehleranteil < 1 %):
https://www.dgn.de/produkt/dgn-gusbox-19/
Es ist also nicht so, dass Fax über VoIP gar nicht geht.
awi
Beiträge: 61
Registriert: 19 Jun 2013, 15:22

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von awi »

Bisher bin ich nur dazu gekommen, die fälschlicherweise hinzugefügten 'telephone-event' und 'ptime' zu entfernen.
Diese Änderung ist ab 9.24.0343, bzw. 10.12.0207 enthalten.
Alles weitere kann dann erst im nächsten Jahr angegangen werden.

Gruß und schöne Feiertage
awi
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von Jirka »

Hallo zusammen,

ok, die neue Beta-Firmware (9.24.0344) habe ich jetzt diesbezüglich mal überprüft und die T.38-Aushandlung klappte auf Anhieb (die Übertragung natürlich noch nicht), damit ist Problem Nr. 1 ("488 Not Acceptable Here") gelöst.

Die FRITZ!Box gibt im SDP beim T.38-Re-INVITE an:

Code: Alles auswählen

v=0\r\n
o=user 5883977 5883978 IN IP4 10.10.22.5\r\n
s=call\r\n
c=IN IP4 10.10.22.5\r\n
t=0 0\r\n
m=image 7078 udptl t38\r\n
a=T38FaxVersion:1\r\n
a=T38MaxBitRate:14400\r\n
a=T38FaxTranscodingMMR\r\n
a=T38FaxTranscodingJBIG\r\n
a=T38FaxRateManagement:transferredTCF\r\n
a=T38FaxUdpEC:t38UDPRedundancy\r\n
a=T38FaxUdpEC:t38UDPFEC\r\n
a=T38FaxMaxDatagram:512\r\n
Der LANCOM macht daraus zum Provider/Amt hin:

Code: Alles auswählen

v=0\r\n
o=- 0 1 IN IP4 31.16.16.77\r\n
s=call\r\n
c=IN IP4 31.16.16.77\r\n
t=0 0\r\n
m=image 15298 udptl t38\r\n
a=sendrecv\r\n
a=T38FaxVersion:1\r\n
a=T38MaxBitRate:14400\r\n
a=T38FaxTranscodingMMR\r\n
a=T38FaxTranscodingJBIG\r\n
a=T38FaxRateManagement:transferredTCF\r\n
a=T38FaxMaxDatagram:512\r\n
a=T38FaxUdpEC:t38UDPRedundancy\r\n
a=T38FaxUdpEC:t38UDPFEC\r\n
Worauf der Provider sofort mit OK antwortet. Schön.

Zur Erinnerung: Bisher kam ein "488 Not Acceptable Here" vom Provider (allerdings auch nicht von jedem Provider, 1&1 ignorierte z. B. die fehlerhaften Angaben), was daran lag, dass das SDP vom LANCOM so aussah:

Code: Alles auswählen

v=0\r\n
o=- 0 1 IN IP4 31.16.16.77\r\n
s=call\r\n
c=IN IP4 31.16.16.77\r\n
t=0 0\r\n
m=image 13230 udptl t38 101\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n
a=sendrecv\r\n
a=ptime:20\r\n
a=T38FaxVersion:1\r\n
a=T38MaxBitRate:14400\r\n
a=T38FaxTranscodingMMR\r\n
a=T38FaxTranscodingJBIG\r\n
a=T38FaxRateManagement:transferredTCF\r\n
a=T38FaxMaxDatagram:512\r\n
a=T38FaxUdpEC:t38UDPRedundancy\r\n
a=T38FaxUdpEC:t38UDPFEC\r\n
und dort irgendwie die folgenden oder einer der folgenden Punkte störte:
Jirka hat geschrieben:1) m=image 15070 udptl t38 101
Hier stört mich die 101 am Ende.
2) a=ptime:20
Kann/muss man einem T.38-Protokoll den Zeitumfang von 20 ms vorschreiben? Die Pakete kommen alle 20 ms, ja, aber sie enthalten ja nun nicht 20 ms Sprachdaten.
3) a=rtpmap:101 telephone-event/8000\r\n
4) a=fmtp:101 0-15\r\n
Beides zusammen: ja sollen jetzt DTMF-Töne oder Faxe übermittelt werden? Ist das überhaupt vereinbar?
Vielen Dank und viele Grüße,
Jirka
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von Jirka »

Hallo zusammen,

fünfeinhalb Wochen sind seit meinem letzten Posting vergangen, davon drei Wochen im Januar ohne Feiertage. Daher würde ich jetzt gerne mal wissen, wie hier der Stand der Dinge ist. Ich habe die neueste 10.12.0232-Beta probiert, ohne Erfolg.

Vielen Dank und viele Grüße,
Jirka
cpuprofi
Beiträge: 1330
Registriert: 12 Jun 2009, 12:44
Wohnort: Bremen

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von cpuprofi »

Hallo Jirka,
Jirka hat geschrieben:..Ich habe die neueste 10.12.0232-Beta probiert, ohne Erfolg...
da bist Du nicht der Einzige. Auch bei dem VCM und IPv6 Problem hat sich seit Monaten (!!!) nichts getan... :(

Grüße
Cpuprofi
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von MoinMoin »

Moin Jirka!

Wir haben hier einen testaufbau und arbeiten an dem Problem. Mehr kann ich dazu derzeit noch nicht sagen.

Ciao, Georg
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von Jirka »

Hallo Georg,

ok, wenn dran gearbeitet wird frage ich mich zwar, was daran so lange dauert, bin aber immerhin (erst mal) beruhigt...

Ach ja, einen Testaufbau hatte ich hier aber schon längst stehen, wo ich Dir hier im Forum auch die Zugangsdaten gegeben habe (Posting vom 11.12.). Alles fertig. SIP-Leitung eines T.38-Providers, FRITZ!Box dahinter, usw. Aber das Ding steht hier seit 7 Wochen ungenutzt rum. (Ok, von meinen beiden Tests mit neueren Firmwares der letzten 2 Wochen mal abgesehen. Aber die sind in 4 Min. durch: neue Firmware rauf und Wahlwiederholung am Fax drücken...)

Ich erwarte, dass sich hier jetzt bald was tut.

Vielen Dank und viele Grüße,
Jirka
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von MoinMoin »

Moin Jirka!

Wenn du so einen Ton anschlägst, dann wende dich doch bitte mit deinem Problem an den Support. Hier im Forum ist das vollkommen unangebracht.

Ciao, Georg
Benutzeravatar
LoUiS
Site Admin
Site Admin
Beiträge: 5031
Registriert: 07 Nov 2004, 18:29
Wohnort: Aix la Chapelle

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von LoUiS »

Etwas Aehnliches wollte ich gerade ebenfalls schreiben. Der Ton ist vollkommen unangebracht. Wie Du ja weisst, ist dieses Forum ist nicht der offizielle Support.
Wenn Du zugesicherte Antworten und Termine erwartest, wende dich doch bitte direkt an den Support.
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen

Beitrag von Dr.Einstein »

Könntet ihr nicht Jirka zu einem Platinumstatus (also 3rd Level Direktzugang) verhelfen? Quasi für die höchste Anzahl an lancom-forum Beiträgen als Nicht-Lancom-Mitarbeiter (und davon sind rund 99% Sinnvolle und Hilfreiche)?

Immerhin haben genug Partner den Platinumstatus weil man mal ein kleines Projekt gewonnen hat und durch Zufall wer zertifiziert ist. Bei euch anrufen tut dann aber ein 0815 Außendienstler des Partners, der nicht einmal weiß, was PAPNAK ist, geschweige denn an den PPP Trace rankommt ...

Denke, Jirka ist einfach frustriert, weil er bei dem Fehler alles gegeben hat, was man als Techniker des Kunden hätte tun können. Und wenn man bei so einem Problem keinen Partnerstatus hat, keine Chance da innerhalb von zwei Monaten den First/Second Level zu passieren :(

Gruß Dr.Einstein
Antworten