Християн Штредіке
Галас навколо недорогих або зовсім безкоштовних телефонних розмов по internet допомогла остаточно утвердитися S1P як протоколу для передачі голосу по IP. Найбільший інтерес до нього виявляється в сегменті кінцевих користувачів і малих / домашніх офісів (SOHO), тобто в разі телефонних дзвінків по з'єднаннях DSL. Однак і виробники телекомунікаційних систем з підтримкою IP не можуть більше ігнорувати SIP. У статті докладно розповідається про технічний розвиток і зміну стандарту SIP.
Спочатку вважалося, що протокол SIP для передачі голосу по IP розробникам буде реалізувати простіше, ніж усталений, але порівняно складний конкуруючий протокол Н.323. Ці часи давно пройшли. Сьогодні стандарти, пов'язані з SIP, вже налічують понад 2 тис. сторінок, a IETF все ще ретельно стверджує нові запити на коментарі (Requests for Comments, RFC). Мова йде не стільки про основоположні темах, скільки про езотеричних: про транспортний рівні, «політиці сеансів» або просто-напросто про те, яким чином медіа-сервер повинен перехоплювати натискання клавіш і транслювати їх на сервер додатків (див. Малюнок 1).
Для кінцевого користувача такі нюанси навряд чи мають значення, оскільки використовується в повсякденному житті набір функцій має залишатися стабільним. Виробники з області SIP вже настільки добре освоїлися з існуючими стандартами, що продукти різних компаній в основному сумісні один з одним. В областях, де IETF поки ще не встановила остаточного стандарту, часто виробники самі знаходять прагматичні рішення. Приміром, Broadsoft визначила, яким чином має здійснюватися управління світлодіодними індикаторами телефонів і як на телефоні можна прийняти дзвінок з комп'ютера.
Однак стандарт SIP не безперечний, «конкуренція» підтискає з усіх сторін: так, постачальнику Skype вдалося мало не за ніч зайняти ринок безкоштовної Internet-телефонії, та й взагалі створити його. Замість того щоб вплутуватися в дискусії про стандартизацію, інженери Skype віддали перевагу самі творити історію, запропонувавши власний підхід. Та обставина, що при використанні цього методу трафік частково проходить через комп'ютери, які не мають ніякого відношення до беруть участь у розмові користувачам, внаслідок чого доводиться миритися з непереборним ризиком вторгнення в приватну сферу, по всій видимості, нікому не заважає. Для подальшого успіху дуже важливо, чи приймуть цю технологію в якості стандарту такі гравці, як Cisco і Microsoft, - питання поки відкрите. Ще один протокол VoIP, IAX, наробив дуже багато шуму у зв'язку з перспективою появи нового стандарту. У специфікації IAX менше 50 сторінок, і приваблює вона своєю простотою. Натхнене цим фактом спільнота відкритих вихідних кодів, організовані навколо проекту Asterisk, розраховує в зв'язку з цим на появу недорогого обладнання для передачі голосу по IP. Однак мова в разі IAX йде про цілком самостійному протоколі. Стань він розробкою більш великого гравця, обуренню не було б межі. А тепер, як і у випадку зі Skypc, IAX залишається чекати, чи погодяться його прийняти лідери ринку.
NAT: вирішення проблеми
Перетворення мережевих адрес (Network Address Translation, NAT), як і раніше - одна з найважливіших проблем при передачі голосу по IP. В останні роки виробники маршрутизаторів DSL і брандмауерів займалися в першу чергу HTTP і SMTP. Типовим для цих протоколів є те, що дії завжди ініціюються клієнтом: електронна пошта йому ніколи не доставляється - кожні кілька хвилин він сам змушений перевіряти, чи немає на поштовому сервері непрочитаних повідомлень.
У разі телефонії цей підхід більше не працює. Сервер (у Internet) повинен бути в змозі доставити клієнтові (в локальній мережі) повідомлення, що досягається завдяки обмеженню терміну дії реєстрації клієнта, коли тому доводиться реєструватися знову і знову. При цьому заноситься «відмітка» в таблицю NAT, через яку сервер відправляє вхідні повідомлення. Виникає при такому методі «черговий» трафік не варто недооцінювати - на кожного користувача за місяць припадає до 100 Мбайт. Багато операторів швидше змиряться з великою кількістю трафіку, ніж стануть пояснювати своїм клієнтам, як їм слід конфігурувати маршрутизатори.
Проблема NAT вирішується шляхом простого проходження UDP через NAT (Simple Traversal UDP over NAT, STUN). Цей стандарт (RFC 3489) дозволяє кінцевим пристроям у мережі «поглянути на себе в дзеркало» за допомогою зовнішнього сервера і таким чином забезпечити правильну відповідність загальнодоступних і локальних IP-адрес. Однак STUN функціонує не у всіх випадках: якщо брандмауер використовує так звану симетричне перетворення NAT, то кінцевий пристрій стає досяжним через Internet тільки з сервера STUN, а пакети іншого походження, наприклад від IP-телефонів, не пропускаються. STUN працює в багатьох середовищах, проте успішне застосування цього протоколу, на жаль, залишається справою випадку.
Новий інфраструктурний компонент для операторських мереж, який вирішує проблему симетричної трансляції NAT, називається прикордонним контролером сеансів (Session Border Controller, SBC). Спочатку він був оцінений IETF як «невдалий», проте пізніше стало ясно, що без пего, на жаль, не обійтися. Завдяки SBC переважна більшість абонентів Internet-телефонії можуть користуватися своєю IP-телефоном без необхідності внесення будь-яких змін в маршрутизатор або кінцевий пристрій (див. Малюнок 2). Поряд з вирішенням проблеми NAT контролер SBC дозволяє, наприклад, операторам переривати розмову, коли кошти на рахунку клієнта минули. Крім того, з його введенням вирішується і проблема фрагментації UDP, коли маршрутизатор не може коректно переправляти дуже великі пакети. Оскільки SBC не дає повної інформації про маршрутизації, пакети звичайно настільки малі, що труднощів не виникає. Для оператора така технологія привносить цікавий побічний ефект: коли клієнти не бачать інформації про маршрутизації, вони не можуть напряму зв'язатися зі співрозмовником і обійти при цьому оператора і пов'язаний з цим біллінг.
QOS: береги поки не видно
Коли мова йде про передачу голосу по IP в межах корпоративних мереж, належна якість послуг (Quality of Service, QoS) мається на увазі саме собою. Це твердження справедливо також стосовно до різних пропозицій операторів і провайдерів для відповідних сполук через глобальну мережу. Інакше виглядає ситуація в області SOHO, де у користувачів також є бажання долучитися до Inlernet-телефонії за недорогими сполукам DSL. Локальний маршрутизатор DSL в стані сортувати залишають локальну мережу пакети по вихідним черг у відповідності з QoS, однак зворотний напрямок контролює провайдер.
З досвіду Німеччини можна сказати, що ситуація в цій області залишає бажати кращого, оскільки відповідне біти QoS, як правило, ігноруються. Набагато частіше оператор надає пакетів TCP більш високий пріоритет, ніж UDP. На жаль, завантаження в більшості випадків відбувається з TCP, і тому вона може помітно заважати паралельним телефонних розмов по IP. На даний момент існують два рішення цієї проблеми. Перше полягає у виборі провайдера, який пропонує QoS. При використанні SBC він здатний забезпечить правильну сортування пакетів, навіть якщо вхідні пакети VoIP не марковані бітами QoS. Друге, швидше прагматичне, рішення полягає в тому, щоб орендувати другий канал DSL і фізично розділити голос і дані. Цей варіант функціонує дуже добре, і при комерційному використанні часто виправдовує себе економічно.
Безпека: стара тема на новий лад
З зростаючої привабливістю телефонії на базі Internet виникають схожі проблеми, пов'язані з безпекою, як і в інших областях комунікацій по IP: мова йде про спам, хакерських атаках і спробах прослуховування. За аналогією з «сміттєвої» поштою спостерігається справжня хвиля «бур'янистих» дзвінків: снам по Internet-телефонії (Spam via Internet-Telephony, SPIT). Пошукова машина Google видає вже понад 130 тис. збігів але темі «снам і SPIT». Принцип простий: коли телефонні дзвінки безкоштовні, «Спітері» можуть запустити з будь-якої частини Internet мільйони дзвінків, і ті, хто їх приймає, чують, що виграли, наприклад, подорож на південь Тихого океану. Цільові адреси отримати досить просто, випробувавши всі номери, що надаються провайдером його клієнтам.
Заходи протидії відомі по боротьбі з традиційним спамом. По-перше, оператори починають вести так звані «білі списки». Як правило, вони охоплюють адресний потенціал партнерів-операторів. У випадку дзвінка з Internet від третьої сторони він відхиляється. По-друге, складаються і «чорні списки», які містять дані про клієнтів, що розсилають SPIT, що може відбуватися і автоматично, коли клієнт ініціює більше дзвінків, ніж в змозі це зробити.
По всій видимості, справа дійшла до перших вірусних дзвінків, містять маніпульований пакет даних: хоча він і не призводить до відмови всієї системи, але за допомогою відповідного програмного коду перетвориться на слухняного робота, який по команді перетворюється, наприклад, в Подслушивающий жучок. У таких випадках рекомендується поінформувати як виробника кінцевого пристрою, так і провайдера. Для запобігання подібних атак в майбутньому існує достатня кількість технічних можливостей.
Поряд з так званими атаками DoS (до них відноситься і SPIT) важливу роль відіграє захист приватної сфери, для чого використовуються методи, аналогічні тим, що специфіковані в HTTP. Анало-ГВМ HTTPS є SIPS, «захищений» стандарт SIP. Як і у випадку HTTPS, для ідентифікації учасників служать сертифікати, вони представляють базис для узгодження необхідного ключа. Відповідним чином SRTP є доповненням протоколу передачі даних в реальному часі (Real Time Transport Protocol, RTP), причому використовується шифрування AES з довжиною ключа 128 біт. Обмін ключами відбувається за допомогою SIPS. На даний момент дискусія про коректну формулюванні стандарту ще не закінчена, проте всі питання повинні бути вирішені найближчими місяцями, і за допомогою SIPS і SRTP буде можливим повноцінне шифрування переговорів.
Зауважимо, що згадані прикордонні контролери сеансів у разі SIPS і SRTP можуть розшифровувати переговори. З точки зору провайдерів, це дуже зручно, оскільки за рішенням судів іноді вони змушені прослуховувати деякі з'єднання, а ось кінцевому користувачеві це навряд чи сподобається. Тому за аналогією з електронною поштою в області SIP було визначено S / MIME для наскрізного шифрування, в результаті чого оператор не зможе прослуховувати розмови. Правда, виникає питання, чи погодяться законодавчі органи терпіти наскрізне шифрування перед обличчям терористичних загроз, адже власника proxy-сервера (та ще й розташованого за кордоном) прослухати практично неможливо.
SIP в офісі
SIP набув поширення насамперед у галузі кінцевих користувачів і при підключенні невеликих і домашніх офісів. Однак рішення VoIP для корпоративної області, де до цих пір часто зустрічаються нестандартні технології, дають підстави вважати, що SIP і тут буде відігравати більш важливу роль. В області телекомунікаційних систем на базі SIP повідомлення про прогрес пов'язані не стільки з появою новинок в стандартизації, скільки з впровадженням існуючих стандартів. Вибір придатних для використання рішень помітно розширився, так само як і спектр пропозицій сумісних пристроїв. Дедалі виразніше простежується тенденція, коли користувачеві телекомунікаційної системи не доводиться набувати все компоненти в одного виробника. Поряд зі спеціалізованими компаніями великі гравці виходять з того, що вони не повинні більше випускати систему цілком. Якщо не трапиться непередбаченого, незабаром варіантів буде так само багато, як у комп'ютерній галузі.
Трохи менш радує основоположна комунікаційна архітектура. У принципі, технологічний підхід SIP полягав якраз у тому, щоб пристрої здебільшого взаємодіяли безпосередньо один з одним. У порівнянні з централізованою концепцією її перевага полягає в тому, що такі системи набагато краще масштабуються, і при передачі мультимедійних даних затримка помітно коротше. На жаль, через високу складності цей підхід, по всій видимості, зазнав невдачі: більшість систем VoIP використовує традиційну топологію телекомунікаційної телефонної станції і підтримує тільки прямі з'єднання з кінцевими пристроями. Аналоговий кабель телекомунікаційної системи замінюється, якщо можна так сказати, на SIP. І користувачам не варто про це турбуватися, поки їх проблеми вирішуються. LAN
Список літератури
Журнал LAN № серпня 2005