Безперервне зростання Internet і приватних мереж висуває нові вимоги до пропускної здатності. World Wide Web привів до гігантського збільшення трафіку графічної інформації. Сьогодні ще і голосові, а також відеопріложенія висувають свої специфічні вимоги до і без того перевантажених мереж.
Щоб задовольнити всі ці запити, одного збільшення ємності мережі недостатньо. Що дійсно необхідно, так це розумні ефективні методи управління трафіком і контроль завантаженості.
Історично мережі на базі IP надавали всіх програм тільки найпростішу послугу з доставки даних у міру можливості. Однак потреби змінилися з часом. Організації, витратили мільйони доларів на встановлення мережі на базі IP для передачі даних між локальними мережами, тепер стикаються з тим, що такі конфігурації не здатні ефективно підтримувати нові мультимедійні додатки реального часу з багатоадресної розсилкою.
ATM - єдина мережева технологія, спочатку розроблялася для підтримки звичайного трафіку TCP і UDP поряд з трафіком реального часу. Однак орієнтація на ATM означає або створення нової мережевої інфраструктури для трафіку реального часу, або заміну наявної конфігурації на базі IP, причому обидві альтернативи обойдутсявесьма недешево.
Тому потреба в підтримці декількох типів трафіку з різними вимогами до якості послуг у рамках архітектури TCP/IP вельми насущна. Це завдання покликані вирішити два ключових інструменту: транспортний протокол реального часу (Real-Time Transport Protocol, RTP) і протокол резервування ресурсів (Resource Reservation Protocol, RSVP).
RTP гарантує доставку даних одному або більше одержувачам з затримкою в заданих межах. Це означає, що дані можуть бути відтворені у реальному часі. RSVP дозволяє кінцевим системам резервувати мережеві ресурси для отримання необхідної якості послуг, особливо ресурси для трафіку реального часу по протоколу RTP.
Найбільш широко використовуваний протокол транспортного рівня - це TCP. Незважаючи на те що TCP дозволяє підтримувати безліч різноманітних розподілених додатків, що він не підходить для додатків реального часу.
У додатках реального часу відправник генерує потік даних з постійною швидкістю, а одержувач (-и) повинен надавати ці дані з додатком з тією ж самою швидкістю. Такі програми включають аудіо-та відео-конференції, поширення живого відео (для негайного відтворення), колективні робочі області, віддалену діагностику в медицині, комп'ютерну телефонію, розподілене інтерактивне моделювання, ігри та моніторинг у реальному часі.
Використання TCP в якості транспортного протоколу для цих додатків неможливо з кількох причин. По-перше, цей протокол дозволяє встановити з'єднання тільки між двома кінцевими точками, отже, він не підходить для багатоадресної передачі. Він передбачає повторну передачу втрачених сегментів, що прибувають, коли програма реального часу вже їх не чекає. Крім того, у TCP немає зручного механізму прив'язки інформації про синхронізацію до сегментів - інша вимога додатків реального часу.
Інший широко використовуваний протокол транспортного рівня UDP не має перших двох обмежень (з'єднання точка-точка і передача втрачених сегментів), але і він не надає критичної інформації про синхронізацію. Таким чином, UDP не надає сам по собі жодних інструментів загального призначення для додатків реального часу.
Попри те, що кожен додаток реального часу може мати свої власні механізми для підтримки передачі в реальному часі, вони мають багато спільних рис, а це робить визначення єдиного протоколу досить бажаним. Стандартний протокол такого роду - RTP, визначений у RFC1889.
У типової середовищі реального часу відправник генерує пакети з постійною швидкістю. Вони відправляються ним через однакові інтервали часу, проходять через мережу і приймаються одержувачем, що відтворює дані в реальному часі по їх отриманні.
Однак з огляду на варіації затримки при передачі пакетів по мережі вони прибувають через нерегулярні проміжки часу. Для компенсації цього ефекту надходять пакети буферизує, дотримуються на деякий час і потім надаються з постійною швидкістю програмного забезпечення, що генерує висновок. Щоб така схема працювала, кожен пакет отримує позначку про час - таким чином одержувач може відтворити дані, що надходять з тією ж швидкістю, що відправника.
RTP підтримує передачу даних в реальному часі між кількома учасниками сеансу. (Сеанс - це логічний зв'язок між двома і більше користувачами RTP, підтримувана протягом усього часу передачі даних. Процес відкриття сеансу виходить за рамки RTP.).
Хоча RTP може використовуватися і для одноадресних передачі в реальному часі, його сила в підтримці багатоадресної передачі. Для цього кожен блок даних RTP містить ідентифікатор відправника, який вказує, хто з учасників генерує дані. Блоки даних RTP містять також відмітку про час, щоб дані могли бути відтворені з правильними інтервалами приймаючою стороною.
Крім того, RTP визначає формат корисного навантаження переданих даних. З цим безпосередньо пов'язана концепція синхронізації, за яку частково відповідає мікшер - механізм трансляції RTP. Приймаючи потоки пакетів RTP від одного або більше джерел, він комбінує їх і посилає новий потік пакетів RTP одному або більше одержувачам. Мікшер може просто комбінувати дані, а також змінювати їх формат.
Приклад програми для мікшери - комбінування декількох джерел звуку. Наприклад, припустимо, що частина систем даного аудіосеанса генерує кожна свій власний потік RTP. Велику частину часу тільки одне джерело активний, хоча час від часу одночасно "говорять" кілька джерел.
Якщо нова система хоче взяти участь у сеансі, але її канал до мережі не має достатньої ємності для підтримки всіх потоків RTP, то мікшер отримує всі ці потоки, об'єднує їх в один і передає останній новому члену сеансу. При отриманні декількох потоків мікшер просто складає значення імпульсно-кодової модуляції. Заголовок RTP, що генерується мікшери, включає ідентифікатор (-и) відправника (-ів), чиї дані присутні в пакеті.
Більш простий пристрій створює один вихідний пакет RTP для кожного вступника пакету RTP. Цей механізм, званий транслятором, може змінити формат даних в пакеті або використовувати інший комплект низькорівневих протоколів для передачі даних з одного домену в іншій. Наприклад, потенційний одержувач може виявитися не в змозі обробляти високошвидкісний відеосигнал, що використовується іншими учасниками сеансу. Транслятор конвертує відео у формат більш низької якості, який вимагає не такої високої швидкості передачі даних.
Протокол RTP використовується тільки для передачі призначених для користувача даних - зазвичай багатоадресної - всім учасникам сеансу. Окремий протокол управління передачею в реальному часі (Real-Time Transport Control Protocol, RTCP) працює з кількома адресатами для забезпечення зворотного зв'язку з відправниками даних RTP та іншими учасниками сеансу.
RTCP використовує той же самий базовий транспортний протокол, що і RTP (зазвичай UDP), але інший номер порту. Кожен учасник сеансу періодично посилає RTCP-пакет всім іншим учасникам сеансу. RFC 1889 описує три функції, які виконуються RTCP.
Перша функція полягає у забезпеченні якості послуг і зворотного зв'язку у разі перевантаження. Так як RTCP-пакети є багатоадресної, всі учасники сеансу можуть оцінити, наскільки гарні робота і прийом інших учасників. Повідомлення відправника дозволяють одержувачам оцінити швидкість даних і якість передачі. Повідомлення одержувачів містять інформацію про проблеми, з якими вони стикаються, включаючи втрату пакетів і надлишкову нерівномірність передачі. Наприклад, швидкість передачі для аудіо/відеопріложенія може бути знижена, якщо лінія не забезпечує бажаної якості послуг при даній швидкості передачі.
Зворотній зв'язок з одержувачами важлива також для діагностування помилок при розповсюдженні. Аналізуючи повідомлення всіх учасників сеансу, адміністратор мережі може визначити, чи стосується дана проблема одного учасника або носить загальний характер.
Друга основна функція RTCP - ідентифікація відправника. Пакети RTCP містять стандартне текстовий опис відправника. Вони надають більше інформації про відправника пакетів даних, ніж випадковим чином вибраний ідентифікатор джерела синхронізації. Крім того, вони допомагають користувачеві ідентифікувати потоки, що відносяться до різних сеансів. Наприклад, вони дають користувачеві можливість визначити, що одночасно відкриті окремі сеанси для аудіо і відео.
Третя функція полягає в оцінці розмірів сеансу і мастшабірованіі. Для забезпечення якості послуг і зворотного зв'язку з метою управління завантаженістю, а також з метою ідентифікації відправника, всі учасники періодично посилають пакети RTCP. Частота передачі цих пакетів знижується з ростом числа учасників.
При невеликому числі учасників один пакет RTCP надсилається максимум кожні 5 секунд. RFC 1889 описує алгоритм, згідно з яким учасники обмежують частоту RTCP-пакетів в залежності від загального числа учасників. Мета полягає в тому, щоб трафік RTCP не перевищував 5% від загального трафіку сеансу.
Призначення будь-якої мережі полягає в доставці даних одержувачем з гарантованою якістю послуг, що включають пропускну здатність, затримку і допустима межа варіації затримки. З ростом числа користувачів та програм забезпечити якість послуг стає все важче
Просто реагувати на перевантаження вже недостатньо. Необхідний інструмент, за допомогою якого перевантажень можна було б уникнути взагалі, тобто зробити так, щоб програми могли резервувати мережеві ресурси відповідно до необхідного якістю послуг.
Превентивні заходи корисні як при одноадресних, так і при багатоадресної передачі. При одноадресних передачу два додатки домовляються про конкретний рівні якості послуг протягом поточної сесії. Якщо мережа сильно завантажена, то вона може виявитися не в змозі надати послуги необхідної якості. У цьому випадку додаткам доведеться відкласти сеанс до кращих часів або спробувати знизити вимоги до якості послуг, якщо це можливо.
Рішення в даному випадку полягає в резервування одноадресних додатками ресурсів для забезпечення необхідного рівня послуг. Тоді маршрутизатори на передбачуваному шляху виділяють ресурси, наприклад місце в черзі і частину ємності вихідної лінії. Якщо маршрутизатор не має можливості виділити ресурси внаслідок раніше взятих на себе зобов'язань, то він повідомляє про це додаток. У цьому випадку додаток може спробувати ініціювати другий сеанс з меншими вимогами до якості послуг або перенести його на більш пізній термін.
Багато адресна розсилка ставить набагато більш складні завдання з резервування ресурсів. Вона веде до створення величезних обсягів мережевого трафіку у випадку, наприклад, таких додатків, як відео, або великий і розосередження групи одержувачів. Однак трафік від джерела під LGPL може бути в принципі значно знижений.
Для цього є дві причини. По-перше, деякі члени групи можуть не мати потребу в доставці даних від конкретного джерела в певний період часу. Наприклад, члени однієї групи можуть отримувати інформацію одночасно по двох каналах (від двох джерел), але при цьому одержувач може бути зацікавлений у прийомі тільки одного каналу.
Багатоадресної трафік можна знизити і внаслідок того, що деякі члени групи в змозі обробляти тільки частина передається відправником інформації. Наприклад, відеопотік може складатися з двох компонентів: один з низькою якістю картинки, а інший - з високим. Такий формат має ряд алгоритмів стиснення відео: вони генерують базовий компонент з картинкою низької якості і додатковий компонент з підвищеним дозволом.
Деякі одержувачі можуть не мати достатньої обчислювальної потужності для обробки компонентів з високою роздільною здатністю або бути підключені до мережі через підмережа або канал, що не мають достатньої ємності, щоб пропустити повний сигнал.
Резервування ресурсів дозволяє маршрутизаторам заздалегідь визначити, чи в змозі вони здійснити доставку багатоадресного трафіку всім одержувачам.
У попередніх спробах реалізації резервування ресурсів і в прийнятих під frame relay і ATM підходах необхідні ресурси запитує джерело потоку даних. Цей метод достатній у разі одноадресних передачі, тому що передавальний додаток передає дані в певному темпі, а необхідні рівень якості послуг закладений у схему передачі.
Однак такий підхід не можна використовувати для під LGPL. У різних членів групи можуть бути неоднакові вимоги до ресурсів. Якщо вихідний потік може бути розділений на подпотокі, то деякі члени групи, цілком можливо, побажають отримувати тільки один з них. Наприклад, деякі одержувачі можуть бути в змозі обробляти тільки компонент відеосигналу низького дозволу. Або якщо декілька відправників ведуть мовлення на одну групу, то одержувач може вибрати лише одного відправника або якийсь їх підмножина. Нарешті, вимоги різних одержувачів до якості послуг можуть змінюватися залежно від устаткування висновку, потужності процесора і швидкості каналу.
З цієї причини резервування ресурсів одержувачем представляється кращим. Відправники можуть надати маршрутизаторам загальні характеристики трафіку (наприклад, темп передачі даних і варіабельність), але одержувачі повинні самі визначити необхідний рівень якості послуг. Маршрутизатори зводять потім воєдино запити на виділення ресурсів на спільних ділянках дерева розповсюдження.
В основі RSVP лежать три концепції, що стосуються потоків даних: сеанс, специфікація потоку і специфікація фільтра. Сеанс - це потік даних, ідентифікований по адресату. Відзначимо, що ця концепція відрізняється від концепції сеансу RTP, хоча сеанси RSVP і RTP можуть мати взаімооднозначное відповідність. Після резервування маршрутизатором ресурсів для конкретного адресата він розглядає це як початок сеансу і виділяє ресурси на час цього сеансу.
Запит на резервування від кінцевої системи-одержувача, званий описувачем потоку, що складається з специфікацій потоку і фільтра. Специфікація потоку визначає необхідну якість послуг і використовується вузлом для завдання параметрів планувальника пакетів. Маршрутизатор передає пакети з заданим набором переваг, спираючись на поточну специфікацію потоку.
Специфікація фільтра визначає набір пакетів, під які запрошуються ресурси. Разом з сеансом вона визначає набір пакетів (або потік), для яких необхідну якість послуг має бути забезпечене. Будь-які інші пакети, що направляються цьому адресатові, обробляються остільки, оскільки мережа в змозі це зробити.
RSVP не визначає зміст специфікації потоку, він просто передає запит. Специфікація потоку включає зазвичай клас послуг, Rspec (R означає резерв) і Tspec (Т означає трафік). Два інші параметри представляють собою набір чисел. Параметр Rspec визначає необхідну якість послуг, а параметр Tspec описує потік даних. Вміст Rspec і Tspec прозоро для RSVP
У принципі специфікація фільтра описує довільна підмножина пакетів одного сеансу (тобто пакетів, адресат яких визначається цим сеансом). Наприклад, специфікація фільтра може визначати тільки конкретних відправників або протоколи або пакети, поля протокольних заголовків яких співпадають з заданими.
З точки зору хоста робота протоколу складається з наступних етапів (перші два етапи в цій послідовності мають іноді зворотний черговість)
1. Одержувач вступає в групу під LGPL допомогою відправки повідомлення по протоколу IGMP сусіднього маршрутизатора.
2. Потенційний відправник надсилає повідомлення на адресу групи.
3. Одержувач приймає повідомлення Path, ідентифікує відправника.
4. Тепер, коли отримувач має інформацію про зворотному шляху, він може відправляти повідомлення Resv з дескриптор потоку.
5. Повідомлення Resv передаються по мережі відправнику.
6. Відправник починаєпередачу даних.
7. Одержувач починає прийом пакетів даних.
Механізм встановлення з'єднання з резервуванням смуги пропускання.
Процедура встановлення з'єднання з резервуванням смуги пропускання проходить наступним чином:
Кінцевий користувач, зацікавлений у передачі чутливого до затримок трафіку, передає в мережу повідомлення із зазначенням інформації про дані, які він збирається передавати (сюди включається IP адреса джерела та номер UDP/TCP порту), а також інформацію про тип трафіку.
Ця інформація застосовується при налагодженні механізмів управління потоком даних у проміжних вузлах мережі для здійснення резервування смуги пропускання, а також для запобігання надлишкового резервування ресурсів для даного типу трафіку.
При проходженні по мережі цей інформаційний пакет "запам'ятовує" маршрут по якому він дійшов до одержувача.
При отриманні інформаційного пакета приймач аналізує його зміст і, в разі своєї зацікавленості в даній інформації, передає в мережу запит на резервування смуги пропускання.
Даний запит, що описує необхідний тип сервісу і мережевого з'єднання, передається по мережі від приймача до передавача за тим самим маршрутом, що і інформаційний пакет.
Кожен проміжний вузол мережі проводить аналіз отриманого запиту на підставі описаних нижче правил.
Якщо отримано запит на встановлення з'єднання з резервуванням ресурсу у вузлі мережі включаються два механізми: контролер ресурсів каналу, який визначає наявність запитуваної ресурсу і контролер доступу, звіряють права даного користувача з отриманим запитом.
Якщо при відпрацюванні обох механізмів був отриманий позитивний результат, то резервування, у даному сайті, вважається встановленим і відповідна інформація передається в модулі, що відповідають за класифікацію потоків і формування вихідних черг.
Якщо ж хоча б один з механізмів повертає негативний результат, то протокол інформує джерело запиту про неможливість його здійснення.
Обробка запиту на встановлення з'єднання з резервуванням ресурсу проходить окремо для кожного типу мережного з'єднання оскільки протокол RSVP здатний розрізняти типи з'єднання.
Тип мережного з'єднання визначається трьома параметрами: IP адреса одержувача, тип протоколу та тип порту призначення.
Якщо отриманий запит задовольняє всім вимогам, то вузол виробляє резервування необхідної смуги пропускання і передає запит далі, в напрямку до передавача.
Як тільки передавач отримує запит на резервування смуги пропускання від приймача з'єднання вважається встановленим і починається обмін інформацією.
Під час сеансу зв'язку приймач і передавач періодично підтверджують подальшу необхідність у здійсненні резервування смуги пропускання шляхом надсилання інформаційних пакетів передавачем і запитів на резервування приймачем.
Вузол мережі в праві припинити резервування смуги пропускання як тільки він не отримує чергового підтвердження від приймача або передавача.
Резервування смуги пропускання так само може бути припинено після передачі приймачем або передавачем запиту на скасування з'єднання.

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

Комп'ютерна телефонія. Термін "комп'ютерна телефонія" (Computer-Telephony Integration, CTI) відноситься до реалізації традиційних аудіо-(іноді і відео-) сервісів в мережі передачі даних. Системи комп'ютерної телефонії можуть бути реалізовані як в мережах з гарантованою пропускною спроможністю (типу ATM), так і в мережах передачі кадрів (типу Ethernet або frame relay).

CIF. Загальний проміжний формат (Common Intermediate Format) з роздільною здатністю 352 пікселів по горизонталі на 288 пікселів по вертикалі є найбільш популярним форматом зображень у відеоконференціях. За меншої пропускної здатності відеосистеми використовують, як правило, або QCIF (Quarter CIF) з роздільною здатністю 176х144 пікселів, або SQCIF (Sub-Quarter CIF) з роздільною здатністю 128х96 пікселів. Відео з високою пропускною здатністю описується форматом 4CIF (704х576 пікселів) або 16CIF (1408х1152 пікселів).

G.711. Один з основних стандартів ITU-T для аудіокодеків (кодувальників-декодувальник голосу і музики). G.711 є частиною більш загальних мультимедійних стандартів, таких як H.320 і H.323, крім того, він використовується в комп'ютерній телефонії і сам по собі. G.711 визначає аудіосигнал з шириною смуги 3,4 КГц (іншими словами, звичайний аналоговий голосовий сигнал) з інформаційних каналах в 64 Кбіт/с. Стандарт G.722 описує аудіопотік з шириною смуги 7,0 КГц по каналу в 64 Кбіт/с, а стандарт G.728 - аудіопотік з шириною смуги 3,4 КГц по каналу в 16 Кбіт/с. Стандарт G.723 визначає передачу комп'ютерної аудиоинформации по узкополостним телефонних лініях. Він описує ущільнений сигнал у 3,4 КГц для звичайних телефонних ліній і використовується в мультимедійному стандарті H.324.

H.233. Стандарт шифрування даних ITU-T для мультимедійної інформації реального часу. H.233 підтримується цілою низкою стандартних служб, у тому числі H.320, H.323 і H.324. Стандарт H.234 визначає, яким чином обробляються ключі шифрування.

H.261. Стандарт ITU-T на кодек із стискуванням відео. Підтримуваний H.320, H.323 і H.324, H.261 сумісний з форматами зображень CIF і QCIF. H.261 розроблявся для О ПРОДАЖУ з ISDN і допускає швидкості передачі даних, кратні 64 Кбіт/с. Новий стандарт H.263 (підтримуваний H.324) підвищує ефективність H.261 і сумісний з зображеннями у форматах SQCIF, 4CIF, 16CIF.

H.320. Один з основних стандартів ITU-T для мультимедіа в реальному часі. H.320 - це стандарт для відеоконференцій у вузькосмугових глобальних мережах з комутацією каналів, таких як ISDN. Він включає специфікації для даних (T.120), голоси (G.711 і G.728), відео (H.261) і шифрування (H.233 і H.234). H.323 є вдосконаленим стандарт H.320 для основних мереж з комутацією пакетів. Споріднені стандарти для мультимедіа реального часу, не розглядаються окремо в цьому словнику, включають H.321 для широкосмугового ISDN та ATM, H.322 для мереж комутації пакетів з гарантованою смугою пропускання і H.310 для мультимедіа високої роздільної здатності поверх ATM.

H.323. В даний час шлюзи і клієнтське програмне забезпечення є здебільшого нестандартними. Якщо обидва компоненти не представлені однією компанією, то, швидше за все, ви не зможете використовувати IP-телефонію для дзвінка іншому абоненту.

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

Але через те, що Н. 323 розроблявся для відеоконференцій, далеко не кожен шлюз і клієнт IP-телефонії підтримує стандарт. Проте ця ситуація поступово змінюється, тому що кількість виробників, що висловлюються на користь стандартів і працюють над їх оптимізацією для IP-телефонії, неухильно зростає. Серед компаній, що заявили про підтримку Н.323, - VocalTec, Clarent, Dialogic, Array Telecom, Micom, Microsoft, Intel, Brooktrout. У вересні 1997 року на конференції "Голос по мережі" в Бостоні виробники з усіх областей ринку IP-телефонії
взяли участь у найбільшій публічної демонстрації інтероперабельності Н. 323.

H.324. Стандарт ITU-T для передачі мультимедіа в реальному часі по звичайних телефонних лініях за допомогою модемів V.34 на 28,8 Кбіт/с або більш швидких. Подібно H.320, H.324 включає стандарт T.120 для розділення даних, стиснення відео за стандартом H.261, а також стандарти шифрування H.233 і H.234. На відміну від H.320, H.324 використовує аудіостандарт G.723.

MMX. За твердженням Intel, акронім "MMX" не має якого-небудь конкретного значення, але зазвичай він розшифровується як "Мультимедійні розширення". Більш конкретно MMX реалізується як набір нових команд для мікропроцесорів Pentium з MMX і Pentium II. Однак MMX займається не тільки Intel: так, наприклад, компанія Advanced Micro Devices, що конкурує виробник процесорів, випустила нове MMX-сумісний сімейство процесорів. Багато нових мультимедійні продукти під Windows для комп'ютерної телефонії та відеоконференцій пишуться з урахуванням переваг нових команд MMX.

RTP. Транспортний протокол реального часу - це стандарт IETF для передачі даних, таких як голос або відео, в реальному часі по пакетної мережі, не гарантує якості послуг. Пов'язані з ним стандарт - протокол управління передачею в реальному часі (Real-Time Transport Control Protocol, RTCP) - обеспечіваетобратную зв'язок між двома пристроями або групою. Такі мультимедійні стандарти ITU-T для мереж без забезпечення якості послуг, як H.323 і H.324, спираються на RTP/RTCP.

T.120. Цей стандарт ITU-T стосується поділу мультимедійних даних по мережі в реальному часі. Він служить базисом для таких додатків, як спільна робота над проектами при двосторонніх або багатосторонніх сеансах. T.120 є складовою частиною деяких стандартів відеоконференцій, наприклад H.320, H.323 і H.324.

РЕЗЮМЕ.
Вчорашні методи роботи з великими обсягами трафіку зовсім не підходить для сучасних систем. Задовольнити зростаючим вимогам до передачі даних у зв'язку із зростанням їх обсягу, розповсюдженням додатків реального часу і під LGPL без нових інструментів неможливо. RTP і RSVP забезпечують надійний фундамент для мереж наступного покоління.