В данной статье рассматривается проблема коммуникации людей с нарушениями слуха, проблемы связанные с недостатком ресурсов и программное обеспечение помогающее взаимодействовать со специальными службами и между людьми при помощи специально обученного оператора. Узкоспециализированное программное обеспечение позволяет проводить трехсторонние видео-конференции, включающие в себя не только передачу видео-информации, а также сохранение истории, ведение статистики, администрирование базой данных и т. д.
Ключевые слова: слабослышащие; нарушение слуха; call-центр; сурдопереводчик; передача видео-информации; оператор; язык жестов; видео-конференции; диспетчер.
Client-server video conferencing system of helping people with hearing impairments
В настоящее время проблема коммуникации людей с какими-либо нарушениями слуха не решена в полной мере. Люди с нарушением слуха нуждаются в помощи во взаимодействии со специальными службами и в повседневных затруднительных бытовых ситуациях. Для решения этих проблем в последнее время набирает популярность практика открытия специализированных call — центров для слабослышащих, где люди могут получить квалифицированную помощь обученных операторов. Однако, к данному моменту не существует open-source специализированного программного обеспечения для этих целей.
В общении людей-инвалидов по слуху с разными организациями помогают операторы — переводчики языка жестов. В Диспетчерскую службу на специально установленные экраны поступает видео звонок от абонента, который жестами показывает, какая услуга его интересует. Оператор call-центра службы связывается с необходимой социальной или иной организацией, договаривается по всем вопросам, и уже на языке жестов передает ему полученную информацию.
Практика создания call-центров для слабослышащих затронула многие города в России, ближнем зарубежье, в Европе и в США. Подобные call-центры занимаются помощью людей с нарушением слуха. Благодаря этой службе слабослышащие получают возможность самостоятельно:
- позвонить в полицию;
- вызвать скорую помощь;
- заказать железнодорожные и авиа билеты;
- купить лекарства;
- заказать такси;
- вызвать скорую помощь, пожарную службу;
- навести справки о работе многих организаций и многое другое.
Связь с диспетчером осуществляется посредством обмена текстовыми сообщениями и видео-потоками (язык жестов).
С нарастающей популярностью подобных call-центров встал вопрос о создании соответствующего программного обеспечения. Аналогичные системы либо не специализированными для подобных call-центров либо являются платными и не полными.
Таким образом, встала задача о разработке, проектировании и программировании специализированного программного обеспечения, поддерживающего клиент-серверную архитектуру. Такое программное обеспечение дает возможность взаимодействия трех сторон:
- Оператор — обученный сотрудник call — центра по совместительству сурдопереводчик
- Клиент 1– человек, который обращается в call-центр
- Клиент 2 — человек, с которым необходимо настроить коммуникацию
Программная реализация
Передача видеоинформации в потоковом режиме подразумевает использование стороннего сервера, взаимодействующего с клиентскими частями по API. Такая серверная реализация является очень ресурсоемкой, поэтому целесообразно вынести в отдельную программную часть сервер передачи сообщений от клиентов к оператору и наоборот.
Рис. 1. Схема реализаций передачи сообщений в системе
На рис. 1 показана схема возможной реализации механизма передачи сообщений. Процессы пользуются услугами модуля передачи сообщений. Запросы на эти услуги могут иметь вид примитивов и параметров. Примитив соответствует исполняемой функции, в параметры используются для передачи данных и контроля над информацией. Конкретная форма примитивов зависит от программного обеспечения передачи сообщений. Это может быть вызов процедуры или передача сообщения процессу операционной системы.
Примитив Send используется процессом, желающим отправить сообщение. Входными параметрами этого примитива являются идентификатор получающего процесса и содержимое сообщения. Модуль передачи сообщений формирует блок данных, включающий эти два элемента. Этот блок данных посылается на машину, на которой работает получающий процесс, при помощи каких-либо сетевых протоколов, например, TCP/IP. Когда адресат получает блок данных, этот блок направляется модулю передачи сообщений. Этот модуль исследует поле идентификатора процесса и сохраняет сообщение клиент-сервер в буфере этого процесса.
В этом сценарии получающий процесс должен объявить о своем желании получать сообщения, выделить буфер для сообщений и информировать модуль передачи сообщений при помощи примитива Receive. Альтернативный метод не требует подобного объявления. Просто когда модуль передачи сообщений получает сообщение, он сигнализирует процессу, которому оно адресовано, а затем помещает сообщение в общий буфер.
Рис. 2. Схема совместной обработки данных
В данной конфигурации обработка данных оптимизирована таким образом, чтобы использовать сильные стороны как клиента, так и сервера, а также самого факта распределения данных. Подобные конфигурации гораздо сложнее в установке и обслуживании, но в долговременной перспективе они позволяют обеспечить лучшие показатели производительности и эффективности использования сетевых ресурсов, чем другие методы реализации архитектуры клиент-сервер.
Обработка данных на стороне и сервера и клиента обусловлена необходимостью декодирование потоков фотографий в видео контент на обоих сторонах.
Работа с видео-контентом
После начала видео-конференции контент необходимо подготовить для доставки в потоковом виде, или выполнить его кодирование. Для каждого из форматов необходимо соответствующее кодирующие программные функции. Кодирование определяет качество контента и скорость его передачи, а также обеспечивает доставку контента в формате потокового медиа пользователя. При кодировании происходит:
- преобразование аналогового контента в цифровую форму;
- создание файла в формате, который распознается сервером и плеером потокового медиа;
- компрессия файла, чтобы контент, который можно передать в реальном времени с учетом ограничений скорости передачи, был как можно более богатым по содержанию;
- определение скорости передачи, с которой будет передаваться контент: 28, 56, 100, 300 Кбит/с и т. д.
Следует учитывать, что файлы, которые имеют большую степень компрессии, (т. е. из них удалено больше деталей) передаются с более высокой скоростью, но качество контента у них ниже. Файлы с низкой степенью компрессии (т. е. из них удалено меньше деталей) передаются с большой скоростью и дают контент более высокого качества.
Чтобы наиболее полно охватить аудиторию, владельцы контента могут кодировать медиа для разных скоростей: пользователи с быстрым подключением смогут получать контент с высоким качеством, а для пользователей с медленным подключением он будет доступен с худшим качеством.
Для транспорта не потокового контента используется протокол TCP (Transmission Control Protocol), по которому между сервером и клиентом устанавливается соединение, поддерживаемое до полного приема контента. Клиент может сообщить о не принятых IP-пакетах, и сервер передаст их повторно. В результате файл, успешно переданный по TCP всегда будет идентичен оригиналу. Протокол TCP хорош тогда, когда критически важна целостность данных, потому что сервер автоматически контролирует получение адресатом каждого пакета. Но такой контроль сильно отражается на скорости. Для передачи потокового медиа применяют протокол UDP (User Datagram Protocol), который не предусматривает подтверждение (контроль) соединения и повторную отправку потерянных пакетов. UDC обеспечивает более быструю доставку информации конечному пользователю, хотя качество контента при его передачи через несложные или централизованные сети может ухудшаться.
Один из способов снизить до минимума ограничения Интернета при передаче потокового медиа -- использование сети Content Delivery Network, специализирующейся на доставке потокового контента. Хорошая сеть CDN поможет преодолеть ограничения Интернета и дает значительные преимущества: лучшее качество, большую надежность, а также возможность одновременного обслуживания большого количества запросов из любой точки земного шара.
Заключение
Преимуществом такого программного обеспечения является то, что оно узко-специализированно и направленно на работу оператор — клиент — клиент. Поддерживание собственной базы данных клиентов и операторов позволяет вести статистику и историю звонков, что значительно расширяет возможности call-центра.
Литература:
1. Алейкин Е. В. Разработка методов контроля и перераспределения видео-потоков. М, 2001. С 6–257.
2. Васкевич Д. Н. Стратегии клиент/сервер. Диалектика. Киев. 1997, С 1–320.
3. Зайцева Г. Л. Жестовая речь. Гуманитарный издательский центр ВЛАДОС. 2000. С 2–145.
4. Елманова Н. З. Borland C++ Builder. Архитектура «клинт/сервер», многозвенные системы и Internet-приложения. М.:Диалог-МИФИ, 1998, С 202.
5. Kent Beck. Text Driven Development: By Example. N.Y. 2006. C 1–454.
