Translated ['src/network-services-pentesting/pentesting-voip/basic-voip-

src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md

@@ -4,72 +4,72 @@
 
 ## Основна інформація
 
-SIP (Session Initiation Protocol) є **протоколом сигналізації та управління викликами**, який широко використовується для встановлення, модифікації та завершення мультимедійних сесій, включаючи голос, відео та миттєві повідомлення, через IP-мережі. Розроблений **Internet Engineering Task Force (IETF)**, SIP визначається в **RFC 3261** і став де-факто стандартом для VoIP та об'єднаних комунікацій.
+SIP (Session Initiation Protocol) — це **протокол сигналізації та управління викликами**, який широко використовується для встановлення, зміни та завершення мультимедійних сесій, включаючи голос, відео та миттєві повідомлення через IP-мережі. Розроблено **Internet Engineering Task Force (IETF)**, SIP визначено в **RFC 3261** і він став де-факто стандартом для VoIP та уніфікованих комунікацій.
 
 Деякі ключові особливості SIP включають:
 
-1. **Текстовий протокол**: SIP є текстовим протоколом, що робить його зрозумілим для людини та легшим для налагодження. Він базується на моделі запит-відповідь, подібній до HTTP, і використовує методи, такі як INVITE, ACK, BYE та CANCEL для управління сесіями викликів.
-2. **Масштабованість та гнучкість**: SIP є високоефективним і може використовуватися як у малих, так і у великих підприємствах та середовищах операторів. Його легко розширити новими функціями, що робить його адаптивним до різних випадків використання та вимог.
-3. **Сумісність**: Широке впровадження та стандартизація SIP забезпечують кращу сумісність між різними пристроями, додатками та постачальниками послуг, сприяючи безперешкодній комунікації на різних платформах.
-4. **Модульний дизайн**: SIP працює з іншими протоколами, такими як **RTP (Real-time Transport Protocol)** для передачі медіа та **SDP (Session Description Protocol)** для опису мультимедійних сесій. Цей модульний дизайн дозволяє забезпечити більшу гнучкість та сумісність з різними типами медіа та кодеками.
-5. **Проксі та редирект-сервери**: SIP може використовувати проксі та редирект-сервери для полегшення маршрутизації викликів та надання розширених функцій, таких як переадресація викликів, передача викликів та послуги голосової пошти.
-6. **Присутність та миттєві повідомлення**: SIP не обмежується лише голосовою та відео-комунікацією. Він також підтримує присутність та миттєві повідомлення, що дозволяє створювати широкий спектр об'єднаних комунікаційних додатків.
+1. **Текстовий протокол**: SIP є текстовим протоколом, що робить його читабельним для людини і легшим для відлагодження. Він базується на моделі запит-відповідь, подібно до HTTP, і використовує методи такі як INVITE, ACK, BYE і CANCEL для керування дзвінками.
+2. **Масштабованість і гнучкість**: SIP високо масштабований і може використовуватись як у малих розгортаннях, так і в великих корпоративних або операторських середовищах. Його легко розширювати новими можливостями, що робить його адаптивним до різних випадків використання та вимог.
+3. **Сумісність**: Широке запровадження та стандартизація SIP забезпечують кращу сумісність між різними пристроями, додатками та провайдерами послуг, що сприяє безшовній комунікації між різними платформами.
+4. **Модульний дизайн**: SIP працює разом з іншими протоколами, такими як **RTP (Real-time Transport Protocol)** для передачі медіа та **SDP (Session Description Protocol)** для опису мультимедійних сесій. Така модульна архітектура дозволяє більш гнучко працювати з різними типами медіа та кодеками.
+5. **Проксі та редирект-сервери**: SIP може використовувати проксі та редирект-сервери для полегшення маршрутизації дзвінків і надання розширених функцій, таких як переадресація виклику, переведення виклику та голосова пошта.
+6. **Присутність та миттєві повідомлення**: SIP не обмежується лише голосом та відео. Він також підтримує присутність і миттєві повідомлення, що дозволяє реалізовувати широкий спектр уніфікованих комунікаційних додатків.
 
-Незважаючи на численні переваги, SIP може бути складним для налаштування та управління, особливо при вирішенні проблем з NAT та брандмауерами. Однак його універсальність, масштабованість та широкий рівень підтримки в галузі роблять його популярним вибором для VoIP та мультимедійної комунікації.
+Незважаючи на численні переваги, SIP може бути складним у налаштуванні та керуванні, особливо при вирішенні проблем з NAT та брандмауерами. Однак його універсальність, масштабованість і широка підтримка в індустрії роблять його популярним вибором для VoIP та мультимедійного зв'язку.
 
 ### Методи SIP
 
 Основні методи SIP, визначені в **RFC 3261**, включають:
 
-1. **INVITE**: Використовується для **ініціювання нової сесії (виклику)** або модифікації існуючої. Метод INVITE несе опис сесії (зазвичай за допомогою SDP), щоб проінформувати отримувача про деталі запропонованої сесії, такі як типи медіа, кодеки та транспортні протоколи.
-2. **ACK**: Надсилається для **підтвердження отримання** остаточної відповіді на запит INVITE. Метод ACK забезпечує надійність транзакцій INVITE, надаючи підтвердження з кінця в кінець.
-3. **BYE**: Використовується для **завершення встановленої сесії (виклику)**. Метод BYE надсилається будь-якою стороною в сесії, щоб вказати, що вони бажають завершити комунікацію.
-4. **CANCEL**: Надсилається для **скасування очікуючого запиту INVITE** перед встановленням сесії. Метод CANCEL дозволяє відправнику скасувати транзакцію INVITE, якщо вони змінюють свою думку або якщо немає відповіді від отримувача.
-5. **OPTIONS**: Використовується для **запиту можливостей SIP-сервера або агента користувача**. Метод OPTIONS може бути надісланий для запиту інформації про підтримувані методи, типи медіа або інші розширення без фактичного встановлення сесії.
-6. **REGISTER**: Використовується агентом користувача для **реєстрації свого поточного місцезнаходження з SIP-регістратором**. Метод REGISTER допомагає підтримувати актуальну відповідність між SIP URI користувача та їхньою поточною IP-адресою, що дозволяє маршрутизацію та доставку викликів.
+1. **INVITE**: Використовується для **ініціювання нової сесії (дзвінка)** або зміни існуючої. Метод INVITE несе опис сесії (зазвичай за допомогою SDP), щоб інформувати отримувача про деталі пропонованої сесії, такі як типи медіа, кодеки та транспортні протоколи.
+2. **ACK**: Надсилається для **підтвердження отримання** остаточної відповіді на запит INVITE. Метод ACK забезпечує надійність транзакцій INVITE, надаючи підтвердження від кінця до кінця.
+3. **BYE**: Використовується для **завершення встановленої сесії (дзвінка)**. Метод BYE надсилається будь-якою з сторін у сесії, щоб вказати на бажання завершити зв'язок.
+4. **CANCEL**: Надсилається для **скасування очікуваного INVITE** запиту до встановлення сесії. Метод CANCEL дозволяє відправнику припинити транзакцію INVITE, якщо він передумає або якщо немає відповіді від отримувача.
+5. **OPTIONS**: Використовується для **запиту можливостей SIP сервера або user agent**. Метод OPTIONS може бути надісланий для отримання інформації про підтримувані методи, типи медіа або інші розширення без фактичного встановлення сесії.
+6. **REGISTER**: Використовується user agent для **реєстрації свого поточного місцезнаходження на SIP registrar server**. Метод REGISTER допомагає підтримувати актуальне відображення між SIP URI користувача та його поточною IP-адресою, дозволяючи маршрутизацію та доставку дзвінків.
 
 > [!WARNING]
-> Зверніть увагу, що для того, щоб зателефонувати комусь, **необхідно використовувати REGISTER** для чогось.\
-> Однак можливо, що для виконання **INVITE** абоненту потрібно спочатку **автентифікуватися**, інакше він отримає відповідь **`401 Unauthorized`**.
+> Зверніть увагу, що для здійснення дзвінка **необов'язково використовувати REGISTER** для чогось.\  
+> Однак можливо, що для виконання **INVITE** абоненту спочатку потрібно **аутентифікуватися**, інакше він отримає **`401 Unauthorized`** відповідь.
 
-На додаток до цих основних методів, існує **кілька розширених методів SIP**, визначених в інших RFC, таких як:
+Окрім цих основних методів, існує **кілька розширень SIP**, визначених в інших RFC, таких як:
 
-1. **SUBSCRIBE**: Визначений у RFC 6665, метод SUBSCRIBE використовується для **запиту сповіщень** про стан конкретного ресурсу, такого як присутність користувача або статус виклику.
-2. **NOTIFY**: Також визначений у RFC 6665, метод NOTIFY надсилається сервером для **інформування підписаного агента користувача** про зміни в стані контрольованого ресурсу.
-3. **REFER**: Визначений у RFC 3515, метод REFER використовується для **запиту, щоб отримувач виконав передачу або звернувся до третьої сторони**. Це зазвичай використовується для сценаріїв **передачі викликів**.
-4. **MESSAGE**: Визначений у RFC 3428, метод MESSAGE використовується для **надсилання миттєвих повідомлень між SIP-агентами користувача**, що дозволяє текстову комунікацію в рамках SIP.
-5. **UPDATE**: Визначений у RFC 3311, метод UPDATE дозволяє **модифікувати сесію без впливу на стан існуючого діалогу**. Це корисно для оновлення параметрів сесії, таких як кодеки або типи медіа, під час поточного виклику.
-6. **PUBLISH**: Визначений у RFC 3903, метод PUBLISH використовується агентом користувача для **публікації інформації про стан подій на сервер**, роблячи її доступною для інших зацікавлених сторін.
+1. **SUBSCRIBE**: Визначений у RFC 6665, метод SUBSCRIBE використовується для **запиту сповіщень** про стан конкретного ресурсу, наприклад присутності користувача або статусу виклику.
+2. **NOTIFY**: Також визначений у RFC 6665, метод NOTIFY надсилається сервером для **інформування підписаного user agent** про зміни в стані монітореного ресурсу.
+3. **REFER**: Визначений у RFC 3515, метод REFER використовується для **запиту, щоб отримувач виконав передачу або перенаправив на третю сторону**. Це зазвичай використовується для сценаріїв переведення виклику.
+4. **MESSAGE**: Визначений у RFC 3428, метод MESSAGE використовується для **відправки миттєвих повідомлень між SIP user agents**, що дозволяє текстову комунікацію в межах SIP.
+5. **UPDATE**: Визначений у RFC 3311, метод UPDATE дозволяє **змінювати сесію без впливу на стан існуючого діалогу**. Це корисно для оновлення параметрів сесії, таких як кодеки або типи медіа, під час поточного дзвінка.
+6. **PUBLISH**: Визначений у RFC 3903, метод PUBLISH використовується user agent для **публікації інформації про стан подій на сервері**, роблячи її доступною для інших зацікавлених сторін.
 
-### Код відповіді SIP
+### SIP Коди відповідей
 
-- **1xx (Проміжні відповіді)**: Ці відповіді вказують на те, що запит був отриманий, і сервер продовжує його обробку.
-- 100 Trying: Запит був отриманий, і сервер працює над ним.
-- 180 Ringing: Абонент отримує сповіщення і відповість на виклик.
-- 183 Session Progress: Надає інформацію про хід виклику.
-- **2xx (Успішні відповіді)**: Ці відповіді вказують на те, що запит був успішно отриманий, зрозумілий і прийнятий.
-- 200 OK: Запит був успішним, і сервер його виконав.
-- 202 Accepted: Запит був прийнятий для обробки, але ще не завершений.
-- **3xx (Відповіді на перенаправлення)**: Ці відповіді вказують на те, що для виконання запиту потрібні подальші дії, зазвичай шляхом звернення до альтернативного ресурсу.
-- 300 Multiple Choices: Є кілька доступних варіантів, і користувач або клієнт повинен вибрати один.
-- 301 Moved Permanently: Запитуваний ресурс отримав новий постійний URI.
-- 302 Moved Temporarily: Запитуваний ресурс тимчасово доступний за іншим URI.
-- 305 Use Proxy: Запит повинен бути надісланий на вказаний проксі.
-- **4xx (Відповіді на помилки клієнта)**: Ці відповіді вказують на те, що запит містить неправильний синтаксис або не може бути виконаний сервером.
-- 400 Bad Request: Запит був неправильно сформульований або недійсний.
+- **1xx (Попередні відповіді)**: Ці відповіді вказують, що запит отримано, і сервер продовжує його обробляти.
+- 100 Trying: Запит отримано, і сервер працює над ним.
+- 180 Ringing: Абонент повідомляється про виклик і відповість на дзвінок.
+- 183 Session Progress: Надає інформацію про прогрес дзвінка.
+- **2xx (Успішні відповіді)**: Ці відповіді вказують, що запит успішно отримано, зрозуміло та прийнято.
+- 200 OK: Запит успішний, і сервер його виконав.
+- 202 Accepted: Запит прийнято для обробки, але він ще не завершений.
+- **3xx (Перенаправлення)**: Ці відповіді вказують, що для виконання запиту потрібні додаткові дії, зазвичай шляхом звернення до альтернативного ресурсу.
+- 300 Multiple Choices: Існує кілька варіантів, і користувач або клієнт повинен обрати один із них.
+- 301 Moved Permanently: Запитуваному ресурсу присвоєно новий постійний URI.
+- 302 Moved Temporarily: Ресурс тимчасово доступний за іншим URI.
+- 305 Use Proxy: Запит має бути відправлений на вказаний проксі.
+- **4xx (Помилки клієнта)**: Ці відповіді вказують, що запит містить помилковий синтаксис або не може бути виконаний сервером.
+- 400 Bad Request: Запит був сформований неправильно або недійсний.
 - 401 Unauthorized: Запит вимагає автентифікації користувача.
 - 403 Forbidden: Сервер зрозумів запит, але відмовляється його виконати.
 - 404 Not Found: Запитуваний ресурс не знайдено на сервері.
-- 408 Request Timeout: Сервер не отримав повний запит протягом часу, який він був готовий чекати.
-- 486 Busy Here: Абонент наразі зайнятий і не може відповісти на виклик.
-- **5xx (Відповіді на помилки сервера)**: Ці відповіді вказують на те, що сервер не зміг виконати дійсний запит.
+- 408 Request Timeout: Сервер не отримав повний запит у відведений час.
+- 486 Busy Here: Абонент наразі зайнятий і не може прийняти дзвінок.
+- **5xx (Помилки сервера)**: Ці відповіді вказують, що сервер не зміг виконати дійсний запит.
 - 500 Internal Server Error: Сервер зіткнувся з помилкою під час обробки запиту.
 - 501 Not Implemented: Сервер не підтримує функціональність, необхідну для виконання запиту.
 - 503 Service Unavailable: Сервер наразі не може обробити запит через технічне обслуговування або перевантаження.
-- **6xx (Глобальні відповіді на помилки)**: Ці відповіді вказують на те, що запит не може бути виконаний жодним сервером.
-- 600 Busy Everywhere: Усі можливі напрямки для виклику зайняті.
-- 603 Decline: Абонент не бажає брати участь у виклику.
-- 604 Does Not Exist Anywhere: Запитуваний ресурс недоступний в мережі.
+- **6xx (Глобальні помилки)**: Ці відповіді вказують, що запит не може бути виконаний жодним сервером.
+- 600 Busy Everywhere: Усі можливі місця призначення для дзвінка зайняті.
+- 603 Decline: Абонент відмовляється брати участь у дзвінку.
+- 604 Does Not Exist Anywhere: Запитуваний ресурс недоступний ніде в мережі.
 
 ## Приклади
 
@@ -94,43 +94,43 @@ s=-
 c=IN IP4 pc33.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
-a=rtpmap:0 PCMU/8000te
+a=rtpmap:0 PCMU/8000
 ```
 <details>
 
-<summary>Кожен параметр пояснено</summary>
+<summary>Пояснення кожного параметра</summary>
 
 1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Цей рядок вказує метод (INVITE), URI запиту (sip:[jdoe@example.com](mailto:jdoe@example.com)) та версію SIP (SIP/2.0).
-2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Заголовок Via вказує транспортний протокол (UDP) та адресу клієнта (pc33.example.com). Параметр "branch" використовується для виявлення циклів та відповідності транзакцій.
-3. **Max-Forwards**: `Max-Forwards: 70` - Це поле заголовка обмежує кількість разів, коли запит може бути пересланий проксі, щоб уникнути нескінченних циклів.
-4. **To**: `To: John Doe <sip:jdoe@example.com>` - Заголовок To вказує отримувача дзвінка, включаючи їх відображуване ім'я (John Doe) та SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
-5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - Заголовок From вказує відправника дзвінка, включаючи їх відображуване ім'я (Jane Smith) та SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). Параметр "tag" використовується для унікальної ідентифікації ролі відправника в діалозі.
-6. **Call-ID**: `Call-ID: a84b4c76e66710` - Заголовок Call-ID унікально ідентифікує сесію дзвінка між двома користувацькими агентами.
-7. **CSeq**: `CSeq: 314159 INVITE` - Заголовок CSeq містить номер послідовності та метод, використаний у запиті. Він використовується для відповідності відповідей запитам та виявлення повідомлень у неправильному порядку.
-8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Заголовок Contact надає прямий маршрут до відправника, який може бути використаний для подальших запитів та відповідей.
-9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - Заголовок User-Agent надає інформацію про програмне або апаратне забезпечення відправника, включаючи його назву та версію.
-10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Заголовок Allow перераховує методи SIP, підтримувані відправником. Це допомагає отримувачу зрозуміти, які методи можуть бути використані під час спілкування.
-11. **Content-Type**: `Content-Type: application/sdp` - Заголовок Content-Type вказує медіа-тип тіла повідомлення, в даному випадку, SDP (Протокол опису сесії).
+2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Заголовок Via вказує протокол транспорту (UDP) та адресу клієнта (pc33.example.com). Параметр "branch" використовується для виявлення циклів і співставлення транзакцій.
+3. **Max-Forwards**: `Max-Forwards: 70` - Це поле заголовка обмежує кількість переадресацій запиту проксі, щоб уникнути нескінченних циклів.
+4. **To**: `To: John Doe <sip:jdoe@example.com>` - Заголовок To вказує отримувача дзвінка, включаючи його відображуване ім'я (John Doe) та SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
+5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - Заголовок From вказує відправника дзвінка, включаючи його відображуване ім'я (Jane Smith) та SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). Параметр "tag" використовується для унікальної ідентифікації ролі відправника в діалозі.
+6. **Call-ID**: `Call-ID: a84b4c76e66710` - Заголовок Call-ID унікально ідентифікує сеанс дзвінка між двома агентами користувача.
+7. **CSeq**: `CSeq: 314159 INVITE` - Заголовок CSeq містить номер послідовності та метод, який використовується в запиті. Він використовується для співставлення відповідей із запитами та виявлення повідомлень, що надійшли не в порядку.
+8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Заголовок Contact надає прямий маршрут до відправника, який може використовуватися для наступних запитів і відповідей.
+9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - Заголовок User-Agent містить інформацію про програмне або апаратне забезпечення відправника, включаючи його назву та версію.
+10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Заголовок Allow перераховує SIP-методи, які підтримуються відправником. Це допомагає отримувачу зрозуміти, які методи можна використовувати під час зв'язку.
+11. **Content-Type**: `Content-Type: application/sdp` - Заголовок Content-Type вказує тип медіа тіла повідомлення, у цьому випадку SDP (Session Description Protocol).
 12. **Content-Length**: `Content-Length: 142` - Заголовок Content-Length вказує розмір тіла повідомлення в байтах.
-13. **Message Body**: Тіло повідомлення містить опис сесії SDP, який включає інформацію про медіа-типи, кодеки та транспортні протоколи для запропонованої сесії.
+13. **Message Body**: Тіло повідомлення містить опис сесії SDP, який включає інформацію про типи медіа, кодеки та протоколи транспорту для пропонованої сесії.
 
 - `v=0` - Версія протоколу (0 для SDP)
-- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Відправник та ідентифікатор сесії
-- `s=-` - Назва сесії (один дефіс вказує на відсутність назви сесії)
+- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Ініціатор і ідентифікатор сесії
+- `s=-` - Назва сесії (один дефіс означає відсутність назви сесії)
 - `c=IN IP4 pc33.example.com` - Інформація про з'єднання (тип мережі, тип адреси та адреса)
-- `t=0 0` - Інформація про час (час початку та закінчення, 0 0 означає, що сесія не обмежена)
-- `m=audio 49170 RTP/AVP 0` - Опис медіа (тип медіа, номер порту, транспортний протокол та список форматів). У цьому випадку вказується аудіопотік, що використовує RTP/AVP (Протокол реального часу / Аудіо Відео Профіль) та формат 0 (PCMU/8000).
+- `t=0 0` - Інформація про час (час початку і завершення, 0 0 означає, що сесія не обмежена)
+- `m=audio 49170 RTP/AVP 0` - Опис медіа (тип медіа, номер порту, транспортний протокол і список форматів). В цьому випадку вказано аудіопотік з використанням RTP/AVP (Real-time Transport Protocol / Audio Video Profile) і форматом 0 (PCMU/8000).
 - `a=rtpmap:0 PCMU/8000` - Атрибут, що відображає формат (0) на кодек (PCMU) та його частоту дискретизації (8000 Гц).
 
 </details>
 
-### SIP REGISTER Приклад
+### Приклад SIP REGISTER
 
-Метод REGISTER використовується в Протоколі ініціації сесії (SIP), щоб дозволити користувацькому агенту (UA), такому як VoIP телефон або софтфон, **зареєструвати своє місцезнаходження на сервері реєстрації SIP**. Цей процес дозволяє серверу знати, **куди маршрутизувати вхідні SIP запити, призначені для зареєстрованого користувача**. Сервер реєстрації зазвичай є частиною проксі-сервера SIP або спеціалізованого сервера реєстрації.
+Метод REGISTER використовується в Протоколі ініціації сесії (SIP), щоб дозволити агенту користувача (UA), наприклад VoIP-телефону або софтфону, **зареєструвати своє місцезнаходження на сервері реєстрації SIP**. Цей процес дає серверу знати **куди направляти вхідні SIP-запити, призначені для зареєстрованого користувача**. Сервер реєстрації зазвичай є частиною SIP proxy-сервера або виділеного сервера реєстрації.
 
-Ось детальний приклад SIP повідомлень, що беруть участь у процесі аутентифікації REGISTER:
+Ось детальний приклад SIP-повідомлень, що беруть участь у процесі автентифікації REGISTER:
 
-1. Початковий **REGISTER** запит від UA до сервера реєстрації:
+1. Initial **REGISTER** request from UA to the registrar server:
 ```yaml
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -143,11 +143,11 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-Це початкове повідомлення REGISTER надсилається UA (Аліса) на сервер реєстрації. Воно містить важливу інформацію, таку як бажана тривалість реєстрації (Expires), SIP URI користувача (sip:[alice@example.com](mailto:alice@example.com)) та контактну адресу користувача (sip:alice@192.168.1.100:5060).
+Це початкове повідомлення REGISTER відправляється UA (Alice) до реєстраційного сервера. Воно містить важливу інформацію, таку як бажана тривалість реєстрації (Expires), SIP URI користувача (sip:[alice@example.com](mailto:alice@example.com)) та контактна адреса користувача (sip:alice@192.168.1.100:5060).
 
-2. **401 Unauthorized** відповідь від сервера реєстрації:
-```css
-cssCopy codeSIP/2.0 401 Unauthorized
+2. **401 Unauthorized** відповідь від реєстраційного сервера:
+```
+SIP/2.0 401 Unauthorized
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
 From: Alice <sip:alice@example.com>;tag=565656
 To: Alice <sip:alice@example.com>;tag=7878744
@@ -156,9 +156,11 @@ CSeq: 1 REGISTER
 WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
 Content-Length: 0
 ```
-Сервер реєстрації відповідає повідомленням "401 Unauthorized", яке містить заголовок "WWW-Authenticate". Цей заголовок містить інформацію, необхідну для автентифікації UA, таку як **область автентифікації, nonce та алгоритм**.
+Реєстраційний сервер відповідає повідомленням "401 Unauthorized", яке містить заголовок "WWW-Authenticate".
 
-3. Запит REGISTER **з обліковими даними для автентифікації**:
+Цей заголовок містить інформацію, необхідну UA для автентифікації, наприклад **realm аутентифікації, nonce та алгоритм**.
+
+3. REGISTER request **з обліковими даними для автентифікації**:
 ```vbnet
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -172,9 +174,9 @@ Expires: 3600
 Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
 Content-Length: 0
 ```
-UA надсилає ще один запит REGISTER, цього разу включаючи **заголовок "Authorization" з необхідними обліковими даними, такими як ім'я користувача, область, nonce та значення відповіді**, обчислене за допомогою наданої інформації та пароля користувача.
+UA надсилає ще один REGISTER request, цього разу включаючи **"Authorization" header з необхідними обліковими даними, такими як username, realm, nonce та response value**, які обчислюються за допомогою наданої інформації та пароля користувача.
 
-Ось як обчислюється **відповідь Authorizarion**:
+Ось як обчислюється **Authorization response**:
 ```python
 import hashlib
 
@@ -207,7 +209,7 @@ qop = "auth"
 response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
 print(f"MD5 response value: {response}")
 ```
-4. **Успішна реєстрація** відповідь від сервера реєстрації:
+4. **Успішна реєстрація** — відповідь від реєстраційного сервера:
 ```yaml
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -219,13 +221,98 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-Після того, як сервер реєстрації перевіряє надані облікові дані, **він надсилає відповідь "200 OK", щоб вказати, що реєстрація була успішною**. Відповідь містить зареєстровану контактну інформацію та час закінчення реєстрації. На цьому етапі агент користувача (Аліса) успішно зареєстрований на сервері SIP реєстрації, і вхідні SIP запити для Аліси можуть бути направлені на відповідну контактну адресу.
+Після того як registrar server перевіряє надані облікові дані, **він надсилає відповідь "200 OK", щоб вказати, що реєстрація пройшла успішно**. У відповіді міститься зареєстрована контактна інформація та час життя реєстрації. На цьому етапі user agent (Alice) успішно зареєстрований на SIP registrar server, і вхідні SIP-запити для Alice можна маршрутизувати до відповідної контактної адреси.
 
-### Приклад дзвінка
+### Call Example
 
 <figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
 
-> [!NOTE]
-> Не згадується, але Користувач B повинен надіслати **REGISTER повідомлення до Proxy 2**, перш ніж він зможе отримувати дзвінки.
+> [!TIP]
+> Це не вказано вище, але User B повинен був надіслати **REGISTER message to Proxy 2** перед тим, як він зміг би приймати дзвінки.
 
+
+
+---
+
+## SIP Security and Pentesting Notes
+
+Цей розділ додає практичні, специфічні для протоколу поради без дублювання ширшого VoIP керівництва. Для методології атак end-to-end на VoIP, інструментів та сценаріїв дивіться:
+
+{{#ref}}
+../README.md
+{{#endref}}
+
+### Fingerprinting and Discovery
+
+- Надішліть OPTIONS запит і перегляньте заголовки `Allow`, `Supported`, `Server` та `User-Agent`, щоб fingerprint пристроїв та стеків:
+
+```bash
+# nmap NSE (UDP 5060 by default)
+sudo nmap -sU -p 5060 --script sip-methods <target>
+
+# Minimal raw OPTIONS over UDP
+printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060
+```
+
+### Username/Extension Enumeration Behavior
+
+- Перерахування зазвичай зловживає відмінностями між відповідями `401/407` та `404/403` на `REGISTER`/`INVITE`. Закріпіть сервери, щоб вони відповідали однорідно.
+- Asterisk chan_sip: встановіть `alwaysauthreject=yes` (загалом), щоб уникати розкриття дійсних користувачів. У новіших версіях Asterisk (PJSIP) гостьові дзвінки вимкнені, якщо не визначено `anonymous` endpoint, а подібна поведінка "always auth reject" є за замовчуванням; все ж застосовуйте мережеві ACL та fail2ban на периметрі.
+
+### SIP Digest Authentication: algorithms and cracking
+
+- SIP зазвичай використовує HTTP-Digest стиль аутентифікації. Історично переважали MD5 (і MD5-sess); новіші стекі підтримують SHA-256 та SHA-512/256 згідно RFC 8760. Впроваджуйте сильніші алгоритми в сучасних розгортаннях та вимикайте MD5, коли це можливо.
+- Офлайн-крейкінг з pcap тривіальний для MD5 digest. Після витягання challenge/response ви можете використати hashcat mode 11400 (SIP digest, MD5):
+
+```bash
+# Example hash format (single line)
+# username:realm:method:uri:nonce:cnonce:nc:qop:response
+echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash
+
+# Crack with a wordlist
+hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt
+```
+
+> [!NOTE]
+> RFC 8760 визначає SHA-256 та SHA-512/256 для HTTP Digest (також застосовується до SIP Digest). Рівень впровадження непостійний; переконайтеся, що ваші інструменти підтримують ці алгоритми при тестуванні сучасних PBX.
+
+### SIP over TLS (SIPS) and over WebSockets
+
+- Шифрування сигналінгу:
+- `sips:` URI та TCP/TLS зазвичай на 5061. Перевіряйте валідацію сертифікатів на кінцевих точках; багато пристроїв приймають self-signed або wildcard сертифікати, що робить можливим MitM у слабких розгортаннях.
+- WebRTC softphones часто використовують SIP over WebSocket згідно RFC 7118 (`ws://` або `wss://`). Якщо PBX відкриває WSS, перевіряйте аутентифікацію і CORS, і забезпечте, що на HTTP фронтенді також застосовані ліміти швидкості.
+
+### DoS quick checks (protocol level)
+
+- Flooding INVITE, REGISTER або malformed повідомлення можуть вичерпати обробку транзакцій.
+- Простий приклад rate-limiting для UDP/5060 (Linux iptables hashlimit):
+
+```bash
+# Limit new SIP packets from a single IP to 20/s with burst 40
+iptables -A INPUT -p udp --dport 5060 -m hashlimit \
+--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \
+--hashlimit-mode srcip -j ACCEPT
+iptables -A INPUT -p udp --dport 5060 -j DROP
+```
+
+### Recent, relevant SIP-stack CVE to watch (Asterisk PJSIP)
+
+- CVE-2024-35190 (published May 17, 2024): У певних випусках Asterisk `res_pjsip_endpoint_identifier_ip` міг помилково ідентифікувати неавторизовані SIP-запити як локальну кінцеву точку, що потенційно дозволяло неавторизовані дії або розкриття інформації. Виправлено в 18.23.1, 20.8.1 та 21.3.1. Перевіряйте версію вашого PBX під час тестування та відповідально звітуйте.
+
+### Hardening checklist (SIP-specific)
+
+- Віддавайте перевагу TLS для сигналінгу та SRTP/DTLS-SRTP для медіа; вимикайте cleartext де це можливо.
+- Запровадьте сильні паролі та алгоритми digest (SHA-256/512-256 де підтримується; уникайте MD5).
+- Для Asterisk:
+- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, per-endpoint `permit`/`deny` CIDR ACLs.
+- PJSIP: не створюйте `anonymous` endpoint без потреби; запровадьте endpoint `acl`/`media_acl`; увімкніть fail2ban або еквівалент.
+- Topology hiding на SIP proxies (наприклад, outbound proxy/edge SBC) щоб зменшити information leakage.
+- Жорстке оброблення `OPTIONS` та ліміти швидкості; вимикайте непотрібні методи (наприклад, `MESSAGE`, `PUBLISH`), якщо вони не потрібні.
+
+
+
+## References
+
+- RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too): https://www.rfc-editor.org/rfc/rfc8760
+- Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9
 {{#include ../../../banners/hacktricks-training.md}}