Basic VoIP Protocols
Last updated
Last updated
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Це стандарт галузі, для отримання додаткової інформації перегляньте:
MGCP (Протокол управління медіа-шлюзами) є протоколом сигналізації та управління дзвінками, описаним у RFC 3435. Він працює в централізованій архітектурі, яка складається з трьох основних компонентів:
Агент дзвінків або контролер медіа-шлюзів (MGC): Головний шлюз в архітектурі MGCP відповідає за управління та контроль медіа-шлюзів. Він обробляє процеси налаштування, модифікації та завершення дзвінків. MGC спілкується з медіа-шлюзами, використовуючи протокол MGCP.
Медіа-шлюзи (MG) або підлеглі шлюзи: Ці пристрої перетворюють цифрові медіа-потоки між різними мережами, такими як традиційна телефонія з комутацією каналів та пакетна IP-мережа. Вони управляються MGC і виконують команди, отримані від нього. Медіа-шлюзи можуть включати функції, такі як транскодування, пакетація та скасування еха.
Шлюзи сигналізації (SG): Ці шлюзи відповідають за перетворення сигналізаційних повідомлень між різними мережами, що дозволяє безперешкодну комунікацію між традиційними телефонними системами (наприклад, SS7) та IP-мережами (наприклад, SIP або H.323). Шлюзи сигналізації є критично важливими для взаємодії та забезпечення правильного обміну інформацією про управління дзвінками між різними мережами.
Отже, MGCP централізує логіку управління дзвінками в агенті дзвінків, що спрощує управління медіа- та сигналізаційними шлюзами, забезпечуючи кращу масштабованість, надійність та ефективність у телекомунікаційних мережах.
Протокол контролю тонкого клієнта (SCCP) є приватним протоколом сигналізації та управління дзвінками, що належить Cisco Systems. Він в основному використовується для зв'язку між Cisco Unified Communications Manager (раніше відомим як CallManager) та Cisco IP-телефонами або іншими Cisco голосовими та відео терміналами.
SCCP є легким протоколом, який спрощує зв'язок між сервером управління дзвінками та кінцевими пристроями. Його називають "тонким" через його мінімалістичний дизайн та зменшені вимоги до пропускної здатності в порівнянні з іншими VoIP протоколами, такими як H.323 або SIP.
Основні компоненти системи на базі SCCP:
Сервер управління дзвінками: Цей сервер, зазвичай Cisco Unified Communications Manager, управляє процесами налаштування, модифікації та завершення дзвінків, а також іншими телефонними функціями, такими як переадресація дзвінків, передача дзвінків та утримання дзвінків.
Кінцеві пристрої SCCP: Це пристрої, такі як IP-телефони, системи відеоконференцій або інші Cisco голосові та відео термінали, які використовують SCCP для зв'язку з сервером управління дзвінками. Вони реєструються на сервері, надсилають та отримують сигналізаційні повідомлення та виконують інструкції, надані сервером управління дзвінками для обробки дзвінків.
Шлюзи: Ці пристрої, такі як голосові шлюзи або медіа-шлюзи, відповідають за перетворення медіа-потоків між різними мережами, такими як традиційна телефонія з комутацією каналів та пакетна IP-мережа. Вони також можуть включати додаткову функціональність, таку як транскодування або скасування еха.
SCCP пропонує простий та ефективний метод зв'язку між серверами управління дзвінками Cisco та кінцевими пристроями. Однак варто зазначити, що SCCP є приватним протоколом, що може обмежити взаємодію з системами, що не належать Cisco. У таких випадках інші стандартні VoIP протоколи, такі як SIP, можуть бути більш підходящими.
H.323 є набором протоколів для мультимедійної комунікації, включаючи голос, відео та конференції з даними через пакетні мережі, такі як IP-мережі. Він був розроблений Міжнародним союзом електрозв'язку (ITU-T) і надає всебічну структуру для управління мультимедійними комунікаційними сесіями.
Деякі ключові компоненти набору H.323 включають:
Термінали: Це кінцеві пристрої, такі як IP-телефони, системи відеоконференцій або програмні додатки, які підтримують H.323 і можуть брати участь у мультимедійних комунікаційних сесіях.
Шлюзи: Ці пристрої перетворюють медіа-потоки між різними мережами, такими як традиційна телефонія з комутацією каналів та пакетна IP-мережа, що дозволяє взаємодію між H.323 та іншими комунікаційними системами. Вони також можуть включати додаткову функціональність, таку як транскодування або скасування еха.
Контролери доступу (Gatekeepers): Це необов'язкові компоненти, які надають послуги управління та контролю дзвінків у мережі H.323. Вони виконують функції, такі як трансляція адрес, управління пропускною здатністю та контроль доступу, допомагаючи управляти та оптимізувати мережеві ресурси.
Багатоточкові контролери (MCU): Ці пристрої полегшують багатоточкові конференції, управляючи та змішуючи медіа-потоки з кількох кінцевих пристроїв. MCU дозволяють такі функції, як контроль розташування відео, перемикання за голосом та безперервна присутність, що робить можливим проведення масштабних конференцій з кількома учасниками.
H.323 підтримує ряд аудіо- та відеокодеків, а також інші додаткові послуги, такі як переадресація дзвінків, передача дзвінків, утримання дзвінків та очікування дзвінків. Незважаючи на його широке використання на початку ери VoIP, H.323 поступово замінюється більш сучасними та гнучкими протоколами, такими як Протокол ініціації сеансу (SIP), який пропонує кращу взаємодію та легшу реалізацію. Однак H.323 залишається в використанні в багатьох застарілих системах і продовжує підтримуватися різними постачальниками обладнання.
IAX (Inter-Asterisk eXchange) є протоколом сигналізації та управління дзвінками, який в основному використовується для зв'язку між серверами Asterisk PBX (Приватна телефонна станція) та іншими VoIP пристроями. Він був розроблений Марком Спенсером, творцем програмного забезпечення Asterisk з відкритим кодом, як альтернатива іншим VoIP протоколам, таким як SIP та H.323.
IAX відомий своєю простотою, ефективністю та легкістю реалізації. Деякі ключові особливості IAX включають:
Один UDP порт: IAX використовує один UDP порт (4569) для сигналізації та медіа-трафіку, що спрощує проходження через брандмауер та NAT, полегшуючи розгортання в різних мережевих середовищах.
Бінарний протокол: На відміну від текстових протоколів, таких як SIP, IAX є бінарним протоколом, що зменшує споживання пропускної здатності та робить його більш ефективним для передачі сигналізаційних та медіа-даних.
Транкування: IAX підтримує транкування, що дозволяє об'єднувати кілька дзвінків в одне мережеве з'єднання, зменшуючи накладні витрати та покращуючи використання пропускної здатності.
Нативне шифрування: IAX має вбудовану підтримку шифрування, використовуючи методи, такі як RSA для обміну ключами та AES для шифрування медіа, забезпечуючи безпечну комунікацію між кінцевими пристроями.
Комунікація "пір-до-піра": IAX може використовуватися для прямого зв'язку між кінцевими пристроями без необхідності в центральному сервері, що дозволяє простіше та ефективніше маршрутизувати дзвінки.
Незважаючи на свої переваги, IAX має деякі обмеження, такі як його основна орієнтація на екосистему Asterisk та меншу поширеність у порівнянні з більш усталеними протоколами, такими як SIP. Як результат, IAX може не бути найкращим вибором для взаємодії з системами або пристроями, що не належать Asterisk. Однак для тих, хто працює в середовищі Asterisk, IAX пропонує надійне та ефективне рішення для VoIP комунікації.
SDP (Протокол опису сеансу) є текстовим форматом, що використовується для опису характеристик мультимедійних сеансів, таких як голос, відео або конференції з даними, через IP-мережі. Він був розроблений Інженерним комітетом Інтернету (IETF) і визначений у RFC 4566. SDP не обробляє фактичну передачу медіа або встановлення сеансу, але використовується разом з іншими протоколами сигналізації, такими як SIP (Протокол ініціації сеансу), для узгодження та обміну інформацією про медіа-потоки та їх атрибути.
Деякі ключові елементи SDP включають:
Інформація про сеанс: SDP описує деталі мультимедійного сеансу, включаючи назву сеансу, опис сеансу, час початку та час закінчення.
Медіа-потоки: SDP визначає характеристики медіа-потоків, такі як тип медіа (аудіо, відео або текст), транспортний протокол (наприклад, RTP або SRTP) та формат медіа (наприклад, інформація про кодек).
Інформація про з'єднання: SDP надає інформацію про мережеву адресу (IP-адресу) та номер порту, куди медіа повинні бути надіслані або отримані.
Атрибути: SDP підтримує використання атрибутів для надання додаткової, необов'язкової інформації про сеанс або медіа-потік. Атрибути можуть використовуватися для вказівки різних функцій, таких як ключі шифрування, вимоги до пропускної здатності або механізми управління медіа.
SDP зазвичай використовується в наступному процесі:
Ініціююча сторона створює опис SDP запропонованого мультимедійного сеансу, включаючи деталі медіа-потоків та їх атрибути.
Опис SDP надсилається отримуючій стороні, зазвичай вбудований в повідомлення протоколу сигналізації, такого як SIP або RTSP.
Отримуюча сторона обробляє опис SDP, і на основі своїх можливостей вона може прийняти, відхилити або змінити запропонований сеанс.
Остаточний опис SDP надсилається назад ініціюючій стороні як частина повідомлення протоколу сигналізації, завершуючи процес узгодження.
Простота та гнучкість SDP роблять його широко прийнятим стандартом для опису мультимедійних сеансів у різних комунікаційних системах, відіграючи важливу роль у встановленні та управлінні реальними мультимедійними сеансами через IP-мережі.
RTP (Протокол реального часу): RTP є мережевим протоколом, призначеним для доставки аудіо- та відеоданих або інших медіа в реальному часі через IP-мережі. Розроблений IETF та визначений у RFC 3550, RTP зазвичай використовується з протоколами сигналізації, такими як SIP та H.323, для забезпечення мультимедійної комунікації. RTP надає механізми для синхронізації, послідовності та тимчасого маркування медіа-потоків, що допомагає забезпечити плавне та своєчасне відтворення медіа.
RTCP (Протокол контролю реального часу): RTCP є супутнім протоколом до RTP, що використовується для моніторингу якості обслуговування (QoS) та надання зворотного зв'язку щодо передачі медіа-потоків. Визначений у тому ж RFC 3550, що й RTP, RTCP періодично обмінюється контрольними пакетами між учасниками сеансу RTP. Він ділиться інформацією, такою як втрата пакетів, джиттер та час кругового проходження, що допомагає діагностувати та адаптуватися до умов мережі, покращуючи загальну якість медіа.
SRTP (Безпечний протокол реального часу): SRTP є розширенням RTP, яке забезпечує шифрування, автентифікацію повідомлень та захист від повторних атак для медіа-потоків, забезпечуючи безпечну передачу чутливих аудіо- та відеоданих. Визначений у RFC 3711, SRTP використовує криптографічні алгоритми, такі як AES для шифрування та HMAC-SHA1 для автентифікації повідомлень. SRTP часто використовується в поєднанні з безпечними протоколами сигналізації, такими як SIP через TLS, для забезпечення кінцевої безпеки в мультимедійній комунікації.
ZRTP (Протокол реального часу Циммермана): ZRTP є протоколом криптографічного обміну ключами, який забезпечує шифрування з кінця в кінець для медіа-потоків RTP. Розроблений Філом Циммерманом, творцем PGP, ZRTP описується в RFC 6189. На відміну від SRTP, який покладається на протоколи сигналізації для обміну ключами, ZRTP призначений для роботи незалежно від протоколу сигналізації. Він використовує обмін ключами Діффі-Хеллмана для встановлення спільного секрету між сторонами, що спілкуються, без необхідності попередньої довіри або інфраструктури відкритих ключів (PKI). ZRTP також включає такі функції, як Короткі автентифікаційні рядки (SAS) для захисту від атак "людини посередині".
Ці протоколи відіграють важливу роль у доставці та захисті мультимедійної комунікації в реальному часі через IP-мережі. У той час як RTP та RTCP обробляють фактичну передачу медіа та моніторинг якості, SRTP та ZRTP забезпечують захист переданих медіа від прослуховування, підробки та повторних атак.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
