Session initiation protocol

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

Протокол почав розроблятися в 1996 році Геннінгом Шульцрінне (Henning Schulzrinne, Колумбійський університет) і Марком Гендлі (UCL). У листопаді 2000 року SIP був затверджений як сигнальний протокол проекту 3GPP [ 14 травня 2004 у Wayback Machine.] і постійний елемент архітектури IMS. SIP — один з протоколів, що лежать в основі Voice over IP.

Проєкт протоколу

Клієнти SIP традиційно використовують порт 5060 TCP і UDP для з'єднання серверів та інших елементів SIP. В основному SIP використовується для встановлення і роз'єднання голосових і відеодзвінків. При цьому він може використовуватися і в будь-яких інших застосуваннях, де потрібна установка з'єднання, таких як Event Subscription and Notification, Terminal mobility і так далі. Існує велика кількість RFC, що відносяться до SIP і визначають поведінку таких застосувань. Для передачі самих голосових і відеоданих використовують інші прикладні протоколи, найчастіше Real-time Transport Protocol (RTP).

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

Телефонні мережі на основі SIP можуть підтримувати і сучасніші послуги, що зазвичай надаються Signalling System 7 (SS7), не зважаючи на значну відмінність цих двох протоколів. SS7 характеризується складною, централізованою інтелектуальною мережею і простими, неінтелектуальними, терміналами (традиційні телефонні апарати). SIP є протоколом типу точка-точка. Як протоколи такого класу він вимагає тільки дуже просту (і, відповідно, добре масштабовану) мережу з інтелектом^[], вбудованим в крайові елементи на периферії (термінали, побудовані як фізичні пристрої або програми). Іншими словами, функції SIP реалізовані в термінальних пристроях (тобто на межі мережі), на відміну від традиційних можливостей SS7, які підтримуються самою мережею.

Хоча існує багато інших сигнальних протоколів VoIP, SIP характеризується його прихильниками як належний співтовариству IP, а не до телекомунікаційної індустрії. SIP стандартизований і контролюється головним чином IETF, тоді як протокол H.323 сімейства VoIP був традиційно тісніше пов'язаний з ITU. Проте ці дві організації так чи інакше схвалили обидва протоколи.

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

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

SIP схожий на HTTP і розділяє з ним загальні принципи проектування: він придатний для читання людиною і структурований відносно запитів та відповідей. Прихильники SIP також заявляють про нього як про більш простий, у порівнянні з H.323. Проте дехто схильний вважати, що в момент, коли метою SIP була простота, у своєму сьогоднішньому вигляді він став такий же складний, як і H.323. Інші вважають, що SIP — протокол без станів, який тим самим дає легко реалізувати відновлення при відмові і інші можливості, які утруднені в протоколах із станами, таких як H.323. Цей аргумент набув релігійного характеру, але, судячи з усього, SIP виграв битву, якщо не війну протоколів. SIP розділяє з HTTP багато кодів станів, таких як відомий '404 not found'. SIP та H.323 не обмежені голосовим зв'язком, вони можуть обслуговувати будь-який сеанс зв'язку, від голосового до відеосеансу або майбутні види зв'язку.

Опис

Приклад обміну повідомленнями між двома користувачами (Еліс і Боб) за протолом SIP для встоновлення і припинення прямого мультимедійного з'єднання.

Протокол ініціювання сеансів — Session Initiation Protocol — є протоколом прикладного рівня і призначається для організації, модифікації і завершення сеансів зв'язку: мультимедійних конференцій, телефонних з'єднань і розподілу мультимедійної інформації.

Протокол SIP розроблений комітетом IETF, а специфікації протоколу представлені в документі RFC 3261. В основу протоколу закладені наступні принципи:

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

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

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

Інтеграція в стек існуючих протоколів Інтернет, розроблених IETF. Протокол SIP є частиною складної архітектури, розробленої комітетом IETF. Ця архітектура містить у собі також протокол резервування ресурсів (Resource Reservation Protocol, RSVP; RFC 2205), транспортний протокол реального часу (Real-Time Transport Protocol, RTP; RFC 1889), протокол передачі потоків у реальному часі (Real-Time Streaming Protocol, RTSP; RFC 2326), протокол опису параметрів зв'язку (Session Description Protocol, SDP; RFC 2327) та інші. Однак функції протоколу SIP не залежать ні від одного з цих протоколів.

Взаємодія з іншими протоколами сигналізації. Протокол SIP може бути використаний спільно з протоколом Н.323. Можливо також взаємодія протоколу SIP з системами сигналізації ТМЗК — EDSS1 і СКС (Спільно канальна сигналізація) № 7. Для спрощення такої взаємодії сигнальні повідомлення протоколу SIP можуть переносити не тільки SIP-адресу, але й телефонний номер формату Е.164 або будь-якого іншого формату. Крім того, протокол SIP, нарівні з протоколами H.323 і ISUP, може застосовуватися для забезпечення функціонування пристроїв управління шлюзами, в цьому випадку він повинен взаємодіяти з протоколом MGCP або MEGACO. Важливою особливістю протоколу SIP є його незалежність від транспортних технологій. Як транспорт можна використовувати протоколи Х.25, Frame Relay, AAL5, IPX і ін Структура повідомлень SIP не залежить від обраної транспортної технології.

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

Адресація в мережах sip

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

SIP-адреси бувають чотирьох типів:

q ім'я @ домен,

q ім'я @ хост,

q ім'я @ IP-адресу,

q № телефону @ шлюз.

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

У другій частині адреси вказується ім'я домену, робочої станції або шлюзу. Для визначення IP-адреси пристрою необхідно звернутися до служби доменних імен — Domain Name Service (DNS). Якщо ж у другій частині SIP-адреси розміщується IP-адресу, то з робочою станцією можна зв'язатися безпосередньо.

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

  sip: [e-mail]. 

 sip: user1@192.168.0.215 

 sip: [e-mail] 

Структура протоколу SIP

Структура мережі

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

Нижній рівень SIP відповідає за синтаксис і кодування. Кодування визначено з використанням розширеної граматики Backus-Naur Form (BNF). Повне BNF-опис для SIP міститься в RFC 3261, структура повідомлень SIP буде розглянута в розділі.

Другий рівень програмної реалізації протоколу є транспортним. Він визначає, як клієнт посилає запити і приймає відповіді і як сервер отримує запити і посилає відповіді по мережі. Транспортний рівень протоколу описаний в розділі.

Третій рівень - це рівень транзакцій. Транзакція - це запит, відісланий клієнтської стороною з використанням транспортного рівня SIP серверній стороні, разом з усіма відповідями на цей запит, відіслані серверної стороною клієнта. Рівень транзакцій здійснює повторну передачу повідомлень прикладного рівня, визначає відповідність відповідей запиту і повідомляє верхній рівень проткокола у разі таймауту. Будь-яка операція, яку виконує клієнт агента користувача (UAC), реалізується за допомогою серії транзакцій. Опис роботи рівня транзакцій наведено в параграфі. Агенти користувача (UA) та проксі-сервери з збереженням станів транзакцій (stateful проксі-сервери) містять рівень транзакцій. На противагу їм проксі-сервер без збереження станів (stateless проксі-сервер) не включає рівня транзакцій. Рівень транзакцій має клієнтську частину, звану клієнтської транзакцією і серверну частину, звану серверної транзакцією. Кожна з них представлена кінцевим автоматом (state machine), пов'язаних з обробкою певного типу запиту.

Рівень, що знаходиться вище рівня транзакцій, називається користувачем транзакцій (transaction user - TU). Кожен із об'єктів SIP, крім stateless проксі-сервера, є користувачем транзакцій. Коли TU бажає відіслати запит, він створює окрему клієнтську транзакцію, і передає їй запит разом з IP-адресою, портом і типом транспортного протоколу для місця призначення, які визначають куди потрібно відіслати запит. TU, який створив клієнтську транзакцію, може також скасувати її. Коли клієнт скасовує транзакцію, він потребує, щоб сервер припинив подальшу обробку запиту, повернувся у вихідний стан і цієї передав транзакції відповідь з певним кодом помилки. Це здійснюється за допомогою запиту CANCEL, який створює свою власну транзакцію, але виконує свої функції щодо скасовуємо транзакції

SIP елементи, якими є клієнт і сервер агента користувача, stateful і stateless проксі-сервери і сервер реєстрації, містять програмне забезпечення - ядро (core), яка відрізняє їх один від одного. Ядра, за винятком ядра stateless проксі-сервера, є користувачами транзакцій (TU). Попри те, що функціонування ядер UAC і UAS залежить від типу запиту, існують деякі загальні правила для всіх типів запитів. Ці правила описані в розділі для UAC і ці правила стосуються процесу створення запиту, для UAS вони стосуються обробки запиту і створення відповіді. Оскільки реєстрація відіграє важливу роль у протоколі SIP, UAS, який може працювати c запитом REGISTER, має свою назву - сервер реєстрації (registrar). Роботу ядер UAC і UAS для запиту REGISTER. У розділі висвітлюється робота UAC і UAS із запитом OPTIONS, використовуваного для отримання інформації про функціональні можливості UA. Решта запити, визначені в основний RFC для SIP (RFC 3261), надсилаються в режимі діалогу. Діалог являє собою рівноправну взаємодію двох агентів користувача по протоколу SIP, яке триває певний час. Діалог встановлює послідовність повідомлень між UA та забезпечує вірну маршрутизацію запитів. Запит INVITE є єдиним типом запиту, що встановлює діалог, визначеним у рекомендації RFC 3261 (Проте згодом розширення протоколу визначили ще два таких запиту - SUBSCRIBE і REFER). Коли UAC відсилає запит в режимі діалогу, він крім виконання загальних правил UAC, описаних у розділі, дотримується правил для роботи із запитами в ході діалогу. Параграф дає поняття про діалогах і описує процедури їх створення та підтримки на додаток до процедур створення запитів у режимі діалогу.

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

Протокол володіє такими характеристиками:

• Простота: включає тільки шість методів (функцій).
• Незалежність від транспортного рівня, може використовувати UDP, TCP, ATM і т.д.
• Економічність: всі запити формуються на основі тексту.

Можливості протоколу SIP

Основні переваги протоколу SIP:

1. Масштабованість — можливість збільшення кількості клієнтів при розширенні мережі.
2. Мобільність — можливість отримання сервісу незалежно від місцеположення (наприклад електронна пошта), а кожному користувачеві видається персональний ідентифікатор, по якому він може бути знайдений.
3. Розширюваність — можливість доповнення протоколу новими функціями (за рахунок введення нових заголовків і повідомлень). Як вже говорилося вище, якщо пристрою зустрічається невідоме йому розширення протоколу, воно просто ігнорується. Так як протокол H.323 використовує повідомлення двійкового формату, то невідомі функції можуть привести до неможливості надання сервісу.

Протокол SIP розроблявся з розрахунком на можливість використання будь-яких транспортів, але, тим не менше, найбільш переважним є використання UDP-пакетів (це дозволяє підвищити продуктивність в порівнянні з використанням протоколу TCP, але вимагає використання додаткових механізмів перевірки доставки сигнальних повідомлень). Так як телефонія з використанням протоколу SIP дозволяє використовувати велику кількість різноманітних сервісів (крім передачі голосу, можлива передача відео, текстових повідомлень, факсів та ін), необхідний механізм обміну інформацією про те, які сервіси може використовувати викликається \ викликає сторони. Для цієї мети використовується протокол SDP (Session Description Protocol) — протокол опису сесії. Даний протокол дозволяє визначити які звукові (відео та інші) кодеки і інші можливості може використовувати віддалена сторона. Власне сама передача голосу здійснюється завдяки використанню протоколу RTP (Real-time Transport Protocol, протокол транспортування в реальному часі). Сам протокол SIP безпосередньої участі в передачі голосових, відео та інших даних не бере, він відповідає тільки за встановлення зв'язку (по протоколах SDP, RTP і ін), тому під SIP-телефонією розуміється не передача голосу по протоколу SIP, а передача голосу з використанням протоколу SIP. Використання протоколу SIP надає нові можливості встановлення з'єднань (а також можливість безпроблемного розширення даних можливостей), а не безпосередньої передачі голосового та інших видів трафіку. Формат адрес використовуваних протоколом SIP нагадує формат E-Mail-адреси: ім'я @ ідентіфікатор_хоста. На початку адреси ставиться приставка "sip:" (приклад: sip: [e-mail]). Ідентифікатором хоста може слугувати його IP-адреса, домен або ім'я хоста (IP-адреса визначається з використанням DNS, так що в результаті все одно виходить звернення за адресою sip: ім'я @ IP-адресу).

Архітектура SIP-мережі

Стандартними елементами в SIP-мережі є:

1. User Agent (термінал): за протоколом SIP встановлюються з'єднання «клієнт-сервер». Клієнт встановлює з'єднання, а сервер приймає виклики, але так зазвичай телефонний апарат (або програмний телефон) може як встановлювати так і приймати дзвінки, то виходить що він одночасно грає роль і клієнта і сервера (хоча в реалізації протоколу це не є обов'язковим критерієм) — в цьому випадку його називають User Agent (UA) або термінал.
2. Проксі-сервер: проксі-сервер приймає запити і проводить з ним деякі дії (наприклад визначає місцеположення клієнта, виробляє переадресацію або перенаправлення виклику та ін.) Він також може встановлювати власні з'єднання. Найчастіше проксі-сервер суміщають з сервером визначення місцеположення (Register-сервер), у такому випадку його називають Registrar-сервером.
3. Сервер визначення місця розташування або сервер реєстрації (Register): даний вид сервера служить для реєстрації користувачів. Реєстрація користувача проводиться для визначення його поточної IP-адреси, для того щоб можна було зробити виклик user @ IP-адреса. У разі якщо користувач переміститься в інше місце і / або не має певної IP-адреси, його поточну адресу можна буде визначити після того, як він зареєструється на сервері реєстрації. Таким чином клієнт залишиться доступний за однією і тією ж SIP-адресою незалежно від того, де насправді знаходиться.
4. Сервер переадресації: звертається до сервера реєстрації для визначення поточної IP-адреси користувача, але на відміну від проксі-сервера тільки «переадресує» клієнта, а не встановлює власні з'єднання.

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

Повідомлення SIP

Структура повідомлень протоколу SIP

Повідомлення SIP-протоколу мають наступну структуру:

• Стартовий рядок (start-line);
• Заголовки повідомлення (* message-header);
• Порожній рядок (CRLF);
• Повідомлення.

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

У заголовках містяться відомості про джерело, адресат, шлях проходження повідомлення та ін. Цих заголовків може бути досить багато і ця кількість може мінятися на шляху проходження пакетів. У протоколі SIP версії 2.0 існує 6 типів запитів (тип запиту задається в стартовому рядку):

• INVITE — викликає адресата для встановлення зв'язку. За допомогою цього повідомлення адресату передаються види підтримуваних сервісів (які можуть бути використані ініціатором сеансу), а також види сервісів, які бажає передавати ініціатор зв'язку;
• ACK — повідомлення підтверджує згоду адресата встановити з'єднання. У цьому повідомленні можуть бути передані остаточні параметри сеансу зв'язку (остаточно вибираються види сервісів і їх параметри які будуть використані);
• Cancel — відміна раніше переданих запитів (використовується у випадку якщо необхідності в них більше немає);
• BYE — запит завершення з'єднання;
• Register — даним запитом користувач ідентифікує своє поточне місце розташування;
• OPTIONS — запит інформації про функціональні можливості терміналу (застосовується у разі, якщо ці дані потрібно отримати до встановлення з'єднання, тобто до фактичного обміну даною інформацією за допомогою запитів INVITE і ACK).

На кожен запит, відправникові прямує відповідь, що містить код результату виконання запиту. Формат цих відповідей успадкований від протоколу HTTP. Відповіді кодуються 3-хзначним числом, перша цифра якого вказує на клас відповідей, а інші дві — ідентифікують конкретну відповідь в кожному класі. Пристрій може не знати, що означає код відповіді, але повинен обов'язково знати клас відповіді. Всього існує 6 класів відповідей:

• 1?? — Інформаційні відповіді;
• 2?? — Успішне закінчення запиту;
• 3?? — Інформація про зміни місця розташування абонента, що викликається;
• 4?? — Інформація про помилку;
• 5?? — Інформація про помилку сервера;
• 6?? — Інформація про неможливість виклику абонента (користувача з такою адресою не існує, або користувач відмовляється прийняти виклик).

Інформаційні відповіді повідомляють про стадію виконання запиту, вони не є завершенням запиту. Інші ж класи відповідей завершують виконання запиту.

Література

• Гольдштейн, Б.С. Протокол SIP. Справочник. — СПб.: BHV-Санкт-Петербург, 2005. — С. 456. — .
• Гольдштейн, Б. С. IP телефония — М.: Радио и связь, 2001. — 336 C.: ил. —

Посилання

• Сторінка форуму SIP [ 11 березня 2021 у Wayback Machine.]
• (PDF)
• SIP-телефония [ 3 квітня 2013 у Wayback Machine.]

Специфікації

• RFC 2543 [ 2 січня 2008 у Wayback Machine.] — специфікація першої версії протоколу
• RFC 3261 [ 6 березня 2022 у Wayback Machine.] — специфікація другої версії протоколу
• RFC 3263 [ 15 січня 2008 у Wayback Machine.]
• RFC 3265 [ 7 січня 2008 у Wayback Machine.]

Див. також

• NGN
• SoftSwitch