Аналіз мережі ІР-телефонії за показниками якості

3) Підтримка основних телефонних інтерфейсів і типів сигналізацій: важливими критеріями при оцінці характеристик шлюзів є можливо велика різноманітність телефонних інтерфейсів, підтримуваних IP-шлюзом (E1, PRI, BRI) і аналогових зокрема. Істотну роль відіграє підтримка обладнанням механізмів безпеки у відповідності з Рекомендацією Н.235

Рис. 2.11. Положення шлюзу в мережі IP-телефонії

4) Транспортні архітектури: діапазон транспортних архітектур, з якими працюють сучасні шлюзи є досить широким: виділені лінії, ISDN, Frame Relay, ATM, Ethernet.

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

6) Забезпечення факс-зв'язком: переважна більшість вироблених шлюзів мають можливість забезпечувати факсимільний зв'язок на базі протоколу IP. Вона опирається на два основних стандарти, запропонованих МСЕ-Т. Стандарт Т.37 зводить передачу факсів до доставки з проміжним зберіганням, так як зображення факсів передаються у вигляді вкладень електронної пошти. Ще один стандарт Т.38 описує передачу факсів в реальному часі або за допомогою імітації з'єднання з факс-апаратом, або за допомогою методу модуляції під назвою FaxRelay.

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

8) Можливість установки різних алгоритмів кодування мовлення: на показники якості переданого голосу по IP-мережі істотно впливає схема кодування, що використовується в шлюзі VoIP при стисненні голосової інформації.

Класифікація шлюзів IP-телефонії

Шлюзи IP-телефонії за масштабністю застосування можна розділити на два основних типи: шлюзи, орієнтовані на корпоративне застосування, і шлюзи, призначені для операторів і постачальників послуг зв'язку. Продукти останнього типу відрізняються великою ємністю і масштабованістю, присутністю засобів моніторингу. Виконання шлюзів IP-телефонії:

1) автономні IP-шлюзи. Більшість виробників шлюзів пропонує автономні IP-шлюзи, які зазвичай складаються з серверів на базі персональних комп'ютерів з комплектом голосових плат. Голосові плати не призначені для компресії/декомпресії звуку, тому дана операція повинна виконуватися головним процесором ПК.

2) маршрутизатори, шлюзи. У світі виробників устаткування телекомунікацій помітилася тенденція до того, що великі компанії традиційне мережеве обладнання оснащують вузлами, які відповідають за IP-телефонію. Ця продукція - маршрутизатори і пристрої доступу до розподілених мереж з вбудованими шлюзами IP-телефонії - займають окрему важливу нішу на ринку мережевого обладнання.

3) RAS-шлюзи. Свою частину ринку обладнання для IP-телефонії займають шлюзи для VoIP, що складаються з плат, встановлених в сервери дистанційного доступу. В цьому напрямку працюють компанії Ascend Communications і Digi International. Установка пристроїв даного типу при побудові IP-мереж виправдана при роботі з додатками з безліччю голосових портів і мають гранично важливе значення.

4) шлюзи-модулі для УПАТС. В даний час набули поширення шлюзи IP-телефонії, що представляють собою конструктивно модулі для класичних відомчих АТС. Компанії Lucent Technologies і Nortel Networks виробляють їх для своїх станцій Defmity і Meridian 1. Причому, така система перед тим як встановити з'єднання через IP-мережу, перевіряє якість зв'язку. У разі достатній її якості - встановлюється з'єднання. Інакше, виклик направляється по традиційних лініях зв'язку.

5) шлюзи з інтеграцією бізнес-додатків. По мірі розвитку систем IP-телефонії на провідні ролі виходять сервіс-функції. При цьому обладнання повинно орієнтуватися не тільки на інтеграцію трафіку, але і на інтеграцію бізнес-додатків. До таких продуктів слід віднести систему eBridge Interactive Web Responce компанії eFusion, яка забезпечує інтеграцію Web-служб і центрів обробки викликів.

6) відомчі АТС на базі шлюзів. Ще один напрям розвитку обладнання IP-телефонії побудова відомчих телефонних систем на базі інфраструктур ЛОМ. У разі, коли недоцільна установка окремого сервера для перетворення телефонних сигналів в IP-пакети, використовуються мережеві пристрої, що підключаються безпосередньо до мережі lOBaseT (за типом концентратора Ethernet). При цьому кожен концентратор являє, по суті, невелику УАТС з голосовою поштою і автоматичним секретарем [10].

7) мережеві плати з функціями телефонії. Одним з рішень IP-телефонії є багатоцільові мережеві плати з функціями телефонії (невеликі пристрої типу Internet Phone JACK від Quicknet Technologies, або великі пристрої типу плат ATM від Sphere Communications). Такі пристрої обладнані портами RJ-11 для підключення звичайного телефонного апарату.

8) автономні IP-телефони. Являють собою рішення “все в одному” для однієї лінії. За зовнішнім виглядом і базовими сервісними можливостям апаратні реалізації IP-телефонів нічим особливо не відрізняються від звичайних телефонів, але їх електронна “начинка” дозволяє істотно зменшити навантаження на персонал, відповідальний за телефонний зв'язок. Такий тип продуктів пропонує компанія Cisco Systems.

Крім апаратної, існують і програмні реалізації IP-телефонів. У цьому випадку персональний комп'ютер (ПК), обладнаний телефонною гарнітурою або мікрофоном і акустичними системами, перетворюється в багатофункціональний комунікаційний центр. Користувач ПК, крім доступу до звичайного телефонного сервісу, отримує набір додаткових можливостей: отримання інформації про викличного клієнта, контроль за телефонними викликами і роботою з мовною поштою. Недоліками таких систем є неповна сумісність з Н.323 версії 2, а також відсутність підтримки функцій щодо забезпечення безпеки в роботі з gatekeeper.

Отже, у загальному випадку IP-телефонія опирається на дві основні операції: перетворення двобічного аналогового мовлення в цифрову форму всередині кодуючого/декодуючого пристрою (кодека) і пакування в пакети для передачі по IP. Технологія передачі голосу по IP-мережі замість класичної мережі з комутацією каналів передбачає конфігурацію з установкою шлюзів. Шлюз забезпечує стиснення інформації (голосу), конвертування її в IP-пакети і направлення в IP-мережу.

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

Розділ ІІІ. Аналіз мережі ір-телефонії за показниками якості

3.1 Вплив мережі на показники якості IP-телефонії

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

Основними складовими якості IP-телефонії є:

- якість мови, яка включає:

- діалог - можливість користувача зв'язуватися і розмовляти з іншим користувачем в реальному часі і повнодуплексному режимі;

- розбірливість - чистота і тональність мови;

- ехо - чутність власної мови;

- рівень - гучність мови;

- якість сигналізації, що включає:

- встановлення виклику - швидкість успішного доступу і час встановлення з'єднання;

- завершення виклику - час відбою і швидкість роз'єднання;

- DTMF (Dual Tone Multiple Frequency) - визначення і фіксація сигналів багаточастотного набору номера.

Фактори, які впливають на якість IP-телефонії, можуть бути розділені на дві категорії:

- чинники якості IP-мережі:

- максимальна пропускна здатність - максимальна кількість корисних і надлишкових даних, які вона передає;

- затримка - проміжок часу, необхідний для передачі пакету через мережу;

- джиттер - затримка між двома послідовними пакетами;

- втрата пакета - пакети або дані, втрачені при передачі через мережу;

- чинники якості шлюзу:

- необхідна смуга пропускання - різні вокодери вимагають різні смуги.

Затримка

Затримка створює незручність при веденні діалогу, приводить до перекриття розмов і виникнення еха. Ехо виникає у разі, коли відображений мовний сигнал разом з сигналом від видаленого кінця повертається знову у вухо розмовляючого. Ехо стає великою проблемою, коли затримка в петлі передачі більше, ніж 50 мс. Оскільки ехо є проблемою якості, системи з пакетною комутацією мови повинні мати можливість управляти ехом і використовувати ефективні методи ехоподавлення. Можна виділити наступні джерела затримки при пакетній передачі мови з кінця в кінець (рисунок 3.1).

1) Затримка накопичення (іноді називається алгоритмічною затримкою): ця затримка обумовлена необхідністю збору кадрів мовних звітів, виконувана в мовному кодері. Величина затримки визначається типом мовленнєвого кодера і змінюється від невеликих величин (0,125 мкс) до декількох мілісекунд.

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

3) Мережна затримка обумовлена фізичним середовищем і протоколами, які використовуються для передачі мовних даних. Вона залежить від ємності мережі та процесів передачі пакетів в мережі. Час затримки при передачі мовного сигналу можна віднести до одного з трьох рівнів:

- перший рівень до 200 мс - відмінна якість зв'язку. Для порівняння, в телефонній мережі загального користування (ТфЗК) допустимі затримки до 150-200 мс;

- другий рівень до 400 мс - вважається доброю якістю зв'язку. Але якщо порівнювати з якістю зв'язку по мережах ТфЗК, то різницю буде видно. Якщо затримки постійно утримується на верхній межі 2-го рівня (400 мс), то не рекомендується використовувати цей зв'язок для ділових переговорів;

- третій рівень до 700 мс - вважається прийнятною якістю зв'язку для ведення неділових переговорів. Така якість зв'язку можлива також при передачі пакетів по супутниковому зв'язку [11].

Якість Інтернет-телефонії потрапляє під 2-3 рівні, причому неможливо впевнено сказати, що той чи інший провайдер Інтернет-телефонії працює з другого рівня, оскільки затримки в мережі Інтернет мінливі. Більш точно можна сказати про провайдерів IP-телефонії, що працюють по виділених каналах. Вони потрапляють під 1-2 рівні. Також необхідно враховувати затримки при кодуванні/декодуванні голосового сигналу. Середні сумарні затримки при використанні IP-телефонії зазвичай знаходяться в межах 150-250 мс.

Рис. 3.1. Складові затримки в мережі IP-телефонії

В мережі Інтернет затримки пакетів суттєво залежать від часу. Помітні зміни часу поширення можуть відбутися протягом одного нетривалого сеансу зв'язку, а коливання часу передачі можуть бути в діапазоні від десятків до сотень мілісекунд і навіть перевищувати секунду.

Джиттер

Коли мова або дані розбиваються на пакети для передачі через IP-мережу, пакети часто прибувають в пункт призначення в різний час і в різній послідовності. Це створює розкид часу доставки пакетів (джиттер). Джиттер приводить до специфічних порушень передачі мови, які чуються як тріски і клацання. Розрізняють три форми джиттера:

1) джиттер, залежний від даних (Data Dependent Jitter - DDJ) - відбувається у випадку обмеженої смуги пропускання або при порушеннях в мережевих компонентів;

2) спотворення робочого циклу (Duty Cycle Distortion - DCD) - зумовлено затримкою розповсюдження між передачею знизу вгору і зверху вниз;

Рис. 3.2. Гістограми джиттера пакетів

3) випадковий гейзер (Random Jitter - RJ) - є результатом теплового шуму. На рисунку 3.2 наведено гістограми джитера пакетів в локальній мережі та в мережі Інтернет з різними швидкостями роботи. На осі абсцис відкладена відносна затримка, що характеризує реальний стан пакету в послідовності на тимчасовій осі по відношенню до ідеального в припущенні, що перший пакет прийшов без затримки. Величини виникаючих затримок і їх ймовірності важливі для організації процедури обробки, параметрів обробки.

Згладжуючий буфер

Мовний трафік може бути охарактеризований як безперервний і рівномірний потік пакетів. Якщо в процесі обслуговування черг на маршрутизаторах ця рівномірність порушується (виникає розкид затримки пакетів) і заходи для її відновлення не приймаються, то видача абоненту мовних фреймів буде відбуватися з різною затримкою - він почує “рвану” мову з провалами в прийнятому сигналі. Для гарантії нормальної якості необхідно забезпечити рівномірне надходження мовних фреймів, що досягається шляхом організації на приймальній стороні згладжуючого буфера. Цей буфер приймає і зберігає фрейми, видаючи їх кодеку через рівні інтервали часу. Варіація затримки при цьому усувається, але може виникнути додаткова затримка, рівна сумарній тривалості фреймів, що зберігаються в буфері. Тому потрібно забезпечити, щоб у буфері зберігалися лише мінімально необхідні для усунення варіації затримки, кількість фреймів.

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

Маскування помилок

При виникненні перевантажень в IP-мережі маршрутизатори можуть сильно затримати або скинути пакети. В результаті цього в регенеруючому мовному сигналі виникнуть “прогалини”, які будуть сприйматися абонентом як клацання. Для усунення цього неприємного ефекту використовується процедура маскування помилок (error concealment).

Зрозуміло, що декодер повинен отримувати мовні фрейми через певний інтервал часу. Якщо пакет отриманий занадто пізно і в момент, коли декодеру потрібен черговий кадр, згладжуючий буфер виявився порожнім, процедура маскування помилок повинна сама сформувати кадр, щоб приховати цю помилку. Це ж повинно відбуватися і при отриманні кадру, пошкодженого в процесі передачі.

Використання процедури маскування помилок дозволяє отримати прийнятний результат, якщо втрати пакетів не надто великі. Згідно з матеріалами робочої групи TIPHON, при втраті близько 3% пакетів хороша якість передачі мови зберігається, а при втраті 15% пакетів вона стає вже неприйнятною.

Втрата пакетів

Втрачені пакети IP-телефонії порушують мову і створюють спотворення тембру. В існуючих IP-мережах всі голосові кадри обробляються як дані. При пікових навантаженнях і перевантаженнях голосові кадри будуть відкидатися, як і кадри даних. Однак кадри даних не пов'язані з часом і відкинуті пакети можуть бути успішно передані шляхом повторення. Втрата голосових пакетів, в свою чергу, не може бути заповнена таким способом і в результаті відбудеться неповна передача інформації. Передбачається, що втрата до 5% пакетів непомітна, а понад 10-15% - неприпустима.

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



Рис. 3.3. Гістограми втрати пакетів

Пріоритизація

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

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

Обслуговування черг

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

Механізми обслуговування черг, реалізовані в сучасних маршрутизаторах, дуже нагадують механізми, наявні в комутаторах ATM. Проте навіть найбільш розвинений з таких механізмів забезпечує лише розподіл ресурсів в окремо взятому сайті, але не вирішує задачу прогнозування вимог до ресурсів з боку кожного потоку на всій довжині маршруту від 1-го кінцевого вузла до іншого. В ATM ця задача вирішується в процесі обміну сигнальними повідомленнями, що встановлюють віртуальне з'єднання. Подібний тип резервування ресурсів можливий в IP-мережі, він здійснюється за допомогою протоколів RSVP і MPLS.

3.2 Забезпечення якості IP-телефонії на базі протоколів RSVP та MPLS

Забезпечення якості IP-телефонії на базі протоколу RSVP

Одним із засобів забезпечення якості IP-телефонії і особливо Інтернет-телефонії є використання протоколу резервування ресурсів (Resource Reservation Protocol, RSVP), рекомендованого комітетом IETF. За допомогою PSVP мультимедіа-програми можуть вимагати спеціальної якості обслуговування (specific quality of service, QoS) за допомогою будь-якого з існуючих мережевих протоколів - головним чином IP, хоча можливо використовувати і UDP - щоб забезпечити якісну передачу відео- і аудіосигналів. Протокол RSVP передбачає гарантоване QoS завдяки тому, що через кожен комп'ютер, або вузол, який пов'язує між собою учасників телефонної розмови, може передаватися певна кількість даних.

Протокол RSVP призначений тільки для резервування частини пропускної здатності. Використовуючи RSVP, відправник періодично інформує отримувача про вільну кількості ресурсів повідомленням RSVP Path (рисунок 3.4).

Рис. 3.4. Застосування протоколу RSVP

Транзитні маршрутизатори по мірі проходження цього повідомлення також аналізують наявну в них кількість вільних ресурсів і підтверджують його відповідним повідомленням RSVP Resv, що передається у зворотному напрямку. Якщо ресурсів достатньо, то відправник починає передачу. Якщо ресурсів не досить, одержувач повинен знизити вимоги або припинити передачу інформації [12].

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

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

RSVP має дуже хороші перспективи на корпоративному рівні, де адміністратор має можливість визначити, які параметри маршрутизатор буде використовувати для обслуговування запитів про надання QoS. У глобальних мережах маршрутизатори зовсім не обов'язково перебувають під тією ж юрисдикцією, що і хости і додатки, що виробляють запити, що ускладнює гарантування QoS.

Забезпечення якості IP-телефонії на базі MPLS

Конкурентом DiffServ (Differentiated Services) на роль протоколу для забезпечення QoS є інший проект IETF під назвою “Багатопротокольна комутація міток” (Multiprotocol Label Switching, MPLS). При IP-комутації вузол аналізує перші кілька пакетів, які надходять у трафік і, у випадку короткої посилки, наприклад запиту DNS або SNMP, обробляє їх як звичайний маршрутизатор. Але якщо вузол ідентифікує тривалий потік - від трафіку telnet або ftp до завантаження файлів через Web і мультимедійних додатків, то IP-комутатор переключається на нижче лежачу структуру ATM.

IP-комутація підтримує різні рівні QoS і може використовувати ATM, який має численні вбудовані засоби підтримки QoS, і RSVP. Якщо DiffServ задіює заголовок DS, вже наявний у пакетах IPv4, то MPLS використовує 32-розрядну інформаційну мітку, що додається до кожного IP-пакету. Ця мітка, яка добавляється при вході в мережу з підтримкою MPLS, повідомляє кожного маршрутизатора уздовж шляху, як треба обробляти пакет. Зокрема, вона містить інформацію про необхідний, для даного пакету, рівень QoS.

У звичайній ситуації маршрутизатори аналізують заголовок пакету для визначення його адресата. Зважаючи на те, що такий аналіз проводиться на кожному транзитному вузлі незалежно, передбачити, яким маршрутом буде слідувати пакет, практично неможливо, тому забезпечення гарантованого рівня QoS виявляється неймовірно складним завданням [13].

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

Слід зазначити, що DiffServ функціонує на третьому рівні, a MPLS - на другому, тому з технічної точки зору обидві технології можуть мирно існувати одна з одною. Як вже згадувалося, DiffServ класифікує пакети при їх надходженні на крайовий маршрутизатор, тому даний стандарт, швидше за все, буде використовуватися на кордоні мережі, наприклад, між компанією та її сервіс-провайдером. Зважаючи на те, що MPLS передбачає включення додаткових позначок і використання маршрутизаторів/комутаторів, здатних інтерпретувати цю інформацію, він, ймовірно, знайде застосування виключно всередині корпоративних мереж або базовій мережі оператора, де вимагається високий рівень QoS для ІР-трафіку.

Якщо DiffServ вимагає деякої настройки мережевих маршрутизаторів, то MPLS передбачає більш серйозну модернізацію, щоб маршрутизатори могли читати мітки і направляти пакети по конкретних маршрутах. В даний час DiffServ користується більш широкою увагою, і він ближче до остаточної стандартизації, ніж MPLS. Однак кожна з технологій має свої переваги у конкретних областях мережі, тому постачальники, швидше за все, будуть підтримувати їх обидві.

3.3 Загальні принципи сигналізації у мережах ІР-телефонії

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

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

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



Рис. 3.5. Управління викликами в IP-телефонії.

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

На рисунку 3.6. показано місце механізмів сигналізації IP-телефонії в протокольному стеку: над ними знаходяться програми, під ними - транспортні служби IP.

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

Рис. 3.6. Механізми сигналізації IP-телефонії в протокольному стеку

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

Зараз готується наступна версія стандарту. Мова йде і про такі функції,які поширені у сучасній телефонії, включаючи повідомлення про надходження другого дзвінка і режим довідки. Крім “телефонних” функцій, нова версія буде доповнена засобами, що дозволяють враховувати параметри сеансів для цілей тарифікації, а також підтримкою каталогів - замість цифрових IP-адрес можна буде користуватися іменами абонентів. Для виконання дій сигналізації між шлюзами і gatekeeper у відповідності з Рекомендацією МСЕ-Т Н.323 повинні використовуватися наступні протоколи: сигналізація RAS (Registration, Admission, Status); сигналізація Q.931 (згідно Н.225.0); протокол управління Н.245.

Протокол сигналізації RAS (реєстрації, підтвердження і стану) застосовується для передачі службових повідомлень між терміналами і контролером зони Н.323. RAS-повідомлення служать для реєстрації терміналів, допуску їх до сеансу зв'язку, зміни використовуваної смуги пропускання, інформування про стан сеансу і його припинення. При відсутності контролера зони (gatekeeper), протокол RAS не задіюється. Функції сигналізації RAS використовують повідомлення протоколу Н.225.0. Канал сигналізації RAS не залежить від каналу управління викликом і каналу управління Н.245.

Стандарт Н.225 описує протоколи сигналізації і формування пакетів в системах пакетної передачі мультимедійного трафіку. Канал управління викликами Н.225.0 використовується для встановлення і розриву з'єднань між двома терміналами Н.323, а також між терміналом і шлюзом. Службові повідомлення цього протоколу передаються поверх TCP або UDP. Відповідний механізм Н.225.0 заснований на протоколі Q.931, який був розроблений для мереж ISDN. Він забезпечує надання цілого ряду додаткових видів обслуговування і можливість взаємодії з мережами, що базуються на комутації каналів. Канал керування викликом не залежить від каналу RAS і каналу управління Н.245. Протокол управління мультимедійною передачею Н.245 забезпечує: узгодження можливостей компонентів; встановлення та розрив логічних каналів; передачу запитів на встановлення пріоритету; управління потоком (завантаженням каналу); передачу загальних команд та індикаторів. За допомогою сигналізації Q.931 згідно рекомендації МСЕ-Т Н.225.0 та протоколу управління Н.245 повинна здійснюватися: передача запиту на встановлення з'єднання; ініціалізація з'єднання і обмін інформацією про можливості; встановлення з'єднання для передачі мовної інформації; роз'єднання з'єднання [14].

2) Протокол SIP (описаний в RFC 2543) є досить молодим рішенням, покликаний позбутися від складності та інших недоліків основоположника мереж IP-телефонії - H.323. SIP являє собою текст орієнтований протокол, який є частиною глобальної архітектури мультимедіа, розробленої комітетом IETF. Ця архітектура так само включає в себе протокол резервування ресурсів (RSVP - Resource Reservation Protocol, RFC 2205), транспортний протокол реального часу (RTP - Real-Time Transport Protocol, RFC 1889), протокол передачі потоків у реальному часі (RTSP - Real-Time Streaming Protocol, RFC 2326), протокол опису параметрів зв'язку (SDP - Session Description Protocol, RFC 2327), протокол повідомлення про зв'язок (SAP - Session Announcement Protocol). Однак функції протоколу SIP не залежать від будь-якого з цих протоколів. Слід зазначити, що хоча на сьогодні найбільш широке поширення отримав протокол H.323, все більша кількість виробників намагається передбачити у своїх нових продуктах підтримку протоколу SIP. Підхід SIP до побудови мереж IP-телефонії набагато простіше в реалізації, ніж H.323, але менше підходить для організації взаємодії з телефонними мережами. В основному це пов'язано з тим, що протокол сигналізації SIP, що базується на протоколі HTTP, погано узгоджується з системами сигналізації, що використовуються в ТфЗК. Тому протокол SIP більше підходить постачальникам послуг Internet для надання послуг IP-телефонії, причому ця послуга буде всього лише частиною пакету послуг.

3) Базуючись на стандарті Н.323 для IP-мережі, специфікація TIPHON доповнює його деякими обов'язковими процедурами, а також механізмами взаємодії з мережами комутації каналів. Функціональна модель TIPHON складається з тих же компонентів - gatekeeper, шлюзу і терміналу, - що і модель Н.323, однак у ній передбачено поділ шлюзу на три функціональних об'єкта. Це шлюз сигналізації (SG - Signalling Gateway), транспортний шлюз (MG - Media Gateway) і контролер транспортного шлюзу (MGC - Media Gateway Controller) (рисунок 3.7).

Шлюз сигналізації служить проміжною ланкою сигналізації між мережами з пакетною і канальної комутацією. У завдання транспортного шлюзу входить перетворення та/або перекодування інформації, що передається; він забезпечує термінування ІКМ-трафіку телефонних мереж і пакетного трафіку, транслює адреси, пригнічує ехо, відтворює різні повідомлення для абонентів, приймає і передає цифри кодом DTMF. Контролер сигналізації MGC виконує процедури сигналізації Н.323, які визначені в рекомендаціях Н.323, Н.225 (RAS і Q.931) і Н.245, і перетворює повідомлення сигналізації телефонних мереж в повідомлення сигналізації Н.323. Основне його завдання - керувати роботою транспортного шлюзу, тобто здійснювати контроль за з'єднаннями, використанням ресурсів, трансляцією протоколів.

Рис. 3.7. Функціональна модель мережі по проекту TIPHON

Міжмережева взаємодія. При впровадженні систем IP-телефонії часто необхідно вирішувати завдання по забезпеченню ефективної взаємодії мереж різних операторів. Тут існує маса проблем, пов'язаних з перетворенням адрес між адміністративними доменами, взаєморозрахунками між операторами, контролем доступу до ресурсів мережі, захистом внутрішньої топології. У третій версії рекомендацій Н.323 з'явився додаток G до Н.225. У ньому описаний метод взаємодії адміністративних доменів за допомогою об'єкту. Цей функціональний елемент підтримує відкритий доступ до адміністративного домену для доведення виклику, до вхідного в цей домен сайту або надання інших послуг. Подібні функції міжмережевох взаємодії реалізовані і в проекті TIPHON. На малюнку 3.5 показаний приклад передачі сигнальної інформації між терміналом і шлюзом, розташованими в різних адміністративних доменах.



Рис. 3.5. Приклад взаємодії двох доменів

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

Розділ ІV. Протокол встановлення сесії(SIP)

4.1 Проект протоколу

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

Протокол почав розроблятися в 1996 році Хенінгом Шулзрі (Henning Schulzrinne, Колумбійський університет) і Марком Хендлі (UCL). У листопаді 2000 року SIP був затверджений як сигнальний протокол проекту 3GPP і постійний елемент архітектури 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 не обмежені голосовим зв'язком, вони можуть обслуговувати будь-який сеанс зв'язку, від голосового до відеосеансу або майбутні види зв'язку.

Протокол ініціювання сеансів -- 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.

4.2 Можливості протоколу 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: user@host.com). Ідентифікатором хоста може слугувати його IP-адреса, домен або ім'я хоста (IP-адреса визначається з використанням DNS, так що в результаті все одно виходить звернення за адресою sip: ім'я @ 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: Bohdan@site.ua.

sip: user1@192.168.0.215

sip: 387-75-47@sip-gateway.com.ua

Структура протоколу 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, який створює свою власну транзакцію, але виконує свої функції щодо скасовуємо транзакції