Основна проблема IP-мереж - якість обслуговування при транзиті трафіку реального часу. IP-протокол не потребує встановлення з'єднання. Його базовий принцип полягає в тому, що зв'язність (connectivity) є фундаментальний атрибут мережі, що дозволяє будь-якому абонентові здійснювати комунікацію з будь-яким іншим абонентом без процедури встановлення з'єднання, резервування ресурсів на транзитних комутаторах і т.д. Проте це означає, що додатки, засновані на IP, не повинні залежати від варіації затримок при передачі пакетів. Для HTTP-протоколу не важливо, викачується веб-сторінка п'ять або п'ятнадцять секунд.
Для голосового трафіку варіація затримки навіть критичніша, ніж втрата пакетів. Пропажа одного або декількох пакетів з короткими голосовими фрагментами може бути компенсована алгоритмом кодека за допомогою адаптивної екстраполяції. Врешті-решт, пропажа ланцюжка фрагментів сприймається вухом лише як клацання. А ось варіація затримки приводить до запізнювання і плавання звуку, що заважає розмовляти. З того ж фундаментального принципу IP виходить, що транзитний шлях кожного конкретного пакету може бути разним. Отже виникає ще і проблема переупорядковування пакетів.
.
Щоб вирішити загальні проблеми якості обслуговування в IP, прикладалися колосальні зусилля. Були розроблені механізми попередження і управління перевантаженнями транзитних комутаторів і диференціації класів IP-трафіку. Але для забезпечення крізного контролю якості від джерела до приймача їх опинилося недостатньо. В результаті був розроблений протокол резервування ресурсів для контролю якості обслуговування (RSVP).
Він є протоколом сигналізації всім транзитним комутаторам про резервування ресурсів для передачі високопріоритетного трафіку і виконує дві функції: визначення оптимального (з погляду якості обслуговування) шляху від джерела до приймача і резервування необхідних ресурсів. Поява цього механізму фактично означає повернення до принципу попередньої сигналізації і встановлення з'єднання із заданими параметрами, як це і відбувається в мережах традиційної телефонії і успадкованих пакетних мережах.
.
Інша проблема IP - надмірність заголовків. Є таке поняття, як «затримка на пакетізацию голоси». Це час, використовуваний для заповнення пакету оцифрованими голосовими фрагментами. Чим воно більше, тим більше голосових фрагментів можна упакувати в пакет і тим ефективніше використання смуги пропускання. Проте абсолютна величина цієї затримки обмежена. Якщо сумарна затримка в мережі телефонії перевищує 50 мс, виникає луна-ефект і повинні застосовуватися алгоритми ехоподавленія. При розробці АТМ було встановлено, що розмір корисного простору осередку (payload), рівний 32 октетам, приводить до затримки пакетізациі в 15 мс, що дозволяє обійтися без ехоподавленія.
Проте найбільша ефективність заповнення осередку (з урахуванням того, що АТМ-ЗАГОЛОВОК містить всього п'ять октетів), а значить, і ефективність використання смуги пропускання досягається при 64 октетах. Після довгих суперечок ITU-T схвалив фіксований корисний розмір осередку, рівний 48 октетам, що є середнім арифметичним між швидкістю і ефективністю.
.
Заголовок IP-пакету складає 24 октети. Існує також заголовок другого рівня моделі OSI. Це означає, що для адекватного використання смуги необхідно збільшити ефективний простір пакету мінімум в п'ять разів. Крім того, має місце затримка транзитної передачі по мережі. У реальному житті IP-телефонія з прийнятним рівнем якості живе при загальній затримці в 200-250 мс (хоча деякі вмудряються розмовляти і при 400-500 мс) завдяки застосуванню механізмів ехоподавленія і розумних кодеків. Проте, це приводить до значного об'єму непотрібного трафіку, та і якість не зовсім комерційна.
Для передачі мультимедіа-дані був розроблений протокол RTP/RTCP (Real Time (Control) Protocol), що забезпечує визначення типу трафіку, секвенсированіє, тимчасові мітки фрагментів, синхронізацію і контроль передачі. RTP працює поверх UDP (це ще плюс 20 октетів заголовків). Механізм такий: спочатку, використовуючи протокол TCP, посилається сигнал виклику. Абонент підтверджує з'єднання (знімає трубку), встановлюється контрольне з'єднання (RTCP) і відкривається декілька UDP сесій для передачі RTP-трафіку.
.
Щоб уникнути надмірності заголовків, була розроблена технологія компресії заголовків CRTP, що дозволяє скоротити їх розмір в середньому до 2-4 октетів при передачі RTP-трафіку. Принцип компресії заголовків придуманий Ван Якобсоном на зорі розвитку IP-стека і заснований на тому, що після встановлення з'єднання службова інформація заголовків вже не потрібна, якщо дві системи домовилися про параметри з'єднання. Алгоритм Ван Якобсона, описаний в RFC 1144, застосовний для протоколу TCP, орієнтованого на встановлення з'єднання. CRTP - більш просунута технологія, що забезпечує компресію IP/UDP/RTP-заголовков.
Ідея полягає в тому, що для обміну контекстом компресії (статичною інформацією, що міститься в заголовках початкових інкапсуляцій, інформацією про синхронізацію і т.п. ) виділяється спеціальне TCP-з'єднання. Проте, протокол CRTP не вирішив всіх проблем, пов'язаних з надмірністю заголовків. На з'єднаннях з великою кількістю транзитних вузлів (маршрутизаторів), а також на повільних або переобтяжених каналах виникли проблеми масштабованості.
Кожен втрачений в дорозі компрессированний пакет вимушує приймач скидати і перезапрашивать цілу ланцюжок, оскільки контекст компресії рассинхронізіруєтся на час всього циклу шляху (round-trip-time - час проходження пакету туди і назад). Тому застосування CRTP часто обмежене двома сусідніми маршрутизаторами, сполученими прямими каналами. Крім того, реалізація CRTP вимагає великих обчислювальних ресурсів.
.
0 Відгуків на “Проблеми IP-телефонії і методи їх рішення”
Залишити відгук