Web-Chat, Echtzeitvoice und Telefonie
Ein Kanal verbindet einen veröffentlichten Assistenten mit einem Zugang. Jeder Kanal besitzt einen ausdrücklich gewählten Modus: test oder live. Ein aktiver Livekanal kann Kosten beim externen Anbieter verursachen und braucht alle Livefreigaben.
Webkanal
Lege einen aktiven Webkanal mit data.type=web, agent_id, Farbe und allowed_origins an. Origins enthalten Protokoll und Host, ohne Seitenpfad: https://www.example.at. Öffentliche Endpunkte sind GET /api/widget/{id} und POST /api/widget/{id}/chat.
Der öffentliche Chat benötigt keinen API-Schlüssel. Die Originprüfung begrenzt Browserzugriffe; sie ist keine Authentifizierung eines Besuchers und verhindert keine direkten HTTP-Aufrufe ohne Origin. Rate-Limits und Betreiberfreigaben begrenzen die Nutzung zusätzlich. Veröffentliche erst, wenn du den ausgewählten Agentstand und das Wissensangebot geprüft hast.
Widgetgespräche bleiben an Kanal, Arbeitsbereich und Agent gebunden. Fremde Gesprächs-IDs lassen sich nicht zum Lesen oder Fortsetzen anderer Arbeitsbereiche verwenden. Die Widget-Konfigurations-ID selbst ist öffentlich und kein Geheimnis.
Browser-Spracheingabe/-ausgabe kann je Browser, Betriebssystem und Berechtigung unterschiedlich verfügbar sein. Sie entspricht keiner garantierten Realtime-Sprachsession und kann durch Browserdienste verarbeitet werden. Die Mikrofonfreigabe benötigt bei einer externen Website HTTPS. Einzeldatei-TTS/STT über die Anbieterendpunkte ist eine separate Funktion.
Aktive Kanäle mit veröffentlichtem Agenten zeigen unter /trust/KANAL_ID konkrete öffentliche Anbieter-/Modus-/Aufbewahrungsinformationen. Der Widgetfooter verlinkt diese Seite. Firma und Kontakt kommen aus den Arbeitsbereichangaben; ein Betreiber muss sie korrekt eintragen. Die Seite ist keine pauschale Datenschutz- oder Compliance-Zertifizierung.
Telefonie mit Twilio
Richte TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN und TWILIO_PHONE_NUMBER in der Betreiberumgebung ein. Die öffentliche Basisadresse muss exakt stimmen und HTTPS verwenden. Eine aktive Live-Telefonkanalzuordnung benötigt type=phone und einen veröffentlichten Assistenten.
Twilio-Voice-Webhook: https://sihub.at/hooks/twilio/KANAL_ID/voice. Status-Webhook: https://sihub.at/hooks/twilio/KANAL_ID/status. Verwende POST. SIHub prüft X-Twilio-Signature gegen die kanonische öffentliche URL und alle Formularfelder. Falsche Proxy-/Domainkonfiguration führt zu abgewiesenen Callbacks.
Die Twilio-Route verwendet Gather für Spracherkennung, eine Modellantwort und Say für Ausgabe. Dies ist eine Abfolge einzelner Dialogturns; ElevenLabs/Deepgram-Dateiadapter sind nicht automatisch an diese Route angeschlossen.
Echtzeittelefonie mit LiveKit und deinem SIP-Carrier
Lege einen aktiven Kanal mit type=sip, voice_engine=livekit, mode=live und veröffentlichtem agent_id an. Der Betreiber bindet dessen tatsächliche ID in AIHUB_LIVEKIT_CHANNEL_BINDINGS an den Arbeitsbereich und optional einen Outbound-Trunk. Inbound-Trunk und Dispatchregel werden im LiveKit-Projekt eingerichtet. Zwei getrennte Voice-Worker nutzen Deepgram-STT, Cartesia-/ElevenLabs-TTS und OpenAI-/Groq-LLM mit optionaler DGX-Route. Redis begrenzt die gemeinsame Belegung. Die gesamte Einrichtung für österreichische Telefonie ist separat beschrieben.
LiveKit verarbeitet das bidirektionale Audio und Unterbrechungen. Transkripte, Dauer und Verbrauch werden im Arbeitsbereich gespeichert. Es gibt keinen eigenen SIP-/RTP-Server, automatischen Rufnummernkauf, Carrierfailover oder aktivierte Gesprächsaufzeichnung. Eine gespeicherte SIP-Loginmaske ersetzt nicht die Betreiber-Trunkzuordnung.
Angemeldete Browsergespräche
Verwende einen separaten aktiven Kanal mit type=webvoice, voice_engine=livekit und mode=live. POST /api/voice/web-session reserviert Kapazität und gibt einen kurzlebigen Token für genau diesen Raum zurück. Es gelten Anmeldung, Arbeitsbereich-/Livefreigaben und Mikrofonberechtigung. Browser-Voice im Portal ist getrennt vom öffentlich eingebetteten Textchatwidget.