Hallo,
nach genauerer Analyse und mehrfacher Prüfung meiner Konfiguration nun eine genauere Problembeschreibung eines der festgestellten Fehler in der Lancom-Software. Bevor jemand sagt, daß dieser Anwendungsfall "nicht vorgesehen" sei, so verweise ich darauf, daß Lancom in seinen Handbüchern ausdrücklich den Betrieb sowohl mit übergeordneten wie auch untergeordneten TK-Anlagen vorsieht.
Die Lage ist ist wie folgt:
1.) Am auf ISDN-TE (DSS1) gestellten ISDN1-Port hängt übergeordnet eine TK-Anlage (Auerswald ETS-4308) mit deren internem S0-Bus, welcher die internen MSNs von 41-48 als Nst-Nummern vorsieht
2.) Am Lancom 1723 habe ich (u.a.) zwei SIP-Tln angeschlossen ("Benutzer" in der Lancom-Sprache), denen ich die (Lancom-seitigen) Internnummern 45 und 46 zugewiesen habe.
3.) Im ISDN-Mapping (für eingehende Rufe) habe ich für die MSNs 45 und 46 jeweils eine direkte Abbildung auf die Lancom-seitigen Internnummern *45 und *46 eingerichtet.
4.) In der Call-Routing-Tabelle habe ich die beiden standardmäßigen Einträge (# und *#) als aktiv markiert, und die Priorität des Eintrags *# (der direkt auf USER routet) höher gesetzt als die des Eintrags # (der auf ISDN ext. routet).
Was funktioniert:
- Jeder Teilnehmer kann einzeln sauber von der übergeordneten Anlage gerufen werden und das eingehende Gespräch korrekt führen.
- Jeder Teilnehmer kann einzeln für sich ausgehende Gespräche korrekt führen.
- Beide Teilnehmer können gleichzeitig eingehende und ausgehende Gespräche in beliebiger Kombination führen, d.h. auch unter Vollbelegung beider B-Kanäle ist der ordnungsgemäße Betrieb möglich.
- Wenn von der TK-Anlage ein Sammelruf kommt, in dem beide Tln 45 und 46 gleichzeitig gerufen werden, erfolgt eine korrekte, gleichzeitige Signalisierung des Gespräches an beiden Geräten.
Was nicht funktioniert:
- Wenn von der TK-Anlage ein Sammelruf kommt, in welchem die Tln 45 und 46 gleichzeitig gerufen werden, kann ein funktionierendes Gespräch nur am Tln 45 angenommen werden; wird dagegen der Tln 46 abgehoben, bleibt die Leitung stumm!
==> hierbei ist es egal, in welcher Reihenfolge die ISDN-Mappings im Lancom eingetragen sind (also ob zuerst 45 oder zuerst 46 kommt)
==> hierbei ist es egal, ob zum Zeitpunkt dieses Rufes bereits ein B-Kanal belegt ist oder noch beide frei sind
==> hierbei erfolgt trotz der Stille eine korrekte Signalisierung des gesamten Gespräches von Anfang bis Ende, d.h. die Verbindung bleibt bis zum Auflegen/Auslösen des Gespräches bestehen, und das Auslösen wird, egal wer es initiiert, korrekt auf die Gegenseite gemeldet
Grundsätzlich ist der Anteil der "funktionierenden Details" schonmal recht hoch, was sehr positiv ist, da es schlechtere Implementierungen gibt. Allerdings tut dieses "kurz vor dem Ziel stehen" auch umso mehr weh, da der Bug an dieser Stelle eigentlich ein sehr kleiner sein müßte.
Falls jemand von Lancom hier mitliest: es wäre trotz der geringen Priorität der VoIP-Themen sehr vorteilhaft, wenn solche Fehler noch behoben werden könnten und die Funktionalität verbessert wird.
Gibt es alternativ noch Ideen, wo ich an der Konfiguration etwas probieren könnte, um das gewünschte Verhalten zu bekommen?
Was ich mir als Ursache des Verhaltens vorstellen könnte: die TK-Anlage muß für die Art des Simultanrufs eine D-Kanal-Signalisierung durchführen, die ohne "Reservierung" eines B-Kanals abläuft (oder wo für jeden Ruf derselbe B-Kanal propagiert wird), da ja nur einer benötigt wird - für den ersten abhebenden Tln. An einem Amt dagegen würde ein Simultanruf bedeuten, daß tatsächlich zwei getrennte B-Kanäle benötigt werden würden, da es sich um getrennte Gespräche handeln könnte. Kann es hier sein, daß das Lancom-Gerät für die zweite gerufene MSN eigenständig den "falschen", nicht von der Anlage vorgesehenen Kanal nutzen möchte und deswegen nur Stille erhält?
Auch wenn die Wahrscheinlichkeit sehr gering ist - über jeden Tip wäre ich wirklich _sehr_ dankbar!
Beste Grüße,
Hans-Jürgen
1723: teils stumme Gespräche bei Sammelruf an mehrere MSNs
Moderator: Lancom-Systems Moderatoren
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Moin hjm82!
Kannst da das als D-Kanal-Trace mitschneiden?
Ciao, Georg
Kannst da das als D-Kanal-Trace mitschneiden?
Ciao, Georg
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo Georg,
herzlichen Dank für Deine Antwort! Klar kann ich das aufzeichnen - habe folgende Szenarien kurz durchgespielt:
- Gutfall: Sammelruf an (u.a.) Tln 45 und 46, Abheben an Tln 45, Gespräch (mit Ton) ca. 10 Sekunden, Auslösen der Verbindung durch den A-Tln (seitens Hauptanlage).
- Schlechtfall: Sammelruf an (u.a.) Tln 45 und 46, Abheben an Tln 46, Gespräch (OHNE Ton) ca. 10 Sekunden, Auslösen der Verbindung durch den A-Tln (seitens Hauptanlage).
Das Mitschreiben habe ich mit den Möglichkeiten des Lancom durchgeführt, bei Bedarf kann ich aber auch noch einen D-Kanal-Log seitens der Hauptanlage erzeugen.
Für weitere Fragen usw. stehe ich gerne zur Verfügung!
Beste Grüße,
Hans-Jürgen
==> Daten siehe Anhänge
herzlichen Dank für Deine Antwort! Klar kann ich das aufzeichnen - habe folgende Szenarien kurz durchgespielt:
- Gutfall: Sammelruf an (u.a.) Tln 45 und 46, Abheben an Tln 45, Gespräch (mit Ton) ca. 10 Sekunden, Auslösen der Verbindung durch den A-Tln (seitens Hauptanlage).
- Schlechtfall: Sammelruf an (u.a.) Tln 45 und 46, Abheben an Tln 46, Gespräch (OHNE Ton) ca. 10 Sekunden, Auslösen der Verbindung durch den A-Tln (seitens Hauptanlage).
Das Mitschreiben habe ich mit den Möglichkeiten des Lancom durchgeführt, bei Bedarf kann ich aber auch noch einen D-Kanal-Log seitens der Hauptanlage erzeugen.
Für weitere Fragen usw. stehe ich gerne zur Verfügung!
Beste Grüße,
Hans-Jürgen
==> Daten siehe Anhänge
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Moin Hans-Jürgen!
Im Schlecht-Fall kommen Setups für die 41, 42, 44, 45 und 46 (CallReference 88 bis 92), alle auf B-Kanal 1. Der Gut-Fall sieht im Prinzip genauso aus (CallReference 83 bis 87). Ich habe so das Gefühl, daß das LANCOM den B-Kanal "vergißt", wenn ein weiterer Ruf für denselben B-Kanal reinkommt.
Ciao, Georg
Im Schlecht-Fall kommen Setups für die 41, 42, 44, 45 und 46 (CallReference 88 bis 92), alle auf B-Kanal 1. Der Gut-Fall sieht im Prinzip genauso aus (CallReference 83 bis 87). Ich habe so das Gefühl, daß das LANCOM den B-Kanal "vergißt", wenn ein weiterer Ruf für denselben B-Kanal reinkommt.
Ciao, Georg
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo Hans-Jürgen,
könntest Du vielleicht mal zusammen mit dem D-Channel-Trace den Callmanager, Media- und Sip-Packet-Trace
auf dem Gerät einschalten und Traces für den Gut- und Schlechtfall anfertigen?
Gruß
Andreas
könntest Du vielleicht mal zusammen mit dem D-Channel-Trace den Callmanager, Media- und Sip-Packet-Trace
auf dem Gerät einschalten und Traces für den Gut- und Schlechtfall anfertigen?
Gruß
Andreas
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo zusammen,
besten Dank für eure Antworten! Vom "Gefühl" her würde ich den Hintergrund auch in der Art vermuten, wie Georg ihn beschreibt - daß die "scheinbare Mehrfachreservierung" des B-Kanals nicht korrekt interpretiert wird (wobei doch gerade dadurch klar sein müßte, daß das derselbe Ruf ist, denn die Widerspruchsfreiheit der Signalisierung sollte eigentlich Sache des Amts / der Anlage sein).
Andreas, Deinem Wunsch bin ich nachgekommen und habe neue Logs mit den vier gewünschten Datenquellen erzeugt - Szenarien sind genau identisch zur "ersten Runde".
Besten Dank und viele Grüße,
Hans-Jürgen
besten Dank für eure Antworten! Vom "Gefühl" her würde ich den Hintergrund auch in der Art vermuten, wie Georg ihn beschreibt - daß die "scheinbare Mehrfachreservierung" des B-Kanals nicht korrekt interpretiert wird (wobei doch gerade dadurch klar sein müßte, daß das derselbe Ruf ist, denn die Widerspruchsfreiheit der Signalisierung sollte eigentlich Sache des Amts / der Anlage sein).
Andreas, Deinem Wunsch bin ich nachgekommen und habe neue Logs mit den vier gewünschten Datenquellen erzeugt - Szenarien sind genau identisch zur "ersten Runde".
Besten Dank und viele Grüße,
Hans-Jürgen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo Hans-Jürgen,
danke erstmal für die Traces.
Leider geben sie noch keinen Aufschluss darüber, was hier schief läuft.
In beiden Fällen unterscheiden sich die Traces nicht, so dass hieraus nicht ersichtlich
ist warum es in einem Fall funktioniert und im anderen nicht.
Vielleicht bekommen wir mehr Hinweise, wenn zusätzlich zu den bisherigen Traces (D-Channel-Dump, Sip-Packet, Callmanager und Media)
Media-PCM, PCM-Dump und PSTN-MGNT eingeschaltet wird.
Wäre es möglich einen solchen Trace mit all diesen Daten-Quellen aufzuzeichen für den Gut-Fall und den Schlecht-Fall?
Sorry für den Aufwand, aber das scheint ein kniffliger Fall zu sein.
(Nach dem Abheben, nicht zu lange laufen lassen, da recht viele Daten anfallen)
Gruß
Andreas
danke erstmal für die Traces.
Leider geben sie noch keinen Aufschluss darüber, was hier schief läuft.
In beiden Fällen unterscheiden sich die Traces nicht, so dass hieraus nicht ersichtlich
ist warum es in einem Fall funktioniert und im anderen nicht.
Vielleicht bekommen wir mehr Hinweise, wenn zusätzlich zu den bisherigen Traces (D-Channel-Dump, Sip-Packet, Callmanager und Media)
Media-PCM, PCM-Dump und PSTN-MGNT eingeschaltet wird.
Wäre es möglich einen solchen Trace mit all diesen Daten-Quellen aufzuzeichen für den Gut-Fall und den Schlecht-Fall?
Sorry für den Aufwand, aber das scheint ein kniffliger Fall zu sein.
(Nach dem Abheben, nicht zu lange laufen lassen, da recht viele Daten anfallen)
Gruß
Andreas
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo Andreas,
erstmal danke für die Rückmeldung - freut mich sehr, daß das hier nicht eingeschlafen ist, da hatte ich erst etwas Sorge - aber eben auch die Geduld zu warten
Natürlich werde ich die gewünschten Logs so schnell wie möglich erzeugen und dann hier einstellen - solange es eine Chance und Unterstützung gibt, schaffe ich alle machbaren Daten dazu heran. Ich werde die Zeit des Gespräches darauf begrenzen, eine verläßliche Aussage auf Sprachübertragung ja/nein zu bekommen, d.h. etwa 2-4 Sekunfen sollten dafür reichen. Ich prüfe es ja immer bidirektional, falls mal eine einseitige Verbindung auftauchen sollte.
Nochmals danke - und zur Info: dieser Beitrag enthält die Logs noch nicht, ich hänge sie mit einem neuen an, sobald sie fertig sind - kann ein paar Tage aktuell leider dauern.
Beste Grüße,
Hans-Jürgen
erstmal danke für die Rückmeldung - freut mich sehr, daß das hier nicht eingeschlafen ist, da hatte ich erst etwas Sorge - aber eben auch die Geduld zu warten
Natürlich werde ich die gewünschten Logs so schnell wie möglich erzeugen und dann hier einstellen - solange es eine Chance und Unterstützung gibt, schaffe ich alle machbaren Daten dazu heran. Ich werde die Zeit des Gespräches darauf begrenzen, eine verläßliche Aussage auf Sprachübertragung ja/nein zu bekommen, d.h. etwa 2-4 Sekunfen sollten dafür reichen. Ich prüfe es ja immer bidirektional, falls mal eine einseitige Verbindung auftauchen sollte.
Nochmals danke - und zur Info: dieser Beitrag enthält die Logs noch nicht, ich hänge sie mit einem neuen an, sobald sie fertig sind - kann ein paar Tage aktuell leider dauern.
Beste Grüße,
Hans-Jürgen
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo Andreas,
so, es ist vollbracht - die Logs sind fertig
Jetzt hoffe ich mal, daß die etwas mehr Licht ins Dunkel bringen - auf die Schnelle sieht es so aus, als ob im Schlechtfall recht statische Audiodaten übermittelt werden, was zur Stille ja gut passen dürfte... mehr kann und will ich auf den ersten Blick aber mal nicht interpretieren.
Besten Dank auf jeden Fall wieder für alle Mühe in Zusammenhang mit dem Problem!
Schöne Grüße,
Hans-Jürgen
so, es ist vollbracht - die Logs sind fertig
Jetzt hoffe ich mal, daß die etwas mehr Licht ins Dunkel bringen - auf die Schnelle sieht es so aus, als ob im Schlechtfall recht statische Audiodaten übermittelt werden, was zur Stille ja gut passen dürfte... mehr kann und will ich auf den ersten Blick aber mal nicht interpretieren.
Besten Dank auf jeden Fall wieder für alle Mühe in Zusammenhang mit dem Problem!
Schöne Grüße,
Hans-Jürgen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo Hans-Jürgen,
danke erstmal für die Traces.
Was die statischen Audiodaten angeht, so sind sie nur statisch in Tx-Richtung.
Ist denn auf beiden Seiten nichts zu hören?
Was in den Traces auffällt ist dass nach der "B-CHANNEL QUEUE INDICATION" im Gutfall ein "B-Channel Reconnect"
durchgeführt wird und im Schlechtfall nicht.
Ob dies der Grund ist für das Verhalten, und warum dies anders ist, wenn ein anderer Teilnehmer abhebt, kann ich erstmal noch nicht sagen.
Mal weiter schauen.
Gruß
Andreas
danke erstmal für die Traces.
Was die statischen Audiodaten angeht, so sind sie nur statisch in Tx-Richtung.
Ist denn auf beiden Seiten nichts zu hören?
Was in den Traces auffällt ist dass nach der "B-CHANNEL QUEUE INDICATION" im Gutfall ein "B-Channel Reconnect"
durchgeführt wird und im Schlechtfall nicht.
Ob dies der Grund ist für das Verhalten, und warum dies anders ist, wenn ein anderer Teilnehmer abhebt, kann ich erstmal noch nicht sagen.
Mal weiter schauen.
Gruß
Andreas
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo Andreas,
besten Dank für die kleine Vorab-Analyse - und natürlich wieder mal Deine Mühe
Ja, es sit in beide Richtungen nichts zu hören - daß eine Richtung auf der LAN-Strecke jedoch dynamische Daten hat, ist klar - das Telefon sollte nämlich ordnungsgemäß funktionieren und der 1723 somit "echte" Daten empfangen. Kernpunkt scheint die B-Kanal-Auswahllogik zu sein bzw. ein logisches Problem dahingehend, daß die Lancom-Firmware davon ausgeht, daß für jedes Gespräch ein eigener B-Kanal "schon beim Signalisieren" reserviert werden müsse, obwohl ja die parallelen Rufe alle denselben B-Kanal als Ziel nennen (und das, wie schon irgendwo geschrieben, ja auch Zuständigkeit und Verantwortung des "NT"-Gerätes am Bus und NICHT eines TE-Geräts sein sollte, über die Sinnhaftigkeit der Signalisierung eigene Entscheidungen zu treffen nach dem Motto "ist ein zweiter Ruf, kann daher nicht auf B-Kanal 1 kommen, weil wir da schon eine andere gerufene MSN signalisiert bekommen haben".
Wären es zwei getrennte Rufe, die eine separate B-Kanal-Zuordnung benötigen würden, würde dies von der Anlage auch so gemeldet und der eine Ruf dem B1, der andere dem B2 zugeordnet in den SETUP-Nachrichten.
Meine Vermutung läßt sich dahingehend untermauern, indem der Simultanruf noch um eine dritte im 1723 programmierte und von der Anlage gerufene MSN erweitert wird. Für die dritte liefert der 1723 sofort eine Abweisung, obwohl der Ruf aufgrund der B1-Zuordnung signalisiert werden könnte.
Beste Grüße und nochmals danke,
Hans-Jürgen
besten Dank für die kleine Vorab-Analyse - und natürlich wieder mal Deine Mühe
Ja, es sit in beide Richtungen nichts zu hören - daß eine Richtung auf der LAN-Strecke jedoch dynamische Daten hat, ist klar - das Telefon sollte nämlich ordnungsgemäß funktionieren und der 1723 somit "echte" Daten empfangen. Kernpunkt scheint die B-Kanal-Auswahllogik zu sein bzw. ein logisches Problem dahingehend, daß die Lancom-Firmware davon ausgeht, daß für jedes Gespräch ein eigener B-Kanal "schon beim Signalisieren" reserviert werden müsse, obwohl ja die parallelen Rufe alle denselben B-Kanal als Ziel nennen (und das, wie schon irgendwo geschrieben, ja auch Zuständigkeit und Verantwortung des "NT"-Gerätes am Bus und NICHT eines TE-Geräts sein sollte, über die Sinnhaftigkeit der Signalisierung eigene Entscheidungen zu treffen nach dem Motto "ist ein zweiter Ruf, kann daher nicht auf B-Kanal 1 kommen, weil wir da schon eine andere gerufene MSN signalisiert bekommen haben".
Wären es zwei getrennte Rufe, die eine separate B-Kanal-Zuordnung benötigen würden, würde dies von der Anlage auch so gemeldet und der eine Ruf dem B1, der andere dem B2 zugeordnet in den SETUP-Nachrichten.
Meine Vermutung läßt sich dahingehend untermauern, indem der Simultanruf noch um eine dritte im 1723 programmierte und von der Anlage gerufene MSN erweitert wird. Für die dritte liefert der 1723 sofort eine Abweisung, obwohl der Ruf aufgrund der B1-Zuordnung signalisiert werden könnte.
Beste Grüße und nochmals danke,
Hans-Jürgen
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Moin Hans-Jürgen!
Btw.: Gibt es hier zu dem Fall eine Bugmeldung an den LANCOM-Support, also über den offiziellen Weg?
Ciao, Georg
Ich denke, hier läuft das Gerät in ein wediteres Problem, daß ihm schlicht die Datenstrukturen ausgehen. Die Grundstruktur des ISDN stammt noch aus der Zeit der Jahrtausendwende. Damals wäre es sehr ungewögnlich gewesen, wenn so "viele" Rufe gleichzeitig reingekommen wären. Das Problem können wir bei bedarf später nochmal angehen. Ich denke, das ist bei dir derzeit nicht dringend.hjm82 hat geschrieben:Meine Vermutung läßt sich dahingehend untermauern, indem der Simultanruf noch um eine dritte im 1723 programmierte und von der Anlage gerufene MSN erweitert wird. Für die dritte liefert der 1723 sofort eine Abweisung, obwohl der Ruf aufgrund der B1-Zuordnung signalisiert werden könnte.
Btw.: Gibt es hier zu dem Fall eine Bugmeldung an den LANCOM-Support, also über den offiziellen Weg?
Ciao, Georg
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo Georg,
danke für die Rückmeldung. Also der dritte Ruf hat in der Tat keine Wichtigkeit, das stimmt - es war lediglich ein "Test mit mehr oder weniger akademischem Wert"
Zwei simultane Rufe sind schon gut - sollte allerdings tatsächlich die Vermutung mit der B-Kanal-Zuordnung stimmen, würde es ja ohnehin danach auch einen dritten Ruf verkraften. Für den Datenstruktur-Aspekt als (eventuell) separat beschränkende Größe habe ich natürlich Verständnis.
Nein, einen offiziellen Bugreport gibt es bisher nicht - da das Gerät anfangs eine Teststellung war, wollte ich auch nicht zu viele Fässer aufmachen, und es gab ja auch immer die Aussagen, daß man sich als Kunde nicht an den Support wenden könne bzw. das ungern gesehen würde.
Was ich mal gemacht hab, war dieses "Presales"-Kontaktformular genutzt, um eine Anfrage zu stellen innerhalb der ersten Testzeit des Gerätes - das ging es aber eher um das Vermitteln an einer übergeordneten Anlage.
Aber da das hier bisher so positiv mit Unterstützung läuft, ist zumindest für ein 1723 meine Kaufentscheidung schon gefallen - kein anderes der geprüften Geräte hat meine Anforderungen zumindest "so gut" abgedeckt, wie es das 1723 schafft.
Kann/soll ich den Bug irgendwo offiziell eintüten - wen ja, wo und wie am besten?
Besten Dank und viele Grüße,
Hans-Jürgen
danke für die Rückmeldung. Also der dritte Ruf hat in der Tat keine Wichtigkeit, das stimmt - es war lediglich ein "Test mit mehr oder weniger akademischem Wert"
Zwei simultane Rufe sind schon gut - sollte allerdings tatsächlich die Vermutung mit der B-Kanal-Zuordnung stimmen, würde es ja ohnehin danach auch einen dritten Ruf verkraften. Für den Datenstruktur-Aspekt als (eventuell) separat beschränkende Größe habe ich natürlich Verständnis.Nein, einen offiziellen Bugreport gibt es bisher nicht - da das Gerät anfangs eine Teststellung war, wollte ich auch nicht zu viele Fässer aufmachen, und es gab ja auch immer die Aussagen, daß man sich als Kunde nicht an den Support wenden könne bzw. das ungern gesehen würde.
Was ich mal gemacht hab, war dieses "Presales"-Kontaktformular genutzt, um eine Anfrage zu stellen innerhalb der ersten Testzeit des Gerätes - das ging es aber eher um das Vermitteln an einer übergeordneten Anlage.
Aber da das hier bisher so positiv mit Unterstützung läuft, ist zumindest für ein 1723 meine Kaufentscheidung schon gefallen - kein anderes der geprüften Geräte hat meine Anforderungen zumindest "so gut" abgedeckt, wie es das 1723 schafft.
Kann/soll ich den Bug irgendwo offiziell eintüten - wen ja, wo und wie am besten?
Besten Dank und viele Grüße,
Hans-Jürgen
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hi,
http://www.lancom-systems.de/service-su ... -formular/
Nun du kannst schon mal sehr gut Teile deines Anfangspostings nutzen und am besten auch auch die Trace und Konfiguration mitgeben (Achtung Zugangsdaten vorher entfernen).
Und natürlich auch weitere Erkenntnisse reinschrieben die Du in diesem Thread gewonnen hast, damit der Supporter mit dir nicht das alles nochmal abklappert.
Ich hoffe da beschreibt das "wie" ausreichend.
Gruß
http://www.lancom-systems.de/service-su ... -formular/
Nun du kannst schon mal sehr gut Teile deines Anfangspostings nutzen und am besten auch auch die Trace und Konfiguration mitgeben (Achtung Zugangsdaten vorher entfernen).
Und natürlich auch weitere Erkenntnisse reinschrieben die Du in diesem Thread gewonnen hast, damit der Supporter mit dir nicht das alles nochmal abklappert.
Ich hoffe da beschreibt das "wie" ausreichend.
Gruß
Erst wenn der letzte Baum gerodet, der letzte Fluss vergiftet, der letzte Fisch gefangen ist, werdet Ihr merken, dass man Geld nicht essen kann.
Ein Optimist, mit entäuschten Idealen, hat ein besseres Leben als ein Pessimist der sich bestätigt fühlt.
Ein Optimist, mit entäuschten Idealen, hat ein besseres Leben als ein Pessimist der sich bestätigt fühlt.
Re: 1723: teils stumme Gespräche bei Sammelruf an mehrere MS
Hallo Marius,
danke für den direkten Link - leider ist die Lancom-Seite manchmal etwas unübersichtlich
Aufgrund Urlaub habe ich es leider bisher noch nicht geschafft, denke aber im Laufe der Woche (hoffe heute..) dazuzukommen. Sollte also jemand darauf warten - die Infos kommen so schnell es geht. Würde mich ja auch freuen, falls sich da tatsächlich was tun könnte!
Besten Dank und Grüße,
Hans-Jürgen
danke für den direkten Link - leider ist die Lancom-Seite manchmal etwas unübersichtlich
Aufgrund Urlaub habe ich es leider bisher noch nicht geschafft, denke aber im Laufe der Woche (hoffe heute..) dazuzukommen. Sollte also jemand darauf warten - die Infos kommen so schnell es geht. Würde mich ja auch freuen, falls sich da tatsächlich was tun könnte!
Besten Dank und Grüße,
Hans-Jürgen