Architektura wirtualnej centrali: siedem elementów jednej usługi
„Centrala w chmurze” opisuje miejsce utrzymania części systemu, ale nie pokazuje całej drogi połączenia. Do rzetelnej oceny potrzebny jest diagram z siedmioma obszarami: urządzeniami użytkowników, siecią dostępową, warstwą sterowania, transportem mediów, stykiem z operatorem, danymi oraz administracją. Dopiero wtedy można sprawdzić jakość, bezpieczeństwo i odporność bez przerzucania odpowiedzialności między zespołami.
1. Punkty końcowe
Punktem końcowym może być telefon IP, aplikacja komputerowa, aplikacja mobilna, brama dla urządzenia analogowego albo rozwiązanie uruchomione w przeglądarce. Każdy wariant ma inne zależności: telefon biurkowy potrzebuje zasilania i sieci, softphone korzysta z systemu operacyjnego oraz urządzeń audio, a aplikacja mobilna zależy także od mechanizmów oszczędzania energii i zmieniającej się sieci.
Na diagramie zapisz sposób uwierzytelniania, źródło konfiguracji, cykl aktualizacji i właściciela urządzenia. Konto użytkownika w aplikacji oraz poświadczenia SIP telefonu nie powinny być traktowane jako ten sam sekret współdzielony przez cały zespół.
2. Sieć dostępowa
Głos przechodzi przez sieć lokalną, Wi-Fi lub internet mobilny, router, zaporę i łącze operatora dostępu. Przepustowość jest tylko jednym z parametrów. Kolejki na przeciążonym łączu, niestabilne Wi-Fi i nieprawidłowe mechanizmy obsługi NAT mogą pogorszyć rozmowę mimo dobrego wyniku pobierania dużego pliku.
Oznacz osobno każdą lokalizację oraz pracowników zdalnych. QoS może pomóc w kontrolowanej sieci, jeśli urządzenia prawidłowo oznaczają ruch, a kolejne elementy respektują oznaczenia. Nie zakładaj jednak, że priorytet zostanie zachowany przez cały publiczny internet.
3. Sygnalizacja SIP
SIP jest protokołem warstwy aplikacji używanym do zestawiania, modyfikowania i kończenia sesji. Obsługuje między innymi rejestrację urządzenia, zaproszenie do rozmowy, odpowiedzi i zakończenie. Treść sygnalizacji może uzgadniać parametry mediów za pomocą SDP, lecz same pakiety głosu zwykle płyną inną ścieżką.
Na schemacie wskaż serwer rejestracji, elementy proxy, centralę i brzeg połączenia z operatorem. Zanotuj transport, sposób weryfikacji certyfikatów i granice terminacji TLS. Szyfrowanie jednego odcinka nie oznacza automatycznie poufności sygnalizacji na wszystkich odcinkach.
4. Media RTP lub SRTP
RTP przenosi dane czasu rzeczywistego, a towarzyszący mu RTCP może raportować informacje o odbiorze. RFC 3550 opisuje między innymi liczbę utraconych pakietów i estymację jittera między kolejnymi przyjściami pakietów. Rozszerzenia RTCP XR z RFC 3611 dodają raporty dotyczące na przykład odrzuceń, opóźnień, okresów strat i bufora jittera.
SRTP dodaje mechanizmy ochrony mediów, ale trzeba ustalić sposób negocjacji kluczy oraz miejsca, w których media są odszyfrowywane. Transkodowanie, nagrywanie lub konferencja mogą wymagać przetwarzania głosu przez element pośredni. Dlatego pytanie powinno brzmieć nie tylko „czy jest SRTP?”, lecz „między którymi punktami i kto ma dostęp do postaci jawnej?”.
5. NAT, ICE, STUN i TURN
Urządzenia znajdujące się za NAT nie zawsze mogą bezpośrednio wymienić media. STUN jest narzędziem pomagającym ustalić adres i port widoczny po stronie sieci publicznej. ICE zbiera możliwe ścieżki i wykonuje testy łączności. Gdy bezpośrednia droga nie działa, TURN może zapewnić przekaźnik mediów. Aktualny RFC 8656 zastąpił wcześniejszy RFC 5766 dotyczący TURN.
Nie każda centrala korzysta z pełnego zestawu tych mechanizmów, a klasyczne urządzenia SIP mogą działać inaczej niż klient WebRTC. Nie otwieraj szerokich zakresów portów wyłącznie na podstawie ogólnego poradnika. Wymagane kierunki, adresy i protokoły uzyskaj od dostawcy, a następnie zweryfikuj je podczas pilotażu.
6. Operator, trunk i SBC
Połączenia do publicznej sieci telefonicznej przechodzą przez operatora lub dostawcę łącza SIP. Session Border Controller może pośredniczyć na granicy domen: kontrolować sygnalizację, ukrywać wewnętrzną topologię, egzekwować polityki, pomagać w zgodności protokołów i czasem kotwiczyć media. Nie jest jednak uniwersalnym lekarstwem. Źle skonfigurowany SBC może sam stać się pojedynczym punktem awarii lub miejscem zakończenia szyfrowania.
Na diagramie oznacz właściciela numerów, stronę odpowiedzialną za trasowanie, prezentację numeru, połączenia alarmowe, ochronę przed nadużyciami i przeniesienie numeracji. Ustal także, czy media przechodzą przez SBC, czy tylko sygnalizacja.
7. Dane i płaszczyzna administracyjna
Historia połączeń, książki adresowe, poczta głosowa, nagrania, transkrypcje, konfiguracja kolejek i tokeny integracji mają różną wrażliwość. Rozpisz miejsce przechowywania, administratora, procesora, podwykonawców, kopie, retencję, eksport oraz usuwanie. Osobno potraktuj panel administracyjny i API: powinny mieć silne uwierzytelnianie, role, rejestrowanie zmian i procedurę odbierania dostępu.
Gotowy diagram powinien pokazać normalny przepływ, wariant pracy zdalnej oraz tryb awaryjny. Jeżeli nie wiadomo, gdzie biegną media albo kto odtwarza konfigurację, architektura nie jest jeszcze gotowa do odbioru.
Przejdź do planu wyboru i wdrożenia
Źródła
Elementy protokołów opisano za dokumentami wymienionymi w tekście: RFC 3550, RFC 3611 i RFC 8656. Konkretne wdrożenie może różnić się doborem elementów i sposobem ich konfiguracji.