Nagrywanie rozmów w centrali VoIP – gdzie powstaje plik i jak działa zapis

Nagrywanie rozmów w centrali VoIP polega na zapisaniu dźwięku, do którego ma dostęp centrala albo współpracujący z nią rejestrator. Samo zalogowanie telefonu do konta SIP nie uruchamia nagrywania. Potrzebne są jeszcze odpowiednia ścieżka przesyłania głosu, mechanizm zapisu oraz konfiguracja określająca, kiedy ma on działać. Wirtualna centrala może realizować te zadania na serwerach usługodawcy, ale szczegóły zależą od konkretnego systemu.

SIP zestawia połączenie, RTP przenosi głos

W telefonii internetowej trzeba rozróżnić sygnalizację i media. SIP, opisany w RFC 3261, służy do nawiązywania, zmieniania i kończenia sesji. Umożliwia też rejestrację urządzenia, dzięki której system może ustalić, gdzie skierować połączenie. Komunikaty sygnalizacyjne przekazują informacje potrzebne do uzgodnienia komunikacji, lecz same nie stanowią zapisu wypowiedzi.

Dźwięk jest przesyłany osobnym strumieniem, zwykle za pomocą RTP. RFC 3550 opisuje między innymi oznaczanie kolejności pakietów i czasu próbkowania. Dzięki temu odbiorca może odtworzyć strumień mimo właściwości transmisji sieciowej. SRTP dodaje mechanizmy ochrony mediów, w tym szyfrowanie. Nie należy utożsamiać zabezpieczenia sygnalizacji SIP z szyfrowaniem samego głosu.

To rozróżnienie wyjaśnia częsty problem: telefon ma status zarejestrowanego, połączenie się zestawia, a nagrania brakuje. Rejestracja potwierdza wykonanie określonej czynności sygnalizacyjnej. Nie dowodzi, że rejestrator otrzymał dźwięk z obu kierunków ani że rozpoczął zapis do pliku.

Gdzie musi trafić dźwięk, aby powstało nagranie

Element zapisujący rozmowę musi otrzymać jej media w postaci umożliwiającej nagrywanie. Może działać wewnątrz centrali, która przetwarza dźwięk, albo przyjmować jego kopię od innego urządzenia. Sam fakt, że komunikaty SIP przechodzą przez firmowy serwer, nie oznacza, że przechodzą przez niego również pakiety z głosem.

RFC 7245 wyraźnie rozróżnia te role. Serwer proxy SIP, który obsługuje wyłącznie sygnalizację, nie może sam pełnić funkcji źródła mediów dla nagrywania SIPREC. Taką funkcję może natomiast realizować odpowiednio wyposażony telefon, brama lub element infrastruktury mający dostęp do dźwięku. To możliwości architektury, a nie zestaw funkcji każdego urządzenia z obsługą SIP.

Przykładowo: jeśli rozmówcy wymieniają dźwięk bezpośrednio, a centrala pośredniczy tylko w zestawieniu połączenia, moduł zapisujący na tej centrali nie dostaje automatycznie materiału. Konfiguracja musi zapewnić mu dostęp do mediów albo ich kopii. Dlatego przy analizie wdrożenia przydaje się schemat pokazujący osobno drogę sygnalizacji i drogę głosu.

Centrala lokalna i hostowana: co zmienia miejsce instalacji

W centrali lokalnej oprogramowanie może pracować na serwerze w firmie. Jeżeli zapis odbywa się na tym serwerze, administrator musi uwzględnić miejsce na pliki, uprawnienia do katalogów i działanie procesu nagrywającego. Centrala hostowana działa na infrastrukturze poza siedzibą przedsiębiorstwa. Samo przeniesienie programu na zewnętrzny serwer nie przesądza jednak, jak realizuje on nagrywanie.

Wirtualna centrala udostępniana jako usługa może łączyć obsługę połączeń z funkcją rejestracji po stronie dostawcy. Aparat na biurku jest w takim układzie urządzeniem do prowadzenia rozmowy; nie musi być miejscem powstawania pliku. Z kolei panel internetowy jest sposobem obsługi systemu, a jego adres nie wskazuje fizycznej lokalizacji archiwum.

Jednym z przykładów jest otoTelefon – system telefoniczny w chmurze z wirtualną centralą IP-PBX i nagrywaniem rozmów jako usługą dodatkową. Usługę otoTelefon świadczy Telepartner Sp. z o.o., z którą powiązany jest ten serwis. Opis tej usługi nie potwierdza wykorzystania SIPREC ani konkretnej drogi przesyłania mediów, więc nie można na jego podstawie odtworzyć wewnętrznej architektury nagrywania.

Jak zapisuje rozmowę Asterisk MixMonitor

Konkretny przykład zapisu wewnątrz centrali daje dokumentacja Asterisk. Aplikacja MixMonitor rejestruje dźwięk bieżącego kanału do wskazanego pliku i pozwala mieszać dźwięk podczas nagrywania. Kanał można tu rozumieć jako część obsługi połączenia w centrali. Wywołanie aplikacji umieszcza się w logice obsługi połączeń, czyli dialplanie.

Dokumentacja określa także miejsce zapisu: podanie ścieżki bezwzględnej wskazuje konkretną lokalizację, natomiast sama nazwa pliku powoduje użycie katalogu nagrań określonego w konfiguracji Asterisk. To wyjaśnia, dlaczego nagranie może istnieć na serwerze, choć nie pojawia się jeszcze w żadnym panelu dla pracownika. Utworzenie pliku i udostępnienie go użytkownikowi są odrębnymi zadaniami.

Opcja b ogranicza zapis do okresu, gdy kanał jest połączony z drugim kanałem w mostku. Opcje r oraz t pozwalają zapisywać osobno dźwięk odbierany i wysyłany. Są to możliwości opisane dla MixMonitor; nie należy przenosić tych nazw ani zachowania do innych central. Dokumentacja zaznacza również, że MixMonitor sam nie odbiera połączenia.

Jeżeli dalszy etap dialplanu ma przetwarzać gotowy plik, dokumentacja wymaga użycia StopMixMonitor, aby zagwarantować jego dostępność. Administrator powinien więc sprawdzić zarówno uruchomienie nagrywania, jak i moment zakończenia zapisu. Samo pojawienie się nazwy pliku w katalogu nie rozstrzyga, czy można już bezpiecznie przekazać go do następnego procesu.

SIPREC: osobna sesja do rejestrowania rozmowy

SIPREC pozwala oddzielić obsługę rozmowy od systemu, który odbiera materiał do rejestracji. RFC 7245 opisuje architekturę, a RFC 7866 protokół. W tym modelu występują dwie podstawowe role:

• SRC, czyli klient nagrywania – dostarcza kopię mediów oraz informacje opisujące nagrywaną sesję.
• SRS, czyli serwer nagrywania – odbiera media i metadane przekazane w celu rejestracji.

Między tymi elementami powstaje sesja przeznaczona do nagrywania, odrębna od sesji rozmówców. Metadane pomagają powiązać strumienie z uczestnikami i przebiegiem komunikacji. Nie chodzi więc tylko o wysłanie anonimowego dźwięku do drugiego serwera. System potrzebuje również informacji, których rozmów i uczestników ten materiał dotyczy.

SIPREC nie jest nazwą uniwersalnego panelu archiwum. Standard nie określa wyglądu listy nagrań, przycisku pobierania ani całej organizacji przechowywania. Możliwość wyszukania pliku, jego eksportu czy przypisania uprawnień trzeba potwierdzić w dokumentacji produktu. Podobnie reguła nagrywania wszystkich połączeń albo tylko wybranej grupy jest cechą konfiguracji danego rozwiązania.

Jakość nagrania zależy także od punktu rejestracji

RTP nie gwarantuje dostarczenia wszystkich pakietów ani wymaganej jakości usługi. Straty i zmienne opóźnienia mogą wpłynąć na odbiór głosu, a ich znaczenie zależy od miejsca wystąpienia. Rejestrator otrzymujący niepełny strumień nie ma z samego faktu nagrywania dostępu do oryginalnej, kompletnej wypowiedzi.

W architekturze z kopiowaniem mediów trzeba uwzględnić także odcinek prowadzący do rejestratora. Rozmówcy mogą słyszeć się poprawnie, a kopia dostarczona inną drogą może mieć braki. Przy diagnozie należy więc porównywać tor rozmowy z torem nagrywania, zamiast oceniać cały system wyłącznie na podstawie jakości odsłuchu w telefonie.

Znaczenie mają również kodeki i ewentualna konwersja między nimi. RFC 7245 przewiduje możliwość transkodowania, gdy wymaga tego zgodność elementów systemu. Obciążenie łącza i serwera zależy od konfiguracji oraz liczby równoczesnych strumieni. Nie ma jednej wartości przepustowości, która gwarantowałaby poprawne nagrywanie w każdej centrali.

Co sprawdzić w rzeczywistym wdrożeniu

Analizę techniczną można uporządkować w pięciu krokach:

1. Ustalić, który element otrzymuje dźwięk z obu kierunków i który uruchamia rejestrację.
2. Sprawdzić warunki rozpoczęcia i zakończenia zapisu w dokumentacji użytej centrali.
3. Wskazać miejsce tworzenia pliku oraz sposób jego udostępnienia uprawnionemu użytkownikowi.
4. Zweryfikować zachowanie przy przekazaniu rozmowy, zmianie urządzenia i przerwaniu połączenia.
5. Oddzielnie sprawdzić ochronę transmisji, archiwum oraz dostępu do odsłuchu.

Szyfrowanie głosu w sieci nie jest potwierdzeniem szyfrowania plików na dysku. RFC 7866 rozdziela ochronę mediów, metadanych oraz przechowywania i odtwarzania. Tak samo sama pozycja w historii połączeń nie dowodzi istnienia kompletnego nagrania. Dopiero ustalenie drogi dźwięku, warunków zapisu i dostępności gotowego materiału pozwala ocenić, co centrala rzeczywiście rejestruje.

Źródła

• IETF: RFC 3261, SIP: Session Initiation Protocol, czerwiec 2002, rfc-editor.org/rfc/rfc3261.
• IETF: RFC 3550, RTP: A Transport Protocol for Real-Time Applications, lipiec 2003, rfc-editor.org/rfc/rfc3550.
• IETF: RFC 7245, An Architecture for Media Recording Using the Session Initiation Protocol, maj 2014, rfc-editor.org/rfc/rfc7245.
• IETF: RFC 7866, Session Recording Protocol, maj 2016, rfc-editor.org/rfc/rfc7866.
• Asterisk: dokumentacja aplikacji dialplanu MixMonitor, docs.asterisk.org/Latest_API/API_Documentation/Dialplan_Applications/MixMonitor/.
• otoTelefon: opis systemu telefonicznego w chmurze, wirtualnej centrali IP-PBX i usług dodatkowych, ototelefon.pl.

Zdjęcie: Антон Пищулин, CC BY-SA 4.0 (creativecommons.org/licenses/by-sa/4.0/), Wikimedia Commons, commons.wikimedia.org/wiki/File:IP-Phone_Grandstream_GXP1610.jpg