Передача факсимільного інформації

Матеріал з Вікі ЦДУ
Версія від 04:37, 20 листопада 2010; Козінцев Олексій (обговореннявнесок)

(різн.) ← Попередня версія • Поточна версія (різн.) • Новіша версія → (різн.)
Перейти до: навігація, пошук

3.6 Передача факсимільного інформації
У становленні IP-телефонії, поряд з телефоном, значну роль зіграв телефакс. Ідею нинішнього телефаксу (від грецького «теле» - далеко і латинського «facsimale» - роби подібне) запропонував англієць Олександр Байн в 1843 році, тобто за 33 роки до появи телефону. У такій же послідовності (починаючи з факсів) стали практично використовуватися переваги IP-телефонії з її досить низькими тарифами для передачі інформації на далекі відстані. Значний економічний ефект від такого застосування обумовлений надзвичайно високою поширеністю факс-машин; у світі їх налічується багато мільйонів.
Говорячи про поширеність факс-машин, відзначимо, що маються на увазі апарати групи 3, специфіковані в рекомендації ITU-TT.30. Саме поява цієї технології і відкрило дорогу широкому впровадженню послуг факсимільного зв'язку. Виявилося, що функції, реалізовані в факсах групи 3, цілком влаштовують користувачів, а стандарт практично не потребує розвитку. Про це свідчить той факт, що більш сучасна технологія, т.зв. факс групи 4, не отримала ніякого поширення і практично забута. На наш погляд, неуспіх цієї технології можна пояснити тим, що, по-перше, всі її потенційні переваги (передача кольорових зображень, висока швидкість обміну тощо) простіше і дешевше реалізуються на базі комп'ютерних технологій (обмін файлами по електронній пошті, наприклад), а по-друге, мережа ISDN, на яку були орієнтовані факси групи 4, не отримала глобального розповсюдження.
Що ж стосується необхідності забезпечити можливість обміну факсимільними повідомленнями факс-машин групи 3, то, в силу величезної кількості останніх, без такої функції не має сенсу навіть розмірковувати про надання послуг ТфОП на базі IP-мереж. Пересилання факсів через Інтернет не є чимось новим. Дуже багато компаній пропонують послуги факс-серверів відкладеної доставки (Store & Forward). Користувач відправляє факс на спеціальний сервер за заздалегідь встановленим телефонним номером, вводячи слідом за цим телефонний номер пункту призначення. Сервер, що імітує роботу факсу приймаючої сторони, приймає повідомлення, перетворює його в набір графічних файлів і відправляє дані файли через Інтернет до іншого сервера, який знаходиться ближче до місця призначення, наприклад, в іншій країні. Сервер-одержувач організовує зв'язок з пунктом призначення за отриманим їм телефонним номером і передає факсимільне повідомлення адресату, повідомляючи відправника про успішну (або неуспішної) передачі. Технологія Store & Forward Fax описана в рекомендації Т.37.
Використання такого принципу пересилання факсів не дуже зручно з точки зору як користувача, так і оператора мережі IP-телефонії. Для користувача в даному випадку втрачається одна з найважливіших переваг факсимільного технології - можливість відразу ж дізнатися результат пересилання: доставлений чи документ, і з якою якістю він доставлений. Оператора ж технологія Store & Forward змушує приймати на себе додаткову відповідальність за успішну доставку повідомлення, у той час як воно може виявитися не доставленим не з вини оператора, а просто тому, що адресат забув включити свою факс-машину.
Єдиним повноцінним вирішенням цих проблем є організація передачі факсів по IP-мереж в реальному часі і так, щоб користувачі двох факсимільних апаратів не підозрювали про те, що зв'язок між їх терміналами здійснюється з використанням мережі з комутацією пакетів. На щастя, специфікації протоколу передачі факсимільного інформації групи 3 дозволяють реалізувати таке рішення. Результатом зусиль ITU-T в даному напрямку стала рекомендація Т.38, що визначає процедури взаємодії факсимільних терміналів групи 3 в реальному часі з використанням IP-мереж. Ця рекомендація дозволяє обмін факсимільного інформацією між факсами з використанням шлюзів, між факсом і комп'ютером, підключеними до Інтернет, або навіть між комп'ютерами, хоча останнє не здається корисним властивістю - просто при встановленні з'єднання ми можемо не здогадуватися, що маємо справу з комп'ютером, а не з факсом.
Принцип передачі факсів в реальному часі очевидна: на ближньому кінці сигнали факсу демодулируется і упаковуються в пакети двійкових даних, а на віддаленому кінці відбувається їх відновлення у вид, придатний для передачі по каналах ТфОП. Крім власне інформаційних пакетів, що містять керуючі послідовності і графічні дані, передається також інформація про всі інші події, пов'язаних з передачею факсу, тобто про тональних сигнали та службових послідовностях, необхідних для налаштування приймачів модемних сигналів. Такий підхід, зі зрозумілих причин, не вимагає для передачі факсу значною смуги пропускання. Однак потрібно віддавати собі звіт в тому, що факсимільні сесії більш вимогливі до якості обслуговування, ніж мовні, у зв'язку з особливостями протоколу передачі факсимільного інформації. Дійсно, втрата 100 мс мовної інформації може бути сприйнята лише як клацання, тоді як для факсимільного сесії втрата всього одного інформаційного пакету може обернутися втратою кількох рядків зображення.
Рекомендація Т.38 передбачає використання особливого протоколу IFP, мета якого - перенесення повідомлень між шлюзами і / або комп'ютерами. Повідомлення IFP, у свою чергу, можуть передаватися всередині TCP-з'єднання або з використанням UDP, причому в останньому випадку передбачається введення інформаційної надлишковості, що забезпечує відновлення одиночних втрачених пакетів. Використання протоколу Т.38 закріплено в рамках рекомендації Н.323. Обов'язковою умовою є підтримка протоколу TCP для переносу інформації IFP, і використовує протокол UDP є лише можливим варіантом. Інформація IFP передається по двох логічним каналах (від відправника до одержувача й у зворотному напрямку). Коли в якості транспорту застосовується протокол TCP, існує два можливих варіанти: передавати повідомлення IFP, використовуючи їх Туннелирование в каналі H.225.0/Q.931, або використовувати для цього виділене з'єднання.
Незважаючи на те, що згідно з ITU-T реалізація на основі протоколу TCP є обов'язковою, на шлюзах більшості великих виробників реалізований транспорт IFP поверх протоколу UDP. Частково це можна пояснити тим, що при такому вирішенні механізм відкриття логічних каналів виглядає цілком аналогічно механізму, що використовується для передачі мовної інформації. Крім того, протокол Т.38 звичайно реалізується на основі або тих же DSP, що і мовні кодеки, або спеціалізованого процесора, що забезпечує пересилку мовної інформації, а для таких процесорів реалізація протоколу TCP занадто тяжеловесна, і її намагаються уникнути. Як би там не було, реалізації Т.38 на базі протоколу UDP широко експлуатуються і довели працездатність такого рішення. Шлюз IP-телефонії сімейства обладнання Протей-IP використовує транспорт UDP, а варіант з TCP може бути реалізований, якщо на ринку з'явиться в достатній кількості обладнання, що використовує цей підхід.