Moin..

Die Bedenken wurden schon erwähnt, komme ich zur technischen Umsetzung.

In meinem Kopf formen sich Teile eines Systems, bestehend aus einem Linux-PC,
einem Melder (oder Scan..ach nein, bleiben wir beim TKG), einer mindestens ISDN-
Leitung (oder zwei VoIP-Leitungen, oder analog + VoIP, oder oder oder - Hauptsache:
2 einzeln nutzbare Leitungen).

Die Software reagiert dann nach einem einfachen Logikplan:

Melder piepst, über einen Eingang (usb, seriell, soundkarte, was man halt gerade frei hat)
merkt der Rechner das (für nicht-TKG'ler: Soundkartenauswertung z.B. über "monitor"),
und wählt das Handy an.

Das Handy klingelt - die Rufnummer wird dem/der Handybesitzerin eindeutig zeigen,
das es sich um das "Notrufsystem" handelt, wenn es eine eigene Rufnummer ist, die
zu keinem anderen Zweck genutzt wird.

Wird nun ans Handy gegangen, spielt der Rechner ein "Bitte warten, ich verbinde" ab
und wählt gleichzeitig die interne Durchwahl des Leitstellendisponenten (oder technisch
möglich natürlich auch die 112, macht aber wenig Sinn). Wird hier ne eigene Rufnummer
verwendet, könnte ein Leitstellensystem auch hier den Anrufer eindeutig als Notarzt er-
kennen, da ja nicht die Handynummer, sondern die System-Rufnummer übertragen wird.

Nachdem die Verbindung von Handy über System an Leitstelle hergestellt ist, kann man
den Auftrag annehmen, oder auch nicht .. beim Auflegen werden beide Verbindungen
automatisch beendet.

Wenn nicht ans klingelnde Handy gegangen wird oder das Gerät nicht erreichbar ist,
könnte man weitere Rufnummern (auch parallel, maximal soviele Parallelrufe wie Leitungen
am PC verfügbar) anrufen lassen, oder einfach nicht tun. - Ist also keiner erreichbar,
würde auch nicht die Leitstelle angerufen/blockiert.

Wenn man nun nicht schnell genug ist - Melder geht, Handy klingelt 5-6 Sekunden später,
je nach Verbindungsaufbau-Geschwindigkeit, Teilnehmer geht ans Handy, nochmal ein
paar Sekunden bis es im Hörer "tuuuut" macht .. naja, technisch geht's nicht schneller.

So, die Gedanken zu solchem System sind niedergeschrieben - technisch und von meinem
persönlichen Wissen her absolut realisierbar. Bei Interesse würde ich dir so ein System auch
zusammenstellen, die Hardware empfehle ich dir, du kaufst sie dir, die Softwareinstallation
kann ich dir auf CD schicken, von der du das System bootest und die sich dann selbst
installiert. Rufnummern (ob nun Alarmschleife oder Telefon) würdest du per Web-Interface
einstellen. An Hardwarekosten kannst du dir etwa einen PC vorstellen, der mindestens 500 MHz
schnell ist und 512 MB RAM hat. Melder musst du selbst wissen, ein Interface zwischen Melder
und serieller Schnittstelle zur Alarmerkennung kostet nen paar Euro, oder du lässt per Soundkarte
des Rechners erkennen.. Die Software ist Open Source, für die Einrichtung der Logik würde
ich aber schon ne Aufwandsentschädigung haben wollen ^^ .. die Logik ist nur mässig
anspruchsvoll, ich würde wohl 2 Arbeitsstunden schätzen..

Obligatorisch ist der Hinweis, das dieses System, sollte es in Bereichen eingesetzt werden,
wo wirklich Menschenleben von abhängen, ausfallsicher aufzubauen wäre! Das hiesse nicht
einfach nen PC zu nehmen, sondern durchaus redundant zu arbeiten. Kostenfaktor also mindestens
1,8fach zu nicht redundantem System. Dabei ist bei "1fach" die Stromausfall-Sicherung schon
drin, ne USV kostet ja nicht mehr viel .. auch Sensoren, die dann per Sprachanruf oder SMS
"Störungen" melden, könnten in die Logik eingebaut werden.

Dennoch hat das System dann immer noch kein Zertifikat ! Sowas gibt es sicherlich, die Grund-
software gibt's sogar zertifiziert, ist dann kein Open Source mehr und kostet gutes Geld. Auch
ein Gesamtzertifikat würde sicherlich für eine Einzelanwendung verdammt viel Geld kosten..

Aus technischer Sicht also wie gesagt keinerlei Problem (ausser das Geld *G*) .. ob aber die
NA-Alarmierung mit sowas wirklich gut ist, steht auf einem anderen Blatt!!

Alle Klarheiten beseitigt ? ;)

Gruss,
Tim