В. програмування систем ір-телефонії підручник з дисципліни "Програмування систем ір-телефонії" для всіх спеціальностей напряму Телекомунікації Одеса 2009

Вид материала

Документы

Содержание

Подобный материал:

1 2 3 4 5 6 7 8

Контрольні запитання:

Які задачі вирішували перші системи комп'ютерної телефонії?
Коли з'явилися перші системи комп'ютерної телефонії?
Що таке системи СРВ?
Що таке Call-центри?
Коли з'явилися комп'ютерні системи обробки вхідних викликів?
Коли з'явилися перші системи IP-телефонії?
Що таке TSAPI?
Що таке TAPI?
Які прогнози у сфері телефонного зв'язку в межах установ?
Які прогнози у сфері мереж зв'язку загального користування?
Які етапи розвитку пройшла IP-телефонія?

1.2 Стандарти IP-телефонії

Вхідний контроль:

Для чого потрібні стандарти?
Хто розробляє стандарти у сфері телекомунікацій?
Як пов'язані комп'ютери і IP-телефонія?
Який вид комутації використовується в IP-телефонії?
Що таке IP?

1.2.1 Задачі стандартизації

В історії комп'ютерної телефонії відомо чимало конфліктів, що виникали при створенні стандартів, чому малися цілком об'єктивні причини. Насамперед, можна згадати про ті конфлікти між виробниками комп'ютерів і виробниками систем комутації, що були зв'язані з розробкою протоколу ЕСМА CSTA. Комп'ютерники хотіли стандартизувати увесь набір функцій АТС і мати формалізовану модель роботи вузла комутації. Фахівці в області комутації підкреслювали складність і функціональне різноманіття комутаційних систем і наполягали на тому, що необхідно дати кожній АТС можливість працювати по-своєму, і на тім, що досить мати можливість описувати телефонні операції, але зовсім не обов'язково накладати обмеження на порядок виконання цих операцій. Перемогла точка зору розроблювачів систем комутації. Аналогічна дискусія велася і розроблювачами SCAI з ANSI, але тут переміг ухил убік комп'ютерного підходу.

Як випливає з історії комп'ютерної телефонії, і Call-центри, і інші системи комп'ютерної телефонії були однієї з тих областей інфокомунікацій, що менше інших піддавалися стандартизації. Однак сьогодні усе більшу популярність здобуває (і стимулюється багатьма операторськими компаніями) підхід, заснований на застосуванні постачальниками не закритих систем з використанням внутрішньофірмових технологій, а відкритих систем, що базуються на устояних, загальноприйнятих стандартах.

Існують міжнародні комітети, форуми, інститути, комісії, консорціуми, що створюють стандарти загального користування,

які в процесі їхньої розробки повинні бути (і іноді бувають) відкриті для аналізу й обговорення. Такі стандарти називають стандартами де-юре. Найбільш відомої з подібних організацій, що багато зробила, серед іншого, і в тій області, що розглядається в даній книзі, є Сектор стандартизації електрозв'язку Міжнародного союзу електрозв'язку (ITU-T).

Існують й інші міжнародні стандарти — де-факто, — які формально не є стандартами загального користування. У їхнє число входять протоколи і процедури, визначені для своїх продуктів такими всесвітньо визнаними авторитетами, як, наприклад, Microsoft чи IBM. Завдяки високому професіоналізму розроблювачів, а також завдяки своїй приступності і коректності, описи і специфікації відповідних інтерфейсів стали настільки широко використовуватися, що, власне кажучи, перетворилися в стандарти. Саме такого роду стандартами є, наприклад, протокол TCP/IP і операційна система Windows. Правда, завжди існує імовірність боротьби стандартів. Наочними прикладами такої боротьби можуть служити війна Бета зі стандартом VHS чи війна IBM PC з Apple Macintosh.

Дуже актуальний у контексті даної книги приклад — це два стандарти для відкритих інтерфейсів API, застосовуваних у системах комп'ютерної телефонії, — TSAPI (прикладний програмний інтерфейс телефонних послуг), розроблений Novell Inc., і ТАРІ (телефонний прикладний програмний інтерфейс), розроблений Microsoft.

Користувачам потрібні такі продукти комп'ютерної і традиційної телефонії, які можна інтегрувати з існуючими інформаційними системами, а обидва згадані інтерфейси задовольняють цій вимозі. З моменту їхнього впровадження в 1993 році інтерфейси API стали грати в індустрії комп'ютерної телефонії сполучну роль. І хоча це питання вже було порушено в розділі 1.1, у даному розділі вони розглядаються для того, щоб показати, наскільки непроста ситуація зі стандартами у сфері комп'ютерної телефонії.

Стандартизація в комп'ютерній телефонії охоплює, насамперед, моделі обробки виклику, тобто алгоритми обробки сигнальної інформації, об'єкти цих моделей і протоколи взаємодії комутаційної й обчислювальної галузей. Обробкою виклику займається програмне забезпечення комутатора, що включає в себе операційне середовище, що керує ресурсами системи, і драйвери пристроїв, що створюють інтерфейс між апаратною і програмною частинами комутаційної підсистеми. Існує безліч варіантів реалізації програмної частини. Так, існують комутаційні системи, що дотепер досить успішно працюють із програмним забезпеченням обробки виклику, написаним на асемблері, тоді як в інших воно реалізовано на спеціальних мовах і з використанням спеціальних алгоритмів обробки виклику. Інтеграція двох галузей, що розвиваються незалежно — дуже непроста задача, тим більше що комп'ютерна частина повинна реалізовувати усі функції керування комутатором і бути здатною інтерпретувати одержувані від нього повідомлення. Для виконання цих і інших задач комп'ютерний домен систем CTI повинний працювати з відповідною абстрактною моделлю комутаційного устаткування й алгоритмів обслуговування виклику.

Незважаючи на очевидні переваги й актуальність розглянутої в книзі технології, розвиток і стандартизація систем комп'ютерної телефонії протікали досить складно. Основною причиною цього були розбіжності між виробниками комп'ютерної і комутаційної техніки. Архітектура third-party CTI вимагає спеціального стандартного протоколу зв'язку між станцією і комп'ютером. А до початку 1990-х років ситуація характеризувалася тим, що комп'ютерне устаткування для взаємодії «із зовнішнім світом» уже підтримувало ряд різних протоколів, і постачальники комп'ютерів не прагнули додавати до цього ряду ще трохи, тоді як виробники систем комутації або взагалі не мали потрібного протоколу, або мали свої власні внутрішньогалузеві протоколи. Кожен постачальник комп'ютерних чи систем API підтримував ті протоколи, що він вважав стратегічно важливими (у силу сформованих партнерських чи взаємин інших, здебільшого, суб'єктивних причин). Проте, програмісти-конструктори додатків Call-центрів і комп'ютерної телефонії мали потребу в загальній платформі, на якій могло б базуватися їхнє програмне забезпечення. У сфері комп'ютерних систем двома прикладами таких загальних платформ є IBM-сумісні персональні комп'ютери і стандартизація операційної системи UNIX, але цього явно не вистачало, щоб стимулювати виробництво сумісного ПЗ для комп'ютерної телефонії.

На початку 90-х років стандарти стали з'являтися, але їхня кількість і різноплановість прекрасно ілюстрували відоме висловлення: «єдина перевага стандартів полягає в тому, що їх завжди дуже багато, а тому — є, з чого вибирати». Очевидно, що коли ситуація зі стандартами заплутана, виробники не прагнуть вкладати значні кошти в їхнє впровадження. Більш того, коли вибір занадто великий, виробник, імовірніше всього, збереже своє власне внутрішньофірмове рішення, особливо, якщо воно надає більше можливостей і послуг, чим кожний з існуючих стандартів. До того ж, на розробку стандартів більший вплив роблять не вимоги користувачів, а технічні аспекти. Цим пояснюється і те, що головним об'єктом уваги в сфері стандартизації Call-центрів і CTI були і залишаються питання протоколів, а не розробка стандартного API, принаймні, у частині архітектури зовнішніх серверів комп'ютерної телефонії (third-party CTI).

Сьогодні, щоправда, протоколи first-party специфікуються шляхом визначення лінійної сигналізації між термінальними пристроями і комутаційним устаткуванням. Тут найбільш розповсюдженою базою для стандартизації є специфікована ITU-T сигналізація ISDN (рекомендація Q.931). Саме передбачена в Q.931 модель процесу обслуговування виклику і стану цього процесу лягли в основу моделі процесу, застосовуваної в тих інтерфейсах API, через які забезпечується програмний доступ до керування з'єднаннями, що встановлюються і руйнуються з використанням цього протоколу.

1.2.2 Етапи стандартизації

На початку 1980-х років був розпочатий ряд зусиль, спрямованих на стандартизацію каналів зв'язку між АТС і комп'ютерами. На передньому краї цієї діяльності, як і в інших телекомунікаційних галузях, виступила компанія AT&T, що розробила в 1984 році протокол DMI (цифровий мультиплексний протокол), що спочатку забезпечував зв'язок НР-АТ&Т Незважаючи на те, що цей стандарт був реалізований деякими виробниками УАТС (інтерфейс підтримувала, наприклад, іSDX виробництва Plessey) і що з ним почали експериментувати деякі УАТС виробники комп'ютерів (наприклад, компанія DEC реалізувала його у дослідному устаткуванні Annecy у Франції), ринок фактично ігнорував цю концепцію — разом з більшістю спроб забезпечити транспортування даних через УАТС. Компанія Nortel запропонувала подібне рішення — інтерфейс Computer PBX Interface (CPI), що теж не знайшло широкого поширення.

Проте, DMI і подібні протоколи, у деякому змісті, проклали дорогу повноцінним протоколам, що включають у себе великий набір команд і станів взаємодіючих об'єктів. AT&T спонсорувала форум виробників ISDN/DMI Usеr's Group, що зібрав 170 виробників систем комутації і комп'ютерів і організував у 1987 році групу для вивчення технічних питань реалізації прикладного інтерфейсу АТС-комп'ютер. У результаті цієї роботи був визначений протокол ASAI. Хоча протокол був відкритим (у тім змісті, що специфікацію ASAI можна було придбати в AT&T за мінімальну суму), він був занадто зв'язаний з AT&T, щоб стати універсальним стандартом.

Тим часом, у Великобританії British Telecom організував ряд робочих зустрічей, спрямованих на створення національного стандарту CTI. Основна увага на цих зустрічах було приділено використанню протоколу НСI компанії Mitel як відправну точку для визначення національного стандарту.

У процесі подальшої роботи на зміну Mitel прийшла Європейська асоціація виробників обчислювальної техніки ЕСМА з задачею створити Європейський стандарт для телефонних додатків з використанням обчислювальної техніки (Computer-Supported Telephony Applications — CSTA), у якому згодом, для розширення сфери охоплення, замінила слово «телефонні» на «телекомунікаційні».

Аналогічна робота тоді ж (у 1990 році) була організована в Американському національному інституті стандартів (ANSI) за назвою Switch Computer Application Interlaces (SCAI).

Як CSTA, так і SCAI є протоколами обміну повідомленнями між комутаторами і комп'ютерами — ні ЕСМА, ні ANSI не визначають інтерфейс API. Ці два протоколи створювалися досить повільно (протягом трьох чи чотирьох років), але з'явилися першими дійсно відкритими стандартами додатків комп'ютерної телефонії для протоколів рівня ланки даних. Специфікації CSTA були удосконалені і стандартизовані ITU-T із включенням у них елементів прикладного інтерфейсу SCAI. До CSTA близько примикає і додатковий прикладний інтерфейс комп'ютер-комутатор ASAI (Adjunct Switch/System Application Interface), а також сумісна з IBM архітектура CSA — CallPath Services Architecture IBM.

Ще один стандарт — MVIP — був розроблений тоді ж (у 1990 році) компанією Natural Microsystems і дотепер підтримується багатьма виробниками, що використовують апаратні засоби цієї компанії. MVIP допускає установку декількох телефонних плат в одному PC, забезпечує обробку до 256 одночасних викликів через 8 шин по 2,048 Мбіт/с і передбачає взаємозв'язок ресурсів до 20 комп'ютерів, поліпшуючи тим самим масштабованість системи. Більш 50 виробників, включаючи Mitel, підтримують MVIP через міжнародну організацію GO-MVIP.

Розроблена Dialogic архітектура обчислювальних систем обробки сигналів SCSA заснована на архітектурі клієнт/сервер і являє собою сукупність незалежних апаратних засобів (клієнтська частина, хост-компьютер, середовище передачі) зі стандартизованими інтерфейсами між ними.

Далі в цьому розділі розглядаються основні напрямки стандартизації Call-центрів і комп'ютерної телефонії.

1.2.3 Рекомендації ITU-T

Першою в історії міжнародною організацією по стандартизації електрозв'язку є Сектор стандартизації електрозв'язку Міжнародного союзу електрозв'язку — ITU-T (українська абревіатура ССЕ-МСЕ). Цей орган випускає документи, що формально носять рекомендаційний характер, але фактично обов'язкові для виконання. Створення рекомендацій і їхнє затвердження в структурі ITU-T доручено дослідним комісіям (ДК), цілий ряд яких випускає рекомендації з тематиці даної книги.

ДК-2 (Operational aspects of service provision, networks, and performance) відповідає за дослідження загальних аспектів надання послуг ТфЗК, ISDN, мобільного й універсального персонального зв'язку, включаючи принципи сполучення послуг і аспекти якості обслуговування користувачів; питань експлуатації мереж, включаючи маршрутизацію, нумерацію, експлуатаційне керування мережею; питань якості роботи мереж (розрахунок навантаження, робочі характеристики і їхні виміри); людських факторів; аспектів запобігання облудних дій. Є ведучою комісією в питаннях визначення послуг, нумерації, маршрутизації і глобальній мобільності.

ДК-3 (Tariff and accounting principles including related telecommunications economic and policy issues) визначає тарифні принципи і принципи обліку, включаючи стосовні до цього економічні питання і питання прийняття рішень.

ДК-4 (Telecommunication management, including TMN) відповідає за дослідження, що відносяться до мережі експлуатаційного керування системами електрозв'язку (TMN), до техобслуговування мереж і їхніх складових частин, до визначення механізмів техобслуговування і до застосування такого роду механізмів, запропонованих іншими комісіями. Є ведучою комісією в питаннях TMN.

ДК-7 (Data networks and open system communications) відповідає за дослідження, що відносяться до мереж даних, до розвитку моделі взаємодії відкритих систем і до їх застосування, включаючи використання в мережах, обробку повідомлень, захищеність інформації і відкриту розподілену обробку. Є ведучою комісією в питаннях відкритої розподіленої обробки (ODP), ретрансляції кадрів (FR) і захисту систем зв'язку.

ДК-10 (Languages and general software aspects for telecommunication systems) відповідає за алгоритмічні мови, методи їхнього застосування й інші питання, що мають відношення до аспектів програмного забезпечення телекомунікаційних систем. Є ведучою комісією в питаннях мов і засобів опису. Саме цією комісією розроблена мова специфікацій і описів SDL, яка використовується для представлення алгоритмів.

ДК-11 (Signaling requirements and protocols) відповідає за дослідження, що стосуються вимог до сигналізації і протоколів для телефонії, ISDN, а також універсального персонального, мобільного і мультимедійного зв'язку. Є ведучою комісією в питаннях Інтелектуальної мережі; саме нею розроблені не тільки всі, що згадуються в книзі системи сигналізації, але і сама концепція Service Node (SN). Цей термін українською мовою можна перекласти "вузол послуг".

ДК-13 (Multi-protocol and IP-based networks and their interworking) відповідає за дослідження перспективних загальномережних аспектів і впливу нових системних концепцій і нових технологій на телекомунікаційні мережі в плані очікуваних наслідків, включаючи дослідження широкосмугових і IP-мереж і глобальної інформаційної інфраструктури.

ДК-16 (Multimedia services, systems and terminals) відповідає за дослідження, що стосуються визначення мультимедійних послуг і систем, включаючи термінали, модеми, протоколи й обробку сигналів. Є ведучою комісією в питаннях мультимедійних послуг і систем. Саме в ній створені основні рекомендації, що стосуються Контакт-центрів і ряду інших питань, які згадуються в книзі. До цих питань відносяться і розроблювальні перерахованими Дослідними комісіями рекомендації наступних серій (табл. 1.1.).

Таблиця 1.1 — Рекомендації ITU-T

G	Системи передачі і передавальне середовище. Цифрові системи і мережі
Н	Системи аудіовізуального і мультимедійного зв'язку
I	Мережі ISDN
J	Передача мультимедійних сигналів
Р	Якість телефонної передачі, телефонні установки й абонентські лінії
U	Комутація і сигналізація
I	Телематичні термінали
V	Передача даних по телефонних мережах
X	Мережі даних і взаємодія відкритих систем
Y	Глобальна інформаційна інфраструктура
Z	Мови програмування.

З питаннями, що торкаються в книзі, тісно зв'язані і рекомендації серії Q.500 (вимоги до цифрових систем комутації), серії Q.700 (специфікації системи сигналізації №7), серії Q.600 (взаємодія різних систем сигналізації), серії Q.900 (цифровий доступ), а також рекомендації серії Q.2000, що визначають вимоги до широкосмугових мереж. У цих рекомендаціях викладаються основи мови специфікацій і описів SDL відповідно до рекомендацій Z.100, на якому написані SDL-діаграми, що приводяться в даній книзі, наприклад, SDL-діаграма процесу обслуговування власника поштової скриньки в системі мовної пошти, аспекти ISDN відповідно до рекомендацій серії I та інші.

У контексті основної тематики книги дуже цікаві також стандарти серії Q.1200, присвячені концепції створення телекомунікаційних послуг, називаною Інтелектуальною мережею. Ця концепція була спочатку революційною, а потім дуже швидко стала класичною.

Ця концепція містить наступні основні аспекти стандартизації її фізичних і функціональних елементів. Для підтримки послуг зі списків CS-1 і CS-2 рекомендаціями ITU-T серії Q. 12хх визначені наступні фізичні елементи: вузол комутації послуг (Service Switching Point — SSP), вузол доступу до мережі (Network Access Point — NAP), вузол керування послугами (Service Control Point — SCP), допоміжний вузол керування послугами (Adjunct — AD), інтелектуальні периферійні пристрої (Intelligent Peripheral — IP), вузол послуг (Service Node — SN), сполучений вузол керування і комутації послуг (Service Switching and Control Point — SSCP), вузол надання даних для послуг (Service Data Point — SDP), вузол доступу (Enhanced ISDN Customer Premises Equipment — Enhanced ISDN CPE), вузол прийому й обробки інформації, що не відноситься до зв’язку користувача (Call-Unrelated Service Point — CUSP). Перераховані фізичні елементи містять функціональні об'єкти; підтримки доступу (CCAF), керування зв'язком користувача (CCF), комутації послуг (SSF), керування послугами (SCF), надання даних для послуг (SDF), спеціалізованих ресурсів (SRF), доступу до мережі (IAF), прийому й обробки інформації, що не відноситься до зв’язку користувача (CUSF), передачі інформації керування послугою від користувача (SCUAF), експлуатаційного керування послугами (SMF).

У цій концепції докладно розроблена структура Інтелектуальної мережі, визначені відповідно до рекомендації Q.1225 і іншими рекомендаціями ITU-Т цієї серії функціональні і фізичні елементи мережі й інтерфейси між ними. Визначення фізичного елемента мережі обмежується описом його функцій, інтерфейсів з іншими елементами мережі і набором функціональних елементів, що він може містити. Так, для вузла послуг визначаються інтерфейси підключення до комутаційного вузла (PRI/BRI) і функціональні елементи SSF, CUSF, CCF, SCF, SDF, SRF. При цьому функції SSF/CCF тісно зв'язані з функцією SCF і недоступні для інших вузлів, що виконують функції керування послугами. Сьогодні такі вузли послуг будуються, як правило, на базі технології комп'ютерної телефонії третього покоління.

Займатися проблемами комп'ютерної телефонії ITU-T почав досить давно. Ще в ті часи, коли він називався Міжнародним консультативним комітетом з телеграфії і телефонії (МККТТ), одним з напрямків роботи його Дослідної комісії 11 було «Телекомунікаційні додатки для комутаторів і комп'ютерів» (TASC). Робота почалася у вересні 1992 року в підкомісії, що спеціалізувалася на Інтелектуальних мережах. На першому засіданні був погоджений план створення міжнародних рекомендацій і визначений ряд цікавих положень. Найбільш важливі положення, розроблені на цьому першому засіданні, стосувалися того, що повинен являти собою протокол TASC, якими повинні бути сфера його застосування і його відношення до Інтелектуальних мереж.

Фактично, TASC являв собою технологію доступу до мережі, а технологію мережної взаємодії визначала концепція Інтелектуальної мережі. Додатки TASC повинні були доповнювати і підтримувати послуги Інтелектуальної мережі. З цією метою, а також щоб уникнути конфліктів взаємодії, для TASC і Інтелектуальної мережі будувалася єдина модель процесу обслуговування виклику. При розробці рекомендацій серії Q.1300, присвячених протоколу TASC, ITU-T використовував досвід розробки інтерфейсів взаємодії комп'ютер-АТС, накопичений ЕCMA і SCAI.

Наступним значним кроком ITU-T, що може істотно вплинути на розвиток технологій комп'ютерної телефонії в цілому, стали рекомендації серії Q.1900, (табл. 1.2) присвячені протоколу керування обслуговуванням виклику в мережах з комутацією пакетів, що не залежить від засобів доставки інформації (ВIСС). Цей протокол орієнтований на використання для зв'язку між елементами мережі наступного покоління NGN, під якою розуміється результат конвергенції телефонної мережі загального користування, мереж кабельного телебачення (з можливістю передачі іншої інформації), мереж рухливого зв'язку й Інтернет. Одною з основних переваг протоколу BICC є те, що він є спадкоємцем стека протоколів ОКС7, а саме — протоколу ISUP, що значно спрощує алгоритми взаємодії елементів мережі нового покоління з елементами традиційних мереж. З цієї серії стандартів на даний момент вийшли у світ наступні специфікації (частина вийшла ще в попередньому варіанті).

Таблиця 1.2 — Специфікації серії Q.1900

Специфікація	Опис
Q.1901	Протокол керування обслуговуванням виклику поза залежністю від засобів доставки інформації (BICC)
Q.1902.1	Функціональний опис протоколу BICC (CS2)
Q.1902.2	Основні функції повідомлень і параметрів протоколів BICC та ISUP (OKC7)
Q.1902.3	Формати і коди протоколів BICC та OКС7
Q.1902.4	Протокол BICC: основні процедури обслуговування виклику
Q.1902.5	Вилучення з прикладного механізму транспортування в контексті BICC
Q.1902.6	Загальні процедури сигналізації і підтримка протоколом BICC додаткових послуг ISUP
Q.1912.1	Сполучення сигналізації ISUP (OKC7) і BICC
Q.1912.2	Сполучення деяких систем сигналізації (доступ до ТфЗК, DSS1, З5, R1, R2, TUP) та BICC
Q.1912.3	Сполучення сигналізації протоколів Н.323 і BICC
Q.1912.4	Сполучення сигналізації DSS2 і BICC
Q.1922.2	Взаємодія між INAP CS2 і BICC
Q.1950	Протокол керування обслуговуванням виклику поза залежністю від засобів доставки інформації (ВЮС)
Q.1970	BICC — Протокол керування доставкою інформації за допомогою IP (IPBCP)
Q.1990	BICC — Протокол тунеліровання інформації керування доставкою

1.2.4 Стандарти ISO

Міжнародна організація стандартів (ISO) також розпочала деякі зусилля в розглянутому напрямку і навіть придумала новий термін в області CTI-методи інтеграції АТС і комп'ютерів (MISC — Methods for Integrating Switches and Computers). Перше засідання робочої групи відбулося ще в 1993 році, і вже тоді на ньому було вирішено, що цю роботу за назвою TASC очолить ITU-T, про що говорилося в попередньому параграфі.

1.2.5 Стандарти ETSI

Європейський інститут стандартизації в галузі електрозв'язку (European Telecommunications Standards Institute) був створений у 1988 році. Основний офіс ETSI розташований на півдні Франції в Sophia Аntipolis, а сама організація нараховує сотні членів з десятків країн, що представляють адміністраторів, мережних операторів, дослідницькі організації і кінцевих користувачів, а також кандидатів в учасники і спостерігачів.

ETSI грає значну роль в розробці міжнародних стандартів і іншої технічної документації в ключових галузях інфокомунікацій, у тому числі в розглянутих в даній книзі напрямках. На рис. 1.2 представлена структура ETSI, котру складають загальні збори, управління, технічні комітети, спеціальні комітети, а також основні проекти.

OCG — Група координації робіт;

SAGE — Група спеціалістів по перевірці безпеки алгоритмів;

ETSAG — Група відсліжування європейських телекомунікаційних стандартів;

JEEC — Об’єднаний комітет ETSI/ECMA;

NGN — Мережі нового покоління.

Загальні збори (technical assembly) є вищим органом ETSI, що приймає останнє рішення про затвердження готових стандартів. Розробкою самих стандартів займаються технічні комітети. До 2002 року до складу ETSI було включено 15 технічних і 7 спеціальних комітетів.

1.2.6 Структура ЕСМА

Європейська асоціація ЕСМА була заснована в 1961 році для стандартизації систем зв'язку й інформації. В асоціації менш 20 активних членів, але її склад добре збалансований. У неї завжди входили представники трьох основних напрямків — виробники комп'ютерів, виробники систем комутації і телекомунікаційні компанії.

П

ро результати роботи цієї асоціації можна судити по тій кількості стандартів ЕСМА, що стали загальноєвропейськими і міжнародними. ЕСМА також бере активну участь в інших організаціях і форумах чи має з ними угоди про взаємодію. Взаємодія ЕСМА з іншими організаціями, що розробляють стандарти, ілюструє рис. 1.3.

Рисунок 1.2 — Загальна організаційна структура ETSI

Рисунок 1.3 – Взаємодії ЕСМА з іншими організаціями

Найбільш відомою і важливою розробкою ЕСМА є інтерфейс взаємодії комутаційного і обчислювального доменів CSTA, що вже згадувався на початку розділу 1.2. Під час розробки комітет очолювали виробники комп'ютерів — спочатку DEC, а потім IBM. При подальшому розвитку стандарту виник ряд розбіжностей. Деякі з них з'явилися в процесі доробки технічного звіту ЕСМА при визначенні моделі обслуговування виклику для опису функцій галузі комутації (питання з моделлю комп'ютерної галузі було менш насущним і менш спірним). Визначення станів і подій для інтерфейсів CTI фактично було включено в технічний звіт, але тільки для відомості. Але навіть цим розроблювачі АТС були дуже стурбовані, тому що стандартизація процесу обробки викликів у їхніх системах, швидше за все, суперечила б поточному поводженню вироблених ними АТС. Інше питання, що викликало істотні розбіжності, стосувалося кількості послуг, що повинен був реалізувати у своєму продукті виробник комутаційних станцій, щоб забезпечити їхню відповідність стандарту. Деякі виробники АТС наполягали на тому, що досить обмовити в стандарті тільки підтримку процедур установлення базового з'єднання. Але виробники ПЗ комп'ютерних систем вважали, що мінімальний набір послуг, реалізованих в АТС, повинен бути розширений. У результаті стандартний набір послуг так і не був визначений, що згодом обмежило можливості надання послуг під керуванням серверів CTI.

Позитивним моментом у діяльності ЕСМА був намір у першу чергу намагатися використовувати існуючі стандарти. Група, що працювала з CSTA, не прагнула створити для протоколу нову архітектуру, а вирішила організувати її на базі існуючої архітектури і на результатах робіт інших міжнародних груп, що займаються стандартизацією, головним чином, ISO і ITU-T. Ціль подібних дій — досягти повної незалежності протоколу від нижчележачих транспортних рівнів. Чи передаються повідомлення про запити і стани по проводах, коаксіальному кабелю чи оптичному волокну, чи використовуються при цьому такі транспортні протоколи нижніх рівнів, як X.25, чи протокол IP — усе це не представляє інтересу для протоколу CSTA: аби для передачі повідомлень мався який-небудь тракт. Саме з цієї причини на функціональному рівні був застосований принцип відкритої розподіленої обробки, а для взаємодії між відповідними рівнями протоколу — OSI ROSE, у результаті чого була створена архітектура, представлена в табл. 1.3. Незважаючи на те, що ЕСМА є європейською організацією, її стандарти одержують усе більше міжнародне поширення, а в групу, що займалася специфікацією протоколу, із самого початку ввійшли AT&T, Nortel, Mitel, Siemens — з боку виробників систем комутації — і IBM, Nixdorf та DEC — з боку виробників обчислювальної техніки.

Таблиця 1.3 — Архітектура протоколу CSTA

Рівень	Засоби
Функціональний	Відкрита розподілена обробка
Взаємодія	OSI ROSE
Модель мережі доступу	ISDN

1.2.7 Американський інститут стандартів ANSI

Уже згадуваний вище інтерфейс SCAI стандартизований комітетом T1S1 Американського національного інституту стандартів ANSI Група SCAI є частиною комітету Т1S1.1, що займається також питаннями Інтелектуальних мереж. У групу SCAI входить близько 40 активних учасників, включаючи Bellcore і сім регіональних операторських компаній Bell, AT&T, Nortel, Roim, IBM, Hams, Hewlett-Packard і Mitel.

Робота почалася трохи пізніше, ніж робота ЕСМА, і йшла рівнобіжним курсом. Ці дві групи взаємодіяли між собою але переконати їх у необхідності злиття не вдалося. Перевага в складі SCAI традиційних операторів ТфЗК привело до фундаментальних розходжень у підході. У групі SCAI більша увага приділена узгодженню зі стандартами для Інтелектуальних мереж і взаємодії з мережами загального користування.

1.2.8 Консорціум мультимедіа і телеконференцій IMTC

Міжнародний консорціум по мультимедіа і телеконференціях IMTC, об'єднуючий більш 150 компаній-учасників, займається додатками мультимедійного телеконференцзв'язку, їхньою функціональною сумісністю і відкритими стандартами. Основні напрямки роботи консорціуму IMTC сконцентровані на стандартизації стеків протоколів Н.320 і Т.120 для відеотелефонного конференцзв'язку і конференцзв'язку з передачею даних, відповідно.

1.2.9 Конференції OpenSig and OpenArch і робоча

група IEEE P1520

Вимоги мати в мережному устаткуванні відкриті інтерфейси були сформульовані мережними операторами ще на початку ери комп'ютерної телефонії. Розроблювачі мережних додатків, як і розроблювачі розглянутих у наступній главі користувальницьких додатків, шукали нові шляхи використання мережі. У 1996 році Колумбійський університет провів перший семінар OpenSig, націлений на просування досліджень питань відкритого мережного керування. У 1998 році телекомунікаційне об'єднання IEEE спонсорувало розширений семінар OpenSig як частина конференції OpenArch IEEE. Потім IEEE створює групу стандартизації Р1520, задача якої — зробити мережу такою же програмувальною, як персональний комп'ютер. Робота цієї групи орієнтована на мережі IP і ATM і базується на моделі, що містить наступні інтерфейси (рис. 1.4):

V — API інтерфейси, що забезпечують доступ користувальницьких додатків до рівня додаткових послуг;
U — API інтерфейси, що забезпечують доступ до основних послуг мережі;
L — API інтерфейси, що забезпечують доступ до віртуальних пристроїв мережі., дозволяючи маніпулювати станами ресурсів мережі;
ССМ — інтерфейс керування з'єднаннями, тобто набір відкритих протоколів доступу до фізичних елементів мережі.

Група Р1520 представила свої ідеї реалізації цієї моделі у 1999 році на виставці Telecom'99. Основні зусилля групи сьогодні спрямовані на стандартизацію L-інтерфейсу для IP-маршрутизаторів і ATM-комутаторів, а також СCM-інтерфейса для ATM комутаторів.

1.2.10 Міжнародний консорціум IPCC

У травні 1999 року був створений консорціум ISC (International Softswitch Consortium), який пізніше був названий Консорціум IPCC (International Packet Communication Consortium — міжнародний консорціум пакетного зв'язку). На даний момент Консорціум IPCC містить у собі приблизно 150 членів, серед яких Alcatel, Cisco Systems, Clarent Corporation, Samsung Electronics Co. Ltd., Lucent Technologies, Nokia Telecommunications, Siemens Carrier Networks LLC, Radcom Ltd., VocalTec Communications, Ltd., Marconi Communications, Level 3 Communications, Motorola inc. Є шість робочих груп — група додатків (Applications WG), група керування пристроями (Device Control WG). група маркетингу (Marketing WG), група SIP (SIP WG), адміністративна група (Session Management WG) і юридична група (Legal Intercept WG).

Рисунок 1.4 — Структура моделі Р1520

Своєю основною задачею консорціум вважає розвиток і підтримку відкритих архітектур, протоколів і API-інтерфейсів, що припускає значне спрощення розгортання послуг, як для виробників систем, так і для операторів послуг. Консорціум фокусує свою увагу на питаннях взаємодії і сертифікації послуг реального часу.

Архітектура консорціуму IPCC розрізняє 5 площин — площина даних, площина додатків, площина керування зв'язком, площина транспорту і площина експлуатаційного керування. Стільки ж стандартів уже прийнято IPCC. Протоколи для інтерфейсів однорівнєвих компонентів містять у собі Н.323, SIP, RTP і RTSP, а також протоколи MGSP і MEGACO, що передбачають декомпозицію компонентів на керуючі і керовані.

1.2.11 Форум MSF

Форум MSF (Multiservice Switching Forum) був заснований компаніями Cisco, Bellcore і MCI WorldCom у листопаду 1998, а зараз нараховує 57 учасників. Він одержав широку підтримку мережних операторів (учасниками форуму є ВТ, SBC, US West, Telia. Telecom Italia, France Telecom і NTT), виробників телекомунікаційного устаткування й устаткування передачі даних, а також виробників різних компонентів апаратних і програмних засобів. Ціль MSF полягає в тім, щоб прискорити упровадження відкритих комунікаційних систем із гнучкою підтримкою широкого спектра мережних послуг на базі різних технологій.

Загальна структура форуму MSF представлена на рис. 1.5. Рада директорів визначає загальні задачі, загальну політику і структуру організації. Склад ради відкрито вибирається з кандидатів, висунутих членами організації. Як і більшість організацій, що стандартизують, форум MSF містить у собі кілька комітетів; у їхньому числі — технічний комітет, комітет маркетингу і навчання, комітет взаємодії з іншими промисловими групами.

У своїй роботі MSF спирається на протоколи і стандарти, розроблені іншими організаціями. На рис. 1.5 позначені проблемні області мультисервісної мережі і зазначені організації, що займаються стандартизацією в цих областях.

Одне з фундаментальних положень, що формують основу MSF, - використовувати подібність в архітектурі IP-маршрутизаторів, комутаторів Frame Relay і ATM-комутаторів. Розроблювальне устаткування повинне стати загальною платформою для систем з комутацією пакетів даних будь-яких форматів. Таке рішення дозволяє підтримувати на цій платформі широкий спектр послуг.

1.2.12 Консорціум Parlay Group

Консорціум Parlay Group був сформований у березні 1998 р. для створення специфікацій API-інтерфейсу, що забезпечує доступ до мережної інформації і керування мережними ресурсами. Спочатку угоду уклали фірми ВТ, Ulticom, Microsoft, Nortel Networks і Siemens. У травні 1998 року вона була обнародувана, а вже в листопаду 1998 було оголошено про завершення 1 стадії роботи над технічними специфікаціям, і в грудні були видані перші версії технічних вимог і проведена демонстрація гіпотетичного додатка Guaranteed Call Delivery. Цей додаток забезпечував можливість, працюючи поза областю мережного оператора, пропонувати послуги кінцевим користувачам, використовуючи деякі з ключових можливостей версії 1 Parlay API. Спочатку 1999 року до угоди приєдналися 6 нових членів: AT&T, Cegetel, Cisco, Ericsson, IBM і Lucent, і були початі роботи над стадією 2, присвяченої, насамперед, керуванню обслуговуванням виклику, обміном повідомленнями і захистом. Роботи стадії 2 зосереджені також на розширенні функціональних можливостей API, особливо в областях безпровідних послуг і IР-послуг, включаючи конвергенцію безпровідних мереж, ТфЗК і мереж IP. Хронологія випуску специфікацій Parlay API представлена в табл. 1.4.

Рисунок 1.5 — Проблемні області MSF і розроблювачі стандартів

Таблиця 1.4 — Хронологія специфікацій Parlay API

Версія	Дата	Причина змін
1.0	4 грудня 1998	Перше видання для промислової оцінки
1.1	7 травня 1999	Другий випуск
1.2	10 вересня 1999	Третій випуск із розширеним механізмом повідомлення про події
2.0	24 січня 2000	Фаза 2: Перший випуск для оцінки промисловістю
2.1	26 червня 2000	Незначні редакційні зміни
2.1.1	20 листопада 2000	Незначні зміни діаграм і зв'язаних з ними описів

Діяльність консорціуму Parlay API спрямована на створення універсального інтерфейсу програмування для керування мережними ресурсами. Історично можливості такого керування контролювалися й експлуатувалися винятково мережними операторами, що частково було обумовлено несумісністю стандартів, але також і задачею забезпечити захист і цілісність мережі. Однак, щоб забезпечити гнучкість уведення нових послуг, додатки повинні створюватися, тестуватися й експлуатуватися операторами послуг поза мережною областю. Необхідно забезпечити доступ до мережної інформації ззовні і мати можливість контролювати ззовні мережні ресурси, що може бути досягнуте завдяки використанню прикладного програмного інтерфейсу API між прикладним рівнем і рівнем компонентів послуг, як це показано на рис. 1.6.

Рисунок 1.6 — Використання прикладного програмного інтерфейсу

Parlay API

Керування мережними можливостями за допомогою інтерфейсу API не означає, що мережа загального користування стане більш відкритою. Скоріше, мережні можливості стануть «видимими», зберігаючи при цьому ефективність і захист. Забезпечити цілісність і захист мережі — одне з головних вимог до розробки API-інтерфейсу і його доповнень. Використовуючи API-інтерфейс, можна домогтися швидкого створення і введення в комерційну експлуатацію нових послуг, що відповідають потребам конкретного споживача. Архітектура Parlay API містить інтерфейси декількох категорій. Перша версія Parlay API охоплює інтерфейси між клієнтськими додатками і послугами Parlay, а також базовий API інтерфейс, що забезпечує можливості, необхідні для організації інтерфейсів послуг. В другій версії додалися інтерфейси для підтримки адміністративних функцій усередині підприємства і для підтримки послуг Parlay сторонніми виробниками.

1.2.13 Інтерфейси TAPI, TSAPI і JTAPI

Про ці інтерфейси зовнішнього керування алгоритмом обробки виклику в АТС уже говорилося раніше, але важливість і драматичні аспекти їхньої стандартизації говорять про необхідність відбити ці аспекти більш докладно.

Отже, про API. Зовнішні керуючі системи (а це, як правило, могутні сервери), реалізовані на базі технологій комп'ютерної телефонії, є чимось на зразок локальних SCP Інтелектуальної мережі і забезпечують можливість модифікувати алгоритми керування обслуговуванням викликів силами технічного персоналу. Іншими словами, цей персонал може доробити і модифікувати стандартне програмне забезпечення, що дозволяє оператору чи адміністратору самостійно розробляти правила керування обробкою викликів від різних абонентів. Але це ще не все. Крім власне керування АТС, такий сервер може взаємодіяти і з іншими пристроями, а також з корпоративною базою даних.

Як уже відзначалося, сьогодні існують дві основні схеми реалізації інтерфейсів API — Telephony Services API (TSAPI), запропонована Novell і AT&T, і Telephony API (TAPI), розроблена Microsoft. І той, і інший стандарт передбачає, що API приймає запити CTI-додатків і направляє їх до телефонних систем, що і виконують команди. Розходження між стандартами полягає в тім, як обробляються запити. TSAPI передбачає їхню обробку на файловому сервері, a TAPI — на робочій станції.

Специфікація TSAPI випущена в березні 1994 року, орієнтована на платформи PC і є протокольним стеком, не потребуючим, щоб виготовлювач цілком відкривав інтерфейс комутатора. Можливості першої версії TSAPI виявилися не настільки широкими, хоча ця версія була транслятором CSTA для дуже популярних у Росії АТС для установ сімейства Definity. Версія 2 (1995) інтерфейси TSAPI поширила API на інші УАТС і комп'ютерні системи, включаючи OS/2, Macintosh, UnixWare і Windows NT. Більш нові версії TSAPI відрізняються кращою погодженістю з CSTA і підтримують клієнт-серверні технології Windows NT і мережні аспекти TCP/IP.

Microsoft і Intel спільно розробили специфікацію TAPI-прикладного інтерфейсу телефонного зв'язку для тих же задач, що і TSAPI. Як невід'ємна частина розробленої Microsoft відкритої архітектури службових функцій для середовища Windows (WOSA), TAPI функціонує в середовищі мережного термінала Windows і також заснований на архітектурі клієнт-сервер. Орієнтований із самого початку на максимальну незалежність від телефонного устаткування, TAPI містить набір функцій, що дозволяють керувати з персонального комп'ютера під Windows різноманітними телефонними пристроями, відповідати на виклики, набирати потрібний чи номер переключати зв'язок з одного номера на іншій. Програмісти розробляють комп'ютерно-телефонні додатки, використовуючи ці функції TAPI, а ті, у свою чергу, дають додаткам можливість звертатися до TAPI-сумісних пристроїв. Виробники апаратних телефонних засобів поставляють свої пристрої (наприклад, телефони, факси, модеми) разом із програмними чи модулями драйверами, що підтримують інтерфейс TAPI. У якості одного з найпростіших прикладів, що ілюструють підхід TAPI, можна привести задачу написати додаток, у якому потрібно, щоб пристрій (приміром, телефон) ініціював телефонний виклик. Для цього програміст визначає в TAPI функцію GetDialTone, необхідну для того, щоб до набору номера знайти сигнал «Відповідь станції». У свою чергу, ТАРI звертається до драйвера, що поставляється разом з телефоном, і виконує фрагмент програми, що дає вказівку телефону включитися і набрати номер, якщо сигнал розпізнаний. Реальні програми керування різними пристроями відмінні одна від інший, але це не повинно турбувати програміста - його завдання полягає лише в тім, щоб написати код, відповідальний за виконання завдання, що було передано через інтерфейс TAPI.

TSAPI теж використовується для керування обслуговуванням викликів, однак у ньому застосовується інший підхід. Як і у випадку з TAPI, програмні додатки запускаються на робочих станціях, але запити телефонного обслуговування передаються через мережний адаптер на файловий сервер. Сервер розпізнає запит і передає відповідний пакет даних на TSAPI-сумісну УАТС для виконання. Пакет містить телефонний номер користувача і власне запит. Якщо, наприклад, прийшов запит зняти трубку, УАТС уключить гучномовець телефону, і користувач почує гудок. Якщо в користувача немає убудованої акустичної системи, УАТС просто передасть до його телефону викличний сигнал. Аналогічно, якщо в запиті додатка зазначений номер телефону, УАТС передасть цей номер.

Крім того, користувачі Windows NT 4.0 можуть за допомогою TAPI імітувати для Windows NT Server дії, аналогічні діям TSAPI компанії Novell. Адміністраторам самим можна вирішувати, яка конфігурація для них зручніше.

Перевага архітектури TSAPI полягає в тому, що телефонні переговори практично не завантажують локальну мережу. Кілька пакетів керування, переданих по локальній мережі, роблять на її завантаження незначне (у порівнянні з потоком даних при двосторонній розмові) вплив. TSAPI забезпечує передачу інформації тільки про початок і про завершення розмови, а інші функції керування, наприклад, функції керування переключенням зв'язку, працюють у звичайному режимі, тоді як TAPI у процесі обслуговування виклику передає по мережі інформацію про значно більше число подій.

Вибір між TAPI-додатками і TSAPI-додатками визначається декількома факторами. По-перше, TSAPI — це модуль, що завантажується і контролюється засобами NetWare, без них його запустити не можна. По-друге, деякі додатки підтримують тільки один інтерфейс, так що вибір залежить від того, з яким додатком захоче працювати користувач.

Таким чином, якщо користувач підключений до NetWare, і обраний ним додаток підтримують і TAPI, і TSAPI, те рішення залежить від завантаження мережі. Для організації, що встановлює нове обладнання, кращим буде використання рішення на базі ТАРІ й установка високошвидкісної локальної мережі, такої, наприклад, як Fast Ethernet чи FDDI. Швидкісна локальна мережа підтримує передачу і мови, і даних. Телефони можна підключати прямо до персонального комп'ютера, так що телефонні виклики не будуть перевантажувати мережний сервер. Ця конфігурація дає й інші вигоди. Одна з них — економія на телефонній проводці; інша — можливість купувати менш дорогі телефони, оскільки всякі додаткові функції, зокрема, повторний набір, короткочасний обрив шлейфа (flash), режим утримання (hold), телефонні конференції, лічильник часу, визначник номера і т.п. можуть бути. убудовані в додаток, що запускається з комп'ютера.

Отже, і TSAPI, і ТАРI створювалися, у першу чергу, з урахуванням задач своїх творців і їхніх прихильників. Найбільше досягнення, у контексті даної глави, полягає в тому, що користувачі одержали надійні і підтримувані стандарти, створені могутніми компаніями-розроблювачами програмного забезпечення. В остаточному підсумку, користувачі в цій складній ситуації виграли, оскільки вони мають можливість доступу з програмного забезпечення своїх систем до будь-якого пристрою, підтримуваному тим і іншому стандарту, аби програмне забезпечення їхніх систем також відповідало цим АРІ. Слід зазначити, що це виявилося можливим тільки завдяки підтримці з боку творців великих операційних систем і виробників устаткування, інакше інтерфейси TSAPI і ТАРІ мали б мало шансів на широке визнання, а комп'ютерно-телефонна інтеграція могла б залишитися обмеженим досягненням першого покоління систем CTI, що розглядалися в розділі про історію IP-телефонії.

І, нарешті, прикладний інтерфейс програмування телефонних задач JTAPI являє собою рішення на основі Java, розроблене спільно Sun Microsystems, Lucent Technologies, IBM і Nortel. Це - крос-платформне неоднорідне рішення, що використовує високоефективні Java-додатки для комп'ютерної телефонії. JTAPI містить додаткові функції комп'ютерної телефонії для Інтернет, що дає можливість створювати додатка на основі Web, у яких інтегровані браузери-додатки і функції Call-центра.

1.2.14 Форум ECTF

Заснований у 1995 році, форум ECTF являє собою об'єднання постачальників, розроблювачів і споживачів устаткування CTI. Серед учасників форуму такі компанії як Nortel, Ericsson, HP, Microsoft, Lucent, Motorola, Dialogic, Natural MicroSystems і ряд інших. Робота форуму спрямована на обговорення, розробку і тестування варіантів багаторівневої взаємодії компонентів CTI усередині ТфЗК, IP-мереж, а також усередині відомчих і корпоративних мереж. Основна мета форуму - розробка угод про взаємодію апаратних і програмних рішень комп'ютерної телефонії в частині керування обслуговуванням виклику і керування медіа-ресурсами. Використання стандартів ECTF розроблювачами систем CTI дозволяє надати покупцям устаткування більшу волю вибору (тобто можливість будувати готове рішення з оптимальним набором компонентів різних виробників), прискорити процес упровадження нових послуг за рахунок наявності відкритих інтерфейсів, забезпечити масштабованість систем і таке інше. Не заглиблюючись в організаційну структуру форуму, зупинимося лише на технічних аспектах, тобто на діяльності технічного комітету ECTF. Можна виділити наступні основні напрямки діяльності цього комітету:

Питання конвергенції комп'ютерного і телефонного устаткування;
Забезпечення погодженості відкритих інтерфейсів устаткування CTI;
Розробка документів, що стандартизують, що забезпечують можливість створення відкритих, розширюваних, поєднуваних у мережу платформ і додатків комп'ютерної телефонії, а так само стандартів, що забезпечують взаємодію устаткування СТ, що випускається різними виробниками.

Технічний комітет має кілька робочих і дослідницьких груп, діяльність яких охоплює області взаємодії додатків і пристроїв, структури, адміністрування, обробки виклику, і платформ комп'ютерної телефонії.

Стандарти ECTF розділені на наступні групи:

серія М.ХXX — адміністративні послуги;
серія S.XXX — програмні інтерфейси;
серія Н.ХХХ — апаратне забезпечення й інтерфейси;
серія С.ХХХ — керування обслуговуванням виклику;

серія R.XXX — модель обліку статистичної інформації;
серія А.XXX — інтерфейси додатків.

Зупинимося коротко на основних стандартах цих груп (рис. 1.7).

Специфікація З001 визначає модель керування обслуговуванням виклику і містить у собі описи послуг керування і їхніх інтерфейсів. Основою специфікації послужили попередні роботи в цій сфері — стандарти форуму ЕСМА і консорціуму CTI Encyclopedia.

Н.100/Н.110 — специфікації шин комп'ютерної телефонії для систем PCI/compact PCI. Шина Н.110 являє собою додаткову шину в compact PCI модифікації і дозволяє одночасно комутувати до 4096 каналів на швидкості 64 кбіт/сек кожний. S.100 — специфікація прикладного програмного інтерфейсу для розроблювачів додатків комп'ютерної телефонії, що визначає архітектуру клієнт-сервер, у якій клієнтський додаток використовує набір послуг для роботи з ресурсами устаткування. У рамках моделі базового процесу обслуговування виклику описаний прикладний програмний інтерфейс API, що дозволяє розроблювачам різних додатків (факсів-серверів, IVR, Call-центрів і ін.) спростити написання прикладних пакетів програм. Як головну мету реалізації програмного інтерфейсу в стандарті S.100 декларується незалежність створених прикладних засобів від апаратури і від драйверного програмного шару різних виробників.

Рисунок 1.7 — Структура стандартів ECTF

S.200 — транспортний протокол передачі команд S.100 до сервера і відповідей сервера — до клієнтського додатка.

S.300 — специфікація взаємодії платформ послуг S.100 з ресурсами комп'ютерної телефонії, що забезпечує незалежність програмного забезпечення від виробників апаратури.

S.900 — специфікація адміністративних аспектів побудови систем комп'ютерної телефонії. Специфіковано процедури розподіленого керування, дозволу доступу до систем. Стандарт описує механізми побудови програмних систем, керування якими сильно спрощується за рахунок використання специфікованих процедур доступу до даних.

М.100 — специфікація адміністративних послуг, що дозволяють створювати адміністративні додатки, що керують запуском і відключенням серверів комп'ютерної телефонії, їх конфігурацією і послугами. Основними функціями протоколу М.100 є функції контролю стійкості роботи системи (контролю ініціювання ресурсів і інших елементів сервера). У випадках виникнення несправностей протокол М.100 забезпечує зупинку сервера без утрати даних.

R.100 — специфікація моделей і алгоритмів обліку статистичної інформації про роботу операторських центрів, що включає в себе модель обслуговування виклику, мінімальний набір даних, структуру записів у базі даних.

Незважаючи на неоднозначні оцінки майбутнього форуму ECTF, сьогодні ця організація — усе ще ведучий авторитет в області стандартів комп'ютерної телефонії. Причини ж неоднозначності оцінок зв'язані з тим, що вихідні матеріали для стандартизації, як правило, надаються компанією, що до моменту початку стандартизації більше інших процвітала у визначеному напрямку розробок, так що в ряді випадків підготовлені стандарти несуть на собі яскраво виражений корпоративний відбиток. Крім того, хоча ECTF працює швидше згадуваних вище традиційних організацій, що стандартизують, часу на розробку і узгодження стандартів іде досить багато, і в ряді випадків уже погоджені стандарти спираються на не самі нові і перспективні підходи і технології (з погляду розробки апаратних і програмних засобів).

Утім, із приводу останнього зауваження про відставання стандартів від розвитку технології, уже було кимсь замічено що стандарти не можуть не відставати від часу, тому що саме це відставання і робить їх стандартами.

1.2.15 Група інженерних проблем Інтернет (IETF)

Велику кількість стандартів пов'язаних з IP-телефонією розробила група інженерних проблем Інтернет — Internet Ingeneering Task Force (IETF), що була створена у 1989 році. Пізніше ця група розділилася на декілька робочих груп. З них найбільш відомими є робочі групи AVT, Sigtran, MMUSIC та Megaco.

Робоча група транспортування аудіо/відео — Audio/Video Transport (AVT) розробила протокол реального часу Real-Time Protocol (RTP), призначений для організації передачі пакетів з кодованими мовними сигналами по IP-мережі.

Робоча група транспортування сигнальної інформації — Signaling Transport (Sigtran) розробила систему загальноканальної сигналізації ОКС7 (чи SS7), яка представляє собою стек протоколів, серед котрих найбільш відомі протоколи ISUP, MAP, INAP, TCAP, SCCP, MTP. Крім того робоча група Sigtran розробила транспортний протокол передачі з управлінням потоками — Stream Control Transmission Protocol (SCTP).

Робоча група управління мультимедійним сеансом — Multiparty Multimedia Session Control (MMUSIC) розробила родину протоколів для мультимедійного конференцзв'язку через Інтернет, включаючи самий удалий протокол IP-телефонії — протокол SIP.

Робоча група управління транспортними шлюзами — Media Gateway Control (Megaco) розробила протокол управління медіа шлюзами — Media Gateway Control Protocol (MGCP) та його наступника Megaco. Останній був розроблений спільно з ITU і тому має ще іншу назву H.248.

Контрольні запитання:

Для чого призначені стандарти комп'ютерної телефонії?
Які ви знаєте організації, що розробляють стандарти?
Що таке ITU-T?
Що таке ISO?
Які стандарти розробила робоча група Sigtran?
Що таке ECMA?
Що таке інтерфейси TSAPI, TAPI та JTAPI?
На які робочі групи поділяється IETF?
Які найбільш відомі стандарти розробила група IETF?
Що таке ECTF?
Що таке консорціум IPCC?
Що таке консорціум Parlay Group?

Blog

В. програмування систем ір-телефонії підручник з дисципліни "Програмування систем ір-телефонії" для всіх спеціальностей напряму Телекомунікації Одеса 2009

Содержание