Ekspertyza · Telefonia i contact center
Budujemy centralę: trunky SIP, reguły routingu według harmonogramu, menu IVR odczytywane z bazy, kolejki oczekiwania, przekierowanie do człowieka, nagrywanie i analiza połączeń. Połączenie staje się nagraniem z transkrypcją i podsumowaniem, a nie wspomnieniem.
Już zbudowaneTrzy własne implementacje, cytowane poniżej. (1) Warstwa Asterisk w platformie Kallina: 5.522 linii konfiguracji dialplan, skryptów AGI i mostów audio w `asterisk/`, plus szablony trunków generowane automatycznie dla każdego numeru. (2) `asterisk-manager` — osobna usługa, która zarządza kolejkami, trunkami i strumieniem RTP przez interfejs zarządzania centrali. (3) Middleware dla wirtualnej centrali operatora, który działał w produkcji: commit reconciling z 14 lipca 2026 wprowadza do repozytorium kod, który działał na serwerze i był o około 40 dni przed gitem. Zastrzeżenie, powiedziane zanim zapytasz: host SIP, przez który przechodzą nasze linie testowe, nie odpowiada — sprawdzone dziś, 06.09.2026, bez odpowiedzi na ping i bez odpowiedzi po HTTP. Nie prezentujemy numeru demonstracyjnego, pod który można teraz zadzwonić, ponieważ nie moglibyśmy go uruchomić przed Tobą.
Między Twoim operatorem telefonii a osobą, która faktycznie odbiera — człowiekiem lub agentem głosowym — musi istnieć warstwa, która podejmuje decyzje. Kto odbiera połączenie o 23:40. Co się dzieje, jeśli nikt nie odbiera. Gdzie trafia połączenie, gdy klient prosi o „człowieka”. Co zostaje z rozmowy po jej zakończeniu. Ta warstwa to centrala, a my budujemy ją tak, aby była własnością biznesu, a nie dostawcy głosu: jeśli jutro zmienisz silnik agenta, reguły routingu, kolejki i historia pozostają u Ciebie.
Konkretnie, co zbudowaliśmy: dwanaście plików dialplanu — produkcja, IVR, kolejka, transfer, voicemail, przekierowanie, połączenia wychodzące z agentem — cztery skrypty AGI w Pythonie i dwa mostki audio, łącznie 5.522 linii. Silnik IVR nie ma menu zapisanych w pliku: czyta je z bazy przez skrypt AGI i zwraca jedną z sześciu decyzji — do agenta, do innego menu, do kolejki, transfer na numer zewnętrzny, komunikat końcowy albo zamknięcie. Kolejki są nazwane według swojego identyfikatora i nie mają członków wpisanych w konfigurację: dodaje się ich i usuwa z zewnątrz, przez interfejs zarządzania, co oznacza, że operator może wejść do kolejki lub z niej wyjść bez restartu centrali.
Trasowanie ma rzeczywiste reguły, a nie jedno „dzwoń tutaj”: godziny pracy i strefa czasowa, tryb nocny typu 22:00 → 06:00 oraz dopasowanie według priorytetu — nagłówek SIP `Diversion`, który niesie oryginalny numer, z którego przekierowano połączenie, potem własny numer, a potem reguła rezerwowa. Trunki są generowane per numer, z nazwą zbudowaną z dostawcy i numeru, przez funkcję konfiguracji — nie wpisywane ręcznie przy każdej nowej linii.
To, co wychodzi z połączenia, jest równie ważne jak samo połączenie. Dla linii powiązanej z wirtualną centralą operatora zbudowaliśmy middleware w Pythonie, który odpyta listę nagrań co minutę, z szeroką rekoncyliacją co sześć godzin, aby awaria sieci niczego nie zgubiła, oraz skan co trzy minuty połączeń nieodebranych — te nie mają nagrania i inaczej byłyby całkowicie niewidoczne. Każde nagranie jest pobierane, transkrybowane, analizowane i odzwierciedlane w analizie połączeń, a połączenie nieodebrane staje się alertem. Idempotencja opiera się na zbiorze Redis, aby to samo nagranie nie zostało przetworzone dwa razy.
Co obejmuje
Szablony trunków są parametryzowane i uzupełniane przez funkcję konfiguracji, z nazwą utworzoną z dostawcy i numeru. W szablonie zapisane są transport, dozwolone kodeki, obsługa NAT, tryb DTMF i uwierzytelnianie. Praktyczny skutek: dziesiąty numer łączy się tak samo jak pierwszy, a różnice między operatorami są w jednym miejscu.
Godziny pracy i strefa czasowa, tryb nocny typu 22:00 → 06:00, dopasowanie według priorytetu: nagłówek SIP `Diversion` (numer, z którego przekierowano), potem własny numer, potem reguła rezerwowa. Wyszukiwanie reguły odbywa się przez skrypt AGI, który pyta platformę w trakcie połączenia, z własnym limitem czasu — więc reguła zmieniona w interfejsie obowiązuje przy następnym połączeniu, bez restartu.
Do agenta głosowego audio przechodzi przez most, który konwertuje kodek w obie strony, `g711_ulaw` ↔ `PCM16`. Do ludzi połączenie trafia do kolejki zarządzanej z zewnątrz. A przekazanie jest pod ręką osoby rozmawiającej: przekazanie ślepe przez `##` i przekazanie asystowane przez `*2`, a połączenie ląduje w kontekście napisanym do tego celu, który odróżnia wewnętrzne czterocyfrowe rozszerzenia od numerów zewnętrznych.
Silnik IVR otrzymuje identyfikator menu i odczytuje je z bazy przez skrypt AGI. Wynik to jedna z sześciu decyzji: do agenta, do innego menu (rekursywnie), do kolejki, przekazanie zewnętrzne, wiadomość końcowa, zamknięcie. Wiadomości mogą być syntetyzowane albo mogą to być pliki audio nagrane wcześniej. Zmiana menu oznacza zmianę jednego wiersza w bazie, a nie edycję pliku konfiguracyjnego na serwerze.
Każda kolejka nosi nazwę pochodzącą od swojego identyfikatora. Członkowie nie są utrwalani w konfiguracji: są dodawani i usuwani w trakcie działania przez interfejs zarządzania centralą, a jednoczesne umieszczanie na wielu wolnych miejscach jest włączone. W praktyce operator wchodzi do kolejki albo z niej wychodzi bez restartu centrali i bez wpływu na oczekujące połączenia.
Agent może zadzwonić samodzielnie do kogoś z zewnątrz i wrócić z odpowiedzią. Mechanizm jest zaimplementowany z własną tabelą i jawnymi stanami — dzwoni się, w trakcie, ponów próbę, zakończone, nieudane, brak odpowiedzi, wygasłe — z maksymalnie trzema próbami i przerwą dwóch minut między nimi, a wynik (w tym szacowany czas przyjazdu) wraca w uporządkowanej formie do rozmowy, która go zażądała. To nie jest koncept: są pięć dedykowanych funkcji serwera, plus zamiatanie połączeń, które zostały zawieszone.
Zaplanowany proces odczytuje listę nagrań co minutę, z szeroką rekoncyliacją co sześć godzin, aby awaria niczego nie zgubiła. Nagranie jest pobierane do WAV, transkrybowane, analizowane i odzwierciedlane w analizie połączeń wraz z audio. Osobno, co trzy minuty, odczytywane są połączenia nieobsłużone — które nie mają nagrania i inaczej nie istniałyby nigdzie — i stają się alertem. Nieodebrane połączenie to utracony klient; uczynienie go widocznym to najtańsza poprawa w centrum obsługi.
Klient, który komunikuje się z centralą operatora, ma własny limitator szybkości, z koszem tokenów, i jawne obsługiwanie błędów. To nie jest teoretyczna ostrożność: middleware, który odpyta co minutę i reconciluje co sześć godzin, bez hamulca może uderzyć w limit operatora i zostać zablokowany dokładnie wtedy, gdy jest potrzebny.
Jak to wygląda
Jakie numery istnieją, u jakiego operatora, kto odpowiada dziś za każdy z nich, w jakim są planie i co dzieje się teraz, gdy nikt nie odpowiada. Wygląda jak biurokracja; to część, która zapobiega niespodziankom. Z naszego doświadczenia wynika, że w puli numerów niemal zawsze są linie, o których baza mówi jedno, a centrala drugie — i nie wychodzi to na jaw przy uruchomieniu, lecz teraz.
Numer trafia na trunk, a połączenia przychodzące i wychodzące są testowane jako dwa odrębne elementy, bo psują się odrębnie. Udokumentowałyśmy przypadek, w którym połączenia przychodzące działały bez zarzutu przez wiele dni, podczas gdy wszystkie połączenia wychodzące były odrzucane przez centralę operatora z `403 Forbidden`, bez żadnych zmian po naszej stronie. Jeden test „zadzwoniło i zadziałało” tego nie obejmuje.
Reguły czasu pracy i priorytetów, menu, kolejki i ścieżki transferu zapisuje się jako dialplan i jako wiersze w bazie, a nie jako ustne ustalenie. Na końcu wiadomo dokładnie, co dzieje się z połączeniem o 23:40, w sobotę, gdy agent nie rozumie prośby.
Wynik połączenia — transkrypt, podsumowanie, sentyment, adres nagrania, czas trwania — jest przekazywany dalej przez podpisany webhook, a organizacja jest identyfikowana po numerze telefonu. Tam, gdzie istnieje CRM, połączenie łączy się z kartą i może automatycznie zmieniać status; o tej części piszemy na stronie o CRM i automatyzacji sprzedaży.
Centrala na jednym hoście to pojedynczy punkt awarii, i doświadczyłyśmy tego dokładnie: gdy host nie odpowiada, wszystkie linie przechodzące przez niego padają razem z nim, niezależnie od tego, jak dobrze jest skonfigurowany agent. Sygnatura awarii jest jasna — połączenie zwraca „request timed out” z pustym identyfikatorem połączenia SIP, czyli połączenie SIP nigdy nie zostało zestawione. Dlatego w realnym projekcie pytanie „co się dzieje, gdy host pada” zadaje się i budżetuje na początku: drugi host, monitoring, który wzywa człowieka, i ścieżka zapasowa do zwykłych numerów.
Dane
Pytania, które zadaje każdy, kto ma inspektora ochrony danych — postawione tutaj, zanim on je zada.
Przykład
Sytuacja
W przepływie analizy rozmów część połączeń trafiała do analizy, a część nie. Wzorzec wskazał przyczynę: brakowało dokładnie długich połączeń. To błąd, który zgłasza się jako „czasami nie działa” i błędnie szuka w transkrypcji.
Co zbudowaliśmy
Były dwie ścieżki transkrypcji i obie się wywalały, z różnych powodów. Ścieżka multimodalna wysyła cały plik audio zakodowany w treści żądania; powyżej określonego rozmiaru limit treści serwera pośredniczącego zwracał 413. Ścieżka rezerwowa wymagała modelu transkrypcji, na który klucz dostępu już nie pozwalał, więc odpowiadała 403. Obie kończyły się niepowodzeniem, proces raportował, że wszystkie modele transkrypcji zawiodły, a połączenie było porzucane. Krótkie połączenia pozostawały poniżej limitu treści, więc przechodziły — stąd wzorzec. Naprawa polegała na: pomijaniu ścieżki multimodalnej dla plików WAV powyżej 12 MB (próg konfigurowalny z środowiska), ponownym używaniu już obliczonego transkryptu zamiast transkrybowania drugi raz oraz przeniesieniu transkrypcji ostatniej instancji na dozwolony model.
Co z tego wyszło
Sprawdzone na pozostawionym zablokowanym nagraniu: rozmowa 21-minutowa, plik WAV 41 MB — ścieżka multimodalna pominięta, transkrypt pobrany, analiza wygenerowana, wiersz i audio trafiły do analizy połączeń, zero niepowodzeń. Rekonsyliacja potwierdziła potem, że nie ma już innych zablokowanych nagrań.
Czego nie mówi ten przypadek
Próg 12 MB jest właściwością serwera pośredniczącego, nie połączenia. Gdy zmienia się gateway, klucz albo model, próg trzeba sprawdzić ponownie — dlatego uczyniliśmy go konfigurowalnym ze środowiska, a nie wpisanym w kod.
Pytania
Nie dziś i wolimy to powiedzieć, niż podać numer, który dzwoni w próżnię. Część agenta można odsłuchać na stronie, od razu. Część telefoniczna zależy od hosta SIP, a host, przez który przechodzą nasze linie testowe, nie odpowiada w chwili pisania — sprawdzone dziś, brak odpowiedzi na ping i brak odpowiedzi po HTTP. Dla Twojego projektu telefonia jest uruchamiana na hoście dedykowanym projektowi, nie na testowym.
Ponieważ reguły routingu, kolejki, transfer, voicemail i historia połączeń należą do firmy, a nie do dostawcy głosu. Z własną centralą możesz zmienić silnik agenta bez przepisywania tego, jak działa Twój telefon, możesz skierować to samo połączenie raz do agenta, raz do człowieka, i możesz trzymać ewidencję połączeń u siebie. Bez niej jesteś związany tym, co dostawca zdecyduje się udostępnić.
Padają wszystkie linie, które przez niego przechodzą. To nie hipoteza: to, czego doświadczyliśmy, a sygnatura jest łatwa do rozpoznania — połączenie zwraca „request timed out” z pustym identyfikatorem połączenia SIP, więc to nie wina agenta, numeru ani promptu. Wniosek, jaki wyciągnęliśmy i który teraz wpisujemy do każdego projektu: ciągłość nie jest funkcją centrali, tylko decyzją architektoniczną i budżetową, podjętą na początku. Rozwiązuje się to drugim hostem i zapasową trasą do zwykłych numerów, a nie ustawieniem.
Nie. To dwie różne rzeczy, a operator może traktować je różnie. Mamy udokumentowany przypadek, w którym przy naszej niezmienionej konfiguracji i działających połączeniach przychodzących centrala operatora zaczęła odrzucać wszystkie połączenia wychodzące z `403 Forbidden` — dowodem, że problem był po stronie operatora, było to, że drugie konto o identycznej strukturalnie konfiguracji nadal dzwoniło na zewnątrz. Dlatego nie obiecujemy kampanii połączeń wychodzących przed udanym testem wychodzącym na Twój numer.
Tak, i robiliśmy to: napisaliśmy middleware w Pythonie nad API wirtualnej centrali operatora, z własnym klientem, limitatorem rate, pobieraniem nagrań, transkrypcją, analizą i alertowaniem, uruchomione w produkcji. Co trzeba wiedzieć z góry: dostęp do rozszerzonego API to często osobna usługa, kontraktowana oddzielnie, a dane uwierzytelniające mogą nie zadziałać od pierwszej próby — u nas cykl wyjaśniania specyfikacji i resetu hasła z operatorem trwał miesiące, przy już fakturowanej usłudze. Dlatego w ofercie zależnej od API operatora wyraźnie stawiamy warunek: praca zaczyna się po wykazaniu uwierzytelnienia, nie po obietnicy.
Mogą być rejestrowane, transkrybowane i analizowane. Pozostają przypisane do przestrzeni roboczej Twojej firmy, a dostęp wymaga uwierzytelnienia — nie ma wspólnego repozytorium między klientami. To, kto w Twoim zespole ma prawo odsłuchu, ustala się podczas wdrożenia. Powiadomienie rozmówcy i podstawa rejestracji to Twoje decyzje jako administratora danych; zapisujemy je w scenariuszu, nie zakładamy ich.
Są najgorzej obsługiwanym przypadkiem w większości firm, bo nie zostawiają śladu: nie ma nagrania, nie ma transkryptu, istnieją tylko w rejestrze połączeń. U nas proces czyta rejestr co trzy minuty, identyfikuje nieodebrane połączenia i zamienia je w alert oraz widoczny wiersz. Żeby było jasne, od czego to zależy: widzimy je tylko w takim zakresie, w jakim administrator ujawnia je w swoim rejestrze.
Tak, a menu znajdują się w bazie, a nie w plikach na serwerze. Silnik odczytuje konfigurację menu w trakcie połączenia i wybiera jedną z sześciu ścieżek: do agenta, do innego menu, do kolejki, transfer na numer zewnętrzny, wiadomość końcową albo zakończenie. Wiadomości mogą być syntetyzowane lub nagrane wcześniej. W praktyce zmiana menu nie wymaga ingerencji w centralę.
Przez uzgadnianie i to jest element, który budujemy jawnie. Szybkie zapytanie ma okno kilku dziesiątek godzin, a ponad nim co sześć godzin działa uzgadnianie na oknie tygodnia, które ponownie odczytuje kilka stron wyników. Każdy przetworzony rekord jest oznaczany, więc ponowne odczytanie niczego nie dubluje. Bez uzgadniania awaria trwająca godzinę oznacza trwałą dziurę w danych — i nikt jej nie zauważa.
22 z nich to kod i pliki z naszych repozytoriów. Nie publikujemy ich nazw ani numerów linii: razem, na jednej stronie, opisałoby to zbyt dokładnie, jak zbudowane są systemy, które nie należą tylko do nas. Przechodzimy je razem z Tobą, w repozytorium, na życzenie — weryfikacja pozostaje możliwa, tylko odbywa się w rozmowie.
Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.