CC BY
97
Применение протоколов управления медиа ресурсами в современных информационных системах
НЕОБХОДИМОСТЬ РАЗРАБОТКИ СПЕЦИФИКАЦИЙ ДЛЯ СЕТЕЙ СОТОВОЙ СВЯЗИ ТРЕТЬЕГО ПОКОЛЕНИЯ ПРИВЕЛО К СОЗДАНИЮ ПАРТНЕРСКИХ ПРОЕКТОВ 3GPP (3RD GENERATION PARTNERSHIP PROJECT) И 3GPP2 КОТОРЫЕ РАЗРАБОТАЛИ УНИФИЦИРОВАННУЮ ПЛАТФОРМУ И АРХИТЕКТУРУ IP MULTIMEDIA SUBSYSTEM, СОКРАЩЕННО IMS, КОТОРАЯ ПОЗВОЛЯЕТ ОСУЩЕСТВЛЯТЬ ПОСТРОЕНИЕ, КАК СОТОВЫХ СЕТЕЙ НОВОГО ПОКОЛЕНИЯ, ТАК И NGN-СЕТЕЙ.
Сивицкий ПА.,
Руководитель отдела новых технологий, продуктов и услуг,
ООО 'Тривон Нетворке"
Введение
Одним из компонентов IMS стал Media Server, функциональный модуль, решающий задачи распознавания и синтеза речи. Для обеспечения его функционирования необходим унифицированный интерфейс, предоставляющий возможность управления и контроля медиа ресурсов сети. Данным интерфейсом стал протокол MRCP (Media Resource Control Protocol).
Разработкой протокола MRCP занимается рабочая группа IETF SpeechSC (Speech Service Control) сформированная в 2002 г. и ориентированная на стандартизацию интерфейсов для сервисов синтеза речи TTS (text to speech), идентификации по голосу SI (speech identification), верификации по голосу SV (speech verification) и механизмов распознавания речи ASR (automatic speech recognition). Предложенная группой базовая концепция описана в документе RFC 4313. Протокол MRCP представляет собой реализацию этой концепции. В данный момент предложена вторая версия этого протокола (MRSPv2). В работе группы SpeechSC участвуют такие известные фирмы разработчики систем обработки речи, как Nuance Communications, Voxpilot, IBM, Cisco Systems. Кроме представителей крупнейших фирм производителей в составе группы SpeechSC присутствуют члены совета директоров форума SIP и члены комитета MRCP форума VoiceXML, профессионалы с большим опытом работы. Таким образом, разработка первой и второй спецификаций протокола MRCP велась в плотном сотрудничестве со специалистами, которые во многом
определяют развитие систем обработки речи.
Об особенностях реализации MRCPv2, его отличиях от первой версии и применении пойдет речь в данной статье.
Архитектура систем автоматизированной обработки и синтеза речи
На рис. 1 изображена общая архитектура систем автоматизированной обработки и синтеза речи принятая группой IETF SpeechSC. Основными компонентами данной архитектуры являются:
Meda Processing Entity (обработчик медиа потоков) — элемент производящий "манипуляции" с медиа потоками, проксирование, изменение кодеков (транскодирование), микширование и т.д.
Application Server (Сервер приложений) — элемент обеспечивающий логику работы сервиса, содержит алгоритмы обработки медиа потоков.
Media Server (Медиа Сервер) — элемент содержащий ресурсы позволяющие производить обработку медиа потоков: распознавание (ASR), синтез (TTS) речи и т.д.
Взаимодействие между этими компонентами осуществляется через IP-сеть c помощью следующих протоколов:
• RTP Real-Time Transport Protocol (протокол транспортировки информации в реальном времени) RFC1889 — предназначен для передачи медиа данных (голоса) через сеть IP
• SIP Session Initiation Protocol (протокол установления соединений) — протокол применяемый для установления и управления голосовы-
Рис. 1. Архитектура систем автоматизированной обработки и синтеза речи [гЪ4313]
ми сессиями в сети, получил большое распространение за счет гибкости в использовании.
• VoiceXML Voice Extensible Markup Language (расширяемая спецификация языка для создания страниц WWW с применением голосовых функций) — язык появившийся в результате дальнейшего развития HTML и имеющий больший функционал, в частности возможность реализовывать голосовые сервисы.
• SpeechSC — протокол управления медиа ресурсами сети, создание которого является основной целью рабочей группы IETF SpeechSC.
Анализ различий между MRCP v1 и v2
Первая версия протокола MRCP могла работать только с двумя типами медиа-ресурсов: синтезатором речи (TTS) и ресурсом распознавания речи (ASR). Во второй версии стандарта добавлена возможность управления ресурсами записи речи (Record), верификации (Speech Verification) и идентификации говорящего (Speech Identification). Функции ресурсов описанных в спецификации MRCPvl были расширенны. Так например, ресурс распознавания речи в первой спецификации не поддерживал voice enrolled grammars и hotword.
Другим важным отличием между первой и второй версией стандарта является механизм, используемый для управления медиа сессией и транспортный протокол. В MRCPvl для инициации и управления медиа сессией с медиа ресурсом используется протокол RTSP (Real Time Streaming Protocol). MRCPv2 для этих целей использует протокол SIP. Таким образом, MRCPvl инкапсулирует свои сообщения в тело RTSP сообщения. В отличие от этого MRCPv2 использует для передачи своей информации протоколы с установлением соединения. Это делает MRCPv2 более универсальным, гибким и легким во внедрении стандартом.
Особенности архитектуры MRCPv2
Система использующая MRCPv2 состоит из клиента который запрашивает обработку и генерацию медиа потоков и сервера который содержит ресурсы ("enginеs") для их обработки. Архитектура клиент-сервер, описанная протоколом MRCP, показана на рис. 2.
Протокол MRCP в качестве транспортных, использует протоколы с установлением соединения, к ним относится TCP, либо SCTP (применение протокола SCTP в текущей спецификации не описано).
Клиент использует протоколы SIP и SDP (Session Description Protocol протокол описания сеансов связи) для установки канала управления с сервером, для использования его медиа ресурсов. Адресация MRCPv2 медиа-серверов
происходит с использованием SIP URI (Universal Resource Identificator).
Пример адресации медиа-сервера: sip:mrcpv2@example.net
Протокол управления сессиями (SIP) использует модель диалога протокола SDF, описанную в RFC3264, для установления сессии и описания ее характеристик между клиентом и медиа сервером. Для каждого процесса обработки медиапотока устанавливается отдельная сессия управления. Каждая такая сессия устанавливается между клиентом и сервером, по мере необходимости, используя re-INVITE транзакции. Также на основе протокола SIP происходит установление медиа сессий для передачи голосовой информации между клиентом и сервером, для этого используется механизм SIP m-lines.
В протоколе нет ограничений на количество сессий между клиентом и сервером. Таким образом, один или более медиа ресурсов могут совместно использовать одну SIP сессию, либо каждый медиа ресурс может поддерживать свою собственную сессию с клиентом.
Медиа ресурсы сервера MRCPv2
MRCPv2-сервер может предоставлять клиенту один или несколько из следующих ресурсов для организации сервисов:
Basic Synthesizer. Ресурс синтеза речи, имеющий очень ограниченные возможности, может генерировать медиа поток только путем соединения заранее подготовленных аудио фрагментов. Информация для генерации голоса описывается ограниченным числом SSML (Speech Synthesis Markup Language) элементов. Basic Synthesizer должен поддерживать следующие SSML таги <speak>, <audio>, <say-as> and <maik>.
Speech Synthesizer. Ресурс с максимальными возможностями по синтезу речи из текста. Данный ресурс обязан иметь полную поддержку SSML.
Recorder. Данный ресурс имеет возможность записи аудио и сохранения его на URI.
DTMF Recognizer. Ресурс с возможностью извлечения и интерпретации DTMF (Dual-tone multi-frequency) цифр из медиа потока.
Speech Recognizer. Полноценный ресурс по распознованию голоса, имеющий возмож-
Рис. 2. Архитектура протокола MRCPv2
Пример: Установление канала управления ресурсом синтезатора речи (synthesizer), а также установления односторонней RTP медиа-сессии от сервера.
C->S: INVITE sip:mresources@server.example.com SIP/2.0 Via:SIP/2.О/TCP client.atlanta.example.com:5060;
To:MediaServer <sip:mresources@server.example.com>
Fromrsarvi <sip:sarvi@example.com>;tag=1928301774
0=sarvi 2890844526 2890842808 IN IP4 192.0.2.4
Via:SIP/2.0/TCP dient.atlanta.example.com:5060;
To:MediaServer <sip:mresources@server.example.com>
From:sarvi <sip:sarvi@example.com>;tag=1928301774
Contact:<sip:mresources@server.example.com>
0=- 2890844526 2890842808 IN IP4 192.0.2.4
C->S: ACK sip:mresources@server.example.com SIP/2.0 Via:SIP/2.0/TCP dient.atlanta.example.com:5060;
To:MediaServer <sip:mresources@server.example.com>;tag=a6c85cf From:Sarvi <sip:sarvi@example.com>;tag=1928301774
ность принять аудио поток с записью голоса, интерпретировать его и выдать результат распознавания.
Speaker Verifier. Ресурс имеющий возможность сопоставления верификационной информации, например ранее записанной фразы, с предоставляемым образцом.
Анализ использования других протоколов управления медиа-ресурсами в системах распознования и синтеза речи
Кроме протокола MRCP в мире существует ряд других протоколов управления медиа-ресурсами в распределенной сетевой архитектуре. К ним можно отнести протоколы MGCP, H.248, MEGACO, MSML, Intel R4 API. Данные протоколы являются либо внутренней разработкой компаний, предлагающих на рынке свои продукты, либо изначально направлены на другие цели. Например, протоколы MGCP H.248 предназначены для управления медиа-шлюзами в сетях передачи голоса, протокол MSML направлен на стандартизацию управления конфернц-вызовами. R4 API является интерфейсом разработчика к медиа-серверам Intel.
Обратим внимание на отсутствие в SpeechSC компании Microsoft. Ее продукт — Microsoft Speech Server, который базируется на собственном коммуникационном протоколе компании, известном под названием SAPI (Speech Application Programming Interface), является важным компонентом развиваемой Microsoft концепции объединенных коммуникаций. Сервер Speech Server, например, позволяет пользователю системы Exchange 2007 получать электронную почту на мобильный телефон (при этом используются функции распознавания речи и TTS). Но Microsoft до сих пор не делала никаких официальных заявлений по поводу MRCPv2 — ни за, ни против.
Отношение Microsoft к MRCPv2 не является показателем успешности стандарта. Свидетельством этого может служить история со стандартом VoiceXML. Изначально Microsoft намеревалась использовать для продукта Speech Server технологию SALT (Speech Application Language Tags). Однако в апреле 2006 г. она заявила, что продукт Speech Server 2007 будет полностью поддерживать и SALT и VoiceXML. Одной из причин такого решения стал поворот рынка в сторону VoiceXML, и Microsoft поняла необходимость поддерживать эту технологию. В случае широкого применения MRCPv2, Microsoft придется с этим считаться. Возможно, будет разработан транслятор SAPI — MRCP, который эффективно решит проблему, связанную с неучастием Microsoft в проекте MRCPv2.
Заключение
Принятие фирмами-производителями стандарта MRCPv2 упростит и удешевит разработку речевых приложений и, следовательно, увеличит потенциал соответствующего рынка. Однако стандарт сделает проще и переход от одной системы обработки речи к другой, что, конечно, принесет пользу ИТ-службам, но выгода для самих поставщиков средств речевой обработки здесь не столь очевидна. Компания Nuance Communications полагает, что более открытый рынок полезнее, чем рынок замкнутый, и все, что способствует росту отрасли, хорошо для производителей. Рынок систем обработки речи сравнительно невелик и пока на нем не наблюдалось бурного роста; компании надеются, что принятие стандарта MRCPv2 станет катализатором этого процесса.
Выгоды от принятия стандарта MRCPv2 получают Cisco, IBM и другие фирмы, которые пользуются технологиями обработки речи, но не обязательно являются их разработчиками. Дело в том, что наличие стандартных интерфейсов облегчает разработку приложений и перенос их с одной платформы! на другую, а также упрощает подбор кадров программистов.
Литература
1. Media Resource Control Protocol Version 2 (MRCPv2) draft-ietf-speechsc-mrcpv2-14.
2. Стандарт MRCP на службе у разработчиков голосовых приложений, Майкл Дж. Димариа.
3. Intel Technology Journal. Volume 10. Issue 01. Published, Feburary 15, 2006. ISSN 1535-846X. Using Intel Technologies to Build Next-Generation Media Servers.
