Internet-телефонія як двигун SIP

Християн Штредіке

Галас навколо недорогих або зовсім безкоштовних телефонних розмов по 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 № 8 2005