SIP-телефонія

Протокол SIP (Session Initiat Protocol, протокол установки з'єднання) не є першопроходцем в області IP-телефонії . Протокол H. 323 вже давно використовується для цілей IP-телефонії , проте спочатку він не розроблявся для IP-мереж, що знижує "оптимальність" їх спільної роботи. За роки роботи з протоколом H. 323 накопичено великий досвід використання, який дозволив виявити як його позитивні риси, так і недоліки, які були враховані при розробці протоколу SIP .

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

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

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

  • Масштабованість - можливість збільшення кількості клієнтів при розширенні мережі.
  • Мобільність - можливість отримання сервісу незалежно від місцеположення (як наприклад електронна пошта), а кожному користувачеві видається персональний ідентифікатор, по якому він може бути знайдений.
  • Розширюваність - можливість доповнення протоколу новими функціями (за рахунок введення нових заголовків і повідомлень). Як вже мовилося вище, якщо пристрою зустрічається невідоме йому розширення протоколу, воно просто ігнорується. Оскільки протокол 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 :user@host.com). Як ідентифікатор хоста може служити його IP-адреса, домен або ім'я хоста (IP-адреса визначається з використанням DNS, так що у результаті все одно виходить звернення за адресою SIP : имя@IP-адрес).

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

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

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

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

Повідомлення 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 -протокола (приклад узятий з RFC 3261). Даний приклад відображає роботу базових функцій телефонії і відповідно не зачіпає такі можливості як відеозв'язок передача текстових повідомлень і ін. - загальний принцип роботи протоколу залишається незмінним.

    Користувач Alice ( SIP :alice@atlanta.com) викликає користувача Bob ( SIP :bob@biloxi.com).

    • 1. Користувач Alice посилає повідомлення INVITE прокси-серверу за умовчанням (atlanta.com) Якби користувачеві Alice була відома IP-адреса користувача Bob і він міг до нього звернутися безпосередньо, то запит INVITE в цьому випадку міг бути посланий користувачеві, що безпосередньо викликався.
    • 2. Прокси-сервер посилає запит INVITE серверу абонента, що викликається (biloxi.com).
    • 3. Далі прокси-сервер користувача Bob при необхідності визначає його поточна IP-адреса і посилає йому повідомлення INVITE - у користувача починає дзвонити телефон, про що повідомляється відповідає 180 (Ringing).
    • 4. Якщо користувач, що викликається, відповів на дзвінок, то на запит INVITE висилається відповідь 200 (OK).
    • 5. Зухвалий користувач відправляє повідомлення ACK, що повідомляє що викликається про те, що він отримав відповідь на свій запит INVITE, їм задаються остаточні параметри з'єднання. На цьому етапі все готово до встановлення з'єднання по протоколу RTP (Real-time Transport Protocol).
    • 6. Встановлюється RTP-з'єднання з наперед узгодженими параметрами.
    • 7. Для завершення з'єднання, завершуючим користувачем (кладе трубку) висилається запит BYE, на яке висилається відповідь 200 (OK)

    Поки повідомлення встановлення з'єднання (INVITE) ходять між прокси-серверамі і невідомо чи доступний користувач, що викликається, у відповідь на INVITE посилається відповідь 100 (Trying), що повідомляє про спробу встановлення з'єднання.

    Оскільки прокси-сервер може встановлювати власні з'єднання, його використання дозволяє викликам без проблем долати NAT. Також можлива побудова декілька прокси-серверов в один ланцюжок, що дозволяє долати відразу декілька NAT.

    Кодеки

    Для передачі звуку і відео використовуються різні алгоритми стиснення і кодування даних. Ці алгоритми називаються кодеками. Різні кодеки використовують різну ширину смуги пропускання, а також вносять різні затримки і забезпечують різну якість сервісу. Для звукових кодеків бично ширина смуги пропускання складає від 4-х до 64 кбит/с.

    Методика тестування

    Основне напрями тестування SIP-телефонії полягає в розгляді якості передачі голосу при обмеженні ширини смуги пропускання. Також розглядатиметься якість передачі голосу при динамічній зміні числа сеансів IP-телефонії і зміні завантаженості каналу зв'язку. При тестуванні IP-маршрутизаторів також розглядатиметься поведінка потоків трафіку при встановленні сеансів IP-телефонії .

    чіткіша методика розроблятиметься у міру наростання грунтовної бази результатів тестування SIP -оборудования різних виробників.

    Висновок

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

  • .

    Джерело: ip.zvonok.net

    Статті по темі


    0 Відгуків на “SIP-телефонія”


    1. Немає коментарів

    Залишити відгук