Basic VoIP Protocols

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Протоколи сигналізації

SIP (Протокол ініціювання сесій)

Це стандарт галузі, для отримання додаткової інформації перегляньте:

pageSIP (Session Initiation Protocol)

MGCP (Протокол керування медіа-шлюзом)

MGCP (Протокол керування медіа-шлюзом) - це протокол сигналізації та керування дзвінками, описаний в RFC 3435. Він працює в централізованій архітектурі, яка складається з трьох основних компонентів:

  1. Агент дзвінків або Контролер медіа-шлюзу (MGC): Головний шлюз в архітектурі MGCP відповідає за управління та керування медіа-шлюзами. Він обробляє процеси налаштування, зміни та завершення дзвінків. MGC спілкується з медіа-шлюзами за допомогою протоколу MGCP.

  2. Медіа-шлюзи (MGs) або Вторинні шлюзи: Ці пристрої конвертують цифрові потоки медіа між різними мережами, такими як традиційна комутована телефонія та пакетна IP-мережа. Вони керуються MGC та виконують команди, отримані від нього. Медіа-шлюзи можуть включати функції, такі як транскодування, пакетизація та скасування еха.

  3. Шлюзи сигналізації (SGs): Ці шлюзи відповідають за конвертацію сигнальних повідомлень між різними мережами, забезпечуючи безперервну комунікацію між традиційними телефонними системами (наприклад, SS7) та IP-мережами (наприклад, SIP або H.323). Шлюзи сигналізації є важливими для взаємодії та забезпечення правильної передачі інформації про керування дзвінками між різними мережами.

У підсумку, MGCP централізує логіку керування дзвінками в агенті дзвінків, що спрощує управління медіа- та сигнальними шлюзами, забезпечуючи кращу масштабованість, надійність та ефективність в телекомунікаційних мережах.

SCCP (Протокол керування клієнтом Skinny)

Протокол керування клієнтом Skinny (SCCP) - це пропрієтарний протокол сигналізації та керування дзвінками, належить компанії Cisco Systems. Він використовується переважно для комунікації між Cisco Unified Communications Manager (раніше відомий як CallManager) та Cisco IP-телефонами або іншими голосовими та відео-кінцевими точками Cisco.

SCCP - це легкий протокол, який спрощує комунікацію між сервером керування дзвінками та кінцевими пристроями. Він називається "Skinny" через свій мінімалістичний дизайн та зменшені вимоги до пропускної здатності порівняно з іншими протоколами VoIP, такими як H.323 або SIP.

Основні компоненти системи на основі SCCP:

  1. Сервер керування дзвінками: Цей сервер, зазвичай Cisco Unified Communications Manager, керує процесами налаштування, зміни та завершення дзвінків, а також іншими функціями телефонії, такими як переадресація дзвінків, перенаправлення дзвінків та утримання дзвінків.

  2. Кінцеві точки SCCP: Це пристрої, такі як IP-телефони, відеоконференц-системи або інші голосові та відео-кінцеві точки Cisco, які використовують SCCP для комунікації з сервером керування дзвінками. Вони реєструються на сервері, надсилають та отримують сигнальні повідомлення та виконують інструкції, надані сервером керування для обробки дзвінків.

  3. Шлюзи: Ці пристрої, такі як голосові шлюзи або медіа-шлюзи, відповідальні за конвертацію медіа-потоків між різними мережами, такими як традиційна комутована телефонія та пакетна IP-мережа. Вони можуть також включати додаткові функції, такі як транскодування або скасування еха.

SCCP пропонує простий та ефективний метод комунікації між серверами керування дзвінками Cisco та кінцевими пристроями. Однак варто зауважити, що SCCP є пропрієтарним протоколом, що може обмежувати взаємодію з не-Cisco системами. У таких випадках інші стандартні протоколи VoIP, такі як SIP, можуть бути більш підходящими.

H.323

H.323 - це набір протоколів для мультимедійного зв'язку, включаючи голос, відео та конференції з обміном даними по пакетних мережах, таких як IP-мережі. Він був розроблений Міжнародним телекомунікаційним союзом (ITU-T) і надає комплексну структуру для управління мультимедійними сеансами зв'язку.

Деякі ключові компоненти набору H.323 включають:

  1. Термінали: Це кінцеві пристрої, такі як IP-телефони, системи відеоконференцій або програмні додатки, які підтримують H.323 та можуть брати участь у мультимедійних сеансах зв'язку.

  2. Шлюзи: Ці пристрої конвертують медіа-потоки між різними мережами, такими як традиційна комутована телефонія та пакетна IP-мережа, забезпечуючи взаємодію між H.323 та іншими системами зв'язку. Вони можуть також включати додаткові функції, такі як транскодування або скасування еха.

  3. Керівники шлюзів: Це необов'язкові компоненти, які надають послуги керування та управління дзвінками в мережі H.323. Вони виконують функції, такі як переклад адрес, управління пропускною здатністю та контроль допуску, допомагаючи управляти та оптимізувати ресурси мережі.

  4. Багатоточкові управляючі одиниці (MCU): Ці пристрої сприяють багатоточковим конференціям, керуючи та змішуючи медіа-потоки з кількох кінцевих точок. MCU дозволяють функції, такі як керування макетом відео, перемикання за голосом та постійна присутність, що дозволяє проводити конференції великого масштабу з численними учасниками.

H.323 підтримує ряд аудіо- та відеокодеків, а також інші додаткові послуги, такі як переадресація дзвінків, перенаправлення дзвінків, утримання дзвінків та очікування дзвінків. Незважаючи на широке поширення в початкові роки VoIP, H.323 поступово замінюється більш сучасними та гнучкими протоколами, такими як Протокол ініціювання сесій (SIP), який пропонує кращу взаємодію та простоту впровадження. Однак H.323 залишається використовуваним в багатьох застарілих системах та продовжує підтримуватися різними виробниками обладнання.

IAX (Inter Asterisk eXchange)

IAX (Inter-Asterisk eXchange) - це протокол сигналізації та керування дзвінками, в основному використовуваний для комунікації між серверами Asterisk PBX (Private Branch Exchange) та іншими VoIP-пристроями. Він був розроблений Марком Спенсером, творцем відкритого програмного забезпечення Asterisk PBX, як альтернатива іншим протоколам VoIP, таким як SIP та H.323.

IAX відомий своєю простотою, ефективністю та легкістю впровадження. Деякі ключові особливості IAX включають:

  1. Один UDP-порт: IAX використовує один UDP-порт (4569) як для сигналізації, так і для медіа-трафіку, що спрощує просування через брандмауери та NAT, полегшуючи впровадження в різних мережевих середовищах.

  2. **Біна

Протоколи передачі та транспорту

SDP (Протокол опису сесій)

SDP (Протокол опису сесій) - це текстовий формат, який використовується для опису характеристик мультимедійних сесій, таких як голос, відео або конференції з обміну даними, по IP мережах. Він був розроблений Internet Engineering Task Force (IETF) і визначений в RFC 4566. SDP не обробляє фактичну передачу медіа або установку сесій, але використовується разом з іншими сигнальними протоколами, такими як SIP (Протокол ініціювання сесій), для переговорів та обміну інформацією про потоки медіа та їх атрибути.

Деякі ключові елементи SDP включають:

  1. Інформація про сесію: SDP описує деталі мультимедійної сесії, включаючи назву сесії, опис сесії, час початку та закінчення.

  2. Потоки медіа: SDP визначає характеристики потоків медіа, такі як тип медіа (аудіо, відео або текст), транспортний протокол (наприклад, RTP або SRTP) та формат медіа (наприклад, інформація про кодек).

  3. Інформація про підключення: SDP надає інформацію про мережеву адресу (IP-адресу) та номер порту, куди слід відправляти або отримувати медіа.

  4. Атрибути: SDP підтримує використання атрибутів для надання додаткової, необов'язкової інформації про сесію або потік медіа. Атрибути можуть використовуватися для вказівки різних функцій, таких як ключі шифрування, вимоги щодо пропускної здатності або механізми керування медіа.

SDP зазвичай використовується в такому процесі:

  1. Ініціююча сторона створює опис SDP запропонованої мультимедійної сесії, включаючи деталі потоків медіа та їх атрибути.

  2. Опис SDP надсилається отримувальній стороні, зазвичай вбудований у повідомлення сигнального протоколу, такі як SIP або RTSP.

  3. Отримувальна сторона обробляє опис SDP, і, виходячи зі своїх можливостей, може прийняти, відхилити або змінити запропоновану сесію.

  4. Остаточний опис SDP надсилається ініціюючій стороні як частина повідомлення сигнального протоколу, завершуючи процес переговорів.

Простота та гнучкість SDP роблять його широко прийнятим стандартом для опису мультимедійних сесій у різних системах зв'язку, відіграючи важливу роль у встановленні та управлінні реальними мультимедійними сесіями по IP мережах.

RTP / RTCP / SRTP / ZRTP

  1. RTP (Протокол реального часу передачі): RTP - це мережевий протокол, призначений для передачі аудіо- та відеоданих або інших медіа в реальному часі по IP мережах. Розроблений IETF і визначений в RFC 3550, RTP часто використовується з сигнальними протоколами, такими як SIP та H.323, для забезпечення мультимедійного зв'язку. RTP надає механізми для синхронізації, послідовності та відмітки часу потоків медіа, допомагаючи забезпечити плавне та вчасне відтворення медіа.

  2. RTCP (Протокол управління транспортом в реальному часі): RTCP є супутнім протоколом до RTP, використовується для моніторингу якості обслуговування (QoS) та надання зворотного зв'язку щодо передачі потоків медіа. Визначений в тому ж RFC 3550 як RTP, RTCP періодично обмінюється керуючими пакетами між учасниками у сесії RTP. Він обмінює інформацію, таку як втрати пакетів, джиттер та час затримки у двох напрямках, що допомагає в діагностиці та адаптації до умов мережі, покращуючи загальну якість медіа.

  3. SRTP (Безпечний протокол передачі в реальному часі): SRTP - це розширення RTP, яке забезпечує шифрування, аутентифікацію повідомлень та захист від повторного відтворення для потоків медіа, забезпечуючи безпечну передачу чутливих аудіо- та відеоданих. Визначений в RFC 3711, SRTP використовує криптографічні алгоритми, такі як AES для шифрування та HMAC-SHA1 для аутентифікації повідомлень. SRTP часто використовується в поєднанні з безпечними сигнальними протоколами, такими як SIP через TLS, для забезпечення кінцево-кінечної безпеки в мультимедійному зв'язку.

  4. ZRTP (Протокол передачі в реальному часі Zimmermann): ZRTP - це криптографічний протокол узгодження ключів, який забезпечує кінцеве шифрування для потоків медіа RTP. Розроблений Філом Ціммерманом, творцем PGP, ZRTP описаний в RFC 6189. На відміну від SRTP, який покладається на сигнальні протоколи для обміну ключами, ZRTP призначений для роботи незалежно від сигнального протоколу. Він використовує обмін ключами Діффі-Хеллмана для встановлення спільного секрету між спілкуючимися сторонами, не потребуючи попереднього довіри або інфраструктури відкритих ключів (PKI). ZRTP також включає функції, такі як короткі рядки аутентифікації (SAS) для захисту від атак типу "чоловік посередині".

Ці протоколи відіграють важливу роль у передачі та захисті реального мультимедійного зв'язку по IP мережах. У той час як RTP та RTCP відповідають за фактичну передачу медіа та моніторинг якості, SRTP та ZRTP забезпечують захист переданого медіа від прослуховування, втручання та атак типу "повторний відтворення".

Last updated