SIHub Schritt für Schritt konfigurieren

Diese Anleitung ist der Einstieg für deinen Betrieb unter sihub.at. Die fertig vorbereiteten Dateien stehen im Projekt; Domain, Serveradresse, Rufnummern und Anbieterzugänge trägst du mit deinen tatsächlichen Daten ein. Echte Anrufe und der Nachweis für 20 gleichzeitige Gespräche sind erst nach dieser Einrichtung möglich.

SIHub bedeutet Super Intelligent Hub. Die technischen Variablennamen bleiben kompatibel: Verwende weiterhin AIHUB_*, die Redis-/Docker-Projekt-/Dienstnamen und den LiveKit-Agentnamen aihub-voice. Die Umbenennung braucht keinen neuen Arbeitsbereich. Die Datenbank ist MariaDB; eine alte SQLite-Installation wird nach der Übernahmeanleitung migriert.

Alle angelegten Benutzer, Agenten, Arbeitsbereicheinstellungen, Wissen, Kanäle und übrigen Plattformdaten werden dauerhaft in MariaDB SIHub gespeichert. SIHub gleicht beim Start das gesamte Schema ab und ergänzt fehlende Tabellen, Spalten und Indizes automatisch. Nach einem neuen Repositorystand reicht der vorbereitete Update-/Neustartablauf; manuelles Anlegen von Tabellen entfällt. Tabellenzuordnung, Statusprüfung und Verhalten bei inkompatiblen Änderungen stehen unter Datenbankbetrieb.

Zuerst nur Website und Portal wie TattooHub veröffentlichen: Der Apache-Schnellstart verwendet sudo bash apache2/install.sh prepare, den eigenen Dienst sihub und die fertigen HTTP-/HTTPS-Dateien in apache2/. Die vollständigen Befehle stehen im Repository unter apache2/README.md. API-/SMTP-Werte gehören bei diesem direkten Betrieb in /etc/sihub/sihub.env. Die nachfolgende Anleitung beschreibt den vollständigen Docker-/Voicebetrieb mit einer eigenen Betreiberdatei.

Wenn deine Installation bereits läuft: Sichere die aktuelle Betreiberdatei und ändere dort AIHUB_PUBLIC_URL=https://sihub.at. Behalte Redis-URLs, Schlüssel und vorhandene Telefoniebindungen bei. Die Datenbank-URL muss nach der Übernahme nach MariaDB auf MariaDB zeigen. Richte danach DNS und die neuen Apache-/HTTPS-Dateien nach Serveranleitung, Abschnitt 5 ein. Lade die konfigurierte App neu, sobald HTTPS bereitsteht. Ändere bestehende Twilio-Callbacks auf https://sihub.at/hooks/twilio/KANAL_ID/voice und /status; direkte Website-/Widgetlinks verwenden ebenfalls die neue Domain. Beim LiveKit-Pfad bleibt das SIP-Ziel die LiveKit-Adresse.

Abos, Botshop und Kontaktformular: Commerce und Kontakt einrichten erklärt Stripe-Produkte mit deinen eigenen Preisen, Checkout, automatische Verlängerung, Kundenportal und den signierten Webhook. Kontaktanfragen, Bestellungen und Abos werden in MariaDB gespeichert; neue Tabellen ergänzt der Startabgleich automatisch. SMTP ist mit mail.heartfrequency.solutions:587 und STARTTLS vorbereitet, Anmeldung office@sihub.at, Absender/Empfänger kontakt@sihub.at. Das SMTP-Passwort ergänzt du in deiner Betreiberdatei und aktivierst anschließend den Mailworker. Diese Einrichtung funktioniert auch im direkten Apachebetrieb ohne Voiceworker.

1. Entscheide dich zunächst für den Cloudstart

Für den ersten funktionierenden Telefonanruf verwendest du diese Kette:

AT-Rufnummer / SIP-Provider → LiveKit Cloud → SIHub Voiceworker
                                          ├─ Deepgram: hört und transkribiert
                                          ├─ OpenAI oder Groq: formuliert Antworten
                                          └─ Cartesia oder ElevenLabs: spricht
SIHub Website / Portal → MariaDB + Redis
Optional danach: eigener DGX-LLM über WireGuard, mit Cloud-Fallback

Du brauchst einen Cloud-LLM-Anbieter und einen TTS-Anbieter. Cartesia und ElevenLabs müssen nicht beide eingerichtet werden. Twilio ist für den LiveKit-Pfad nur nötig, wenn du es als SIP-Carrier wählst; die separaten TWILIO_*-Variablen gehören zum vorhandenen Gather/Say-Anrufpfad. Die Website läuft weiter als Flask/Gunicorn hinter Apache.

2. Diese Zugangsdaten bereitlegen

Dienst	Was du besorgst	Wo SIHub es verwendet
Domain/DNS	Zugriff auf sihub.at, öffentliche Server-IP	A-Record @ für die Hauptdomain, Apache, HTTPS
Appserver	SSH-Schlüssel, Sudo-Konto, Ubuntu 24.04 LTS	/var/www/SIHub, Docker und Apache
LiveKit Cloud	Projekt-URL, API-Key, API-Secret, SIP-Endpunkt	Medienräume, Workerdispatch, Browseraudio
Österreichische Rufnummer / SIP-Trunk	E.164-Nummer, SIP-Host, Authdaten, Inboundrouting, Kanallimit	LiveKit-Inbound-/Outboundtrunk
Deepgram	API-Key und freigegebenes Modell	Streaming-Spracherkennung
OpenAI oder Groq	API-Key und im Konto verfügbare Textmodell-ID	Voice-LLM und ggf. Textchat
Cartesia oder ElevenLabs	API-Key, Voice-ID und Modell-ID	Streaming-Sprachausgabe
SMTP/Webhook, optional	Server-/TLS-/Authdaten bzw. freigegebene HTTPS-Zieladresse	Zusammenfassungen und Benachrichtigungen
SMTP für Kontaktformular	Passwort für office@sihub.at, Freigabe für Absender kontakt@sihub.at	Versand gespeicherter Kontaktanfragen über STARTTLS
Stripe für Abos/Botkäufe	Secret Key, Webhooksignaturschlüssel, deine EUR-Preis-IDs	Checkout, wiederkehrende Abbuchungen, Botbestellungen und Kundenportal
DGX, optional	GPU-/Modellinstallation, privates VPN und eigener Serverkey	Privater Hybrid-LLM

Der Rufnummernanbieter muss die Weiterleitung zu LiveKit unterstützen. Bitte ihn um 30 gleichzeitige SIP-Gesprächskanäle, wenn du 20 produktive Calls plus Reserve planst. Lass dir die konkrete Konfiguration für seinen Trunk geben: Origination-/Inbound-Ziel, Termination-/Outbound-Host, Transport, Authverfahren, Absendernummern und Carrier-IP-Netze. Ohne gewählten Anbieter gibt es keinen universell richtigen Carrier-Webhook oder SIP-Passwortablauf. LiveKit-SIP-Anbietereinrichtung

3. Zuerst Server, Datenbank und Domain einrichten

Arbeite die Serveranleitung bis einschließlich HTTPS durch. Sie enthält Dockerinstallation, SQLite-Übernahme, MariaDB, Redis, Adminbenutzer und die Apache-Dateien für deine Domain.

Der Generator legt eine geschützte Betreiberdatei an:

cd /var/www/SIHub
python3 deploy/prepare_environment.py

Wenn sie bereits existiert, wird sie nicht überschrieben. Bearbeite sie stattdessen mit:

sudoedit /var/www/SIHub/deploy/.env.production

deploy/.env.production gehört zum Dockerbetrieb. Die Rootdatei .env gehört zur lokalen Pythoninstallation; Änderungen dort wirken nicht automatisch auf Docker. Die Betreiberdatei bleibt Modus 0600. Der Generator schreibt bereits neue Datenbank-/Redis-/Sitzungs-/Workerkeys und passende interne URLs; diese Werte musst du nicht aus Beispielen kopieren.

Bei einer übernommenen SQLite-Installation meldest du dich nach der Migration mit deinem bestehenden Konto an. Bei einer neuen Installation erstellst du den Admin mit dem in der Serveranleitung gezeigten interaktiven Kommando. Öffne danach https://sihub.at/login.

Der Installer provisioniert Datenbank und DB-Konto einmalig; die App aktualisiert anschließend das Schema ihrer bestehenden Datenbank unter einer MariaDB-Sperre. Im direkten Apachebetrieb liest sudo bash apache2/install.sh manage schema-status den Ist-/Sollstand ohne Änderungen. Im Dockerbetrieb lautet derselbe Befehl:

sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml run --rm --no-deps app python manage.py schema-status

4. Anbieterkeys und Modelle eintragen

Erstelle die Konten über die offiziellen Anbieter-Dashboards. Speichere die nachstehenden Werte in deploy/.env.production; alle Platzhalter müssen durch reale Werte ersetzt werden. Ein vorhandenes Chatprodukt-Abonnement beweist keinen API-Zugang mit Guthaben und Modellfreigabe.

LiveKit

1. Öffne LiveKit Cloud und erstelle oder wähle dein SIHub-Projekt.
2. Übernimm Projekt-URL, API-Key und API-Secret aus dem Projekt.
3. Notiere den SIP-Endpunkt für die anschließende Carrierkonfiguration.

LIVEKIT_URL=wss://DEIN_PROJEKT.livekit.cloud
LIVEKIT_API_KEY=DEIN_API_KEY
LIVEKIT_API_SECRET=DEIN_API_SECRET
AIHUB_VOICE_AGENT_NAME=aihub-voice

Die Projekt-URL ist die LiveKit-Adresse. sihub.at bleibt die Adresse deiner Website. Verwende für EU-SIP den tatsächlich zu deinem Projekt gehörenden regionalen Endpunkt aus den Einstellungen. LiveKit-Regionen

Deepgram für Spracherkennung

1. Öffne die Deepgram Console und wähle dein Projekt.
2. Erstelle einen API-Key mit Berechtigung für Streaming-STT.
3. Prüfe Modell-/Regionzugang und dein gleichzeitiges Verbindungslimit.

DEEPGRAM_API_KEY=DEIN_API_KEY
DEEPGRAM_MODEL=nova-3
DEEPGRAM_BASE_URL=https://api.eu.deepgram.com/v1/listen
DEEPGRAM_MIP_OPT_OUT=1

nova-3 unterstützt Deutsch. Der EU-Endpunkt ist ein regionaler STT-Endpunkt; die weiteren Anbieter müssen gesondert nach deinen Anforderungen ausgewählt werden. Deepgram-Modelle und Sprachen, EU-Endpunkt

OpenAI als Cloud-LLM

1. Öffne dein OpenAI-Projekt und richte dessen API-Nutzung ein.
2. Erstelle einen projektbezogenen API-Key und wähle eine tatsächlich zugängliche Textmodell-ID.
3. Trage das Modell ausdrücklich ein; SIHub errät keine kontospezifische Freigabe.

VOICE_LLM_PROVIDER=openai
OPENAI_API_KEY=DEIN_PROJEKT_API_KEY
OPENAI_MODEL=DEINE_VERFUEGBARE_MODELL_ID

Die offizielle OpenAI-Dokumentation verlangt, API-Keys serverseitig zu halten. Der Key gehört in die Betreiberdatei. OpenAI API-Authentifizierung

Für Groq wählst du stattdessen VOICE_LLM_PROVIDER=groq, setzt GROQ_API_KEY und GROQ_MODEL aus deinem Groq-Projekt. Die Voicepipeline unterstützt derzeit diese beiden Cloudanbieter. Die übrigen Textchat-Adapter sind kein zusätzlicher Realtime-Voiceanbieter.

Cartesia als Sprachausgabe

1. Öffne Cartesia und erstelle einen API-Key.
2. Wähle eine geeignete, zur Nutzung freigegebene Stimme und kopiere deren Voice-ID.
3. Prüfe Modellzugang und Streamingkonkurrenzlimit.

AIHUB_VOICE_TTS_PROVIDER=cartesia
CARTESIA_API_KEY=DEIN_API_KEY
CARTESIA_VOICE_ID=DEINE_VOICE_ID
CARTESIA_MODEL=sonic-3

Voice-ID und Model-ID sind unterschiedliche Angaben. Cartesia-Streaming-TTS

Für ElevenLabs setzt du stattdessen:

AIHUB_VOICE_TTS_PROVIDER=elevenlabs
ELEVENLABS_API_KEY=DEIN_API_KEY
ELEVENLABS_VOICE_ID=DEINE_VOICE_ID
ELEVENLABS_MODEL=eleven_flash_v2_5

Prüfe Stimme und Modell im eigenen Konto. Die offizielle Modelldokumentation führt eleven_flash_v2_5 als Alternative zu den älteren Turbo-Modellen auf. ElevenLabs-Modelle

5. Wissen, Assistent und Kanäle einrichten

1. Melde dich im Portal mit einem eigenen Nicht-Demo-Arbeitsbereich an.
2. Trage unter Wissen deine Unternehmensinformationen, FAQ, Öffnungszeiten und freigegebene Auskünfte ein.
3. Erstelle unter Assistenten einen Agenten mit deutscher Sprache, eindeutiger Begrüßung und Gesprächsziel. Teste seine Antworten zunächst im Testmodus.
4. Ordne das Wissen zu und veröffentliche einen Agentstand. Ein unpublizierter Entwurf reicht nicht für Live-Voice.
5. Lege einen aktiven SIP-/Telefonkanal mit voice_engine=livekit, mode=live und der veröffentlichten Agent-ID an. Für Browseraudio lege separat einen Kanal vom Typ webvoice an.
6. Notiere Kanal-ID und tatsächliche Arbeitsbereich-ID. Die ID bekommst du auch mit:

sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml run --rm --no-deps app python manage.py list-workspaces

Falls eine Oberfläche noch nicht jedes Kanalattribut anbietet, enthält LiveKit-Setup den genauen JSON-Vertrag für POST /api/entities/channels. Die API-Dokumentation erklärt Authentifizierung und CSRF für eigene Requests. Anbieterkeys werden niemals in der Kanal-Entity gespeichert.

6. Rufnummer, Trunks und Dispatch binden

Folge jetzt LiveKit-Setup, Abschnitten 2 bis 5:

1. Erstelle in LiveKit einen Inboundtrunk für deine Rufnummer und einen Outboundtrunk für deinen Provider.
2. Konfiguriere das Inboundziel beim Carrier auf deinen LiveKit-SIP-Endpunkt.
3. Erstelle genau passende Dispatchmetadaten mit der Kanal-ID und agentName=aihub-voice.
4. Notiere beide ST_...-Trunk-IDs und die verifizierte E.164-Absendernummer.
5. Ergänze die Betreiberbindung in derselben deploy/.env.production:

AIHUB_LIVEKIT_CHANNEL_BINDINGS='{"DEINE_CHANNEL_ID":{"workspace_id":"DEINE_WORKSPACE_ID","inbound_trunk_id":"ST_INBOUND","outbound_trunk_id":"ST_OUTBOUND","from_number":"DEINE_VERIFIZIERTE_E164_NUMMER"}}'
AIHUB_LIVE_WORKSPACE_IDS=DEINE_WORKSPACE_ID

JSON-Werte bleiben in einfachen äußeren Anführungszeichen, die enthaltenen JSON-Schlüssel in doppelten. Bei weiteren Kanälen fügst du weitere Einträge in dasselbe Objekt ein. Ein Webvoice-Eintrag benötigt nur seine echte workspace_id; er braucht keinen SIP-Trunk.

7. Prüfen, dann Live aktivieren und Worker starten

Solange du konfigurierst, bleibt AIHUB_LIVE_ENABLED=0. Prüfe zuerst die Datei ohne Anbieteraufrufe:

sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml config --quiet
sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml run --rm --no-deps app python manage.py check-config --voice

Fehlende Werte werden nur mit ihrem Variablennamen angezeigt. Exitcode 1 bedeutet: die genannten Einträge korrigieren. Ein erfolgreicher Check prüft Formate und Anwesenheit; er beweist keine gültigen Providerkeys oder realen Trunklimits.

Setze danach AIHUB_LIVE_ENABLED=1, erzeuge die App neu und aktiviere im Portal unter Einstellungen den Livebetrieb für deinen Arbeitsbereich. Die drei Freigaben sind notwendig: Betreiberflag, Betreiberliste mit Workspace-ID und Liveeinstellung im Arbeitsbereich.

sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml up -d --force-recreate app
sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml --profile voice up -d --build voice-worker-a voice-worker-b
sudo docker compose --env-file deploy/.env.production -f deploy/compose.yml ps

restart übernimmt geänderte Umgebungsvariablen nicht; up -d --force-recreate erzeugt die betreffenden Container mit der neuen Datei. Prüfe anschließend /api/voice/status im angemeldeten Portal und Workerregistrierung im LiveKit-Projekt. Aktiviere auch den Reaper-Minuttimer aus der Serveranleitung, damit abgelaufene Räume nach einem Workerabbruch geschlossen werden.

Führe jetzt einen autorisierten eingehenden Anruf zu deiner eigenen Rufnummer durch, dann einen Testanruf aus dem Portal zu einer einwilligenden Testperson. Erst danach prüfst du Browseraudio und die Stufen für 5/20/30 Gespräche unter Kapazitätsabnahme. Bei aktivem Carrier-Routing können tatsächliche Anrufer sofort kostenpflichtige Sessions auslösen.

8. Optional erweitern

DGX: Erst wenn Cloud-Voice funktioniert, richte den DGX-/WireGuard-Pfad ein. Prüfe manage.py check-config --voice --hybrid, dann wähle im Assistenten oder Arbeitsbereich die LLM-Route hybrid und veröffentliche den neuen Agentstand. Die lokale URL bleibt ein Betreiberziel.

Tools und Automationen: Konfiguriere erlaubte HTTPS-Hosts, Arbeitsbereichbindungen und Credentialreferenzen nach Tools. Beginne mit einer lesenden Aktion; schreibende Buchungen brauchen eindeutige Eingabe-/Erfolgsprüfung. Ein API-Key allein erstellt keinen fertigen CRM- oder Kalenderworkflow.

Benachrichtigungen: Richte SMTP oder gebundene Webhookziele nach Integrationen ein und aktiviere erst anschließend den eigenen Notifications-Timer. Kontrolliere die Outbox und tatsächliche Zustellung.

Preise: Trage deine aktuellen Vertragspreise in AIHUB_USAGE_PRICING ein. Der konkrete Feldvertrag steht unter Kapazitätsabnahme. Die Werte sind Kostenschätzungen und kein automatischer Rechnungs-/Zahlungseinzug.

Abos und Botverkäufe: Die tatsächlichen Verkaufspreise kommen aus deinen Stripe-Preis-IDs SIHUB_STRIPE_PRICE_*. Für den automatischen Zahlungseinzug richtest du Checkout und den Zahlungswebhook ein. Eigene Anbieter-Kostenschätzungen in AIHUB_USAGE_PRICING und Verkaufspreise verwaltest du separat.

Betrieb: Lege geprüfte, getrennt aufbewahrte Backups, Monitoringzugang und einen Wiederherstellungstest nach Deployment fest. Vor öffentlichem Kundenbetrieb müssen zusätzlich die tatsächlich gemessene Voicekapazität und deine verbleibenden Funktionsanforderungen abgenommen sein.