mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
232 lines
24 KiB
Markdown
232 lines
24 KiB
Markdown
# SIP (Session Initiation Protocol)
|
||
|
||
{{#include ../../../banners/hacktricks-training.md}}
|
||
|
||
## Основна інформація
|
||
|
||
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 не обмежується лише голосовою та відео-комунікацією. Він також підтримує присутність та миттєві повідомлення, що дозволяє створювати широкий спектр об'єднаних комунікаційних додатків.
|
||
|
||
Незважаючи на численні переваги, 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-адресою, що дозволяє маршрутизацію та доставку викликів.
|
||
|
||
> [!WARNING]
|
||
> Зверніть увагу, що для того, щоб зателефонувати комусь, **необхідно використовувати REGISTER** для чогось.\
|
||
> Однак можливо, що для виконання **INVITE** абоненту потрібно спочатку **автентифікуватися**, інакше він отримає відповідь **`401 Unauthorized`**.
|
||
|
||
На додаток до цих основних методів, існує **кілька розширених методів 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 використовується агентом користувача для **публікації інформації про стан подій на сервер**, роблячи її доступною для інших зацікавлених сторін.
|
||
|
||
### Код відповіді 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: Запит був неправильно сформульований або недійсний.
|
||
- 401 Unauthorized: Запит вимагає автентифікації користувача.
|
||
- 403 Forbidden: Сервер зрозумів запит, але відмовляється його виконати.
|
||
- 404 Not Found: Запитуваний ресурс не знайдено на сервері.
|
||
- 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: Запитуваний ресурс недоступний в мережі.
|
||
|
||
## Приклади
|
||
|
||
### Приклад SIP INVITE
|
||
```
|
||
INVITE sip:jdoe@example.com SIP/2.0
|
||
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
|
||
Max-Forwards: 70
|
||
To: John Doe <sip:jdoe@example.com>
|
||
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
|
||
Call-ID: a84b4c76e66710
|
||
CSeq: 314159 INVITE
|
||
Contact: <sip:jsmith@pc33.example.com>
|
||
User-Agent: ExampleSIPClient/1.0
|
||
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
|
||
Content-Type: application/sdp
|
||
Content-Length: 142
|
||
|
||
v=0
|
||
o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
|
||
s=-
|
||
c=IN IP4 pc33.example.com
|
||
t=0 0
|
||
m=audio 49170 RTP/AVP 0
|
||
a=rtpmap:0 PCMU/8000te
|
||
```
|
||
<details>
|
||
|
||
<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 (Протокол опису сесії).
|
||
12. **Content-Length**: `Content-Length: 142` - Заголовок Content-Length вказує розмір тіла повідомлення в байтах.
|
||
13. **Message Body**: Тіло повідомлення містить опис сесії SDP, який включає інформацію про медіа-типи, кодеки та транспортні протоколи для запропонованої сесії.
|
||
|
||
- `v=0` - Версія протоколу (0 для SDP)
|
||
- `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).
|
||
- `a=rtpmap:0 PCMU/8000` - Атрибут, що відображає формат (0) на кодек (PCMU) та його частоту дискретизації (8000 Гц).
|
||
|
||
</details>
|
||
|
||
### SIP REGISTER Приклад
|
||
|
||
Метод REGISTER використовується в Протоколі ініціації сесії (SIP), щоб дозволити користувацькому агенту (UA), такому як VoIP телефон або софтфон, **зареєструвати своє місцезнаходження на сервері реєстрації SIP**. Цей процес дозволяє серверу знати, **куди маршрутизувати вхідні SIP запити, призначені для зареєстрованого користувача**. Сервер реєстрації зазвичай є частиною проксі-сервера SIP або спеціалізованого сервера реєстрації.
|
||
|
||
Ось детальний приклад SIP повідомлень, що беруть участь у процесі аутентифікації REGISTER:
|
||
|
||
1. Початковий **REGISTER** запит від UA до сервера реєстрації:
|
||
```yaml
|
||
REGISTER sip:example.com SIP/2.0
|
||
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
|
||
Max-Forwards: 70
|
||
From: Alice <sip:alice@example.com>;tag=565656
|
||
To: Alice <sip:alice@example.com>
|
||
Call-ID: 1234567890@192.168.1.100
|
||
CSeq: 1 REGISTER
|
||
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).
|
||
|
||
2. **401 Unauthorized** відповідь від сервера реєстрації:
|
||
```css
|
||
cssCopy codeSIP/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
|
||
Call-ID: 1234567890@192.168.1.100
|
||
CSeq: 1 REGISTER
|
||
WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
|
||
Content-Length: 0
|
||
```
|
||
Сервер реєстрації відповідає повідомленням "401 Unauthorized", яке містить заголовок "WWW-Authenticate". Цей заголовок містить інформацію, необхідну для автентифікації UA, таку як **область автентифікації, nonce та алгоритм**.
|
||
|
||
3. Запит REGISTER **з обліковими даними для автентифікації**:
|
||
```vbnet
|
||
REGISTER sip:example.com SIP/2.0
|
||
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
|
||
Max-Forwards: 70
|
||
From: Alice <sip:alice@example.com>;tag=565656
|
||
To: Alice <sip:alice@example.com>
|
||
Call-ID: 1234567890@192.168.1.100
|
||
CSeq: 2 REGISTER
|
||
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
|
||
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 та значення відповіді**, обчислене за допомогою наданої інформації та пароля користувача.
|
||
|
||
Ось як обчислюється **відповідь Authorizarion**:
|
||
```python
|
||
import hashlib
|
||
|
||
def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
|
||
# 1. Calculate HA1 (concatenation of username, realm, and password)
|
||
ha1_input = f"{username}:{realm}:{password}"
|
||
ha1 = hashlib.md5(ha1_input.encode()).hexdigest()
|
||
|
||
# 2. Calculate HA2 (concatenation of method and uri)
|
||
ha2_input = f"{method}:{uri}"
|
||
ha2 = hashlib.md5(ha2_input.encode()).hexdigest()
|
||
|
||
# 3. Calculate the final response value (concatenation of h1, stuff and h2)
|
||
response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
|
||
response = hashlib.md5(response_input.encode()).hexdigest()
|
||
|
||
return response
|
||
|
||
# Example usage
|
||
username = "alice"
|
||
password = "mysecretpassword"
|
||
realm = "example.com"
|
||
method = "REGISTER"
|
||
uri = "sip:example.com"
|
||
nonce = "abcdefghijk"
|
||
nc = "00000001"
|
||
cnonce = "lmnopqrst"
|
||
qop = "auth"
|
||
|
||
response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
|
||
print(f"MD5 response value: {response}")
|
||
```
|
||
4. **Успішна реєстрація** відповідь від сервера реєстрації:
|
||
```yaml
|
||
SIP/2.0 200 OK
|
||
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
|
||
Call-ID: 1234567890@192.168.1.100
|
||
CSeq: 2 REGISTER
|
||
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
|
||
Expires: 3600
|
||
Content-Length: 0
|
||
```
|
||
Після того, як сервер реєстрації перевіряє надані облікові дані, **він надсилає відповідь "200 OK", щоб вказати, що реєстрація була успішною**. Відповідь містить зареєстровану контактну інформацію та час закінчення реєстрації. На цьому етапі агент користувача (Аліса) успішно зареєстрований на сервері SIP реєстрації, і вхідні SIP запити для Аліси можуть бути направлені на відповідну контактну адресу.
|
||
|
||
### Приклад дзвінка
|
||
|
||
<figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
> [!NOTE]
|
||
> Не згадується, але Користувач B повинен надіслати **REGISTER повідомлення до Proxy 2**, перш ніж він зможе отримувати дзвінки.
|
||
|
||
{{#include ../../../banners/hacktricks-training.md}}
|