SIP

SIP ( англ. Session Initiation Protocol - Протокол встановлення сеансу) - протокол передачі даних, який описує спосіб встановлення і завершення призначеного для користувача інтернет-сеансу, що включає обмін мультимедійним вмістом ( відео- та аудіоконференція, миттєві повідомлення, онлайн-ігри).

В моделі взаємодії відкритих систем SIP є мережевим протоколом прикладного рівня.

Протокол описує, яким чином клієнтське додаток (наприклад, софтфон) може запросити початок з'єднання в іншого, можливо, фізично віддаленого клієнта, що знаходиться в тій же мережі, використовуючи його унікальне ім'я. Протокол визначає спосіб узгодження між клієнтами про відкриття каналів обміну на основі інших протоколів, які можуть використовуватися для безпосередньої передачі інформації (наприклад, RTP). Допускається додавання або видалення таких каналів протягом встановленого сеансу, а також підключення і відключення додаткових клієнтів (тобто допускається участь в обміні більше двох сторін - конференц-зв'язок). Протокол також визначає порядок завершення сеансу.

Приклад мережі на базі протоколу SIP

1. Принципи протоколу

Розробкою займалася організація IETF MMUSIC Working Group [1]. Протокол почав розроблятися в 1996 році Хенінга Шулзрі (Henning Schulzrinne, Колумбійський університет) і Марком Хендлі ( Університетський коледж Лондона). У листопаді 2000 року SIP був затверджений як сигнальний протокол проекту 3GPP і основний протокол архітектури IMS (модифікація 3GPP TS.24.229 [2]) [3]. Поряд c іншим поширеним протоколом H.323, SIP - один з протоколів, що лежать в основі Voice over IP.

В основу протоколу робоча група MMUSIC заклала наступні принципи:

  • Простота: включає в себе тільки шість методів (функцій)
  • Незалежність від транспортного рівня, може використовувати UDP, TCP, ATM і т. д.
  • Персональна мобільність користувачів. Користувачі можуть переміщатися в межах мережі без обмежень. Це досягається шляхом привласнення користувачеві унікального ідентифікатора. При цьому набір надаваних послуг залишається незмінною. Про свої переміщення користувач повідомляє за допомогою повідомлення REGISTER.
  • Масштабованість мережі. Структура мережі на базі протоколу SIP дозволяє легко її розширювати та збільшувати число елементів.
  • Розширюваність протоколу. Протокол характеризується можливістю доповнювати його новими функціями при появі нових послуг.
  • Інтеграція в стек існуючих протоколів Інтернет. Протокол SIP є частиною глобальної архітектури мультимедіа, розробленої комітетом IETF. Крім SIP, ця архітектура включає в себе протоколи RSVP (протокол), RTP, RTSP, SDP.
  • Взаємодія з іншими протоколами сигналізації. Протокол SIP може бути використаний спільно з іншими протоколами IP-телефонії, протоколами ТфОП, і для зв'язку з інтелектуальними мережами.

2. Дизайн протоколу

Клієнти SIP традиційно використовують порт 5060 TCP і UDP для з'єднання елементів SIP-мережі. В основному, SIP використовується для встановлення і роз'єднання голосових і відеодзвінків. При цьому він може використовуватися і в будь-яких інших додатках, де потрібно установка з'єднання, таких, як системи оповіщення, мобільні термінали і так далі. Існує велика кількість рекомендацій RFC, що відносяться до SIP і визначають поведінку таких застосувань. Для передачі самих голосових і відеоданих використовують інші транспортні протоколи, найчастіше RTP.

Головним завданням розробки SIP було створення сигнального протоколу на базі IP, який міг би підтримувати розширений набір функцій обробки виклику і послуг, представлених в існуючій ТфОП. Сам протокол SIP не визначає цих функцій, а зосереджений тільки на процедурах встановлення дзвінка і сигналізації. При цьому він був спроектований з підтримкою таких функціональних елементів мережі, як проксі-сервери (Proxy Servers) та Користувальницькі Агенти (User Agents). Ці елементи забезпечують базовий набір послуг: набір номера, виклик телефонного апарату, звукове інформування абонента про статус виклику.

Телефонні мережі на основі SIP можуть підтримувати і більш сучасні послуги, що зазвичай надаються ОКС-7, незважаючи на значну відмінність цих двох протоколів. ОКС-7 характеризується складною, централізованою інтелектуальної мережею і простими, неінтелектуальними, терміналами (традиційні телефонні апарати). SIP - навпаки, вимагає дуже просту (і, відповідно, добре масштабовану) мережа з інтелектом, вбудованим в кінцеві елементи на периферії (термінали, побудовані як фізичні пристрої або програми).

SIP використовується разом з декількома іншими протоколами і бере участь тільки в сигнальній частині сесії зв'язку. SIP виконує роль носія для SDP, який описує параметри передачі медиаданнiх в рамках сесії, наприклад використовувані порти IP і кодеки. У типовому застосуванні сесії SIP - це просто потоки пакетів RTP. RTP є безпосереднім носієм голосових і відеоданих.

Перша запропонована версія стандарту (SIP 2.0) була визначена в RFC 2543. Протокол був додатково уточнений у RFC 3261, хоча багато реалізацій як і раніше засновані на проміжних версіях стандарту. Зверніть увагу, що номер версії залишився 2.0.


3. Адресація

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

На початку SIP-адреси (в тексті) ставиться слово sip:, яке вказує, що це саме SIP-адресу, так як бувають і інші c таким же форматом (наприклад, адреси електронної пошти, що позначаються mailto:).

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

Імена користувачів являють собою звичайні алфавітно-цифрові ідентифікатори. В IP-телефонії, як правило, використовують чисто цифрові ідентифікатори ("номера") для зручності розширення / заміни класичних телефонних мереж. Номери місцевого зв'язку, як правило, 2-3-4-значні.

Номер телефону, передаваний шлюзу - будь-який доступний через нього, і може бути як номером місцевого зв'язку, так і номером мобільного або звичайного міського телефону. Адреса шлюзу (IP-адресу або доменне ім'я) задається в настройках телефону або програми-клієнта, а користувачеві для здійснення дзвінка досить тільки набору номера.


4. Архітектура мережі

Протокол SIP має клієнт-серверну архітектуру.

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

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


4.1. Термінал

Коли клієнт і сервер реалізовані в кінцевому обладнанні і взаємодіють безпосередньо з користувачем, вони називаються користувацьким агентськими клієнтом - User Agent Client (UAC) - і користувацьким агентськими сервером - User Agent Server (UAS). Якщо в пристрої присутні і UAC, і UAS, то воно називається користувальницьким агентом - User Agent (UA), а по своїй суті являє собою термінальне обладнання SIP.

Сервер UAS і клієнт UAC мають можливість безпосередньо взаємодіяти з користувачем. Інші клієнти і сервери SIP цього робити не можуть.


4.2. Проксі-сервер

Проксі-сервер (від англ. proxy - "Представник") представляє інтереси користувача в мережі. Він приймає запити, обробляє їх і виконує відповідні дії. Проксі-сервер складається з клієнтської і серверної частин, тому може приймати виклики, ініціювати запити і повертати відповіді.

Передбачено два типи проксі-серверів

  • із збереженням станів (stateful). Такий сервер зберігає в своїй пам'яті всі отримані запити та пов'язані з ним нові сформовані запити до закінчення транзакції.
  • без збереження станів (stateless). Такий сервер просто обробляє одержувані запити. Але на його базі можна реалізувати складні, інтелектуальні послуги.

4.3. Сервер переадресації

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

Однак, для здійснення з'єднання користувач може не використовувати сервер переадресації, якщо він сам знає поточний адресу необхідного користувача.

4.4. Сервер визначення місцеположення користувачів

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

Користувач, якому потрібна адресна інформація не зв'язується з сервером визначення місцеположення безпосередньо. Цю функцію виконують інші SIP-сервери за допомогою протоколів LDAP, R WHOIS, або інших протоколів.


4.5. B2BUA

B2BUA - (англ. back-to-back user agent, буквально: користувальницькі-агенти-спина-до-спини) - варіант логічного елемента в додатках, що працюють з протоколом SIP. B2BUA працює одночасно з двома кінцевими пристроями - терміналами, розділяючи дзвінок або сесію на два плеча-ділянки. З кожною ділянкою B2BUA працює індивідуально, хоча сигнальні повідомлення передаються в рамках сесії в обидві сторони синхронізовано. Таким чином кожен з учасників сесії, на рівні сигналізації взаємодіє з B2BUA, як з кінцевим пристроєм, хоча насправді він є посередником.

B2BUA може надавати такі функції:

  • Управління дзвінками ( біллінг, переклад дзвінка, автоматичне роз'єднання і т. д.)
  • Сполучення різних мереж (зокрема, для адаптації різних діалектів протоколу, залежних від виробників)
  • Приховування структури мережі (приватні адреси, мережна топологія і т. п.)

Досить часто B2BUA є частиною медіа-шлюзу для того, що б повністю контролювати медіа-потоки в рамках сесії. Сигнальний шлюз, який є частиною прикордонного контролера сесій - наочний приклад застосування B2BUA.


5. Повідомлення протоколу SIP

Повідомлення протоколу SIP (запити і відповіді), являють собою послідовності текстових рядків, закодованих у відповідності з документом RFC 2279. Структура і синтаксис повідомлень SIP ідентичні використовуваним в протоколі HTTP. Структура повідомлень протоколу SIP:

Стартовий рядок
Заголовки
Порожній рядок
Тіло повідомлення
  • Стартовий рядок - початкова рядок будь-якого SIP-повідомлення. Якщо повідомлення є запитом, в ній вказується тип запиту, адресат та номер версії протоколу. Якщо повідомлення є відповіддю на запит, в ній вказується номер версії протоколу, тип відповіді і його коротка розшифровка.
  • Заголовки повідомлень містять інформацію, необхідну для обробки повідомлення (інформація про відправника, адресата, шляху проходження і пр.)
  • Тіло повідомлення містить опис сеансів зв'язку. Не всі запити містять тіло повідомлення (наприклад запит BYE). Усі відповіді можуть містити тіло повідомлення, але вміст тіла в них буває різним.

Приклад запиту INVITE:

 INVITE sip: nikolia@example.ru SIP/2.0 Record-Route:  Via: SIP/2.0/UDP 10.0.0.10; branch = z9hG4bK3af7.0a6e92f4.0 Via: SIP/2.0 / UDP 192.168.0.2:5060; branch = z9hG4bK12ee92cb; rport = 5060 From: "78128210000" ; tag = as149b2d97 To:  Contact:  Call-ID: 3cbf958e6f43d91905c3fa964a373dcb@example.ru CSeq: 103 INVITE Max-Forwards: 16 Date: Wed, 10 Jan 2001 13:16:23 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE , NOTIFY Supported: replaces Content-Type: application / sdp Content-Length: 394 v = 0 o = root 3303 3304 IN IP4 10.0.0.10 s = session c = IN IP4 10.0.0.10 t = 0 0 m = audio 40358 RTP / AVP 0 8101 a = rtpmap: 0 PCMU/8000 a = rtpmap: 8 PCMA/8000 a = rtpmap: 101 telephone-event/8000 a = fmtp: 101 0-16 a = silenceSupp: off ---- a = sendrecv 

5.1. Запити

У початковій версії протоколу SIP (RFC 3 261) було визначено шість типів запитів. За допомогою запитів клієнт повідомляє про поточне місцезнаходження, запрошує користувачів взяти участь у сеансах зв'язку, модифікує вже встановлені сеанси, завершує їх і т. д. Тип запиту вказується в стартовій рядку.

  1. INVITE - Запрошує користувача до сеансу зв'язку. Зазвичай містить SDP-опис сеансу.
  2. АСК - Підтверджує прийом відповіді на запит INVITE.
  3. BYE - Завершує сеанс зв'язку. Може бути переданий будь зі сторін, що беруть участь у сеансі.
  4. CANCEL - Скасовує обробку раніше переданих запитів, але не впливає на запити, які вже закінчили оброблятися.
  5. REGISTER - Переносить адресну інформацію для реєстрації користувача на сервері визначення місцеположення.
  6. OPTIONS - Запитує інформацію про функціональні можливості сервера.

    Але в процесі розвитку, в протокол було додано ще кілька типів запитів, які доповнили його функціональність:
  7. PRACK - тимчасове підтвердження (RFC три тисячі двісті шістьдесят-два)
  8. SUBSCRIBE - підписка на отримання повідомлень про подію (RFC три тисячі двісті шістьдесят-п'ять)
  9. NOTIFY - повідомлення передплатника про подію (RFC +3265)
  10. PUBLISH - публікація події на сервері (RFC 3903)
  11. INFO - передача інформації, яка не змінює стан сесії (RFC 2 976)
  12. REFER - запит одержувача про передачу запиту SIP (RFC 3515)
  13. MESSAGE - передача миттєвих повідомлень засобами SIP (RFC 3 428)
  14. UPDATE - модифікація стану сесії без зміни стану діалогу (RFC +3311)

5.2. Відповіді на запити

Відповіді на запити повідомляють про результат обробки запиту або передають запитану інформацію. Структуру відповідей та їх види протокол SIP успадкував від протоколу HTTP. Визначено шість типів відповідей, несучих різну функціональну навантаження. Тип відповіді кодується тризначним числом, найбільш важливою є перша цифра, яка визначає клас відповіді:

  1. 1ХХ - Інформаційні відповіді; показують, що запит знаходиться в стадії обробки. Найбільш поширені відповіді даного типу - 100 Trying, 180 Ringing, 183 Session Progress.
  2. 2ХХ - Фінальні відповіді, які означають, що запит був успішно оброблений. В даний час в даному типі визначені тільки дві відповіді - 200 OK і 202 Accepted.
  3. 3хх - Фінальні відповіді, що інформують обладнання зухвалого користувача про новий місцезнаходження викликається користувача, наприклад, відповідь 302 Moved Temporary.
  4. 4хх - Фінальні відповіді, що інформують про помилку при обробці або виконанні запиту, наприклад, 403 Forbidden чи класичний для протоколу HTTP відповідь 404 Not Found.
  5. 5хх - Фінальні відповіді, що інформують про те, що запит не може бути опрацьований через відмову сервера, 500 Server Internal Error.
  6. 6хх - Фінальні відповіді, що інформують про те, що з'єднання з викликуваним користувачем встановити неможливо, наприклад, відповідь 603 Decline означає, що користувач, що викликається відхилив вхідний дзвінок.

6. Алгоритми встановлення з'єднання

Протокол SIP є керуючим протоколом для встановлення, модифікації і розриву з'єднання, орієнтованого на передачу потокових даних. Параметри передачі медіа-потоків описуються в протоколі SIP допомогою SDP (протокол опису сесії). Потокові медіа-дані можуть передаватися різними засобами, серед яких найбільш популярні транспортні протоколи RTP і RTCP.

Протокол SIP визначає 3 основні сценарії встановлення з'єднання: за участю проксі-сервера, за участю сервера переадресації і безпосередньо між користувачами. Сценарії відрізняються по тому, як здійснюється пошук і запрошення викликається користувача. Основні алгоритми встановлення з'єднання описані в RFC 3665.

Приклад сценарію встановлення з'єднання:

 Сервер Проксі Аліса Перенаправлення сервер 3 Борис | | | | | INVITE F1 | | | | ---------------> | | | | 302 F2 | | | | <----- ---------- | | | | ACK F3 | | | | ---------------> | | | | INVITE F4 | | | ----- ---------------------------> | INVITE F5 | | 100 F6 | -------------- -> | | <-------------------------------- | 180 F7 | | 180 F8 | <---- ----------- | | <-------------------------------- | | | | 200 F9 | | 200 F10 | <--------------- | | <------------------------ -------- | | | ACK F11 | | | --------------------------------> | ACK F12 | | | ---------------> | | Двостороння передача RTP Media | | <==================== ============================> | | | BYE F13 ​​| | BYE F14 | <---------- ----- | | <-------------------------------- | | | 200 F15 | | | - ------------------------------> | 200 F16 | | | ------------- -> | | | | 

7. SIP-T і SIP-I

Для взаємодії з традиційними телефонними мережами, що використовують сигналізацію ОКС-7, були розроблені модифікації протоколу SIP для телефонії: Session Initiation Protocol for Telephones (SIP-T) і Session Initiation Protocol Internetworking (SIP-I). Різниця версій з огляду на те, що SIP-I був розроблений ITU-T, а SIP-T - IETF і описаний в RFC 3372. Основне завдання даних модифікацій протоколу SIP полягає в прозорій передачі повідомлень ISUP по IP-мережі. Дане завдання здійснюється шляхом інкапсуляції сигнальних одиниць ОКС в повідомлення SIP. Всі необхідні завдання щодо взаємодії між протоколами були вирішені на базі протоколу SIP:

Вимога щодо взаємодії Функція SIP-T
Прозорість сигналізації ISUP Інкапсуляція ISUP в тіло повідомлення SIP
Можливість маршрутизувати повідомлення SIP в залежності від ISUP Трансляція параметрів ISUP в заголовку повідомлення SIP
Трансляція адресної інформації при встановленому з'єднанні Використання методу INFO

8. Порівняння з H.323

SIP придатний для читання людиною і структурований відносно запитів і відповідей. Прихильники SIP також заявляють про нього як про більш простому, у порівнянні з H.323 [4]. Однак деякі [ хто? ] схильні вважати, що, в той час як спочатку метою SIP була простота, у своєму сьогоднішньому вигляді він став так само складний, як і H.323. Інші [ хто? ] вважають, що SIP - протокол без станів, який тим самим дає можливість легко реалізувати відновлення при відмові і інші можливості, які ускладнені в протоколах із станами, таких як H.323. SIP та H.323 не обмежені голосовим зв'язком, вони можуть обслуговувати будь-який сеанс зв'язку, від голосового до відеосеанс або додатків майбутнього.

Параметр порівняння SIP H.323
Додаткові послуги
Набір послуг, підтримуваних обома протоколами приблизно однаковий
Персональна мобільність користувачів Є добрий набір засобів підтримки мобільності Персональна мобільність підтримується, але менш гнучко
Розширюваність протоколу Зручна розширюваність, проста сумісність з попередніми версіями Розширюваність підтримується, але існує ряд складнощів
Масштабованість мережі
Обидва протоколу забезпечують хорошу масштабованість мережі
Час встановлення з'єднання Досить однієї транзакції Потрібно декілька транзакцій.
Складність протоколу Простий, мало запитів, текстовий формат повідомлень Складний, багато запитів і протоколів, двійкове подання повідомлень
Сумісність устаткування Практично ніякої. Кожен виробник SIP пристроїв дотримується тільки той набір рекомендацій (RFC) який йому подобається, бо набір цих рекомендацій дуже великий. Сумісний фактично тільки базовий виклик Практично повна. Стандарти усталені і мають чіткий набір специфікацій

9. Безпека

Питань безпеки використання протоколу SIP присвячений окремий розділ RFC 3261. Шифрування сигнального трафіку можливо на транспортному рівні через іcпользованіе TLS замість TCP / UDP. Крім того, розроблений стандарт SIPS ( англ. SIPS ), Який накладає додаткові угоди щодо безпечної передачі даних за допомогою SIP. Для шифрування мультимедійного контенту застосовується протокол SRTP.


Примітки

  1. Multiparty Multimedia Session Control (mmusic) - Charter - www.ietf.org / html.charters / mmusic-charter.html
  2. 3GPP specification: 24.229 - www.3gpp.org/ftp/Specs/html-info/24229.htm
  3. Стаття "Передумови появи NGN" - ims-book.com/node/5
  4. Джим Ван Меггелен, Лейф Мадсен, Джаред Сміт Asterisk - майбутнє IP телефонії. - Символ-Плюс, Санкт-Петербург-Москва, 2009. - 656 с. - 2000 прим. - ISBN 978-5-93286-128-8

Література

  • Гольдштейн, Б. С. Протокол SIP. Довідник. - СПб.: BHV-Санкт-Петербург, 2005. - С. 456. - ISBN 5-8206-0123-8
  • Гольдштейн, Б. С. IP телефонія - М.: Радіо і зв'язок, 2001. - 336 C.: іл. - ISBN 5-256-01585-0