RU2398361C2

RU2398361C2 - Интеллектуальный способ, система и узел ограничения аудио

Info

Publication number: RU2398361C2
Application number: RU2007122372/09A
Authority: RU
Inventors: Ричард Е. ХЬЮБЕР (US); Ричард Е. ХЬЮБЕР; Арун ПУНДЖ (US); Арун ПУНДЖ; Питер Д. ХИЛЛ (US); Питер Д. ХИЛЛ
Original assignee: Эрикссон Аб
Priority date: 2006-06-16
Filing date: 2007-06-14
Publication date: 2010-08-27
Also published as: CA2591732C; CN101090329A; EP1868363A1; ATE432588T1; ES2327288T3; JP2008042889A; EP1868363B1; RU2007122372A; CA2591732A1; DE602007001164D1

Abstract

Настоящее изобретение относится к организации конференц-связи. Техническим результатом является управление потоками аудио, передаваемыми одновременно так, чтобы прерывать состояние перегрузки. Результат достигается тем, что система организации телеконференций включает в себя сеть и множество узлов, таких как терминалы, обменивающиеся друг с другом через сеть потоками аудио, причем терминалы осуществляют передачу друг к другу, чтобы сформировать конференцию. Каждый терминал способен обнаруживать состояние перегрузки, при котором имеется более заранее определенного количества одновременных потоков аудио, передаваемых терминалами, и вместе с другими терминалами управлять количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки. 3 н. и 15 з.п. ф-лы, 23 ил., 1 табл.

Description

Перекрестная ссылка на связанные заявки

Настоящая заявка относится к одновременно поданным предварительным заявкам на патент США № 60/814476 "Conference Layout Control and Control Protocol" авторов Richard E. Huber и Arun Punj, имеющей номер в реестре поверенного FORE-120; №60/814491 "Associating Independent Multimedia Sources Into a Conference Call", авторов Arun Punj, Richard E. Huber и Gregory H. Smith, имеющей номер в реестре поверенного FORE-121, обе из которых включены в настоящее описание по ссылке.

Область техники

Настоящее изобретение относится к организации конференц-связи, где количество потоков аудио, передаваемых одновременно, управляется так, чтобы прервать состояние перегрузки, иначе известное как аудиошторм. Более конкретно, настоящее изобретение относится к конференц-связи, где количество потоков аудио, передаваемых одновременно, управляется так, чтобы прервать состояние перегрузки, при этом каждый терминал приходит к одному и тому же решению независимо от других терминалов относительно состояния перегрузки без каких-либо сообщений синхронизации от сети.

Предшествующий уровень техники

При участии в большой конференц-связи сумма всех возможных каналов аудио может превысить ресурсы центрального процессора и сети. Использование VAD (обнаружение речевой активности) является стандартным способом статистически сохранить количество одновременных потоков аудио ограниченным. Однако имеются моменты времени, когда большое количество участников может генерировать аудиоответ, который может заставить почти все узлы начать осуществлять передачу.

Максимальное число участников конференции для большой конференции представляет проблему обработки аудио, не имеющей место при 15-сторонней конференции. Предположим, что конференция со 100 сторонами была скоординирована, но все удаленные стороны не были подавлены (заглушены) и таким образом способны передавать аудио в любое время. Основная говорящая сторона делает комментарий, на который каждый отвечает и в течение довольно короткого промежутка времени 100-300 мс каждый ViPr терминал начинает посылать данные аудио, таким образом создавая "аудиошторм пакетов". Результатом воздействия такого шторма на конференцию может быть увеличение принятого уровня шума, и все сигналы испытывают скачок, равный 20 дБ на выходе аудио. Терминал обрабатывает 5000 аудио RTP-пакетов (пакетов протокола реального времени) в секунду. Любая линия связи с малой полосой частот, подсоединяющая ViPr терминал к остальной части конференции, должна была бы состязаться с потоком данных аудио 8 Мбит/с. (Примечание: число 8 Мбит/с получено из того, что каждый терминал ViPr передает со скоростью 64 кбит/с для данных аудио, 4,8 кбит/с для служебных RTP, и служебные сигналы IP приблизительно 4 кбит/с). Настоящее изобретение описывает как обнаружить, что конференция входит в это состояние перегрузки, и как управлять тем, какие отправители должны прекратить посылать. Настоящее изобретение обеспечивает механизм ограничения эффектов от слишком большого количества одновременных потоков аудио.

Краткая сущность изобретения

Настоящее изобретение относится к системе организации телеконференций. Система содержит сеть. Система содержит множество узлов, обменивающихся друг с другом через сеть аудиопотоками, которые узлы передают друг другу, чтобы сформировать конференцию. Каждый узел способен обнаруживать состояние перегрузки, когда имеются более чем заранее определенное количество одновременных потоков аудио, передаваемых узлами, и вместе с другими узлами управлять количеством потоков аудио, передаваемых одновременно, чтобы завершить (прервать) состояние перегрузки.

Настоящее изобретение относится к способу, обеспечивающему конференц-связь (телеконференцию). Способ содержит этапы, на которых множество узлов обмениваются друг с другом через сеть аудио потоками, которые узлы передают друг другу, чтобы сформировать конференцию. Имеется этап обнаружения каждым узлом состояния перегрузки, когда имеются более чем заранее определенное количество одновременных потоков аудио, передаваемых узлами. Имеется этап управления количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки.

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

Краткое описание чертежей

На сопроводительных чертежах иллюстрируются предпочтительный вариант осуществления изобретения и предпочтительные способы осуществления изобретения, на которых:

Фиг.1 изображает схематическое представление системы для настоящего изобретения.

Фиг.2 изображает схематическое представление сети для настоящего изобретения.

Фиг.3 изображает схематическое представление видеофона, связанного с персональным компьютером и сетью.

Фиг.4 изображает схематическое представление системы для настоящего изобретения.

Фиг.5a и 5b изображают схематические представления видеофона на видах спереди и сбоку.

Фиг.6 изображает схематическое представление панели соединений видеофона.

Фиг.7 изображает схематическое представление многоэкранной конфигурации для видеофона.

Фиг.8 изображает блок-схему видеофона.

Фиг.9 изображает блок-схему архитектуры видеофона.

Фиг.10 изображает схематическое представление системы.

Фиг.11 изображает схематическое представление системы.

Фиг.12 изображает схематическое представление системы согласно настоящему изобретению.

Фиг.13 изображает схематическое представление другой системы согласно настоящему изобретению.

Фиг.14 изображает схематическое представление смесителя аудио согласно настоящему изобретению.

Фиг.15 изображает блок-схему архитектуры для смесителя.

Фиг.16 изображает блок-схему SBU.

Фиг.17 изображает схематическое представление UAM видеофона в конференции видеофона.

Фиг.18 изображает схематическое представление UAM видеофона при двухстороннем телефонном вызове.

Фиг.19 изображает схематическое представление сети для смесителя.

Фиг.20 изображает блок-схему настоящего изобретения.

Подробное описание изобретения

Обращаясь к чертежам, на которых аналогичные цифровые обозначения относятся к подобным или идентичным частям на нескольких представлениях (видах), и более конкретно к фиг.20, заметим, что на ней показана система 10 организации телеконференций. Система 10 содержит сеть 40. Система 10 содержит множество узлов, таких как терминалы или видеофоны, обменивающихся друг с другом через сеть 40 аудио потоками реального разговора, которые терминалы передают друг другу, чтобы сформировать конференцию. Каждый терминал способен обнаруживать состояние перегрузки, при которой имеются более заранее определенного количества одновременных потоков аудио реального разговора, передаваемых терминалами, и вместе с другими терминалами управлять количеством потоков аудио, передаваемых одновременно, чтобы завершить (прервать) состояние перегрузки.

Предпочтительно, каждый терминал определяет, должен ли он прекратить передавать свой поток аудио, когда обнаружено состояние перегрузки, на основании потока аудио, который он передает, и потоков аудио, передаваемых другими терминалами. Каждый терминал предпочтительно приходит к одному и тому же решению независимо от других терминалов относительно состояния перегрузки без каких-либо сообщений синхронизации от сети 40.

Настоящее изобретение относится к способу, обеспечивающему конференц-связь (телеконференцию). Способ содержит этапы, на которых множество терминалов обмениваются друг с другом через сеть 40 потоками аудио реального (живого) разговора, которые терминалы передают друг другу, чтобы сформировать конференцию. Имеется этап обнаружения каждым терминалом состояния перегрузки, при котором имеются более заранее определенного количества одновременных потоков аудио реального разговора, передаваемых терминалами. Имеется этап управления количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки.

Предпочтительно, этап управления включает в себя этап управления количеством потоков аудио, передаваемых одновременно, и состояния перегрузки каждым из терминалов. Этап управления предпочтительно включает в себя этап, на котором каждый терминал определяет, должен ли он прекратить передавать свой поток аудио, когда состояние перегрузки обнаружено, на основании потока аудио, который он передает, и потоков аудио, передаваемых другими терминалами. Предпочтительно, этап управления включает в себя этап, на котором каждый терминал приходит к одному и тому же решению независимо от терминалов, имеющих отношение к состоянию перегрузки, без каких-либо сообщений синхронизации от сети 40.

Способ предпочтительно включает в себя этап разрешения узлам, имеющим наиболее недавно переданные потоки аудио разговора, продолжать передавать их потоки аудио. Предпочтительно, этап разрешения включает в себя этап оценки каждого узла, при этом узлы, имеющие самое большое значение оценки, продолжают передачу. Этап оценки предпочтительно включает в себя этап использования подсчета пакетов аудио для каждой стороны за прошлые 60 секунд, чтобы определить оценку.

Настоящее изобретение относится к узлу 12 организации телеконференций для сети 40 с другими узлами. Узел содержит интерфейс сети 40, который обменивается с другими узлами, чтобы сформировать конференцию реального (живого) разговора. Узел содержит контроллер 19, который обнаруживает состояние перегрузки, при котором имеются более заранее определенного количества одновременных потоков аудио реального разговора, передаваемых терминалами, и вместе с другими терминалами управляет количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки. Предпочтительно, узел включает в себя приемник 58 аудио, чтобы принять разговор, и устройство изображения, чтобы захватывать живые изображения в узлах, и динамики 64, чтобы воспроизводить потоки аудио, принятые от других узлов.

При работе в предпочтительном варианте осуществления максимальное число участников конференции для большой конференции "в живую" представляет проблему обработки аудио, не имеющую места в конференции с 15 сторонами. Предположим, что конференция с 100 сторонами была скоординирована, но все удаленные стороны не были подавлены (приглушены) и таким образом они способны передавать аудио в любое время. Основная говорящая сторона 64 делает комментарий, на который каждый отвечает, и в течение довольно короткого промежутка времени 100-300 мс каждая оконечная точка начинает посылать данные аудио, таким образом создавая "аудио шторм пакетов". Результатом влияния такого шторма на конференцию может быть увеличение принятого уровня шума, и все сигналы испытывают скачок, равный 20 дБ на выходе аудио. Оконечная точка обрабатывает 5000 RTP (протокол реального времени) пакетов аудио в секунду. Любая линия связи с малой полосой частот, подсоединяющая ViPr терминал к остальной части конференции, должна была бы состязаться с потоком данных аудио, равным 8 Мбит/с. (Примечание: число 8 Мбит/с получено из того, что каждая оконечная точка передает со скоростью 64 кбит/с для данных аудио, 4,8 кбит/с для служебных RTP, и IP служебных (пакетов) приблизительно 4 кбит/с).

При обнаружении сравнивают частоту принятых пакетов аудио с порогом. Каждая оконечная точка независимо определяет, присутствует ли шторм и должна ли она продолжать посылать данные аудио или выполнить глушение самой себя. Общий поток, который оконечная точка совместно использует, является таким, что каждая оконечная точка может оценивать статистику активности разговора других оконечных точек, так как они будут принимать аудио данные друг друга.

Исходя из моделирования, можно ожидать, что число передаваемых каналов аудио превышает предел в течение короткого времени, обычно менее чем 300 мс. Причина этого заключается в том, что имеется задержка в сети 40, которая будет влиять, когда любая оконечная точка сможет обнаружить шторм. Если задержка равна 50 мс, то до трех пакетов может быть на маршруте прежде, чем оконечная точка обнаружит шторм. Аналогично, каждая оконечная точка должна решить, должна ли она сама выполнить глушение самой себя. При типичных вариациях в статистике из-за различий в моменте времени, когда каждая оконечная точка обнаруживает шторм и решает, как смягчить его, будет большее или меньшее количество молчащих оконечных точек, чем ожидаемых. Некоторые будут заглушены немного позже, если недостаточно оконечных точек замолкают, чтобы подавить шторм. В этом процессе имеется случайность, вызванная различными временами, когда оконечные точки выполняют обнаружение шторма и процесс подавления, так же как и случайность канала или дрожание (флуктуация).

Шторм обнаружен (или объявлен), когда количество принятых пакетов аудио в данном интервале времени превышает порог обнаружения.

Обнаружение аудиошторма и подавление

Режим самоконсервации

Цель состоит в том, чтобы предотвратить запирание ViPr терминала аудиоштормом, так как процесс аудио имеет наивысший приоритет. Вызывается только если Режим Защиты Качества Аудио не является активным и послано чрезмерное число пакетов аудио. Этот режим также предотвращает атаки типа "отказ в обслуживании".

Входящие пакеты подсчитываются в течение относительно малого периода времени (100-200 мс), и если порог превышен, тогда любые последующие принятые пакеты отбрасываются в течение этого периода времени.

Режим Защиты Качества Аудио

Цель состоит в том, чтобы ограничить посылку пакетов аудио, чтобы предотвратить перегрузку сети 40 и предотвратить чрезмерный шум и громкость аудио в каждом из удаленных терминалов.

1. Все терминалы собирают статистику обо всех аудиопотоках, включая локальный терминал.

2. Все терминалы независимо обнаруживают возникновение аудиошторма, отслеживая количество входящих каналов, которые активно посылают данные.

3. Каждый терминал независимо решает, прекратить или нет посылать свой поток аудио на основании своей оценки своей локальной передачи аудио и таковой от удаленных терминалов.

Ключевые особенности, которые являются новыми относительно обнаружения и подавления аудио шторма ViPr.

Каждый терминал полностью автономен от других терминалов в решении посылать ли данные аудио.

Тем, что связывает процессы принятия решения всех терминалов вместе, является то, что все терминалы вычисляют приблизительно одинаковую статистику для каждого канала.

Ниже следует в основном описание того, как построить устройство для "Обнаружения Аудио Шторма и Восстановления".

Каждая сторона в конференц-связи (конференц-вызове) посылает пакеты аудио реального разговора через регулярные интервалы времени ко всем другим сторонам в вызове. Первичным способом ограничить сеть 40 и загрузку процессора для каждой стороны является прекращение посылки этих пакетов аудио в течение периодов тишины. В типичном вызове только несколько сторон будут говорить одновременно, а все другие стороны будут находиться в режиме "молчания". Так, каждая сторона будет только активно принимать пакеты от других немногих сторон. Когда новая сторона отвечает на вопрос, логика Обнаружения Активности Аудио будет разрешать передачу пакетов аудио от этой оконечной точки. Аналогично, когда сторона прекращает говорить, логика Обнаружения Активности Аудио будет снова активизировать режим "молчания", чтобы остановить поток пакетов.

Всякий раз, когда возникает ситуация, которая создает большой одновременный аудиоответ, каждая сторона начнет передавать пакеты, так как она выходит из режима "молчания". Когда много потоков аудио активны в одно и то же время, функция смешивания аудио, применяемая в каждой оконечной точке, более интенсивно использует процессор. Имеется также существенное увеличение загрузки сети 40. Это является состоянием, которое называется "Аудиошторм", и нижеследующее описание подробно описывает решение, чтобы обнаруживать и остановить аудио штормы.

Вследствие того, что каждая сторона обрабатывает приходящие пакеты аудио в реальном времени и того, что в течение аудио шторма уже имеется сильно увеличенный трафик сети 40, не существует простого способа использовать вторичную сигнализацию сети 40, чтобы обмениваться информацией об аудио штурме между каждой стороной. Это требует, чтобы каждая оконечная точка независимо обнаруживала аудио шторм. Это также требует, чтобы каждая оконечная точка в вызове поддерживала свою собственную краткосрочную историю пакетов аудио каждой стороны в вызове, включая и саму себя.

Начальное обнаружение аудиошторма является относительно простым. Аудиошторм просто объявляется всякий раз, когда сторона активно принимает данные аудио от по меньшей мере числа сторон, равного "nStormThreshold". Жесткая (аппаратная) часть решает, как управлять этим штормом. Идеальная ситуация заключается в том, чтобы иметь одну(и) и ту(е) же сторону или стороны, которые говорили перед штормом, все еще остающимися слышимыми. Каждая также должна все еще быть способна слышать множество дополнительных сторон так, чтобы они также могли слышать ее реакцию.

История предыдущих пакетов аудио, приходящих от каждой стороны, используется для создания "оценки", которая затем будет решать, какие стороны были самыми последними говорящими сторонами (абонентами). Количество "NsimultaneousTalkers" сторон вверху списка может быть затем использовано, чтобы решить, какие являются немногими выбранными для продолжения передачи после того, как был обнаружен аудиошторм. Так как все оконечные точки сохраняют точную одну и ту же историю пакетов аудио, они должны всегда иметь точный один и тот же список оценок. Если конкретная оконечная точка находится вверху списка, то она должна продолжить передачу; иначе, она должна немедленно прекратить передавать. Другое использование этого списка заключается в том чтобы ограничить, которые стороны декодируются и смешиваются для воспроизведения аудио. Эффекты аудиошторма будут ослабевать и только немногие стороны, находящиеся наверху списка, будут продолжать передавать и будут услышаны.

Последняя оставшаяся вещь состоит в том, чтобы ожидать, пока аудиошторм не завершится, чтобы возобновить нормальную работу конференции. Так как будет иметься точное количество "nSimultaneousTalkers" сторон, передающих изначально, то необходимо ожидать, чтобы было меньше, чем количество "nStormEndThreshold1" сторон, передающих перед объявлением того, что аудиошторм закончился.

Типичный алгоритм оценки должен использовать подсчет пакетов аудио для каждой стороны в течение последних 60 секунд. Этот подсчет затем увеличивается на 100 для каждого предшествующего интервала в 500 миллисекунд, когда по меньшей мере один пакет также был принят от этой стороны. Это продолжается для каждой стороны в обратную сторону за 60-секундную историю до (обнаружения) первого интервала в 500 миллисекунд, не содержащего никаких пакетов. Этот способ оценки благоприятствует тому, чтобы самые недавние говорящие стороны были первыми, а затем - стороны, которые сказали что-нибудь за последние 60 секунд.

Могут использоваться другие более сложные методы оценки, такие как идентификация вручную некоторых сторон в качестве "предъявителей ключа", которые всегда будут оценивать эти стороны как находящиеся вверху списка и поэтому всегда слышимые.

Предложенное решение аудиошторма предполагает, что терминалы должны действовать независимо, чтобы обнаруживать и смягчить шторм (всплеск появления) пакетов аудио. При обнаружении сравнивают частоту принятых пакетов аудио с порогом. Каждый терминал независимо определяет, присутствует ли шторм, и должен ли он продолжать посылать данные аудио или выполнить глушение самого себя. Общий подход, который терминалы ViPr используют совместно, состоит в том, что каждый терминал может оценивать статистику активности разговора других терминалов, так как они будут принимать данные аудио друг друга.

Исходя из моделирования, можно ожидать, что число переданных каналов аудио превысит предел в течение короткого времени, обычно менее чем 300 мс. Причина этого заключается в том, что имеется задержка сети 40, которая будет оказывать влияние, когда любой терминал может обнаружить шторм. Если задержка равна 50 мс, то в маршруте может быть до трех пакетов, прежде чем терминал обнаружит шторм. Также каждый терминал должен решить, выполнить ли глушение самого себя. Учитывая типичные изменения в статистике из-за различий во времени, когда каждый терминал обнаруживает шторм и решает, как его подавить, будет или большее или меньшее количество подавленных терминалов, чем ожидается. Некоторые будут подавлять (глушить) передачу немного позже, если недостаточное количество терминалов молчат, чтобы подавить шторм. В этом процессе имеется случайность, вызванная различными временами, когда терминалы выполняют процесс обнаружения и подавления шторма, а также случайные события или флуктуации канала.

Хронология шторма пакетов аудио

Имеет место большая конференция с более чем 50 участниками. Один или два участника активно говорят, и остальные находятся в режиме прослушивания. Произносится забавное предложение и внезапно более 50 участников начинают смеяться. В каждом ViPr терминале алгоритм VAD (обнаружения речевой активности) начинает обнаруживать увеличение в уровне аудио микрофона, и если это продолжается в течение 60 мс, тогда посылается пачка из 4 или 5 пакетов, и пакеты тогда посылаются в интервалах по 20 мс. Терминалы, которые принимают эту пачку, будут использовать ее для предварительной загрузки буфера смещения во времени (флуктуаций) и начинать воспроизводить принятое аудио. Как только смех спадает, VAD обнаруживает тишину и начнет двухсекундный отсчет обратно до отсечения пакетов.

Координируемая конференция, в которой используется удаленное подавление, является менее требовательной в том, что координатор предоставляет слово участникам. Только те участники, которым дали слово, могут посылать пакеты аудио.

Алгоритм передачи пакета

Пакеты передаются, если выполнены следующие условия:

VAD алгоритм обнаружил речь

И

в координируемой конференции и координатор не заглушил этого участника

ИЛИ

в некоординируемой конференции и нижеследующее является истинным:

шторм аудио пакетов не обнаружен

ИЛИ

шторм аудиопакетов обнаружен,

Участник является важной говорящей стороной

ИЛИ

Был послан ранг участника, основанный на сравнении последних данных аудио с последними данными аудио, принятыми от каждого из других участников.

Обнаружение шторма аудио пакетов

Шторм обнаруживается (или объявляется), когда количество принятых пакетов аудио в данном интервале времени превышает порог обнаружения. Алгоритм является следующим.

Каждый раз, когда пакет принимают, глобальная переменная g_nPktsRcvd увеличивается.

Каждые 100 мс

Если Аудио шторм не обнаружен, BStormDetected устанавливается равной "истина", если g_nPktsRcvd> m_nPktsStormDeclared

Если Аудио шторм обнаружен, BStormDetected устанавливается равной "ложь", если g_nPktsRcvd <m_nPktsStormOver

Установить g_nPktsRcvd равной 0.

Измерение активности говорящей стороны

Активность говорящих сторон измеряется одним из двух способов. Первый способ вычисляет процент от затраченного на разговор времени в течение некоторого интервала, обычно за одну минуту. Его вычисляют только для локальной говорящей стороны и используют следующий алгоритм.

Инициализировать циклический буфер TT_local всеми нулями и индекс (счетчик) indxTT равным 0.

Каждые две секунды и если шторм пакетов аудио не обнаружен, установить 1 в TT_local [indxTT], если локальный участник говорит или установить его в 0 в противном случае. Увеличить indxTT.

Количество единиц в массиве TT_local, разделенное на размер массива, представляет процентное соотношение от времени разговора. Интервал выборки, равный 2 секундам, основан на том, что VAD имеет минимальное время включения, равное 2 секундам. Размер массива TT_local установлен так, чтобы производить выборку последней минуты. Локальная говорящая сторона классифицируется как важная, если разговор был обнаружен в течение 25% последней минуты.

Второй способ измерения активности говорящей стороны использует последний момент, когда пакет был принят или передан. При рассмотрении происхождения шторма пакетов простое использование времени прибытия последнего пакета не будет выдавать полезные результаты. Более интересным является последний момент времени, когда пакет аудио был послан до начала текущего шторма пакетов аудио. Следующий алгоритм отслеживает это время прибытия пакетов.

Если PktRcvTime> PktRcvTimeLast + 1 секунда, то

Последний пакет принят до текущего шторма пакетов аудио и таким образом PktRcvTimeLast копируют в PktRcvTimeLast1.

PktRcvTimeLast = PktRcvTime.

Тот же самый алгоритм используется для передачи пакета аудио, но PktXmtTime заменяет PktRcvTime.

Реализация

В AudioMan вызывается функция SetTalkTimeLast() доступа, если EncoderRdy() возвращает результат "истина" в encoder_decoder_loop() в AudioMan.cpp. Состояние возврата EncoderRdy управляется посредством VAD. Находят SetXmtTimeLast() в AudioStorm.cpp.

Каждые 2 секунды вызывается UpdateTalkerActivity () в Encoder_decoder_loop в AudioMan.cpp. UpdateTalkerActivity() смотрит на состояние eVADstate говорящей стороны VAD, используя функцию IsTalking() доступа, чтобы определить, говорит ли локальный участник. Если разговор обнаружен, тогда "1" загружают в циклический буфер TT_local.

Для каждого принятого пакета вызывается функция SetRecTimeLast(iChannel). Время последнего принятого пакета для этого канала записывают, используя функцию SetRecTimeLast(iChannel) доступа, и увеличивают количество nPktsRcvStorm принятых пакетов для обнаружения шторма пакетов аудио.

Каждые 100 мс StormDetect() использует nPktRcvStorm, чтобы обнаружить, имеет ли место шторм пакетов. StormDetect() расположен вверху цикла while(1) в цикле encoder_decoder_loop(). Если шторм обнаружен, то StormDetect() будет вызывать функцию SetStormMute(истина) доступа VAD, если только локальный участник не является важной говорящей стороной или ранги являются достаточно высокими.

Алгоритм декодирования пакетов

AudioMan выполняется в ядре реального масштаба времени и если загружено больше чем 40 входящими потоками G.722, то будет занимать 100% процессорного времени. Сенсорная панель перестанет отвечать до тех пор, пока количество входящих пакетов аудио не станет меньше 40. (Значение 40 является грубым приближением). Эти значения возможны в большой конференции, если кто-то говорит что-то, на что реагирует большинство участников, например реакция на шутку. AudioMan подсчитывает количество принятых пакетов в течение указанного периода времени. Если подсчет пакетов превышает заданный порог, пакеты аудио, которые прибывают прежде, чем этот период истекает, просто отбрасываются. Количество отброшенных пакетов отслеживается посредством g_nPacketsPoliced, и если более чем нуль отображены в Help (Справка), то отображают экран Show Status (Показать состояние).

Как и во всем в AudioMan, параметрами настройки сервера являются

Audio_MaxReceivedPackets=70

Audio_MaxReceivedPacketsPeriod=40

В этом примере декодируются первые 70 принятых пакетов аудио, принятых в 40 мс период. Любые пакеты, принятые после 70-го, отбрасываются до того, как 40 мс период истечет, и затем процесс запускается снова.

Одной из ключевых "уникальных" особенностей относительно обработки аудиошторма является то, что каждый терминал приходит к "точно" такому же решению независимо "без" каких-либо дополнительных сообщений синхронизации. Это сделано возможным, так как все они принимают одни и те же потоки аудио и все они используют одни и те же правила подсчета оценок.

Следующие заявки включены в настоящее описание по ссылке:

Заявка на патент США № 10/114402 "Videophone And Method For A Video Call",

Заявка на патент США № 10/871852 "Audio Mixer And Method",

Заявка на патент США № 11/078193 "Method And Apparatus For Conferencing With Stream".

Узел может включать в себя элемент, сторону, терминал или участника конференции. Конференция обычно содержит по меньшей мере три узла и может иметь 10 или 20, или даже 50 или 100, или 150 или более узлов.

Количество участников	Общая пропускная способность (Кбит/с)	Пропускная способность с использованием VAD (5 говорящих сторон)	Пропускная способность с использованием VAD (25 говорящих сторон)	Пропускная способность с использованием VAD (все говорящие стороны)	Пропускная способность с использованием управления аудиоштормом (все говорящие стороны)
10	640	320	640	640	640
25	1600	320	1600	6400	640
100	6400	320	1600	6400	640

Общая пропускная способность аудио НИКОГДА не должна превысить 1000 Кбит/с или видео может быть искажено.

Способ управления пропускной способностью аудиошторма ограничивает максимальное количество говорящих сторон 10-ю, чтобы предотвратить ухудшение видео и аудио.

Видеофон

Со ссылками на фиг.8, 9, 10 и 11 устройство 30 отображения, такое как обычная аналоговая камера 32, обеспечиваемая фирмой Sony с функцией S-видео, преобразовывает изображения сцены от устройства 30 отображения в электрические сигналы, которые посылаются по проводам к видео декодеру 34, такому как Philips SAA7114 NTSC/PAL/декодер. Видеодекодер 34 преобразовывает электрические сигналы в цифровые сигналы и выдает их как поток пикселей сцены, например, согласно формату BT 656. Поток пикселей выдается из видеодекодера 34 и разбивается на первый поток и второй поток, идентичный первому потоку. Кодер 36, предпочтительно кодер IBM eNV 420, принимает первый поток пикселей, обрабатывает первый поток и формирует поток данных в формате MPEG-2. Поток данных, произведенный видеокодером 36, сжимается примерно до размера 1/50 по сравнению с данными, которые были сформированы в камере. Поток MPEG-2 является кодированным цифровым потоком и не подвергается буферизации кадров до того, как впоследствии будет пакетирован для минимизации любой задержки. Кодированный MPEG-2 цифровой поток пакетируют с использованием RTP посредством программируемой пользователем вентильной матрицы (FPGA) 38 и программным обеспечением, к которому подается MPEG-2 поток, и передают на сеть 40, такую как Ethernet 802.p или ATM (асинхронной передачи данных) со скоростью 155 мегабит в секунду, используя сетевые интерфейсы интерфейс 42 - интерфейс 44 PLX 9054 PCI. Если требуется, поток видео, ассоциированный с видеомагнитофоном VCR или телевизионным показом, таким как CNN или кинофильм, может быть принят декодером 34 и выдан непосредственно на контроллер 52 дисплея для отображения. Контроллер 46 декодера, расположенный в FPGA 38 и соединенный с декодером 34, управляет работой декодера 34.

Альтернативно, если используется цифровая камера 47, результирующий поток, который сформирован камерой, уже представлен в цифровом формате и не должен быть выдан на декодер 34. Цифровой поток от цифровой камеры 47, который находится в формате BT 656, расщепляется на первый и второй потоки непосредственно от камеры, без прохождения через какой-либо видеодекодер 34.

В другом альтернативном варианте может использоваться камера 48 стандарта FireWire, такая как камера 48 с интерфейсом стандарта 1394 FireWire, чтобы выдавать цифровой сигнал непосредственно на FPGA 38. Камера 48 стандарта FireWire обеспечивает то преимущество, что если формирование потока данных должно иметь место на чуть большем, чем очень короткое расстояние от FPGA 38, то цифровые сигналы могут поддерживаться на этом более длинном расстоянии, например, посредством кабельного соединения от камеры 48 стандарта FireWire. FPGA 38 обеспечивает цифровой сигнал от камеры 48 стандарта FireWire к кодеру 36 для обработки, как описано выше, а также создает поток с низкой скоростью передачи кадров, как описано ниже.

Второй поток подается на FPGA 38, где FPGA 38 и программное обеспечение формируют поток с низкой скоростью передачи кадров, такой как поток JPEG движущихся изображений, который требует малой полосы частот по сравнению с первым потоком. FPGA 38 и основной контроллер 50 с программным обеспечением выполняют кодирование, сжатие и пакетирование в отношении этого потока с низкой скоростью передачи кадров и выдают его на PCI интерфейс 44, который, в свою очередь, передает его сетевому интерфейсу 42 через сетевую интерфейсную плату (СИП) 56 для передачи на сеть 40. Кодированный MPEG-2 цифровой поток и поток с низкой скоростью передачи кадров являются двумя по существу идентичными, но независимыми потоками данных, за исключением того, что поток данных с низкой скоростью передачи кадров масштабируется с уменьшением по сравнению с потоком данных MPEG-2, чтобы обеспечить меньшее представление той же самой сцены относительно потока MPEG-2 и требовать меньшее количество ресурсов сети 40.

По сети 40 каждый цифровой поток передают к требуемому видеофону 15 приемника или видеофонам 15 приемника, если в конференцию вовлечены более двух сторон. Данные маршрутизируют с использованием SIP. Сетевая интерфейсная плата 56 принимающего видеофона 15 принимает пакеты, ассоциированные с первым и вторым потоками данных, и выдает эти данные из пакетов и видеопотока (первого или второго), выбранные основным контроллером, к памяти приема. Основной контроллер 50 принимающего видеофона 15 с программным обеспечением декодирует и расширяет выбранный принятый поток данных и передает его контроллеру 52 дисплея. Контроллер 52 дисплея отображает воссозданные изображения на цифровом плоскопанельном дисплее стандарта VGA, используя стандартные аппаратные средства масштабирования. Пользователь в принимающем видеофоне 15 может выбирать, какой просматривать поток из этих двух потоков данных на сенсорном экране 74, или, если желательно, выбирает оба, и тогда и большое, и малое изображения сцены отображаются, хотя отображение обоих потоков из передающего видеофона 15 обычно не воспроизводится нормально. Описание протоколов для отображения описано ниже. При наличии опции выбирать или большее представление сцены или меньшее представление сцены, пользователь имеет возможность распределить ресурсы системы 10 так, чтобы те личности в данный момент, которые являются более важными для зрителя, были видны на более крупном, более ясном изображении; в то время как те, которых пользователь все еще хотел бы видеть, но не являются настолько важными в этот момент, могут все же быть видны.

Контроллер 52 дисплея вынуждает, чтобы каждый отличный поток видео, если имеются более одного (если имеет место вызов конференц-связи), появлялись рядом на дисплее 54. Изображения, которые сформированы рядом на дисплее 54, обрезаются и не масштабируются посредством уменьшения, так размеры самих объектов в сцене не изменяются, а только удаляются внешние границы с каждой стороны сцены, ассоциированной с каждым потоком данных. Если желательно, изображения из потоков, ассоциированные с меньшими изображениями сцен, могут быть отображены рядом в нижнем правом углу экрана 54 дисплея. Контроллер 52 дисплея обеспечивает стандартное цифровое видео на LCD (ЖК) контроллер 72, как показано на фиг.9. Контроллер 52 дисплея, произведенный фирмой ATI или Nvidia, является стандартным контроллером VGA. ЖК контроллер 72 принимает стандартизированное цифровое видео от контроллера 52 дисплея и делает изображение надлежащим для конкретной используемой панели, такой как панель Philips для Fujitsu.

Чтобы дополнительно расширять отсечение изображения, вместо простого удаления частей изображения, начиная с внешнего края и перемещаясь к центру, часть изображения, которое не показывает какой-либо релевантной информации, отсекается. Если человек, который говорит, появляется с левой или правой стороны изображения, то желательно выполнить отсечение с левой стороны, если человек находится с правой стороны изображения, или с правой стороны, если человек находится с левой стороны изображения, вместо отсечения только с каждого внешнего края, что может привести к тому, что часть человека будет потеряна. Использование отслеживания видео смотрит на изображение, которое сформировано, и анализирует, где встречаются изменения в изображении, чтобы идентифицировать, где в изображении находится человек. Предполагается, что человек будет дополнительно перемещаться относительно других областей изображения, и, идентифицируя это относительное движение, местоположение человека в изображении может быть определено. На основе этого отслеживания видео может быть вызвано такое отсечение, которое происходит на крае или границах, где имеется наименьшая степень изменения. Альтернативно, или в комбинации с отслеживанием видео, может также использоваться отслеживание аудио, чтобы управлять отсечением изображения, которое происходит. Так как видеофон 15 имеет матрицы (наборы) микрофонов, используются стандартные методы триангуляции на основании различных времен, которые требуются для данного звука, чтобы достичь различных элементов массива (набора) микрофонов, чтобы определить, где расположен человек относительно этого массива микрофонов, и так как местоположение массива микрофонов известно относительно сцены, которая отображается, местоположение человека в изображении таким образом становится известным.

Функциональные возможности видеофона 15 управляются сенсорным экраном 74 на мониторе. Сенсорный экран 74, который является стандартным стеклянным сенсорным экраном, выдает необработанные сигналы на контроллер 76 сенсорного экрана. Необработанные сигналы воспринимаются ультразвуковыми волнами, которые создаются на стекле, когда пользователь касается стекла в данном местоположении, как известно в данной области техники. Контроллер 76 сенсорного экрана затем принимает необработанные сигналы и преобразовывает их в значимую информацию в отношении позиции X и Y на дисплее и передает эту информацию на основной контроллер 50.

Если телевизионное соединение или соединение с видеомагнитофоном доступны, подача (сигналов) для телевидения или кинофильма обеспечивается на декодер 34, где такая подача управляется как любой другой сигнал видео, принятый видеофоном 15. Телевидение или кинофильм могут появляться помимо сцены от видеосоединения с другим видеофоном 15 на дисплее 54.

Аудиопоток сцены по существу следует параллельным и аналогичным путем с потоком видео-аудио, за исключением того, что поток аудио обеспечивается от приемника 58 аудио, такого как микрофон, звуковой платы, головного телефона или микротелефонной трубки к аудиоинтерфейсу 60 CS Crystal 4201 или например, кодеку, который выполняет аналого-цифровое и цифроаналоговое преобразование сигналов, а также управляет громкостью и смешением (микшированием), которое оцифровывает аудио сигнал, и выдает его к цифровому сигнальному процессору (DSP, ЦСП) 62 типа TCI 320C6711 или 6205. DSP 62 затем пакетирует цифровой поток аудио и передает цифровой поток аудио к FPGA 38. FPGA 38, в свою очередь, выдает его на PCI интерфейс 44, где он затем передается на сетевую интерфейсную плату 56 для передачи в сеть 40. Поток аудио, который принят принимающим видеофоном 15, передается к FPGA 38 и затем на DSP 62, и затем к аудиоинтерфейсу 60, который преобразовывает цифровой сигнал в аналоговый сигнал для воспроизведения на динамиках 64.

Сетевая интерфейсная плата 56 помечает временными метками каждый пакет аудио и пакет видео, который передается к сети 40. Скорость, с которой аудио и видео, которые приняты видеофоном 15, обрабатываются, является достаточно быстрой для того, чтобы человеческий глаз и ухо, после их прослушивания не могли различить какое-либо рассогласование аудио со связанным во времени видеосцены. Ограничение, меньшее 20-30 миллисекунд, помещают в обработку информации аудио- и видеосцены, чтобы поддерживать эту ассоциацию видео- и аудиосцены. Для того чтобы обеспечить, чтобы аудио- и видеосцены находились в синхронизации, когда они принимаются в принимающем видеофоне 15, просматривается временная метка каждого пакета, и соответствующие основанные на аудио пакеты и основанные на видео пакеты совмещаются видеофоном приема 15 и соответственно воспроизводятся по существу в одно и то же время, так что не имеется никакого рассогласования, которое является заметным для пользователя, в видеофоне 15 приемника для видео- и аудиосцены.

Плата ENC-DSP содержит MPEG-2 кодер IBM eNV 420 и схему поддержки, DSP 62 для кодирования и декодирования аудио и PCI интерфейс 44. Она содержит аппаратные средства, которые необходимы для (обеспечения) полных функциональных возможностей терминала видеофона 15, заданных высокопроизводительной платформой ПК 68 и дисплеем 54 системы 10. Она является полноразмерной PCI 2.2 - совместимой конструкцией. Камера, микрофон(ы), и динамики 64 взаимодействуют с этой платой. DSP 62 будет для аудио выполнять кодирование, декодирование, смешивание, размещение стерео, регулировку уровня, заполнение промежутков, пакетирование и другие функции аудио, такие как AEC (компенсация акустического эха, КАЭ) стерео, управление лучом, подавление шума, отмена щелчка клавиатуры или дереверберация. FPGA 38 разработан, используя инструментальные средства Celoxia (Handel-C), и является полностью реконфигурируемой. Топология поддерживает части в диапазоне 1-3 миллиона логических вентилей.

Эта плата включает в себя микросхему интерфейса цифровой камеры 47, основанной на аппаратных средствах или на "видео DSP" многоканальный интерфейс видеодекодера 34, наложение видео с использованием входных и выходных соединителей стандарта DVI, вплоть до возможностей полностью немого буфера кадров с наложением видео.

Используя видеосигнал в стандарте NTSC или PAL, кодер 36 должен сформировать 640×480, и предпочтительно 720×480 или с еще лучшим разрешением высококачественный поток видео. Скорость передачи в битах должна управляться так, чтобы максимальное количество битов на кадр были ограничены, чтобы предотвратить задержку на передачу сигналов по сети 40. Декодер 34 должен начать декодировать вырезку (срез) после приема первого макроблока данных. Некоторая буферизация может потребоваться, чтобы скомпенсировать незначительную флуктуацию и таким образом улучшить изображение.

MPEG-2 широко используется и развернут, является базовым для DVD и VCD кодирования, цифровых видеомагнитофонов и устройств смещения времени, таких как TiVo, а также как DSS и другого вещания цифрового TV. Обычно рассматривается как нормальный выбор передачи видеосигнала от 4 до 50 Мбит/секунду. Из-за его широкого использования, относительно низкой стоимости, высоко интегрированных решений для декодирования и более последнее - кодирования, в настоящее время (он) является коммерчески доступным.

MPEG-2 должен пониматься как синтаксис для кодированного видео вместо стандартного метода сжатия. В то время как технические требования определяют синтаксис и способы кодирования, имеется очень широкий диапазон в использовании этих способов до тех пор, пока следуют определенному синтаксису. По этой причине обобщения относительно MPEG-2 часто вводят в заблуждение или являются неточными. Необходимо добраться до подробностей более мелкого уровня относительно специфических способов кодирования и намеченных приложений, чтобы оценить производительность MPEG-2 для конкретного применения.

Представляющими интерес для проекта видеофона 15 являются вопросы кодирования и декодирования с низкой задержкой, а также вопросы, связанные с сетью 40. Имеются три первичные проблемы в MPEG-2 алгоритме, которые должны быть поняты, чтобы обеспечить видео высокого качества с малой задержкой по сети 40:

= структура GOP (Группа Изображений) и ее влияние на задержку

= влияние скорости передачи информации в битах, вариации размера кодированного кадра и буфера VBV на задержку и требования сети 40

= влияние структуры GOP на качество с потерей пакетов

Структура GOP и задержка

MPEG-2 определяет 3 вида кодированных кадров: I, P и B. Наиболее общая структура GOP, находящаяся в использовании, имеет длительность 16 кадров:

IPBBPBBPBBPBBPBB. Проблема с этой структурой заключается в том, что каждый последующий кадр B, так как кадр B является движением, оцененным исходя из предыдущего и последующего кадров, требует, чтобы последующие кадры были захвачены перед тем, как может начинаться кодирование кадра B. Так как каждый кадр имеет длительность 33 мс, это добавляет минимум 66 мс дополнительной задержки для этой структуры GOP по сравнению с таковой без B кадров. Это приводит к структуре GOP с малой задержкой, которая содержит только I и/или кадры P, определенные в MPEG-2 спецификациях как кодирование SP@ML (Простой профиль).

Скорость передачи информации в битах, размер кодированного кадра и VBV

Как только B кадры удалены, чтобы минимизировать задержку кодирования, GOP состоит из I кадров и кадров P, которые являются относительными для I кадров. Поскольку I кадр является кодированным полностью внутрикадровым образом, требуется много битов, чтобы выполнить это, и меньшее количество битов для последующих P кадров.

Следует заметить, что I кадры могут быть в 8 раз большего размера, чем кадр P, и в 5 раз больше номинальной скорости передачи (частоты следования) информации в битах. Это имеет прямое воздействие на требования сети 40 и задержку: если имеется ограничение полосы частот, I кадры будут буферизированы с ограничением сети 40, приводя к добавленной задержке времени передачи множества кадров для передачи в ограниченном сегменте. Этот буфер должен быть согласован в приемнике, потому что скорость воспроизведения устанавливается посредством видео, а не полосой частот сети 40. Выборка, используемая для вышеупомянутых данных, была сценой офиса с малым движением; в контенте с большим движением с изменениями сцены кадрам будут назначены больше или меньше битов в зависимости от контента, при нескольких больших P кадрах, встречающихся в изменениях сцены.

Чтобы управлять этим поведением, MPEG-2 реализует буфер VBV (Верификатор буферизации видео, ВБВ), который допускает степень управления соотношением между максимальным размером закодированного кадра и номинальной скоростью передачи информации в битах. Сильно ограничивая VBV так, чтобы I кадры были ограничены менее чем 2-кратным размером, указанным номинальной скоростью передачи информации в битах, добавленная задержка буферизации может быть ограничена временем 1 дополнительного кадра. Стоимостью ограничения размера VBV является качество картинки: причина для больших I кадров должна обеспечить хорошее основание для последующих P кадров, и качество серьезно ухудшается при более низких скоростях передачи информации в битах (<4 Мбит), когда размер I кадров ограничен. Полагая, что при 2 Мбит средний размер кадра равен 8 Кбайт, и даже двукратный этот размер не является достаточным, чтобы закодировать JPEG изображение 320×240 с хорошим качеством, которое является подверженным DCT-сжатию, аналогично I кадру.

Переход к кодированию только I кадров допускает более непротиворечивый размер кодированного кадра, но с дальнейшим ухудшением качества. Кодирование только I кадров с низкой скоростью следования битов не использует преимущества больших возможностей сжатия алгоритма MPEG-2.

Спецификация MPEG-2 определяет режимы CBR (постоянная скорость передачи информации в битах) и VBR (переменная скорость передачи информации в битах) и учитывает переменную структуру GOP в пределах потока. Режим CBR определен, чтобы формировать постоянное количество битов для каждой GOP, используя заполнение по мере необходимости. VBR предназначен, чтобы обеспечить постоянное качество, допуская вариации при кодировании полосы частот, с трудом разрешая распределить потоку больше битов для кодирования областей, пока это компенсируется более низкими скоростями передачи информации в битах в более простых секциях. VBR может быть реализован способами с двумя проходами или единственным проходом. Переменная структура GOP допускает, например, размещение I кадров на границах перехода сцены, чтобы устранить видимые артефакты сжатия. Из-за требования малой задержки и необходимости небольшого предвидения, чтобы реализовать VBR или переменную GOP, эти режимы имеют небольшой интерес для применения в видеофоне 15.

Поскольку P и B кадры в типичной структуре GOP являются зависимыми от I кадра и предшествующих P и B кадров, потеря данных воздействует на все кадры после ошибки до следующего I кадра. Она также воздействует на задержку начала, например, при переключении каналов в системе DSS 10, где декодер 34 ожидает I кадры, прежде чем он сможет начать отображение изображения. По этой причине длина GOP, структура и скорость передачи информации в битах должны быть настроены на приложение и систему 10 поставки. В случае совмещения реального времени, использующего IP, используется ненадежный транспортный протокол, такой как RTP или UDP, потому что последний пакет должен быть обработан как потерянный, так как вы не можете допустить задержку, требуемую для того, чтобы иметь дело с надежным квитированием протокола и повторной передачей. Различный анализ был сделан в отношении влияния потери пакета на качество видео с результатами, показывающими, что для типичной структуры GOP IPB потеря 1% пакетов приводит к потере 30% кадров. Более короткие структуры GOP, и в конечном счете только потоки I кадров (с потерей качества) помогают этому в некоторой степени, и немного могут помочь методы FEC (прямого исправления ошибок), когда происходит потеря, но несомненно одной из проблем, связанных с MPEG-2, является та, что он не очень терпим к потере данных.

Структура GOP, названная (как) непрерывное кодирование P кадров, направлена на решение всех вышеперечисленных проблем и обеспечивает превосходное качество видео при относительно низких частотах следования битов для видеофона 15. Непрерывное кодирование P использует способность к межкадровому кодированию макроблоков кадра в пределах кадра P. Посредством кодирования псевдослучайного набора макроблоков размером 16×16 пикселей в каждом кадре и кодирования движения других эквивалент битов I кадра распределяется в каждом кадре. Реализуя псевдослучайное макровыделение блока, чтобы гарантировать, что все блоки обновлены в частотно-временном масштабе, начало и изменение сцены обрабатываются разумным способом.

IBM реализовала этот алгоритм для кодера S420, устанавливая частоту DCT обновления полного кадра равным 8 кадрам (3,75 раза в секунду). Результаты для типичного офисного контента и контента конференции весьма внушительны. Задержка кодирования, вариации размера кодированного кадра и поведение потерь пакетов являются почти идеальными для видеофона 15. Просмотр закодированных выборок показывает, что для изменений сцены и высокодинамичного контента эти артефакты кодера 36 являются видимыми, но для обычного контента с головами участвующих говорящих сторон качество является очень хорошим.

Высококачественное аудио является существенной предпосылкой для эффективных обменов. Высокое качество определяется как дуплексное, ширина полосы частот равна 7 кГц, (для телефона - 3,2 кГц), отношение сигнал-шум> 30 дБ, никакого заметного эха, отсечения или искажения. Инсталляция будет очень простой, использующей настолько мало кабелей, насколько это возможно. Бортовая (встроенная) диагностика укажет проблему и как ее исправить. Звук от динамиков 64 будет свободен от громких щелчков и гудения, а уровни звука или слишком высокими или слишком низкими.

Сигнал аудио от отсутствующих или запоздавших пакетов может быть "заполнен" на основании предшествующего сигнала аудио. Буфер аудио должен быть приблизительно 50 мс в качестве баланса между флуктуацией сети 40 и добавлением задержки аудио. Текущий размер пакета из 320 выборок или 20 мс может быть уменьшен для уменьшения задержки кодирования и декодирования. Однако 20 мс является стандартной длительностью данных для RTP пакетов.

Некоторые из процессов, описанных ниже, доступны в коммерческих продуктах. Однако вследствие причин стоимости и интеграции они должны быть реализованы на DSP 62. В другом варианте осуществления второй DSP 62 может выполнять компенсацию акустического эха вместо только одного DSP 62, также выполняющего эту функцию.

Аудиосистема 10 имеет передающую и принимающую секцию. Секция передачи состоит из следующего:

Микрофоны

Одной из основных жалоб телефона диктора является глухой звук, который слышат на удаленном конце. Этот глухой звук возникает из-за комнатной реверберации и наилучшим образом понимается как отношение мощности отраженного (отражающегося) звука по отношению к мощности непосредственного звука. В настоящее время лучший способ улучшить считывание заключается в том, чтобы расположить микрофоны близко к диктору и таким образом увеличить мощность непосредственного (прямого) звука. В офисной среде микрофоны могут быть расположены в мониторе персонального компьютера 68, на терминале видеофона 15 и на "белой доске" (проекционном оборудовании для компьютеризованных презентаций).

Автоматическая регулировка усиления

Коэффициент усиления для предварительного усилителя для каждого микрофона автоматически настраивается так, что динамический диапазон АЦП (аналого-цифрового преобразователя) используется полностью. Коэффициент усиления предварительного усилителя должен быть послан другим процессам аудио, таким как AEC (КАЭ) и уменьшение шума.

Кодек

В его самой простой форме он представляет собой устройство АЦП. Однако несколько компаний, таких как Texas Instruments и Ananlog Devices Inc, имеют кодеки с аналоговыми усилителями и аналоговыми мультиплексорами. Также, на кристалле находится ЦАП (цифро-аналоговый усилитель) с аналогичным средством управления. Автоматическая регулировка усиления, описанная в предыдущем разделе, реализуется в кодеке и управляется посредством DSP 62.

Уменьшение шума

Два способа уменьшения шума могут использоваться, чтобы улучшить отношение SNR (сигнал/шум). Первый способ обычно называется стробированием шума, в соответствии с которым включают и выключают канал в зависимости от уровня присутствующего сигнала. Вторым способом является адаптивное подавление помехи (ANC, АПМ) и вычитает нежелательный шум из сигнала микрофона. В офисной среде возможно использование ANC, чтобы удалить объявления громкоговорящей системы, шум вентилятора и в некоторых случаях - даже щелчки клавиатуры.

Алгоритмы уменьшения шума или стробирования доступны в коммерческих пакетах редактирования аудио, таких как Cool Edit и Goldwave, которые могут применять специальные эффекты, удалять скрип и шум щелчка из записей, а также удалять шипение из записей на магнитную ленту.

Компенсация акустического эха

Эхо слышат, когда голос говорящей стороны возвращается диктору после более чем 50 мс. Эхо очень отвлекает и таким образом должно быть удалено. Двумя источниками эха являются эхо линии и акустическое эхо. Эхо линии возникает из-за характеристик телефонной системы 10 с двумя линиями. PSTN (коммутируемая телефонная сеть общего пользования) удаляет это эхо, используя компенсатор эха линии (КЭЛ, LEC). При использовании телефонной дикторской системы 10 акустическое эхо имеет место между телефонным динамиком и микрофоном. Звук от удаленного динамика воспринимается удаленным микрофоном и возвращается диктору. Компенсация акустического эха (КАЭ, AEC) более трудна чем LEC, так как акустика помещения больше сложна для моделирования и может резко изменяться при движении людей. Имеются много продуктов AEC в диапазоне от автономных устройств типа ASPI EF1210 до объектных модулей Signal Works, оптимизированных для выполнения на платформах DSP 62.

Автосмешивание

Автосмешивание выбирает, сигналы какого микрофона нужно смешивать вместе и посылать на монофонический выход смесителя (микшера) к кодеру 36. Критерии выбора основаны на использовании микрофонов вблизи самого громкого источника или использовании микрофонов, которые принимают звук, который является выше порогового уровня. Автосмесители коммерчески доступны от различных продавцов и используются в системах телевизионного образования и организации телеконференций.

Кодирование

Чтобы уменьшить полосу частот передачи данных, сигнал аудио сжимают до более низкой скорости передачи информации в битах, пользуясь преимуществом типовых характеристик сигнала и нашим восприятием речи. В настоящее время кодек G.722 предлагает наилучшее качество аудио (ширина полосы частот 7 кГц, 14 битов) при разумной скорости передачи информации в битах равной 64 кбит/с.

Передача RTP

Кодированные данные аудио сегментируются на сегменты 20 мс и посылаются в качестве пакетов согласно протоколу в реальном масштабе времени (RTP). RTP был специально разработан для обмена данными в реальном масштабе времени, требуемом для приложений конференц-связи и VoIP (передачи речи по IP).

Принимающей секцией являются

Прием RTP

RTP пакеты, содержащие потоки аудио от одного или более удаленных местоположений, помещают в их соответствующие буфера. Отсутствующие или запоздавшие пакеты обнаруживают, и эту информацию передают на обработчик промежутка (отсутствия сигнала). Пакеты, следующие не по порядку, являются специальным случаем запоздавших пакетов и подобно запоздавшим пакетам, вероятно, должны быть отброшены. Альтернатива заключается в том, чтобы иметь буфер для задержки воспроизведения сигнала аудио в течение длительности по меньшей мере одного пакета. Размер буфера должен быть ограничен так, что задержка сквозной (от одного конца до другого) передачи должна быть не больше чем 100 мс.

Декодирование

Поток аудио G.722 декодируется в ИКМ-выборки (импульсно-кодовой манипуляции) для кодека.

Обработка промежутка (отсутствия сигнала)

В любой сети RTP пакеты будет потеряны или разрушены. Поэтому обработчик промежутка будет "заполнять" отсутствующие данные на основании спектра и статистик предыдущих пакетов. Как минимум, нули должны быть добавлены в поток данных, чтобы составить данные, но могут использоваться спектральная интерполяция или алгоритм экстраполяции, чтобы заполнить данные.

Буферизация

Сетевая флуктуация (смещение во времени) будет требовать буферизации, чтобы обеспечить непрерывное воспроизведение аудио. Этот буфер вероятно будет корректировать свой размер (и, следовательно, время ожидания) на основании компромисса между краткосрочной статистикой флуктуации и влиянием времени ожидания.

Управление частотой следования в битах

Номинальная типовая частота следования в битах для терминала видеофона 15 составляет 16 кГц. Однако небольшие различия будут существовать и нуждаться в обработке. Например, предположим, что видеофон 15 Северный производит выборку с точной частотой 16001 Гц, в то время как видеофон 15 Южный производит выборку с частотой 15,999 Гц. Таким образом Южный терминал будет накапливать на 1 выборку в секунду больше, чем он выдает на динамик, и Северный терминал будет работать при дефиците в равном количестве. Долгосрочная статистика в отношении принимающего буфера будет способна определить, что имеется разность частоты выборки, и может быть вычислен соответствующий коэффициент интерполяции (для видеофона 15 Северный) или уменьшения размера изображения (для видеофона 15 Южный).

Регулирование громкости

Настройка громкости (звука), исходящего из динамиков 64, обычно делается удаленными слушателями. Лучшим способом может быть автоматическая настройка звука от динамиков 64 на основании того, как громко он звучит для микрофонов в помещении. Другие факторы, такие как фоновый шум и собственные предпочтения слушателя, могут быть приняты во внимание.

Стереоразмещение

Удаленные дикторы из различных местоположений могут быть помещены в слуховое поле. Таким образом, человек от местоположения А последовательно будет приходить слева, человек из местоположения B - из середины, и человек из местоположения C - справа. Это размещение облегчает возможность следить за тем, кто говорит.

Динамики

Качество звука до некоторой степени определяется качеством динамиков 64 и корпуса. В любом случае для терминала видеофона 15 используются самоусиленные динамики 64.

Дифференцирование

Существующие системы конференц-связи, например PolyCom Soundstation, предлагают удовлетворительное, но с ограниченной полосой частот, дуплексное качество аудио. Однако ширина полосы частот ограничена 3500 Гц и результирующее качество звука напрягает ухо и особенно при различении "щелевых" звуков.

Видеофон 15 расширяет ширину полосы частот до 7 кГц и выполняет автосмешивание множества микрофонов, чтобы минимизировать реверберацию помещения. Когда говорят трое или более людей, каждый из удаленных участников будет помещен в уникальное местоположение в поле стерео звука. Объединенная с высококачественным восприятием аудио и увеличенной шириной полосы частот, конференция по сети 40 быстро приблизится к качеству, присущему человеку.

Система аудио 10 использует множество микрофонов для лучшего захвата звука и широкополосный кодер (G.722) для улучшенной точности, чем в настоящее время предлагается различными имеющимися платными системами. Дополнительно, для конференций с множеством сторон будут реализованы стереоразмещение удаленных говорящих сторон и система 10 компенсации акустического эха, чтобы обеспечить работу со свободными руками. Регулирование громкости в помещении будет управляться автоматически единственным средством управления для конечного пользователя, чтобы скорректировать общий уровень звука.

В сети 40 видеофона 15 шлюз 70 подключает что-то не-SIP к среде SIP. Часто имеются электрические различия, а также различия протокола. Большинство шлюзов 70 подключает другой телефон или устройства видеоконференции к системе 10 видеофона 15.

Шлюзы 70 различаются интерфейсами; одной стороной является сеть 40, для видеофона 15 это сеть Ethernet или ATM. Внешняя сторона может быть аналоговой телефонной линией или портом RS-232. Тип, количество и характеристики портов отличают один шлюз 70 от другого. На стороне сети 40 имеются транспортные протоколы, такие как RTP или AAL2, и протоколы сигнализации, такие как SIP, Megaco или MGCP.

С внешней стороны может иметься широкое разнообразие протоколов в зависимости от предоставляемых интерфейсов. Некоторыми примерами могут быть ISDN (цифровая сеть связи с комплексными услугами) (Q.931) или сигнализация POTS (простой старой телефонной системы). Шлюзы 70 PSTN подключают линии PSTN к системе 10 видеофона 15 на месте. Шлюзы 70 PBX (офисной телефонной станции) позволяют системе 10 видеофона 15 эмулировать частный телефон, чтобы обеспечить совместимость с существующим локальным PBX. Шлюзы 70 PSTN подключают неозвученные аналоговые телефоны с системой 10 видеофона 15. Шлюзы 70 H.323 соединяют систему 10 H.323 с системой 10 видеофона 15, на основании SIP. Он представляет собой шлюз 70 с единственной сигнализацией - сервер 66 аудиовизуальной информации выполняет преобразование H.261 в MPEG.

Тремя разрешающими технологиями для видеофона 15 являются Протокол Инициирования Сеанса связи (SIP), Протокол Описания Сеанса связи (SDP) и транспортный протокол реального масштаба времени (RTP), все из которых включены в настоящее описание по ссылке.

SIP является протоколом сигнализации для инициализации, управления и завершения речевых и видеосеансов связи в сетях с пакетной передачей.

SDP предназначен для описания мультимедийных сеансов связи с целью объявления сеанса связи, приглашения сеанса связи и других форм инициирования мультимедийного сеанса связи. SIP использует SDP, чтобы описать аудиовизуальные сеансы связи.

RTP обеспечивает сквозные транспортные функции сети 40, подходящие для приложений, передающих данные в реальном масштабе времени, таких как аудио, видео или данных моделирования, для многоадресных или одноадресных услуг сети 40. SIP использует RTP для транспортировки мультимедийного сеанса связи.

Видеофон 15 может выполнять конференции с тремя или более сторонами без использования какого-либо моста конференц-связи или MSU. Это выполняется посредством использования потоков ATM "точка - многоточка", как установлено посредством SIP. Более конкретно, когда MPEG-2 поток и поток с низкой скоростью передачи кадров пакетируется для передачи на сеть 40, информация заголовка для каждого из пакетов идентифицирует адреса всех принимающих видеофонов 15 из конференции, как известно в данной области техники. Из этой информации, когда пакеты передаются к сети 40, SIP устанавливает необходимую связность для различных пакетов, чтобы они достигли требуемых адресатов видеофона 15.

В качестве примера конференции, которая не использует никакого моста конференц-связи, рассмотрим 10 видеофонов 15 в дискретных местоположениях, которые являются сторонами в конференции. Каждый видеофон 15 формирует поток, основанный на аудио, и основанный на MPEG-2 поток и поток, основанный на низкой скорости передачи кадров. Однако каждый видеофон 15 не будет посылать никакой из этих потоков назад к себе, так что по существу при 10-сторонней конференции видеофонов 15 каждый обменивается с девятью другими видеофонами 15. В то время как может иметь место ситуация, что видеофон 15 обменивается с собой, чтобы максимизировать использование ширины полосы частот, видео, сформированное любым видеофоном 15 и, если желательно, аудио, сформированное видеофоном 15, может быть показано или прослушано, когда оно по существу возникает на других видеофонах 15, но через внутренний канал, который будет описан ниже, который не требует никакого использования ширины полосы частот сети 40.

Во время конференции каждый видеофон 15 принимает девять потоков данных, основанных на аудио. Три основанных на MPEG-2 потоков данных и шесть потоков данных, основанных на низкоскоростной передаче кадров. Если необходимо, приемник может выбирать до девяти потоков, основанных на низкой скорости передачи кадров, так что дисплей 54 показывает только меньшие изображения каждого видеофона 15, или до четырех основанных на MPEG-2 потоков данных, когда дисплей 54 заполнен четырьмя изображениями от четырех видеофонов 15 из конференции без показа изображения для потоков, основанных на низкой скорости передачи кадров, так как не имеется никакого места на дисплее 54 для них, если отображаются четыре основанных на MPEG-2 потока. Имея показываемыми три основанных на MPEG-2 потока, это позволяет показывать шесть потоков, основанных на низкой скорости передачи кадров. Каждый из потоков формируется так, как описано выше, и принимается так, как объяснено выше для различных видеофонов 15.

Если желательно показывать больше чем четыре больших изображения на конференции, то способом, которым это выполняется, является соединение дополнительных видеофонов 15 вместе, так чтобы дисплеи различных видеофонов 15 были выстроены в линию рядом друг с другом, как показано на фиг.7. Один видеофон 15 может быть главным, и когда каждый дополнительный видеофон добавляется, он становится подчиненным главному видеофону 15, который управляет отображением 54 больших и малых изображений на различных видеофонах 15.

В терминах протоколов для определения, какое изображение показывается как большое и какое изображение показывается как маленькое на дисплеях видеофонов 15 из конференции, одним предпочтительным протоколом является тот, при котором три самые последние говорящие стороны отображаются как большие, а другие стороны показываются как маленькие. То есть сторона, которая в настоящее время говорит, и две предыдущие говорящие стороны показываются как большие. Так как каждый видеофон 15 из конференции принимает все основанные на аудиопотоки конференции, каждый видеофон 15 с его основным контроллером 50 могут определять, где имеет место разговор в данный момент, и вынудить сетевую интерфейсную плату 56 принять MPEG-2 поток, связанный с видеофоном 15, из которого исходит разговор, и не принимать ассоциированный поток с низкой скоростью передачи кадров. В другом протоколе один видеофон 15 установлен как ведущий или координирующий видеофон 15, и ведущий видеофон 15 воспринимает, что каждый другой видеофон 15 видит в виде больших и маленьких изображений. В еще одном протоколе выбор изображений относительно того, какое является большим и какое маленьким, является фиксированным и остается таким же в течение всей конференции. Протокол может быть таким, что каждый видеофон 15 может выбирать, какие изображения он хочет отображать, которые он принимает. И основанный на MPEG-2 поток и поток с низкой скоростью передачи кадров передаются на сеть 40 к принимающим видеофонам конференции. Соответственно, оба потока, основанных на видео, доступны для отображения на каждом принимающем видеофоне 15 в зависимости от протокола для отображения 54, который выбран.

В отношении потоков, основанных на аудио, которые передаются каждым видеофоном 15, для дальнейшего эффективного использования ширины полосы частот и способствования в обработке аудио посредством уменьшения требований к обработке, имеющихся в любом передающем видеофоне 15 или принимающем видеофоне 15, основанный на аудио поток может передаваться видеофоном 15 только когда имеется аудио выше заранее определенного порога в децибелах в передающем видеофоне 15. Передача только основанных на аудио потоков, которые имеют достаточно громкий звук, в предположении, что порог был калиброван для того, чтобы быть удовлетворяемым или превышенным, когда имеет место разговор, не только устраняет необходимость посылки и приема постороннего фонового шума, который по существу ничего не дает, а только использует полосу частот, но помогает в выборе потока MPEG-2, связанного с разговором, так как принимаются только потоки аудио, которые имеют разговор.

Как упомянуто выше, если заданный видеофон 15 желает видеть свое собственное изображение, которое выдается к другим видеофонам 15, тогда поток с низкой скоростью передачи кадров, который сформирован FPGA 38, посылают в локальную память в видеофоне 15, но без какого-либо сжатия, как может иметь место для потока с низкой скоростью передачи кадров, который должен быть пакетирован и послан по сети 40 от видеофона 15. Из этой локальной памяти основной процессор с программным обеспечением будет работать над ним и вызывать его отображение в качестве маленького изображения на дисплее 54.

Кроме того, видеофон 15 предусматривает управление - какие потоки аудио или видео, которые он принимает от сети 40, должны быть слышимы или видимы. В ситуациях, когда конференция имеет более сторон, чем пользователь видеофона 15 желает видеть или слышать, пользователь видеофона 15 может выбирать только видеть или только слышать подмножество потоков видео или аудио, которые составляют полную конференцию. Например, в конференции со 100 сторонами пользователь выбирает видеть три из потоков видео в качестве больших изображений на экране и 20 потоков видео в качестве маленьких изображений на экране для общего количества из 23 изображений из возможных 100 изображений, которые можно было бы показать. Пользователь видеофона 15 выбирает три самые громкие говорящие стороны, чтобы они появлялись как большие изображения, и затем выбирает через сенсорный экран 74 стороны конференции, которые перечислены на странице сенсорного экрана, чтобы они также были отображены как маленькие изображения. Другие протоколы могут быть выбраны, например 20 изображений, которые показываются как маленькие изображения, могут быть последними 20 говорящими сторонами в конференции, начиная со времени, когда конференция началась, и каждая сторона представилась. Управляя количеством показанных потоков видео, организация применяется к конференции, и использование ресурсов видеофона 15 лучше распределяется.

В отношении различных изображений, которые показываются на экране, выбор может быть связан с каждым изображением. Например, одно изображение может быть выбрано координатором (ведущим) конференц-связи, два из изображений могут быть основаны на последних/самых громких говорящих сторонах в данное время в конференции, и другое изображение может быть связано с человеком, которого пользователь выбрал из всех других участников конференции. Таким образом, каждый участник или пользователь конференции могут потенциально видеть различный выбор изображений из общего количества участников конференции. Максимальной шириной полосы частот, которая вследствие этого необходима, является та, которая служит для одного потока видео, посылаемого сети, и четырех потоков видео, принимаемых из сети, независимо от числа участников конференции.

Что касается потоков аудио, в видеофон 15 может быть введено ограничение о том, что только потоки аудио, связанные с тремя самыми громкими говорящими сторонами, выбираются в качестве слышимых, в то время как их соответствующие изображения показываются на экране. DSP 62 может анализировать потоки аудио, которые приняты, и разрешать для воспроизведения только три потока аудио, связанные с самыми громкими говорящими сторонами, и в то же самое время выдавать команду сетевому интерфейсу 42 принимать только первые потоки видео больших изображений, связанные с тремя потоками аудио, имеющими самые громкие говорящие стороны. Вообще говоря, чем больше людей, которые говорят в одно и то же время, тем больше происходит путаницы и имеет место меньшее понимание. Таким образом, управление пользователем осуществляется в отношении потоков аудио, чтобы ввести некоторый уровень их организации.

В качестве части средств управления в отношении потоков аудио, как упомянуто выше, каждый видеофон 15 выдает поток аудио, только если шум вокруг этого видеофона 15 является выше порога. Предпочтительно, этот порог является динамическим и основан на уровне шума трех самых громких потоков аудио, связанных с тремя самыми громкими в данное время говорящими сторонами. Это приводит к тому, что так как для потока аудио, который должен быть рассмотрен в качестве одного из потоков аудио с тремя самыми громкими говорящими сторонами, уровень шума других потоков аудио должен контролироваться и должен быть идентифицирован в отношении их уровня шума. DSP 62 после приема потоков аудио от сетевого интерфейса 42 через сеть 40 выполняет просмотр потока аудио и идентифицирует эти три потока, имеющих самый громкий шум, а также сравнивает уровень шума трех принятых потоков аудио, которые были идентифицированы с тремя самыми громкими говорящими сторонами, с уровнем шума сцены вокруг видеофона 15. Если уровень шума от сцены вокруг видеофона 15 больше, чем любой из принятых потоков аудио, то видеофон 15 посылает свой поток аудио к сети 40. Этот тип независимого анализа посредством DSP 62 происходит в каждом из видеофонов в конференции и таким образом является распределенным анализом по всей конференции. Каждый видеофон, независимый от всех других видеофонов, выполняет свой собственный анализ в отношении потоков аудио, которые он принимает, которые по определению только были выданы соответствующим видеофоном 15 после того, как соответствующий видеофон 15 решил, что шум вокруг его сцены является достаточно громким, чтобы гарантировать, что в данное время он является одним из трех самых громких. Каждый видеофон 15 затем берет эту принятую информацию потока аудио и использует ее как основание для сравнения со своим собственным уровнем шума. Каждый видеофон 15 таким образом выполняет свое собственное определение порога.

Альтернативный путь выполнения этого распределенного анализа заключается в том, что каждый видеофон после определения с помощью своего DSP 62 того, каким, как он полагает, должен быть порог, может посылать этот порог всем другим видеофонам конференции, так что все видеофоны могут выполнять просмотр того, что все другие видеофоны полагают, каким должен быть этот порог, и могут, например, усреднить пороги, идентифицировать порог, который они будут применять в отношении своей сцены.

Используя методику выбора потоков видео из трех самых громких говорящих сторон, могут быть моменты, когда стороны внезапно начинают говорить громко и создают путаницу и неспособность для понимания, но при этом повышается пороговый уровень шума, приводя за очень короткое время к удалению потоков аудио, которые не формируют так много шума как другие, так что только потоки аудио от трех наиболее громко говорящих сторон будут снова выбраны и слышимы, а другие не выбраны, и таким образом удаляя часть шума, которую могут вносить другие потоки аудио. Это подразумевает, что могут иметь место моменты времени, когда более трех потоков аудио принимаются видеофоном 15, так как больше чем три видеофона могут иметь уровень шума выше порога в данный момент времени, позволяя каждому из таких видеофонов формировать поток аудио в этот момент времени и посылать его к сети 40. Однако, как объяснено выше, как только порог изменяется, ситуация останавливается. Этот распределенный анализ в отношении потоков аудио не ограничен видеофоном 15, описанным здесь, но также применим к любому типу аудио конференции, вне зависимости, имеются ли также существующие потоки видео или нет.

Совместимым с акцентом в отношении сохранения использования полосы частот и для посылки только того, что является необходимым для сохранения полосы частот, имеет место отсечение изображения в кодере 36, вместо выполнения этого в принимающем видеофоне 15. В случаях, когда передающий видеофон 15 осведомлен о том, как его изображение будет появляться в принимающих видеофонах 15, кодер 36 отсекает большое изображение сцены, прежде чем оно будет передано, так что имеется намного меньшее изображение для передачи и использования полосы частот. Если отсечение должно произойти в видеофоне 15 приемника, то основной процессор с программным обеспечением будет работать над принятым изображением, прежде чем оно будет выдано на контроллер 52 отображения.

Вторая камера может быть подсоединена к видеофону 15, чтобы обеспечить альтернативное представление сцены. Например, в помещении первая камера, или первичная камера, может быть расположена так, чтобы сфокусироваться на лице зрителя или говорящей стороны. Однако могут иметься дополнительные личности в помещении, которых человек, управляющий видеофоном 15 в помещении, желает показать другим зрителям на принимающих видеофонах 15. Эта вторая камера, например, может быть расположена в верхнем углу помещения так, чтобы вторая камера могла рассматривать по существу намного большую часть помещения, чем первичная камера. Выходной сигнал второй камеры можно обеспечивать на декодер 34. Декодер 34 имеет несколько портов для приема входных сигналов видео. Альтернативно, если поток от второй камеры уже оцифрован, его можно выдавать на обрабатывающие элементы видеофона 15 через такие же каналы, как первичная камера. Предпочтительно, каждый видеофон 15 управляет всем, что он посылает, так что выбор того, сигнал какой камеры должен быть передан, выполняется наблюдателем, управляющим видеофоном 15. Альтернативно, возможно снабдить удаленный принимающий видеофон 15 способностью управлять и выбирать - какой поток от какой камеры в данном видеофоне 15 должен быть передан. Сигналы управления от управляющего видеофона 15 могут быть переданы по сети 40 и приняты соответствующим видеофоном 15, который затем обеспечит выбранный поток для передачи. Помимо второй камеры, любой другой тип подачи видео также можно обеспечивать посредством видеофона 15, такой как подача видео от DVD, видеомагнитофона или камеры "белой доски" (электронная доска белого цвета, на которой пишут цветными маркерами с одновременным представлением информации на экране ПК).

В предпочтительном варианте осуществления видеофон 15 работает в пиковом режиме. В пиковом режиме камера видеофона 15 принимает неподвижное изображение сцены перед ней и передает это изображение к другим видеофонам 15, которые были предварительно идентифицированы для его приема, например, на основе списка тех видеофонов 15 в его меню ускоренного набора. Альтернативно, в пиковом режиме неподвижное изображение, которое принято, поддерживается в видеофоне 15 и выдается по запросу любому, кто просматривает, чтобы вызвать этот видеофон 15. В идеале, как согласуется с предпочтительным использованием видеофона 15, каждый пользователь видеофона 15 управляет всем, что посылается из видеофона 15, и может просто выбрать - выключить пиковый режим или управлять, какое изображение выдается. Когда имеет место активный запрос, пиковый режим выключается, так что не имеется конфликта между пиковым режимом и активным вызовом, в котором непрерывный поток изображения принимается камерой. В пиковом режиме неподвижное изображение сцены может приниматься в заранее определенные интервалы времени, скажем, с приращениями в одну минуту, приращениями в пять минут, приращениями в 30 минут и т.д. В пиковом режиме в заранее определенное время, прежде чем неподвижное изображение будет принято, например, за пять или десять секунд до того как изображение будет принято, слышимая очередь может быть представлена для того, чтобы оповещать кого-либо перед камерой, что изображение собирается быть принятым и что они должны выглядеть презентабельными. Слышимая очередь может быть гудком, звонком или другим записанным шумом или сообщением. Таким образом, когда используется пиковый режим, пик в сцене прежде, чем камера видеофона 15 делается доступной другим видеофонам 15 и обеспечивает индикацию относительно присутствия людей в отношении камеры к другим видеофонам 15.

В качестве другого примера датчика присутствия, расположение автоматической линзы камеры в отношении поля зрения перед ней может действовать в качестве датчика присутствия. Когда никого нет перед камерой, тогда автоматическая линза камеры будет фокусироваться на объекте или стене, которая находится в ее поле зрения. Когда человек находится перед камерой, автоматическая линза будет фокусироваться на этом человеке, что заставляет линзу быть в отличной позиции, чем когда человек не находится перед линзой. Сигнал от камеры, указывающий фокус линзы, может быть послан от камеры к FPGA 38, которая затем вызывает посылку информации о фокусе к заранее определенному списку приемников видеофона 15, например тем, что в списке ускоренного набора номера передающего видеофона 15, чтобы информировать принимающий видеофон 15, находится ли наблюдатель перед видеофоном 15, чтобы указать, что кто-то присутствует.

Видеофон 15 также предусматривает видеопочту. В случае, если вызов видео предпринимается от одного видеофона 15 к другому видеофону 15 и принимающий видеофон 15 не отвечает на видеовызов по истечении заранее определенного времени, например 4 звонков, то сервер 66 видео, связанный с принимающим видеофоном 15, будет отвечать на видеовызов. Сервер 66 видео будет отвечать на видеовызов от передающего видеофона 15 и будет посылать передающему видеофону 15 записанное аудиосообщение, или аудиосообщение с записанным изображением видео от принимающего видеофона 15, который не отвечал, которые были предварительно записаны. Сервер 66 видео будет воспроизводить сообщение и выдавать аудио или очередь (последовательность) аудио и видео к вызывающей стороне, чтобы оставить их сообщение после заранее определенной индикации, такой как гудок. Когда имеет место заранее определенная индикация, вызывающая сторона затем оставит сообщение, которое будет включать в себя аудиопредложение, а также как изображение видео вызывающей стороны. Это видео и аудиосообщение должно быть сохранено в памяти в сервере 66 видео. Сообщение может быть (сохранено) пока требуется, или ограничено заранее определенным периодом времени для сообщения, которое должно быть определено. После того, как заранее определенный период времени прошел, или вызывающая сторона закончила и прервала вызов, сервер 66 видео сохраняет сообщение видео и посылает сигнал принимающему видеофону 15, который не отвечал на первоначальный запрос, что имеется сообщение видео, ожидающее наблюдателя принимающего видеофона 15. Это сообщение может быть текстом или видеоизображением, которое появляется на дисплее 54 в принимающем видеофоне 15, или просто индикатором сообщения, который активизирован, чтобы оповестить наблюдателя принимающего видеофона 15, что имеется почта видео для наблюдателя.

Когда наблюдатель желает просмотреть видеопочту, он может только выбирать на сенсорном экране 74 область, чтобы активизировать видеопочту. Пользователю предоставляется диапазон опций обработки почты, включающий в себя чтение видеопочты, которая посылает сигнал серверу 66 видео, чтобы воспроизвести видеопочту для наблюдателя на дисплее 54 видеофона 15. Поток изображения, который посылается от сервера 66 видео, передается по пути, описанному выше для основанных на видео потоков в принимающий видеофон 15 и через него для отображения. Чтобы наблюдатель видеофона 15 мог записать сообщения на сервере 66 видео, чтобы ответить на видеовызовы, когда наблюдатель не отвечает на видеовызовы, наблюдатель касается области на сенсорном экране 74, что активизирует сервер 66 видео, чтобы запросить наблюдателя записать сообщение или аудио или аудио и видео в заранее определенное время, что наблюдатель затем и делает, чтобы создать сообщение.

Видеофон 15 обеспечивает работу динамиков 64 на заранее определенном уровне без какого-либо управления громкостью со стороны пользователя. Динамики 64 видеофона 15 могут быть калиброваны с микрофоном так, что если микрофон захватывает шум, который является слишком громким, то основной контроллер 50 и DSP 62 понижают уровень вывода аудиодинамиков 64, чтобы уменьшить уровень шума. Посредством установки заранее определенного и желательного уровня видеофон 15 автоматически управляет громкостью звука без необходимости для наблюдателя делать что-нибудь.

Видеофон 15 может быть запрограммирован распознавать запрос говорить с конкретным человеком и затем использовать заранее определенный шаблон речи, который используется для распознавания в качестве тона или сигнала в принимающем видеофоне 15, чтобы информировать наблюдателя в принимающем видеофоне 15, что вызов запрашивается принимающим видеофоном 15. Например, термин "Эй, Крэйг" может использоваться для видеофона 15, чтобы распознать, что вызов должен быть инициализирован к Крэйгу передающим видеофоном 15. Наблюдатель, говоря "Эй, Крэйг", заставляет передающий видеофон автоматически инициализировать вызов к Крэйгу, который затем посылает выражение "Эй, Крэйг" к принимающему видеофону 15 Крэйга. Вместо того, чтобы принимающий видеофон 15 Крэйга звонил, чтобы указать, что запрашивается вызов Крэйга, выражение "Эй, Крэйг" периодически объявляется в видеофоне 15 Крэйга вместо вызова, который обычно имел бы место, чтобы привлечь внимание Крэйга. Функциональные возможности для выполнения этой операции могут быть выполнены основным контроллером 50 и DSP 62. Предложение "Эй, Крэйг" может быть объявлено наблюдателем и передано, как описано выше, на сервер 66. Сервер 66 после анализа этих предложений может распознавать это выражение как команду инициализировать вызов к названной стороне в команде. Сервер 66 затем может использовать адресную информацию видеофона 15 Крэйга, чтобы инициализировать вызов видеофона 15 Крэйга и вызвать формирование такого сигнала или тона в видеофоне 15 Крйэга, как "Эй, Крэйг".

Как известно в данной области техники, кодер 36 способен идентифицировать начало и конец каждого кадра. Когда кодер 36 принимает данные, он кодирует эти данные в течение кадра и сохраняет данные, пока кадр не будет завершен. Благодаря алгоритму, который использует кодер 36, сохраненный кадр используется в качестве основания для формирования следующего кадра. Сохраненный кадр выступает как опорный (эталонный) кадр для следующего кадра, который должен быть закодирован. По существу это имеет место вследствие того, что изменения в кадре, происходящие от одного кадра к следующему, являются фокусом для кодирования, а не весь кадр с начала. Закодированный кадр затем посылают непосредственно для пакетирования, как описано выше, без какой-либо буферизации, за исключением целей пакетирования, чтобы минимизировать любую задержку. Альтернативно, когда кодер 36 кодирует данные для кадра, чтобы дополнительно ускорить передачу данных, закодированные данные упорядочиваются для целей пакетирования без ожидания полного кадра, который должен быть закодирован. Данные, которые закодированы, также сохраняют с целью формирования кадра по причинам, описанным выше, так чтобы опорный кадр был доступен кодеру 36. Однако отдельно, данные, как они были закодированы, пересылаются для целей пакетирования и формируются в кадр, когда он также подготавливается для пакетирования, хотя если пакет готов к передаче, и так случилось, что только часть кадра была сделана частью пакета, оставшаяся часть кадра должна быть передана с отдельным пакетом, и кадр не должен быть сформирован, пока оба пакета с информацией кадра не будут приняты в принимающем видеофоне 15.

Со ссылками на фиг.1, видеофоны 15 подсоединяются к сети 40. Видеофоны 15 поддерживают соединения Ethernet 10/100 и, необязательно, соединения ATM (Асинхронная Передача Данных) на скорости 155 Мбит/с или на основе медного или многомодового оптического волокна. Каждый терминал видеофона 15 обычно ассоциирован с пользователями ПК (персонального компьютера) 68. Роль видеофона 15 заключается в обеспечении аспектов аудио- и видеовызова (конференции). ПК 68 используется для любых других функций. Установление вызова посредством видеофона 15 может автоматически устанавливать сеанс связи Microsoft Netmeeting между связанными персональными компьютерами 68 так, чтобы пользователи могли совместно работать в программах на основе Windows, например презентациях Power Point, или электронных таблицах, обмениваться графикой на электронных "белых досках", передавать файлы или использовать основанную на тексте программу чата и т.д. ПК 68 может быть подсоединен к Ethernet независимо от того, как подсоединен терминал видеофона 15. Он также может быть, конечно, связано с локальной сетью ATM. ПК 68 и ассоциированный передающий видеофон 15 обмениваются друг с другом через сеть 40. ПК 68 и ассоциированный передающий видеофон 15 обмениваются друг с другом так, что ПК 68 знает, с кем передающий видеофон 15 говорит. ПК 68 может затем обмениваться с ПК 68 принимающего видеофона 15 с тем, кто говорит по передающему видеофону 15. ПК 68 может также заказать разговор для видеофона 15.

Большинство функциональных возможностей системы 10 являются основанными на сервере и являются программным обеспечением, выполняющимся на прокси-сервере видеофона 15, который является предпочтительно прокси-сервером SIP. Один сервер 66 необходим для того, чтобы обеспечить базовые функциональные возможности, второй требуется для плавной (гладкой) работы, то есть сохранения услуг в случае, когда один сервер 66 дает сбой. Программное обеспечение в серверах и в терминале видеофона 15 в этом случае должно автоматически перекачиваться на резервный сервер 66. С такой конфигурацией терминалы видеофона 15 могут осуществлять или принимать вызовы к любому другому терминалу видеофона 15 по сети 40 и на любые телефоны, которые являются предпочтительно телефонами SIP, зарегистрированными в сети.

Медиасерверы (серверы мультимедийной информации) обеспечивают пользователям набор услуг в отношении набора медиа (мультимедийных) потоков. Медиасервер 66 управляется сервером 66 функциональных возможностей (предпочтительно сервером 66 функциональных возможностей). Он используется для предоставления источников и "стоков" для медиапотоков в качестве части различных функций, вызываемых пользователем. Услугами, обеспеченными на медиасервере 66 являются:

Соединение конференции

Запись и воспроизведение

Транскодирование

Тональные сигналы и оповещения

Медиасервер 66 является блоком, находящимся в локальной сети или глобальной сети. Обычно он не имеет никаких других подключений к нему. Он является предпочтительно устройством SIP. Серверы функциональных возможностей находятся на пути сигнализации от терминалов видеофона 15. Этот путь мультимедийной информации, однако, может идти непосредственно от медиасервера 66 до прибора.

Во время работы пользователь может запрашивать функцию, такую как видеопочта. Сервер 66 функциональных возможностей может обеспечивать интерфейс пользователя и функцию сигнализации, медиасервер 66 может обеспечивать механизмы для мультимедийных подсказок (если они используются) и запись, и воспроизведение сообщений.

Чтобы дать возможность терминалу видеофона 15 осуществлять или принимать вызовы к любому (видео) телефону, не относящиеся к какому-либо протоколу или стандарту (такому как SIP), добавляют шлюз 70, такой как шлюз SIP. Четыре шлюза 70 аналоговой линии связи могут быть подсоединены или непосредственно к PSTN (коммутируемой телефонной сети общего пользования) или к аналоговым линиям локальной PBX (телефонной системы для частного пользования). Применяются обычные правила для предоставления исходящих линий. Обычно одна магистральная линия предоставляется для каждых шести пользователей, то есть предполагается, что любой пользователь использует свой телефон для набора внешнего соединения в течение 10 минут любого часа. Если терминал видеофона 15 должен действовать в качестве расширения поверх текущей PBX насколько это касается входящих вызовов, то одна аналоговая линия необходима для каждого видеофона 15.

Телевизионные источники, такие как CNN, являются доступными видеофону 15 пользователя. Сервер 66 видео видеофона 15 разрешает эту службу. Этот сервер 66 поддерживает соединение единственного канала видео, который затем становится доступным любому пользователю видеофона 15 в сети 40. Этот канал видео является эквивалентом двум нормальным сеансам связи конференции. Блок настройки (тюнер) может устанавливать канал, который является доступным. Новый сервер 66 видео видеофона 15 должен быть добавлен к конфигурации для каждого отличного канала, который клиент желает иметь доступным одновременно.

Сервер 66 видеофона 15 (предпочтительно SIP) также содержит базу данных для пользовательских данных, включая в себя локальную кэш-память информации о контактах пользователей. Эта база данных может быть синхронизирована с главной базой данных контактов пользователя. Синхронизация может использоваться, например, с пользователями (программ) Outlook/Exchange и для пользователей (программы) Lotus Notes. Отдельная программа, которая будет выполняться на какой-либо основанной на NT платформе сервера 66, выполняет синхронизацию. Только один сервер 66 требуется независимо от количества обслуживаемых местоположений (подразделений).

Как показано на фиг.2, обычно терминалы видеофона 15 должны быть распределены по нескольким местоположениям, объединенных глобальной сетью 40. Один сервер 66 достаточен, чтобы обслужить до 100 и более видеофонов 15 в единственном университетском городке. Когда общее количество видеофонов 15 на местоположении увеличивается, на некотором этапе должно быть установлено больше серверов.

С видеофонами 15, распределенными по нескольким местоположениям (подразделениям), возможно их использование на основании центральных серверов, но это не является рекомендуемой конфигурацией из-за полосы частот, используемой глобальной сетью, и зависимости от глобальной сети. Предпочтительно, каждое местоположение имеет по меньшей мере один сервер 66, который является предпочтительно сервером 66 SIP, когда используется SIP. Для более осторожных, самой простой и самой легкой конфигурацией является такая, в которой каждое местоположение имеет дублированные серверы, предпочтительно каждый являющийся сервером SIP. Однако использование центрального сервера 66 в качестве альтернативы удаленным серверам местоположения также должно работать.

Видеофоны 15 в любом месте в сети 40 могут осуществлять основанные на PSTN или PBX исходящие вызовы из единственного центрального шлюза 70. Однако, если имеется потребность, чтобы видеофон 15 также был расширен над локальной PBX, чтобы принимать входящие вызовы, то необходимо, чтобы PSTN шлюз 70 был обеспечен в каждом местоположении. Должен быть порт на шлюзе 70 для каждого видеофона 15 в таком местоположении.

Центральный сервер 66 CNN может распределять ТВ канал к любому видеофону 15 в сети 40. Тем не менее, может быть предпочтительным добавить специфичные для местоположения (подразделения) серверы, чем принимать эту полосу частот по глобальной сети.

Видеофон 15 является доступным для подключения или к сети Ethernet 40 10/100 (Мбит/с) или к сети АТМ 40 со скоростью 155 Мбит/с (с обеими опциями Fiber (оптическое волокно) и Copper (медный провод)). Подключенный через АТМ видеофон 15 использует панель IP управления, чтобы установить АТМ-адреса оконечных точек для вызова, и затем использует сигнализацию АТМ, чтобы установить канал однонаправленной передачи данных между этими конечными точками. Каналом однонаправленной передачи данных является установленный коммутируемый виртуальный канал (КВК, SVC) с полными заданными требованиями QoS (качества услуг, КУ).

Каждый поток видео является дуплексным потоком от 2 Мбит/с до 6 Мбит/с, как определяется параметрами настройки и согласованиями о полосе частот. Поскольку средство отображения может показывать более одного потока видео, общая требуемая полоса частот соединения к каждому видеофону увеличивается с увеличением количества сторон в вызове. Отсечение передающего конца гарантирует, что максимальная требуемая полоса частот приблизительно в 2,5 раза больше отдельной полосы частот потока видео, находящегося в использовании. Если имеются несколько видеофонов 15 на местоположении (подразделении), обычное телефонное соотношение между пользователями и магистральными линиями связи будет применено к сеансам связи видеофона 15. Другими словами, пользователь видеофона 15, как ожидается, должен будет говорить в среднем с двумя другими людьми в каждом вызове, то есть два потока, и будет использовать видеофон 15 на среднем 10 минут в час. Для средней скорости кодирования 3 Мбит/с, это дает необходимую ширину полосы частот глобальной сети, равную 6 Мбит/с, которая, как ожидается, может поддерживать до 6 пользователей.

Как показано на фиг.3, видеофон 15 работает на "p" разрешенной сети 40 Ethernet, когда имеется низкая плотность терминалов видеофона 15. Система 10 видеофонов 15 будет устанавливать канал SVC по части АТМ сети 40, связывая линей связи эти два видеофона 15 вместе, и делает использование "p" разрешенной Ethernet, чтобы гарантировать, что достаточное качество услуг доставляется по Ethernet-части соединения.

Существенные элементы системы 10 видеофонов 15 иллюстрируются на фиг.4. Вместе они создают мультимедийные инструментальные средства совместной работы, значительно расширяющие способность взаимодействия географически рассредоточенных групп. Такие группы становятся все более и более обычными почти в каждом большом предприятии, все эти инструментальные средства для того, чтобы помочь им работать действенно и эффективно, являются немного измененными по сравнению с десятилетием назад и являются во многих отношениях неудовлетворительными. Видеофон 15 направлен на решение многих проблем существующих систем комплексным способом, чтобы создавать скачкообразное усовершенствование для удаленной совместной работы. Это становится возможным посредством недавно ставшей доступной технологии, отличающейся качеством обслуживания и правильным соединением функций, сделанной пригодной для использования посредством развития превосходного интерфейса пользователя и разработанной так, чтобы быть расширяемой, используя основанную на стандартах архитектуру.

Потоки аудио и видео, как описано выше, передаются от исходного видеофона 15 к оконечным видеофонам 15 в сети, используя, например, известные методы SIP. Сообщения SIP могут быть маршрутизированы через гетерогенные сети, используя методы IP маршрутизации. Желательно для потоков мультимедийной информации в гетерогенных сетях иметь более прямой путь. Предпочтительно, в случаях, когда исходный видеофон 15 конференции подсоединен к Ethernet, а оконечный видеофон 15 конференции подсоединен к сети АТМ, как показано на фиг.15, имеет место нижеследующая адресация пакетов, которые пересекают сеть между исходным и оконечным видеофонами. Исходящий видеофон 15 посылает пакет на Ethernet, с которым он обменивается, с IP адресом исходящего видеофона. Пакет достигает исходящего шлюза 80, который связывает Ethernet с сетью АТМ. В исходящем шлюзе 80 IP адрес исходящего видеофона 15 сохраняют (извлекая) из пакета, и исходящий шлюз 80 добавляет к пакету АТМ адрес исходящего шлюза 80 и пересылает пакет к оконечному видеофону 15. Когда оконечный видеофон 15 принимает пакет, он сохраняет АТМ адрес исходящего шлюза 80 (извлекая) из пакета и посылает назад исходящему шлюзу 80 обратный пакет, указывающий, что он принял пакет, с АТМ адресом оконечного видеофона 15. Исходящий шлюз 80, когда он принимает обратный пакет, сохраняет АТМ адрес оконечного видеофона 15 и добавляет IP адрес исходящего шлюза 80 к обратному пакету. Обратный пакет затем посылается от исходящего шлюза 80 назад к исходящему видеофону 15.

Таким образом, конкретные адреса каждого критического узла общего пути между и с исходным видеофоном 15 и оконечным видеофоном 15 известны для каждого критического узла пути. Как минимум, каждый узел на этом пути знает адрес следующего узла пути, и если требуется, дополнительные адреса могут поддерживаться соответствующими пакетами, когда они перемещаются по пути так, что каждый узел пути знает больше в отношении адресов критических узлов, чем следующий узел, к которому пакет идет. Это имеет место потому, что когда пакет перемещается от узла к узлу, и конкретно в этом примере, от исходящего видеофона 15 к исходящему шлюзу 80 к оконечному видеофону 15 и затем обратно к исходящему шлюзу 80 и затем к исходящему видеофону 15, каждый узел сохраняет критический адрес предыдущего узла, от которого соответствующий пакет был принят, и вводит свой собственный адрес относительно типа сети, частью которой является следующий узел. Следовательно, все критические адреса, по которым каждый узел должен послать пакет на следующий узел, распределяются по всему пути.

Этот пример передачи пакета от исходящего видеофона 15 на Ethernet к оконечному видеофону 15 в сети АТМ также применим для обратного случая, когда исходный терминал или видеофон 15 находятся в связи с сетью АТМ, а оконечный видеофон 15 находится в связи с Ethernet.

Точно так же путь может вовлекать исходящий видеофон 15 в обмен с Ethernet и оконечным видеофоном 15, находящимся в связи с Ethernet, где имеется сеть АТМ, через которую перемещается передаваемый между ними пакет, как показано на фиг.16. В таком случае могут быть два шлюза на каждой границе, где имеется интерфейс между Ethernet и сетью АТМ. Как описано выше, процесс будет просто добавлять дополнительный узел к пути, где исходный шлюз 80 вводит свой собственный ATM адрес в пакет и посылает его к оконечному шлюзу 82, который сохраняет ATM адрес исходящего шлюза и добавляет IP адрес оконечного шлюза к пакету, который он затем посылает на оконечный видеофон 15 по Ethernet. С обратным пакетом то же самое происходит наоборот, и каждый шлюз сохраняет соответствующую адресную информацию от предыдущего шлюза или оконечного видеофона 15, и добавляет свой собственный адрес к обратному пакету, который он пересылает в конечном счете к исходящему видеофону 15, причем исходный шлюз 80 и исходный видеофон 15 сохраняют адрес АТМ оконечного шлюза 82 или исходного шлюза 80 соответственно, так что соответствующие адреса в каждой линии связи полного пути сохраняются для более эффективной и быстрой пересылки последующих пакетов соединения.

Например, основной контроллер 50 и сетевой интерфейс 42 видеофона 15 могут добавлять адрес видеофона 15 к каждому пакету, которые он посылает в сеть 40, с использованием тех же самых методов, которые известны специалистам в данной области техники, размещения SIP, маршрутизирующего информацию (или каждый раз, когда используется стандарт, маршрутизирующий информацию), в пакет. Сетевой интерфейс 42 также сохраняет адресную информацию, которую он принимает из пакета от узла в сети, в локальной памяти. Аналогично, для шлюза в сети 40 может применяться то же самое. Как известно, шлюз имеет средства управления и средства обработки данных для перемещения пакета к его окончательному адресату. Сетевой интерфейс 42 и основной контроллер 50 механизма управления шлюза, функционирующие согласно хорошо известным методам в отношении SIP, маршрутизирующего информацию, сохраняет адресную информацию, принятую из пакета, и размещает свою собственную адресную информацию относительно сети 40, в которую он собирается посылать пакет, в пакете. Например, адресная информация шлюза или видеофона 15 может быть помещена в поле, которое находится в части заголовка, ассоциированной с пакетом. Должно быть отмечено, что в то время как в примере говорится об использовании видеофонов 15 в качестве оконечного и исходящего источников, любой тип устройства, которое формирует и принимает пакеты, может использоваться в качестве узла в этой общей схеме.

Видеофон 15 Виртуального Присутствия (ViPr) (видеофон) является настольным сетевым 40 устройством, которое является терминалом персональной связи. Он заменяет телефон на пользовательском столе, обеспечивая все возможности терминала современной PBX (телефонной системы для частного пользования) с простотой пользовательского интерфейса и легкостью в использовании, предоставляемыми большим сенсорным экраном 74 видеофона 15.

Видеофон 15 добавляет видеоизмерение ко всем меж-персональным обменам, изменяя восприятие к таковому виртуального присутствия. В прошлом качество видео в системах видеоконференции не было достаточно высоким, чтобы сделать технологию прозрачной. Видеофон 15 является первым персональным видеофоном для доставки достаточно высокого качества видео, чтобы создать правильное восприятие. Для эффективной видеосвязи в реальном времени не только необходимо, чтобы качество картинки было близким к качеству радиовещательного TV, но и время ожидания должно сохраняться очень низким. Синхронизация (движения) губ также важна, если должен происходить естественный разговор. Все эти проблемы были решены в конструкции видео подсистемы видеофона 15. Видеофон 15 использует самую современную технологию кодера 36 и декодера 34, сконфигурированных специально для этого применения. Другими словами, видеофон 15 подходит так близко насколько это возможно к понятию "быть там".

Видеофон 15 также значительно усовершенствован относительно эффективности обычного громкоговорящего телефонного аппарата с помощью высококачественного воспроизведения, канала аудиопочти CD-качества, который обеспечивает кристально чистый голос. Стереоканалы аудио обеспечивают пространственное различение каждого из участников аудио. Усовершенствованная компенсация стереоэха подавляет не только весь звук от динамиков 64 модулей, но и дает возможность диктору продолжать разговор на уровнях нормального разговора, даже когда находится в шумном помещении.

Видеофон 15 непосредственно поддерживает установление до 4 вызовов (то есть 5 путей) от удаленных сторон видео конференц-связи и/или до 10 вызовов от сторон аудио конференц-связи. Каждый пользователь имеет обзорность в отношении готовности всех других членов его/ее рабочей группы. Видеофон 15 предпочтительно использует Протокол Инициирования Сеанса связи (SIP) в качестве средства установления, изменения и очистки многопотоковых мультимедийных сеансов связи. Видеофон 15 может устанавливать аудиовызов к любому другому телефону SIP или на любой другой телефон через шлюз 70.

Видеофон 15 предъявляет высокие требования к сети 40, к которой он присоединен. Видеовызовы видеофона 15 требуют сети 40, которая может предоставлять непрерывную широкую полосу частот, с гарантиями в отношении полосы частот, времени ожидания и флуктуации во времени. Marconi plc специализируется на обеспечении сетей, которые поддерживают приложения с высоким качеством услуг. Версия видеофона 15 для конференц-зала также доступна.

Видеофон 15 является терминалом связи (платформой), которая имеет возможность полной интеграции с ПК пользователя 68, его компьютерной платформой. Приложения видеофона 15 для ПК 68 обеспечивает множество услуг интеграции между ПК 68 и ассоциированным терминалом видеофона 15. Оно должно включать в себя автоматическое установление сеансов связи NetMeeting между сторонами в конференц-связи видеофона 15, если это разрешено, с целью совместного использования приложений, таких как "белая доска", или презентаций и т.д., другие возможности, включая набор номера методом "перетащить и отпустить" с помощью видеофона 15 в отношении номера на ПК 68.

Набор серверов, предпочтительно каждый являющийся сервером SIP, обеспечивает управление вызовом и реализацию функциональных особенностей для устройств сети 40. Они являются программными серверами, выполняющимися на стандартных вычислительных платформах, способных к избыточности. Эти серверы также запускают локальную копию базы данных информации о контактах пользователей и базу данных предпочтений пользователей. Приложения, доступные на этих серверах, обеспечивают доступ к общим или другим доступным каталогам согласно LDAP (облегченный протокол службы каталогов).

Сервер 66 синхронизации поддерживает синхронизацию между главной базой данных контактов пользователей и локальной копией на сервере 66 (предпочтительно SIP). Синхронизация для Outlook Exchange или Lotus Notes поддерживается. Набор шлюзов 70 мультимедийной информации используется для аналоговой или цифровой сети 40 PSTN. Набор интерфейсов шлюзов 70 выполняет сопряжение с наиболее часто используемым оборудованием PABX (локальной АТС с исходящей и входящей связью), включая системы речевой почты, связанные с таким PABX оборудованием.

Медиасервер 66 (мультимедийной информации) предоставляет множество услуг терминалу видеофона 15. Он действует как сервер 66 организации моста-конференции для видеоконференции более чем 4 сторон, если требуется. Он может также обеспечивать транскодирование между стандартами видеофона 15 и другими обычными форматами аудио или видео, такими как H320/H323. Он может обеспечивать возможности записи и воспроизведения, допуская, чтобы сеансы связи быть записаны и воспроизведены. Он может обеспечивать источник тональных сигналов и объявлений.

Сетевой брандмауэр согласно используемому стандарту, такой как брандмауэр SIP, требуется, чтобы безопасно передавать динамически созданные RTP потоки под управлением стандартного программного обеспечения - посредника (такого как прокси (промежуточное) программное обеспечение SIP). TV-сервер 66 действует как источник телевизионного вещания, позволяя пользователям видеофона 15 выбирать любой поддерживаемый канал, например CNN.

Видеофон 15 предназначен для настольных систем ATM и Ethernet. Терминал видеофона 15 поддерживает сквозные SVC для АТМ и использует их, чтобы установить соединения с необходимым уровнем качества услуг. Видеофон 15 также поддерживает IP связность посредством услуг LANE (эмуляции локальных сетей). Для этого, чтобы гарантировать требуемое QoS (качество услуг), требуется LANE 2. Видеофон 15 обеспечивает транзитную пересылку ATM к ATM-присоединенным настольным ПК 68, или передачу от ATM к Ethernet через присоединенный ПК 68 через Ethernet.

Видеофон 15 требует поддержки сквозного качества услуг QoS. Для присоединенного к Ethernet видеофона 15 соединение пользователя должно поддерживать 802.1p, DiffServ и/или IntServ или лучше. Если адресат доступен через сеть АТМ 40, шлюз 70 "Ethernet к АТМ" должен быть обеспечен. Прокси сервер 66 SIP и сигнализация SIP установят оконечную точку АТМ, самую близкую к целевому терминалу видеофона 15, то есть его АТМ-адрес, если он присоединен к АТМ, или шлюз 70 Ethernet АТМ, который является самым близким. Сигнализация будет устанавливать SVC через АТМ-часть сети 40 с соответствующим QoS. Этот SVC должен быть связан с конкретным потоком Ethernet, генерирующим соответствующую приоритетную индикацию на удаленном конце.

Линия продуктов видеофона 15 состоит из нескольких оконечных терминалов (приборов), набора серверов, которые обеспечивают функциональные особенности, не встроенные в эти приборы, и набор шлюзов 70, которые соединяют продукты с существующими средствами и помимо PSTN услуг. Основными функциональными возможностями, обеспеченными системой 10, являются:

= услуги телефонной связи, с видео, доступным во всех вызовах "в сети", очень высокое качество аудио и видео;

= услуги многосторонней конференции, аудио и видео, создаваемые для специального случая или заранее спланированные, полностью самообслуживаемые, полностью интегрированные в услуги телефонной связи;

= услуги присутствия с разнообразием инструментальных средств для определения готовности к совместной работе;

= совместно используемые поверхностные услуги - электронная "белая доска", совместное использование приложений, совместное использование документа, вещание презентаций;

= другие ценные добавленные услуги, такие как TV вещание вещания видео (микрофонное сообщение к подразделениям). Оперативное интерактивное обучение и т.д. Службы записи сеансов также доступны, если необходимо.

Видеофон 15 является телефоном со значительными новыми функциональными возможностями, а не компьютером, пытающимся делать то, что делает телефон. Это допускает полное одновременное использование компьютера для вещей, которые являются хорошими в основе, в то же время обеспечивая гибкий, но специфичный для приложения прибор для обмена. Интерфейс пользователя и физическая конструкция могут быть настроены для этого приложения, обеспечивая современное, высоко надежное устройство связи, подобное современным телефонам, кое-что, чем ПК 68 никогда не сможет быть. Этот подход также обеспечивает управление над окружением устройства, устраняя проблемы поддержки, относящиеся к аппаратным и программным проблемам конфигурации ПК 68.

Изучения человеческих факторов демонстрировали раз за разом, что качество аудио является единственным наиболее важным фактором для эффективной прозрачной связи. В то время как телефонная трубка является необходимой, превосходные качественные средства аудио без использования рук, включающие в себя компенсацию акустического эха (АЕС), автоматическую регулировку усиления (АРУ), возможности широкополосного аудио (полоса частот G.722 8 кГц или лучше), стереовыход и интеграция с аудиовыходом ПК 68 обеспечивает новые уровни эффективной удаленной совместной работы. Набор микрофонов высокого качества, разработанный и обработанный для ограничения эффектов "оловянной банки", также имеется.

Используется простая, ясная, интуитивная, полностью гибкая платформа для визуального вывода и кнопок ввода/выбора. В первой модели видеофона имеется высококачественный полноцветный TFT (тонкопленочной технологии) экран, с диагональю 17", экраном 16×9 с разрешением 1260×768 или лучше, поверх которого имеется сенсорный экран со средним разрешением и длительным сроком службы. Яркая (>200 нит), с расширенным углом обзора (> ±60°) панель с активной матрицей используется, чтобы отобразить видео с полным движением для удобного просмотра в офисной среде. Могут использоваться большие, более яркие, быстрые, с более высокой контрастностью и с большими углами обзора экраны.

Видеофон 15 использует ЖК (жидкокристаллический) экран с TFT-цветами, имеющий архитектуру, подобную ПК 68, с интерфейсом на дисплее 54 типа VGA, на основании (процессора) Intel Celeron/440 MMX и контроллера Linx VGA.

Высококачественная цифровая 480 камера с прогрессивной разверткой используется, чтобы обеспечить видео с 30 кадрами в секунду с разрешением по меньшей мере 640×480. Видеофон 15 использует кодирование MPEG-2, используя преимущество технологии видео кодера 36 для телевизионных приставок. Множество различных скоростей передачи информации в битах может быть сформировано, позволяя приспособить качество видео к доступным ресурсам для вызовов один-к-одному, и для вызовов участника с самым высоким качеством для одного вызова или вызовов "многие-к-многим". Модуль интегрированной камеры высокого качества расположен вблизи экрана с входом внешнего видеосигнала (Firewire), обеспеченным для того, чтобы разрешить использование дополнительных камер, видеомагнитофонов или других источников видеосигнала.

Существующее соединение Ethernet 10/100BaseT с настольной системой является единственным соединением, необходимым для обмена с локальной сетью, глобальной сетью, настольным ПК 68 и различными серверами, прокси-устройствами и шлюзами 70. Критичные по времени RTP потоки для аудио и видео отмечаются приоритетом, используя 802.1p, предоставляя механизм в пределах области Ethernet локальной сети для QoS. DiffServ также поддерживается с RSVP (протокол резервирования (ресурсов)) в качестве опции. Чтобы устранить потребность в дополнительной прокладке проводного соединения к настольной системе, видеофон 15 должен включать в себя небольшой коммутатор Ethernet 10/100, позволяющий использовать существующий порт настольной системы и для телефона, и для ПК 68.

Видеофон 15 также поддерживает интерфейс АТМ. Этот интерфейс основан на использовании платы HE155 Мбит/с или с волоконным или медным интерфейсом. Видеофон 15 обеспечивает порт передачи АТМ для подсоединения связанной с ATM настольной системы или подключения связанного с Ethernet ПК 68 к связанному с ATM видеофону 15.

Компромиссы стоимости и эффективности для окружения, такого как конференц-зала, являются очевидно отличными, чем для настольной системы. В видеофон 15 конференц-зала интегрированы проецирование видео, множество камер с удаленным функциями Pan/Tilt/Zoom (панорамирования/наклона/масштабирования), множество микрофонов, множество видео каналов, "белые доски" для рирпроекции и другие продукты, соответствующие среде конференц-зала. Взаимодействие среды конференц-зала и настольной системы является "гладким" и прозрачным. Эта среда должна делать широкое использование OEM оборудования, которое осуществляет взаимодействие с той же самой инфраструктурой и стандартами на месте для настольной системы. Структура аппаратного обеспечения является по существу такой же, с дополнительной поддержкой аудио для множества микрофонов и дополнительной поддержкой видео для множества камер и дисплеев. Альтернативно, может использоваться применение ПК 68, управляемое или мышью или сенсорным экраном 74, если ПК 68 имеет сенсорный экран 74, который обменивается с дешевым телефоном SIP. Для тех настольных систем и других мест, которые не требуют возможностей совместной работы, описанных выше, может использоваться стандартный телефон, который работает с системой 10 без необходимости в дополнительных проводных соединениях, или PBX.

Используя стандарт SIP (Протокол Инициирования Сеанса связи), оконечные устройства поддерживаются одним или более серверами, которые обеспечивают регистрацию, местоположение, профиль пользователя, присутствие и различные посреднические услуги. Эти серверы являются недорогими Linux или BSD машинами, подсоединенными к локальной сети.

Видеофон 15 является телефоном, так что должен быть обеспечен ключевой набор функций PBX, включающий в себя передачу, отправление, конференц-связь с 3 (и 4, 5, ...) сторонами, идентификатор и т.д. вызывающего абонента, историю вызовов и т.д. Некоторые из этих функциональных возможностей могут быть сформированы поверх механизма расширения SIP, названного "CPL", который фактически является языком для обеспечения обработки вызова безопасным расширяемым способом.

Видеофон 15 предусматривает активное присутствие и мгновенную передачу сообщений. Возможно, наиболее революционный инструмент для улучшения повседневно распределенной групповой совместной работы, присутствие позволяет людям знать, кто где находится и что они делают. Это обеспечивает основу для вызовов с очень низкими накладными расходами, устранение телефонных меток и традиционного набора номера, поощрение групп обмениваться в качестве группы вместо отдельных телефонных разговоров один на один, которые являются обычными в настоящее время. Интеграция с (службой) Мгновенной Передачей Сообщений (электронная почта реального времени) обеспечивает способ обмена без какой-либо задержки короткими текстовыми сообщениями, вероятно с использованием клавиатуры ПК 68 для ввода.

Видеофон 15 обеспечивает распределенную/избыточную архитектуру. Он является телефонной системой 10 и она должна быть надежной. Она должна также быть способна централизованно управляться с локальными расширениями, с распределенными серверами, обеспечивающими "мгновенный" ответ всем пользователям. Каждая из различных прокси-функций SIP, например, если SIP используется, должна быть развернута так, что они могут быть произвольно объединены в набор физических серверов, с избыточными версиями, расположенными в сети 40.

Microsoft NetMeeting используется для функциональных возможностей совместно используемых внешних и совместно используемых приложений. Могут использоваться интерфейс компьютер/телефонная связь (CTI) для ПК 68 и PDA с такими функциональными возможностями, как интегрированные списки контактов, автоматический набор номера выбранных номеров телефона или имен, календарная регистрация истории вызовов, автоматическая запись контактов и т.д.

SIP представляет опознавательные вызовы к брандмауэрам, потому что RTP потоки используют динамически распределенные UDP порты, и информация об адресе/порте передается в сообщениях SIP. Это означает, что брандмауэр должен отслеживать сообщения SIP и открывать "отверстия" в брандмауэре для соответствующих комбинаций адреса/порта. Далее, если используется NAT (трансляция сетевых адресов), сообщения должны быть изменены так, чтобы иметь соответствующие транслированные адреса/порты. Существуют два способа выполнить такую задачу. Согласно первому, нужно формировать эту возможность в брандмауэре. Три основных продавца брандмауэров (Checkpoint, Network Associates и Axxent) обеспечивают это. Альтернатива состоит в необходимости иметь специализированный брандмауэр, который имеет дело только с SIP, параллельно с основным брандмауэром. Имеются коммерческие версии такого брандмауэра например таковой от MicroAppliances. Должно быть отмечено, что SIP или NetMeeting являются предпочтительными вариантами осуществления, которые являются доступными для реализации их необходимых соответствующих функциональных возможностей. Могут использоваться их альтернативы, если обеспечиваются необходимые функциональные возможности.

Фиг.5 иллюстрирует основные физические компоненты терминала видеофона 15. Основание обеспечивает средство для легкой корректировки высоты панели основного дисплея 54 и закрепления панели на этой высоте. Диапазон регулирования высоты должен быть по меньшей мере равен 6 дюймам (15,24 см) для перемещения, чтобы приспособиться к различным ростам пользователя. Предполагается, что основание должно находиться на столе и что высоты настольных приборов стандартизированы. Соединение между основанием и основным модулем должно предусматривать ограниченную степень наклона от вертикали, чтобы удовлетворить предпочтениям пользователей и быть легко фиксированной под этим углом. Степень наклона требуется в пределах от -0 + 15E от вертикали. Основной модуль может крепиться непосредственно к стене без необходимости сборки основания в качестве опции.

Корпус основного модуля обеспечивает размещение для всех других элементов в конструкции видеофона 15, включающей в себя все показанные на фиг.5, и всей внутренней электроники. Корпус предусматривает установку телефонной трубки или для левой, или для правой руки. Правши имеют тенденцию брать телефонную трубку левой рукой (потому что правой рукой они должны управлять сенсорным экраном 74 и записывать), а левши - наоборот. Хотя местоположение слева должно быть нормальным местоположением, должно быть возможно располагать телефонную трубку справа. Гнездо динамика обеспечивается на корпусе, чтобы позволить устанавливать динамики 64 удаленным образом от видеофона 15. Входы обеспечиваются, чтобы обработать выходные сигналы динамика от ассоциированного ПК 68 так, чтобы видеофон 15 мог управлять аудио от ПК 68 и видеофона 15. Может использоваться реализация беспроводного соединения к динамикам 64 (посредством стандартов Bluetooth, или SONY).

Телефонная трубка снабжается модулем, который должен соединять, используя стандарт RJ9, витой кабель и гнездо соединителя. В исходном положении телефонная трубка должна быть проста для ее съема и все же быть малозаметной. Опция телефонной трубки обеспечивается на вспомогательной стандартной клавиатуре телефонной трубки. Может использоваться беспроводная телефонная трубка, чтобы улучшить мобильность пользователя терминала.

Гнездо (разъем) обеспечивается для соединения головного стереотелефона + микрофона. Использование головных телефонов для обычных телефонных разговоров увеличивается. Пользователь должен быть способен выбрать использование головного телефона + микрофон, установленный на микрофонном штативе, или только головной телефон, используя набор микрофонов в качестве устройства ввода данных. Имеется опция для беспроводного головного телефона, чтобы повысить мобильность пользователя терминала.

Инфракрасный (ИК) порт обеспечивают, чтобы обеспечить интерфейс к PDA и другим ИК устройствам в такой позиции на основном корпусе, чтобы обеспечить свободный доступ. В настоящее время ИК интерфейсы на телефонах и PDA являются наиболее обычными и поэтому по тем же самым причинам, по каким требуется интерфейс bluetooth, по тем же также требуется ИК интерфейс.

Набор (матрица) микрофонов внедрен в корпус. Этот набор не должен генерировать посторонний шум в процессе нормальной работы терминала. В частности, должно быть невозможно обнаруживать действия пользователя на сенсорном экране. Набор микрофонов позволяет пользователю говорить на уровнях нормального разговора в пределах дуги (скажем, 6 футов (183 см)) вокруг передней стороны устройств и 110Е в горизонтальной плоскости и при наличии заранее определенного значения в децибелах (дБ) фонового шума. Этот модуль должен обеспечить однозначную индикацию, что микрофон является активным/не активным, то есть эквивалентом «трубка положена», «трубка снята». Видеофон 15 пользователя должен требовать гарантии, что его не прослушивают без его ведома. Это является аудиоэквивалентом механического прерывателя камеры.

Основной модуль видеофона 15 может иметь опцию считывающего устройства интеллектуальной (смарт) карточки, чтобы обеспечить безопасный доступ к терминалу для персональных потребностей. Обращение к видеофону 15 должно нуждаться в наборе функциональных возможностей управления доступом, от простого входа в систему с запросом пароля на экране до брелка с защитой. Считывающее устройство интеллектуальной карточки обеспечивает один из этих методов доступа.

Имеется явное преимущество в том случае, если наклон и панорамирование являются управляемыми с экрана, и предпочтительно, если панорамирование и наклон являются только электронными и не нуждаются ни в каких механических механизмах. Крепление камеры должно быть установлено настолько близко к верху основного экрана, насколько это возможно, чтобы улучшить контакт с глазами.

Камера должна быть цифровой камерой 47, способной формировать выходные сигналы 480 p. Камера выдает выходные сигналы на MPEG-2 кодер 36. Должно быть возможно динамически конфигурировать камеру так, чтобы выходной сигнал камеры был оптимизирован для подачи на кодер 36 на скорости передачи выходных данных, выбранной кодером 36. Лица формируют основную часть входных данных, которые будет принимать камера, и поэтому точный захват данных в широком диапазоне условий освещения тона кожи является существенной характеристикой.

Камера должна использоваться в широком диапазоне условий освещения вплоть до нижнего значения, равного 3 люкс. Камера должна обеспечить автоматический баланс белого. Изменения баланса белого должны быть медленными так, чтобы переходные процессы на захваченном изображении не вызвали ненадлежащего возмущения картинки. Только изменения, которые длятся более чем 5 секунд, должны изменять баланс белого. Камера должна быть в фокусе от 18 дюймов (45 см) до 10 футов (3 м), то есть иметь большую глубину резко изображаемого пространства и желательно иметь фокусное расстояние до 20 футов (6,1 м). И пользователь, и информация, если они есть, на его белой доске обе должны быть в фокусе. Устройство автоматической фокусировки, когда камера непрерывно настраивается для наилучшей фокусировки, когда пользователь перемещается, вызывает возмущающее изображение на конце приемника, и его нужно избегать.

Камера должна обеспечить возможности ограниченного изменения масштаба изображения от параметров, когда один пользователь находится непосредственно перед камерой, к другим параметрам, когда несколько пользователей одновременно (отображаются) на одном видеофоне 15. В качестве альтернативы, могут быть обеспечены различные линзы. Это может быть определено в терминах поля зрения линзы, от, скажем, поля зрения в 30Е до поля зрения 75Е.

Камера должна быть способна ввести большую картинку, чем необходимо для передачи, например изображение 1280×960. Это позволит учесть ограниченное изменение масштаба изображения и горизонтальное и вертикальное панорамирование с помощью электроники, устраняя необходимость в электромеханическом средстве управления, ассоциированном с камерой. Камера должна быть физически маленькой, так, чтобы монтаж ее "на экране" не был невозможен просто из-за размеров камеры.

Сенсорная панель с длинным сроком службы и средним разрешением формирует первичный способ обмена с видеофоном 15 и формирует переднюю сторону основного дисплея 54. Панель будет испытывать большое количество контактов пальцами и поэтому должна выдерживать частую чистку, чтобы удалить пятна и другие отпечатки пальцев, которые иначе будут влиять на качество отображения 54. Должна быть возможность простой калибровки сенсорного экрана, то есть гарантия, что совпадение между областью, в которой касаются сенсорного экрана, и дисплеем 54 под ней приведет к удовлетворению требования "ложное касание".

Поверхность сенсорного экрана 74 должна минимизировать поверхностные отражения так, чтобы дисплей 54 был четким, даже когда он обращен к окну. Это требование заключается в том, чтобы "ложные касания» были редкими событиями. Требование разрешения в отношении сенсорного экрана поэтому сильно зависит от наименьшей области дисплея 54, когда пытаются различать касания. Объединенная ошибка разрешения и параллакса должна быть такой, чтобы вероятность "ложного касания" из-за этих факторов средне обученным пользователем должна быть меньше 5% (одно ложное касание за 20 выборов). Желательно, чтобы этот коэффициент ложного касания был меньше чем 2%, то есть одно ложное касание из 50 выборов.

Если является подходящим, слышимая и/или видимая обратная связь успешного касания должна быть обеспечена пользователю. Эти тональные сигналы могут изменяться в зависимости от того, что находится на дисплее 54 сенсорного экрана 74 в это время. Например, при использовании клавиатуры подходящими являются звуки, подобные клавиатуре, при использовании клавиатуры для набора номера отличные звуки, вероятно, должны быть уместными и так далее. Слышимая обратная связь может не быть необходимой во всех обстоятельствах, хотя обычно некоторая слышимая или видимая индикация относительно успешного касания является полезной для пользователя. Для пользователя должна быть обеспечена возможность включать и выключать тональные сигналы и устанавливать тональные сигналы, настраивать продолжительность и уровень громкости, ассоциированные с касанием на экране некоторых параметров настройки. Нужно обеспечить значения, задаваемые по умолчанию. Сенсорный экран 74 может также использоваться вместе с пером, а также задействован пальцем.

Панель дисплея 54 должна быть по меньшей мере плоской панелью 17 дюймов по диагонали (или более) с полноцветной технологией отображения 54, с форматным соотношением, предпочтительно равным 16×9, но форматное соотношение 16×10 является приемлемым.

Разрешение экрана должно быть равно по меньшей мере 1280×768. Просматриваемый угол должен быть по меньшей мере 6Е от оси в и горизонтальной и вертикальной плоскостях. Коэффициент контраста экрана должен быть лучше чем типичное 300:1. Цветовое разрешение должно быть по меньшей мере 6 битов на цвет, то есть должна быть способность отобразить 262 Кб цветов, 6 битов на цвет являются приемлемыми для устройств прототипа. 8 битов на цвет являются предпочтительными, при прочих равных условиях, для промышленных блоков. Панель отображения 54 должна иметь достаточно высокую яркость, при которой можно будет комфортно просматривать (изображение) даже в хорошо освещенном помещении или с естественным освещением. Яркость должна быть по меньшей мере равна 300 кд/м². Дисплей 54 и декодирующая электроника должны быть способны отобразить изображения с высоким разрешением 720P от соответствующих источников таких изображений в сети 40.

Лампа задней подсветки должна иметь минимальный срок службы с 50% минимальной яркости, по меньшей мере равный 25000 часам. Если лампа подсветки выключается из-за неактивности на терминале видеофона 15, то она должна автоматически включаться, если имеется входящий вызов, и когда пользователь касается где-нибудь сенсорного экрана. Период бездействия, по истечении которого сенсорный экран выключается, должен быть устанавлен пользователем, вплоть до "не выключать".

Соединения, требуемые в области соединения видеофона 15, являются такими, как иллюстрируются на фиг.6. Требование к каждому соединителю (коннектору) кратко описаны в параграфах ниже.

Два соединителя Ethernet 10/100 типа RJ45 предназначены для соединения с сетью 40 и от ассоциированного ПК 68.

Необязательный разъем в модуле специализации АТМ должен быть обеспечен при условии, что это дает возможность видеофону 15 легко поддерживать интерфейсы 155 Мбит/с как для оптических, так и для медных интерфейсов.

USB порт должен быть обеспечен, чтобы позволить различным необязательным внешним устройствам, например клавиатуре, мыши, недорогой камере и т.д., быть легко подсоединяемыми

Интерфейс 1394 (Firewire) должен быть обеспечен, чтобы разрешить соединение со внешними (Firewire) камерами или другими источниками видеосигнала. Интерфейс должен разрешить полнополосное управление камерой над интерфейсом Firewire. При необходимости должны использоваться внешние преобразователи, чтобы преобразовывать входные сигналы из, скажем, S-видео во входные сигналы Firewire. Должна быть возможность использовать этот источник вместо источника основной камеры в выходном сигнале видеофона 15 для конференции. Должно также быть возможно определять нормальный или режим "CNN", то есть с возможностью обреза или без возможности обреза на этом источнике видеосигнала.

Выходной видеосигнал XVGA нужно обеспечить, чтобы дать возможность видеофону 15 управлять внешними проекторами с изображением, которое отражает то, что отображается на основном дисплее 54.

Вход аудио должен быть предусмотрен для выходного сигнала PCAudio. Чтобы гарантировать интеграцию аудио ПК 68 и аудио видеофона 15, только один набор динамиков 64 должен быть развернут. Звук ПК 68 будет проходить через канал аудио видеофона 15. Гнездо или пара гнезд (разъемов) должны обеспечиваться, чтобы обеспечить соединение с головным телефоном и прилагаемым микрофонным штативом. Должна быть также возможна работа только головного телефона, используя встроенный набор микрофонов. Если гнездо головного телефона является относительно недоступным, должна быть возможность оставить головной телефон подключенным и выбрать посредством пользовательского средства управления, обеспечено ли аудио на головном телефоне или нет. Соединения обеспечиваются для внешних левых и правых динамиков 64. Возможно использовать один, два или три блока видеофона 15, как если бы они были отдельным функциональным блоком, как проиллюстрировано на фиг.7.

В конфигурациях с более чем одним видеофоном 15 только один модуль действует в качестве основной панели управления, другой(ие) модуль(и) отображают видео и средства управления, непосредственно ассоциированные с отображаемым видео. Только один набор динамиков 64 должен быть необходим для любой из этих конфигураций.

Множество опций должно обеспечиваться, насколько это касается входов микрофона и потоков аудио, от использования единственного общего входа микрофона, для передачи аудио от каждого набора микрофонов до источников видео на таком видеофоне 15.

Множество опций должно быть предусмотрено для входов видеосигнала. Значение по умолчанию должно быть задано, чтобы передавать вид видеофона 15 "панели управления". Если доступна большая полоса частот, чем каждый пользователь может получить, видео от экрана, на котором отображен пользователь, обеспечивает более естественное восприятие. Вся координация множества терминалов видеофонов 15 может быть достигнута при подключении к локальной сети, то есть не требуется какое-либо специальное межблочное кабельное соединение.

Видеофон 15 видеофона обеспечивает своего пользователя множеством основных функций:

Он является офисным телефоном

Он является пользовательским телефоном

Он является видеофоном

Он является телефоном для конференции

Он является телефоном для видео конференции

Он обеспечивает свободный доступ и управление подробностями контактной информации

Он обеспечивает доступ и управление речевой/видео почтой

Функциональные возможности модулей относятся к двум категориям, функциям пользователя и функциям систем.

Функциями пользователя являются любые функции, к которым пользователь будет иметь доступ.

Функциями системы 10 являются те, что требуются для I.T. чтобы установить монитор и поддерживать терминал видеофона 15, и которые являются невидимыми для обычного пользователя. Действительно, важная цель всего проекта заключается в том, чтобы гарантировать, что пользователю предоставляется очень простой интерфейс, причем он может использовать видеофон 15 фактически без обучения.

Нижеследующее определяет основной набор функциональных возможностей, который является минимальным набором функциональных возможностей, которые должны быть доступны.

Видеофон видеофона 15 действует как обычный телефон, когда никакой пользователь не зарегистрирован на терминале. Его функциональные возможности не должны вообще зависеть от того, имеются ли ассоциированные ПК 68.

Нижеследующее описывает функциональные возможности видеофона 15 в качестве обычного телефона в офисе.

Терминал способен иметь обычный номер расширения в отношении PABX (учрежденческой АТС с исходящей и входящей связью), обслуживающей это подразделение.

Терминал способен принять входящий вызов от любого телефона, независимо от PABX, в сети 40 видеофона 15 или любого внешнего телефона без различения.

Видеофон 15 способен принять вызовы от других совместимых с SIP телефонов.

Входящий вызов должен генерировать тональный сигнал звонка, как сконфигурировано (см. ниже установку требований к экрану). В частности, тональный сигнал звонка для вызовов видеофона 15, которые включают в себя видео, должен иметь опцию для отличия звонка от только аудиовызовов, независимо от того, исходит ли от терминалов видеофона 15 или нет.

Входящий вызов должен генерировать индикацию входящего вызова в области состояния (статуса) на дисплее 54. Этот дисплей 54 должен дать столько информации идентификатора (ИД) вызывающего абонента, сколько предусмотрено входящим вызовом, или указывать, что она недоступна.

Возможно принять входящий вызов:

a) нажимая кнопку приема вызова на экранном отображении 54 состояния входящего вызова,

b) поднимая телефонную трубку, что должно всегда принимать все предлагаемые опции, то есть видео и аудио.

Возможно для пользователя легко переключаться между телефонной трубкой и работой без использования рук (громкоговорящего телефонного аппарата) при вызове. Подъем телефонной трубки во время вызова должен автоматически осуществить переключение в режим телефонной трубки из режима громкоговорящего телефонного аппарата. Установка обратно телефонной трубки без переназначения режима громкоговорящего телефонного аппарата разъединит вызов.

Индикация на экране относительно режима должна быть выдана, то есть (в режиме) телефонной трубки или без использования рук.

Строка состояния вызова может отображать продолжительность вызова.

Возможно корректировать громкость входящего вызова посредством легко доступного средства управления на основном дисплее 54. Громкость головного телефона и динамика должны быть корректируемы независимо.

При нахождении в режиме громкоговорящего телефонного аппарата возможно возвратить телефонную трубку на подставку для телефонной трубки без разъединения вызова.

Вызов завершается:

$ если пользователь нажимает кнопку «очистки» вызова на экранном отображении (дисплее) 54 состояния вызова,

$ если пользователь кладет обратно телефонную трубку при нахождении в режиме телефонной трубки и режим со свободными руками не выбран,

$ если удаленная сторона завершает вызов, при условии, что это достоверно указано для видеофона 15.

HOLD (удержание) - Должно быть возможно перевести вызов на удержание (HOLD) и снова снять вызов с удержания. Состояние удержания должно быть отображено на экранном отображении 54 состояния с кнопкой, которая позволяет «поднять» удержанный вызов.

CALL WAITING (ожидание вызова) - Дополнительные входящие вызовы должны генерировать индикацию входящего вызова в области состояния на экранном отображении 54. Они не должны генерировать тональный сигнал вызова, если это не разрешено в меню параметров настройки.

Возможно принять новый входящий вызов в текущем операционном режиме, то есть режиме телефонной трубки или без использования рук, от кнопки приема вызова на экранном отображении 54 состояния.

Прием другого входящего вызова автоматически переведет текущий вызов в состояние удержания.

Нажатие кнопки "снять удержание" в отношении любого вызова должно автоматически перевести любые другие вызовы в состояние удержания.

Количество одновременных входящих вызовов, которые могут быть обработаны, устанавливается доступностью пространства экранного отображения (дисплея) 54 состояния. Оно не должно быть меньше чем на два вызова.

Когда количество текущих вызовов превышает количество, которое может быть обработано, любые другие входящие вызовы:

a) получают сигнал занятости или

b) немедленно направляются на голосовую почту,

c) немедленно направляются на сконфигурированный номер переадресации,

d) получают записанное сообщение,

как определено пользовательскими параметрами настройки "вызов переадресация занято".

Если на входящие вызовы, число которых находится в приемлемых пределах, не отвечают в течение (настраиваемого) интервала времени, то вызовы:

a) направляются на голосовую почту,

b) направляются на заранее сконфигурированный номер переадресации,

c) получают записанное сообщение,

как определено пользовательскими параметрами настройки "вызов переадресация не отвечает".

CALL TRANSFER (передача вызова) - Имеется для пользователя возможность легко передавать любой вызов на любой другой номер. Функция передачи переведет вызов на удержание и позволит набрать новый номер. Как только вызывной тональный сигнал услышан, пользователь должен иметь опцию завершения передачи. Альтернативно, пользователь должен быть способен поговорить с новым номером и затем или инициализировать передачу или сначала объединить все (три) стороны в конференц-вызов. В последнем случае пользователю должна быть предоставлена функция выйти из этого вызова конференц-связи. Когда не имеется никакого ответа или только голосовая почта от вызываемого терминала, пользователь должен иметь возможность возвращения к первоначальному вызову.

CALL FORWARD (переадресация вызова) - Должна быть возможность установить телефон для автоматической переадресации входящих вызовов на заранее сконфигурированный номер. Переадресация вызова может быть:

a) безусловной,

b) переадресацией при занятости,

c) переадресацией при «нет ответа».

КОНФЕРЕНЦ-ВЫЗОВЫ - Возможно объединить конференц-вызовы (вызовы конференц-связи) только в аудиоконференцию, независимо от источника речевого сигнала. Возможно установить конференцию по меньшей мере с 3 вызовами, то есть четырехсторонние переговоры. Требуется только поддерживать единственную конференцию в любой момент времени, но все еще есть возможность принять один другой входящий вызов, как описано выше в отношении ожидания вызова. Приемлемо, чтобы прототип был только способен принимать один входящий вызов для конкретной конференции, то есть внешний мост должен быть необходим для не-видеофонных вызовов.

Опции, ассоциированные с экранным отображением 54 состояния входящего вызова, позволяют пользователю добавлять или удалять вызов из соединения конференц-связи.

Возможно добавить вызовы к конференции независимо от того, являются ли они входящими или исходящими вызовами.

Если удаленный пользователь конференции вешает трубку, эта ветвь вызова должна быть очищена автоматически.

Вызовы могут быть сделаны без использования рук или пока используется телефонная трубка. Поднятие телефонной трубки должно вызвать клавиатуру набора номера, если не находятся в состоянии вызова, и подсоединить аудио к телефонной трубке. Требуется экранная клавиатура тонального набора номера (то есть числа от 1 до 0 плюс "*" и "#"). Кроме того, должна иметься кнопка паузы, чтобы вставить паузу в набираемую строку (для передачи через PABX, если шлюз(ы) 70 не может(могут) быть запрограммированы так, чтобы удалить это требование). Должно быть предусмотрено решение для добавления клавиши + и такой организации, чтобы знак "+" автоматически преобразовывался в строку международного доступа для этого местоположения.

Клавиша для исправления ошибок ввода (например, клавиша BACK [НАЗАД]) и клавиша очистки для очистки ввод также требуются. Короткое нажатие клавиши [НАЗАД] должно удалить последнюю введенную цифру, а более длительное нажатие продолжает удалять цифры, избыточное нажатие должно очистить регистр для цифр.

Экранное отображение 54 номера должно быть автоматически отформатировано к формату номера локального. [Это может требовать пользовательских установок для выбора страны операции, поскольку каждая страна имеет отличный стиль или, если международный код введен, этот код должен использоваться как основание форматирования остающейся части номера].

Когда связано со службами, которые предоставляют использование тональной цифровой клавиатуры, чтобы выбрать функциональные возможности, правильные тональные сигналы должны быть сформированы в направлении этой службы, когда используется эта экранная клавиатура или клавиатура телефонной трубки. Клавиатура набора номера должна быть способна обеспечить эту функцию независимо от того, как инициирован вызов.

REDIAL (повторный набор) - Возможно повторно набрать последний набранный номер посредством единственного касания на соответствующим образом идентифицированной функции.

AUTO REDIAL (автоматический повторный набор) - Возможно запустить механизм автоматического повторного набора, например, удерживая кнопку [REDIAL]. Автоматический повторный набор автоматически повторит вызов, если предыдущие попытки возвращают сигнал "занято" за множество попыток.

CAMP ON BUSY (сторона занята) - При выполнении вызова к устройству, которое разрешает свою поддержку, доступна функция "Camp on Busy". Вызов "Camp on Busy" вызывает пользователя как только вызываемая сторона становится доступной. Должно быть сгенерировано сообщение, чтобы сообщить "это услуга не доступна", если вызываемый номер не может поддерживать "Camp on Busy".

Может иметься соответствующий экран регистрации входа, когда никакой пользователь не зарегистрирован на видеофон 15.

Файл регистрации входящих, исходящих, частых и пропущенных вызовов должен быть отображен на соответствующем виде объединенных экранов набора номера. Доступ одним или двумя касаниями к функциональной возможности "повторный набор последнего номера" должен всегда быть доступен на экранных изображениях набора номера. Дополнительные определения этих видов регистрации даются ниже.

Чтобы получить доступ к полному набору функциональных возможностей, доступных на терминале видеофона 15, пользователь должен зарегистрироваться в терминале. Обеспечивается экранное изображение входа в систему (регистрации), в которое пользователь может ввести свое имя и пароль. Ими могут быть те же самые, что его обычные имя и пароль для доступа к сети 40. Терминал видеофона 15 поэтому будет использовать услуги проверки пользователя подразделений. Должны быть обеспечены любые экранные изображения, необходимые для разрешения IT-персоналу, чтобы сконфигурировать видеофон 15 для использования этих услуг аутентификации. Альтернативные способы идентификации пользователя являются доступными, например использование брелка с идентификатором или интеллектуальной карточки. Не имеется никакого требования для пользователя в отношении того, что он уже должен быть зарегистрирован в ПК 68 до регистрации в терминале видеофона 15.

Множество пользователей могут быть зарегистрированы на единственном видеофоне 15 и могут быть обеспечены отличающиеся тональные сигналы входящих звонков для каждого пользователя. Индикация входящего вызова должна также идентифицировать имена вызываемых сторон, а также имя вызываемых сторон. Если множество пользователей зарегистрированы на единственном видеофоне 15, все функции переадресации вызова являются специфическими для пользователя, к которому адресован вызов.

Если пользователь уже зарегистрирован в своем ПК 68, действие по регистрации на видеофоне 15 должно создать ассоциацию между ПК 68, где пользователь зарегистрировался, и терминалом видеофона 15, при условии, что это подтверждено от ПК 68. Имеется возможность для пользователя зарегистрироваться на множестве терминалов видеофона 15 одновременно. Активным видеофоном 15 является тот, на котором на любой вызов для этого пользователя отвечают первым.

Экран домашней страницы содержит область состояния, которая является видимой на всех экранах (за исключением этого в полноэкранном режиме). Состояние (статус) включает в себя имя зарегистрированного пользователя или "никакой пользователь не зарегистрирован". Состояние "Присутствие" пользователя, иконки для передачи видео и аудио, индикация "Сообщение" голосовой почты и дату и время.

Индикация "Сообщение" подсвечивается и мигает, если имеется непрослушанная голосовая почта в системе 10 голосовой почты пользователя. Нажатие индикатора вызывает экранное изображение обработки голосовой почты.

Касание области даты и времени дает доступ к функциям календаря.

Домашняя страница имеет область строки управления, которая является видимой поверх всех экранных изображений (за исключением полноэкранного режима).

Строка управления дает прямой доступ к наиболее часто используемым функциональным возможностям управления вызовом и доступ ко всем другим функциям. Иконки должны использоваться на кнопках, но может также использоваться текст, чтобы подчеркнуть функциональную цель.

Панель управления также имеет глобальное средство управления для микрофона, камеры и динамиков 64. Это средство управления должно ясно указывать их операционное состояние, например Включено или Выключено, и где возможно должны использоваться иконки.

Изображение самого себя является доступным, которое указывает и изображение, принимаемое камерой, и ту часть, которая является видимой для удаленного конца активного вызова. Возможно включить и выключить изображение самого себя и определить, всегда ли оно включено или только тогда, как только активный вызов был установлен.

Возможно отобразить изображение от камеры в основной области видеоэкрана в любое время, то есть во время вызова, не во время вызова и т.д. Изображение должно быть таким для единственного видеовызова и должно перекрываться любым другим имеющимся видео. Должна быть возможность запрашивать полноэкранную версию этого видео. Это может быть понято как цифровое зеркало и позволяет пользователю быть уверенным, что он/она доволен тем, что камера покажет/показывает.

Для диагностических целей желательно, чтобы пользователь мог также видеть изображение после кодирования и декодирования так, чтобы он знал о качестве изображения, которое будет видно в дальнем конце. Если этот режим поддерживается, то камера направляет и кодированное декодированное изображение рядом друг с другом. Пользователь может захватывать свое собственное изображение для использования в качестве изображения, ассоциированного с его информацией о контактах.

Основная часть домашнего экранного изображения распределена функциям Integrated Dial (Объединенный набор). Имеются четыре основные под-функции, экранное отображение 54 ускоренного набора номера, экранное отображение 54 доступа к каталогам, клавиатура набора номера и доступ для регистрации вызова. Клавиатура набора номера и доступ для регистрации вызова должны занять минимальную область экрана, совместимую с легкостью в использовании, максимизацию области, доступной для страниц ускоренного набора номера/контактов. Область ускоренного набора номера детализируется первой, любые общие требования поверх всех основных под-функций детализируются только при ускоренном наборе номера и подразумеваются для других трех функций. Функция области набора номера предназначена для выбора пользователя, к которому должен быть сделан вызов.

Область ускоренного набора номера является настолько большой, насколько, возможно, совместимой с другими требованиями для экранного изображения набора номера. Более 20 ячеек (местоположений) ускоренного набора номера являются достаточными. Каждая ячейка должна быть достаточно большой, чтобы сделать идентификационную информацию людей, сохраненную с подробностями в этой ячейке, очень легко читаемой на обычном рабочем расстоянии от экрана, скажем 3 фута (91 см).

Информация о пользователе, сохраненная в ячейке ускоренного набора номера, включает в себя имена людей, "состояние присутствия", если оно известно, номер, который должен быть вызван, если этот ускоренный набор номера выбран, и иконку для указания, поддерживает ли пользователь видеовызовы. Подробная информация также хранит вид видео, например видеофон 15, совместимый с MPEG2, H261 и т.д.

Эта область обеспечивает явную область, которой нужно коснуться, чтобы инициализировать вызов. Свернутое в пиктограмму представление человека имеется, если доступно. Обеспечивается способ обработки длинных имен (то есть имен, которые не помещаются в пространство, выделенное на кнопке Speed Dial).

Обычные номера телефонов в стандартном международном формате, то есть "+ код страны код города номер" автоматически преобразуются во внешний доступ плюс коды международного вызова, необходимые для осуществления вызова этого номера.

Полные подробности о контактах, ассоциированные с человеком на странице ускоренного набора номера, являются доступными. Эти подробности о контактах обеспечивают все номера, по которым пользователь может быть вызван, и средства выбора одного из номеров в качестве заданного по умолчанию номера, который используется на странице ускоренного набора номера. Возможно выбирать и набрать альтернативный номер для этого пользователя посредством этой связи со страницей контактов.

Информация о пользователе включает в себя историю наиболее последних вызовов для этого человека, например последние 10 вызовов или пропущенный входящий вызов или выходящий. Только обеспечение информации о "последнем вызове" может быть приемлемой минимальной функциональной возможностью.

Возможно редактировать подробности о контактах, ассоциированные с записью ускоренного набора номера, и/или создавать новую запись о контактах для страницы ускоренного набора номера. Возможно копировать запись из контактов, каталогов или экранов файла регистрации вызовов на страницу ускоренного набора номера. Возможно копировать запись из страницы ускоренного набора номера в контакты или экранные изображения каталогов. Возможно удалить запись ускоренного набора номера или переместить эту запись на другую страницу контактов. (То есть скопировать и затем удалить оригинал).

Возможно управлять размещением пользователей на странице ускоренного набора номера. Должно также быть возможно некоторым способом (цветной маркировкой) проводить различия между различными классами пользователей ускоренного набора номера, то есть в отношении бизнеса, семьи, коллег, продавцов, клиентов. Страница ускоренного набора номера может также содержать названия из множества других категории в информации о возможностях контактов. Доступна некоторая форма автоматической организации, например фамилия - имя - компания или посредством класса с последующими фамилией - именем - компанией и т.д.

Возможно определить группу пользователей как единственную запись ускоренного набора номера. Приемлемо, если размер группы ограничен размером максимальной конференц-связи. Возможно выбрать представление каталогов из страницы ускоренного набора номера. Представление каталогов займет ту же самую экранную область, что и страница ускоренного набора номера. Возможно осуществлять выбор из диапазона сетевых каталогов, к которым видеофон 15 имеет доступ. Значением по умолчанию будет каталог Outlook и/или Lotus Notes, который содержит подробности об основных контактах пользователей. Название выбранного каталога должно быть отображено.

Категории, установленные пользователем в его списке контактов Outlook и/или Notes, доступны в качестве вариантов выбора. Если количество категорий не вписывается в область отображения 54, обеспечиваются кнопки, чтобы листать список или вверх или вниз. Список должен быть организован в алфавитном порядке.

Категория "Ускоренный набор номера" является категорией, используемой для заполнения страницы ускоренного набора номера. Имеется некоторая индикация относительно того, когда страница ускоренного набора номера является заполненной, и больше невозможно добавлять дополнительные названия в эту категорию, если только они не заменяют существующую запись. Должна быть возможность упорядочивать записи ускоренного набора номера в порядке от самого последнего вызова, то есть наименее используемая запись ускоренного набора номера должна быть в конце списка. Это может быть использовано для того, чтобы видеть, какая запись является лучшим кандидатом на удаление, чтобы позволить ввести более часто используемый номер.

Возможно легко находить и выбрать запись из выбранной категории с минимальными пользовательскими входными данными. Механизмы выбора записи должны работать для относительно коротких списков и для очень длинных списков (10000 имен). Эти механизмы должны включать в себя возможность вводить текстовую строку, в отношении которой необходимо проводить поиск. Возможно выбрать порядок сортировки для представленных данных по фамилии, имени или организации. Имеется способ исправления ошибок в записях и быстрого повторного запуска всего поиска.

Желательно, если каждый порядок ключей поиска был существенен и мог бы быть изменен пользователем. Другими словами, например, нажатие и удержание наиболее левого ключа поиска дают возможность пользователю выбрать поиск по фамилии, имени или компании (или расширенному списку атрибутов. Это полезно, например, для отыскания кого-то в конкретном отделе или в конкретном местоположении - "кто находится в Корее"). Второй ключ затем квалифицирует (уточняет) первый поиск по ключу и так далее. Таким образом, ключами установлены Компания, Фамилия, Имя; скажем, Marconi, затем выполнение алфавитного поиска пользователей по фамилиям в Marconi. Ясно, что когда каждая категория вида выбрана, имеется некоторое подразумеваемое под-упорядочение записей с одним и тем же значением в поле этой категории. Так, для выбранной фамилии подразумеваемым вспомогательным порядком является имя, затем компания, а для компании подразумеваемый порядок сортировки - фамилия, имя, а для имени, скажем, фамилия, компания.

Экран регистрации вызова отображает самые недавние записи трех категорий вызовов - исходящие, входящие и пропущенные вызовы, с явной индикацией того, какая категория выбрана. Кроме того, должна иметься категория "частых вызовов", которая перечисляет номера по частоте использования, по последним (<200) вызовам любого типа. Должен иметься доступ к клавиатуре набора номера от экранного изображения регистрации вызовов. Анализ этого значения обеспечения намного большей степени обработки данных регистрации вызова является разностным.

Как минимум, когда касаются (области) "сообщение", соединение выполняется к системе 10 голосовой почты пользователей, причем голосовая почта для этого пользователя вводится, и отображается клавиатура набора номера, чтобы управлять голосовой почтой, используя нажатия обычных телефонных клавиш. Большая часть экрана "голосовой почты" должна вызывать кнопки, чтобы обратиться к каждой функциональной возможности системы 10 почты, например «Следующее Сообщение», «Предыдущее Сообщение», «Воспроизведение Сообщения», «Отправить Сообщение», «Ответить на Сообщение», «Вызвать отправителя» и т.д. со всеми эквивалентами нажатия клавиш в пределах каждой функции, например начать запись, остановить запись, просмотреть запись, удалить запись и т.д. Все эти функции должны быть на кнопках, преобразованы в соответствующие тональные сигналы DMF.

Желательно, чтобы номер "Передать к" или любая команда голосовой почты, которая требует список номеров пользователей, которые должны быть введены, могли быть выбраны из (экранных) представлений ускоренного набора номера или каталогов, и этот выбор автоматически вставляет только соответствующую часть кодов пользователя. Это может быть особенно полезно при переадресации голосового сообщения к группе. Должна быть возможность для пользователя установить время и дату на видеофоне 15. Желательно, чтобы время и дата могли быть установлены автоматически посредством соответствующей услуги сети 40.

Желательно, чтобы были доступны функциональные возможности календаря, который интегрирован с пользовательскими приложениями Schedule/Calendar в Outlook/Palm/Notes. Минимальное требование может заключаться в том, чтобы просто просмотреть назначения на любую дату, по дням, неделе или месяцу (согласно экранным изображениям Outlook или Palm) с изменениями и новыми записями, возможными только через базу данных Outlook или Palm.

Вероятно, что очень малое количество пользователей не будут поддерживать свои собственные календари и действительно могут не иметь персональных компьютеров 68 на своем столе, но нуждаются в просмотре этой информации. Касание области «Состояние Пользователя» части состояния экрана позволяет пользователю устанавливать его состояние. Пользователь должен иметь диапазон опций Status (Состояние) для выбора, включающих в себя:

i) доступный,

ii) занятый - для вызова, когда другой вызов не должен быть принят,

iii) не тревожить - не в состоянии вызова, но является непрерываемым,

iv) вернусь через пять минут,

v) вне офиса,

vi) в отпуске.

Случай одного вызова на терминале видеофона 15 поддерживает от одного входящего потока до максимального количества потоков в конференции. Для видеоконференции терминал будет поддерживать по меньшей мере четыре соединения с другими сторонами в качестве части одной конференции. Возможно принять по меньшей мере два независимых только аудиовызова, даже когда имеет место видеоконференция максимального размера, так чтобы вызов аудио мог быть передан для проведения консультации. Видеофон 15 способен поддерживать по меньшей мере три одновременных "случая вызова", то есть до трех независимых вызовов. Только один вызов может быть активен, то есть управление вызовом может быть применено только к одному вызову одновременно. Больше чем один вызов могут быть приняты, то есть пользовательские аудио и видео передаются в отношении каждого принятого вызова, независимо от того, активный он или нет. Текущие вызовы также могут быть переведены в Удержание, когда пользовательские аудио и видео не передаются пользователю, находящемуся в состоянии Удержание, и аудио и видео от этого пользователя также подавляются.

Состояние входящих вызовов показывается в области экранного отображения 54 управления. Сами вызовы и управление во время вызова показываются в основной секции дисплея 54.

Состояниями вызова являются:

i) Входящий вызов.

ii) Принятый и активный - пользовательское аудио (и видео, если вызов видео) подвержено различным регулировкам приглушения, ассоциированным с этим вызовом. Управление вызовом применяется к этому вызову.

iii) Принятый и не активный - как и выше, но управление вызовом не применяется к этому вызову.

iv) Принятый и в состоянии Удержание - пользовательское аудио (и видео, если вызов видео) не передается к этому вызову.

v) Принятый и передаваемый.

Состояния Вызова обозначены в отношении каждого вызова. Только один принятый вызов может быть активен. Принятый вызов делается активным посредством касания в области экранного отображения 54 вызова, ассоциированной с этим вызовом, или состояния вызова в панели управления. Любой предыдущий активный вызов устанавливается как неактивный. Второе касание выключает активное состояние. Индикация входящего вызова указывает, предлагает ли вызов соединение видео. Никакой индикации не предусматривается для только аудиовызова. Индикация входящего вызова будет показывать имя (имена) сторон, ассоциированных с этим входящим вызовом. Немедленно показывается, если пользователь вызывается один на один, или приглашается присоединиться к конференции.

Пользователь имеет следующие опции для обработки входящего вызова:

i) принять вызов в качестве только голосового вызова

ii) принять вызов в качестве видеовызова (голос подразумевается)

iii) послать речевое сообщение

Установка параметров доступна для установки терминала видеофона 15 на автоматический ответ на входящие вызовы, вплоть до максимального числа поддерживаемых вызовов. Автоматический ответ создает аудио и видеосоединение, если это предлагается. Как только вызов происходит, состояние пользователей должно быть автоматически изменено на "В состоянии вызова". Состояние пользователей возвращается назад к своему предыдущему состоянию (обычно "Доступен"), как только не будет активных вызовов.

Пользователь способен конфигурировать, если пользовательские данные вызова также распределены. Если пользователь уже имеет один или более принятых вызовов, и если все вызовы находятся в состоянии Удержание или являются не активными, этот вызов создаст случай нового вызова, если это приемлемо. Все принятые, но не активные вызовы будут продолжать видеть и слышать пользователя, когда он имеет дело с этим новым вызовом. Если один из принятых вызовов принят и является активным, новый вызов должен быть присоединен к этому вызову, и все стороны для этого вызова должны быть подсоединены как конференция для новой вызывающей стороны, если вызов принят.

Если пользователь не снимает трубку после (> 10) секунд, вызов должны быть автоматически переадресован, как определено параметром настройки "Переадресовать при отсутствии ответа". Как и выше, переадресация является специфической для пользователя, к которому вызов адресован. Если состояние пользователей отмечено как "Не беспокоить" или "Занятый", или "Занятое" состояние было установлено из-за максимального количества обрабатываемых вызовов, вызов переадресовывается "немедленно", как определено параметрами настройки "Переадресация при Занято" и "Переадресация при Не Беспокоить", как модифицировано установкой "Показать переадресованные вызовы", если это реализовано.

В зависимости от параметра настройки "Показать переадресованные вызовы" пользователь может пожелать увидеть индикацию входящего вызова в течение (> 5 секунд) прежде, чем он будет переадресован. (Это означает, что пользователь должен не предпринимать никакого действия, если он не желает принять вызов, вместо положительного действия, требуемого в ответ на вызове выше.) Это не выполняется, если имеется состояние Занято из-за того, что видеофон 15 уже обрабатывает максимальное количество вызовов.

Способность генерировать (очень короткое) текстовое сообщение, которое посылается вместе с вызовом, является полезным способом передачи подробной информации относительно важности вызова и как долго он будет продолжаться. Требования, ассоциированные с формированием и добавлением сообщения к исходящему вызову, описаны ниже. Если существует, текстовое сообщение входящего вызова должно быть отображено ассоциированным с входящим вызовом. Дисплей 54 копирует отображение текстовых сообщений в отношении множества входящих вызовов одновременно. Текстовое сообщение также сохраняется в файле регистрации входящих или пропущенных вызовов.

Согласование (переговоры) о параметрах вызовов ограничены тем, что необходимо для установления вызова в пределах параметров политики сети 40 и использования текущей сети 40. Параметры настройки обеспечиваются для того, чтобы позволить пользователю определять его предпочтения для вызовов к другим терминалам видеофона 15, например всегда предлагать видео, никогда не предлагать видео, запрашивать каждый вызов - хочу ли я предложить видео или нет.

Состояние «Camp on Available» (Сторона доступна) поддерживается для вызовов к другим пользователям видеофона 15. Он будет инициализировать вызов пользователю, как только его состояние изменяется на "доступный". Если пользователь, который должен быть вызван, является группой, вызовы должны быть инициализированы только тогда, когда все члены группы "Доступны".

Конференц-вызов имеет место тогда, когда одна ячейка в списке скоростного набора или каталогов представляет группу людей, каждый из которых должен быть участником вызова. Предлагаемый процесс осуществления этой функциональной возможности заключается в осуществлении каждого вызова по очереди и однократное подтверждение активного вызова, что этот вызов должен быть добавлен к конференции. Это дает «запасной путь», если вызов проходит на голосовую почту. Как только действия в отношении первой вызывающей стороны закончены, то есть вызов принят или отклонен, обрабатывается следующий номер.

Возможно создать исходящий вызов, который является полудуплексным, другими словами, который запрашивает аудио и/или видео от вызываемого абонента, но не ничего не передает ни на каком виде вызова. Это есть режим распространения (pull). Эквивалентно, возможно создать режим распространения, когда исходящий вызов посылает аудио и/или видео, но не требует никакого аудио или видео в ответ. Этот режим может использоваться, чтобы выборочно вещать контент на необслуживаемые терминалы, или терминалы с пользователями, играющими только пассивную роль в конференции.

Полная громкость динамиков 64, телефонной трубки и головного телефона настраиваются независимо. Динамик может быть включен и выключен. Выключение динамика также выключает микрофон. Индикаторы состояния показывают состояние Динамика и Микрофона.

Микрофон может быть выключен и опять включен. Индикаторы состояния показывают состояние глушения микрофона.

Камера может быть выключена и опять включена. Индикаторы состояния показывают состояние глушения (выключения) камеры.

При управлении вызовом работают только над активным вызовом. Принятый вызов делают активным, если он не является активным, или касаясь индикатора состояния текущих вызовов на панели управления, или где-нибудь в области экранного отображения 54 вызова, за исключением областей функций управления текущим вызовом. Любой другой в настоящее время активный вызов переводится в неактивный. Активный вызов может быть переведен в неактивный последующим нажатием в той же самой области. Обеспечивается управление, которое дает отбой ("вешает трубку") для активного вызова. В конференц-связи это очищает все элементы для экземпляра (события) вызова.

Вызов должен быть принят и сделан активным для функционирования управления конференцией. Касание средства управления конференцией присоединит экземпляр в настоящее время активного вызова к следующему вызову, сделанному активным. Средство управления конференцией будет указывать его как активный или до тех пор, пока оно не будет нажато снова, делая его неактивным, или другой экземпляр вызова не будет сделан активным. После того как все вызовы в теперь активном вызове подсоединены к объединенному в конференцию экземпляру вызова, этот вызов становится единым объединенным в конференцию вызовом, и индикация активности управления конференцией гаснет. Для повторной установки конференция выбирает вызов, к которому другие вызовы должны быть подсоединены, и затем выбирают вызов, чтобы присоединить к этому вызову.

Способ завершения участия одной стороны в конференции является для этой стороны переводом в (состояние) «повесить трубку». Вследствие множества причин пользователь может желать иметь независимое управление относительно каждой части экземпляра вызова. Это может быть достигнуто возможностью разъединения конференции. Например, при касании экземпляра вызова в течение более чем трех секунд появляется меню, которое позволяет индивидуальным элементам экземпляра вызова быть идентифицированными и выбранными для разъединения конференц-связи. Этот вызов затем удаляется из конференции и устанавливается как отдельный экземпляр вызова, к которому применяются все обычные средства управления, в частности он может быть удален.

Функция передачи передает активный вызов. Когда касаются средства управления передачей, отображается объединенное экранное отображение набора номера, и активный вызов переводится в Удержание, но указывая, что он задействован в операции в отношении вызова. Средство управления передачей указывает, что он является активным до тех пор, пока оно не будет нажато второй раз, отменяя передачу, или вплоть до тех пор, пока пользователь не выберет и не нажмет набор номера для номера, к которому он желает, чтобы вызов был передан.

Как только исходящий вызов был инициализирован, средство управления передачей указывает изменение состояния, так что касание средства управления вызывает "слепую" передачу, и экземпляр вызова удаляется с экрана. Альтернативно, пользователь может ожидать до тех пор, пока вызываемый номер не ответит, в этот момент создается новый экземпляр вызова, позволяя пользователю говорить с вызываемым абонентом, и функция передачи снова изменяет состояние, чтобы указывать, что ее нажатие снова завершит передачу и завершит оба вызова. В противном случае требование должно возвратиться к говорящему, находящемуся в процессе передачи, и повторно начать процесс передачи или завершения вызова. Передача является основным механизмом, посредством которого "администрация" устанавливает вызов и затем передает его "боссу". В этом случае необходимо, чтобы было невозможно для администрации продолжать прослушивать переданный вызов. Это должно быть особенно верно для безопасной среды.

Активный вызов может быть помещен в состояние Удержание посредством касания средства управления Удержание. В состоянии Удержание исходящие потоки видео и аудио приостанавливаются и удаленному концу выдается индикация, что он находится в состоянии Удержание. Входящие потоки аудио и видео больше не отображаются. Состояние Удержание обозначено на экранном отображении 54 состояния вызова на строке (в панели) управления. Средство управления Удержание указывает, что состояние Удержание является активным, если любой вызов находится в состоянии Удержание. Нажатие Удержание снова, когда активный вызов находится в состоянии Удержание, удаляет Удержание и возвращает вызов к отображенному состоянию.

Имеется средство управления на основной панели управления, которое вызывает домашнее (начальное) экранное отображение и предоставляет доступ ко всем другим функциям, не относящимся к вызовам. Имеется индикация, что выбран пункт Main (Главное). Нажатие Main второй раз восстанавливает отображения текущих вызовов и снимает выделение Main. Отдельные средства управления предусмотрены для каждой принятой и отображенной стороны в вызове и для каждого отображенного вызова. Требуется регулировка громкости аудио от каждого конкретного пользователя. Возможно индивидуально подавлять передачу аудио и/или видео каждого пользователя, отображенного на экране. Имеется индикатор состояния, чтобы указать, является ли подавление аудио или видео включенным.

Если больше чем один экземпляр вызова могут быть отображены в любой момент, например конференц-вызов с двумя другими плюс новый вызов к одному другому пользователю, то возможно подавлять передачу аудио и/или видео для экземпляра полного вызова, например заглушение конференции двух сторон для аудио, в то же время разговаривая со вторым вызовом.

Обеспечивается запрос видео в отношении только аудиосоединения, которое может поддерживать видео. Обеспечивается прием или отклонение запроса видео. Видеосоединение устанавливается, если это соединение согласовано. Элемент страницы параметров настройки дает возможность пользователю всегда принимать или всегда отклонять запросы видео.

Возможно отобразить параметры однонаправленного канала для каждого соединения, то есть скорости кодирования входящих и исходящих (вызовов) для видео, если оно присутствует, и аудио. Во время вызова средства управления работают только в отношении активного вызова. Принятый вызов делают активным, если он не активный.

Возможно разрешить "контроль качества однонаправленного канала" для любого пользователя. Этот контроль, немного схожий с измерением мощности сигнала для мобильного телефона, может отобразить, например, на 100% зеленую область, когда не имеется никаких ошибок или потерянных пакетов в аудио и видеоканалах, желтую область, как только частота потерь или время ожидания превышают заранее определенную частоту, и красную область, как только она превышает более высокую частоту. Интервал времени должен быть коротким, скажем, 50 миллисекунд, так как ошибки в этом периоде будут влиять на пользовательское видео. Так, например, если приемник видит видеоартефакты, но в то же время видит, что область контроля является желтой или красной, он знает, что это вызвано перегрузками сети 40.

Обеспечивается запрос изменения параметров кодирования видео, то есть увеличение или уменьшение скорости кодирования во время вызова. Обеспечиваются прием или отклонение этого запроса и способ изменения скорости кодирования исходящего видео. Видеофон 15 генерирует единственную скорость кодирования исходящего (вызова) для всех участников. Для него возможно принимать различные скорости кодирования входящих (вызовов) для всех входящих потоков.

Обеспечивается запрос на вспомогательную панель со способностью принимать или отклонять вызов. Если является подходящим, вспомогательная панель отключает поток аудио от обоих участников к кому-либо еще, так что они могут иметь частный разговор, все еще продолжая слышать всю дискуссию и продолжать видеть и быть видимым всеми участниками. Обеспечивается способность посылать короткие сообщения обоими способами с запросами видео и вспомогательной панели.

Независимо от того, является ли вызов входящим или исходящим вызовом, переход экрана к представлению видео должен быть гладким. Аудио может опережать видео. Видео не должно быть отображено, пока этот переход не будет сделан. (То есть не должно иметься никаких неровных изображений, наполовину сформированных кадров и т.д. при переходе к видео). Переход к экранному отображению видео на пользовательском дисплее 54 должен начаться только после того, как вызов является "исполняемым в настоящий момент", а не во время инициализации вызова. Отображение видео от пользователя должно максимально использовать область экранного отображения 54, распределенную дисплею 54 пользователя. Средство управления на дисплее 54 способно преобразовывать это экранное отображение 54 единственного пользователя одного экземпляра вызова в полноэкранное отображение 54. Касание где-нибудь внутри "полноэкранного" отображения 54 обеспечит возврат к стандартному экранному отображению 54. В дополнение к управлению во время вызова, упомянутому выше, должны быть отображены имена пользователей. Экранное отображение 54 и экземпляр вызова на панели управления должны указывать, является ли вызов активным или нет, то есть будет работать или нет средство управления во время вызова. При установлении одного экземпляра вызова установка "активный - неактивный" выполняется посредством нажатия на экземпляре вызова или где-нибудь на основном дисплее 54 вне специфичной для текущего вызова области управления.

Переход от одного экземпляра вызова к двухстороннему вызову должен быть гладким и должен быть инициализирован, как только второй вызов становится "исполняемым в настоящий момент". Экранное отображение 54 должно максимально использовать область дисплея 54, выделенную экранному отображению 54 пользователя. В случае необходимости видеоизображения могут быть отсечены с каждого края вместо масштабирования, чтобы вписаться в доступную область. Не имеется никакого требования для полноэкранного отображения 54 для двух или более (вызовов). В дополнение к средствам управления во время вызова, уже упомянутых выше, имя пользователя должно быть отображено для каждой стороны. Должна иметься индикация, что обе стороны являются частью единственного экземпляра вызова. Экранное отображение 54 и экземпляр вызова на панели управления должны указывать, является ли вызов активным или нет. Входящее видео может быть прогрессивно отсечено, чтобы вписаться в доступную область отображения 54, когда большее количество сторон добавляется к видеовызову.

В случаях двух вызовов, где оба являются односторонними вызовами, имеются два отдельных вызова к отдельным пользователям, которые оба отображаются. Экранное отображение 54 и индикация управления вызовом явно указывают, что они являются двумя отдельными и независимыми вызовами, и также указывают, какой, если он есть, является активным. Если какой-либо вызов переведен в состояние Удержание, тот этот вызов больше не отображается, и дисплей 54 возвращается к экранному отображению 54 одного вызова для случая единственного вызова.

Область пользователя должна быть способна отображать любую из следующих комбинаций в дополнение к тем, что описаны выше.

Четыре экземпляра вызова, каждая сторона делает один вызов;

три экземпляра вызова, когда один вызов может быть двухсторонним, а другие - односторонними вызовами;

два экземпляра вызова, где один может быть вплоть до трехстороннего или два могут быть двухсторонним вызовом.

Требованиями экранного отображения 54 в стиле "CNN" являются требования единственного вызова от единственной стороны, как описано выше, включая способность иметь полноэкранное отображение 54. Также возможно отобразить вызов в стиле "CNN" на половине экрана и использовать другую половину для областей отображения одного или двух пользователей, последний случай - в качестве двух экземпляров независимых вызовов или единственного экземпляра двухстороннего вызова.

Предоставляется способность обеспечивать различные уровни шифрования для голосовых потоков и потоков данных. Доступ к функциональным возможностям диагностики, тестирования, измерения и управления должны использовать SMF (простую структуру управления, ПСУ), другими словами, доступ должен быть возможен ко всем функциональным возможностям тремя способами - через SNMP (простой протокол сетевого управления), через сеть и через специализированный интерфейс. Терминал видеофона 15 должен быть удаленным образом управляем, не требуя на месте IT опыта для каждодневной работы или для обновлений программного обеспечения, которые фиксируют ошибки. Диагностика ошибок также возможна для осуществления удаленным образом и должна быть способна определить, имеется ли проблема с аппаратными средствами модулей, конфигурацией модулей, программным обеспечением модулей, сетью 40 или услугами сети 40. Управление может предполагать IP связность, но должно предполагать соединение с относительно малой полосой частот с видеофоном 15.

При нормальной работе видеофон 15 должен выполнить сокращенную версию тестирования аппаратной системы 10 при включении питания. Если оно заканчивается неудачей, видеофон 15 должен отобразить сообщение о неудаче начальной загрузки на основном экране. Терминал может быть переведен в расширенный диагностический режим аппаратного обеспечения. Это может быть выполнено посредством присоединения клавиатуры к USP порту или посредством нажатия в верхнем правом углу сенсорного экрана 74 при включении модуля. Этот режим может предоставить доступ к нижележащей операционной системе 10 и более мощным средствам диагностики, чтобы определить, имеется ли аппаратный отказ или нет.

Может быть использована последовательность простых тестов, которую пользователь может запустить, в случае, когда видеофон 15 проходит тест при начальной загрузке, но не обеспечивает корректные функциональные возможности для пользователя. Терминал обеспечивает технический интерфейс совместно с локальной клавиатурой (и мышью), чтобы помочь в диагностировании проблем модуля или системы 10. Он может предоставлять доступ к различным диагностикам для аудио и видео и т.д.

Возможно безопасно загрузить новые версии программного обеспечения терминала видеофона 15 под дистанционным управлением. Безопасно - это означает быть способным возвратиться к предыдущей версии, если происходят ошибки в загруженной версии, без локального вмешательства (то есть кто-то, имеющий необходимость установить CD). Возможно считать номер версии программного обеспечения на конкретном терминале видеофоне 15, и серийный номер аппаратных средств модулей, номер редакции компоновки и серийный номер и номер редакции компоновки ключевых подсистем посредством интерфейсов управления. В случае, когда система 10 отказывает, видеофон 15 должен сохранить или иметь сохраненную информацию, чтобы помочь диагностировать причины этого аварийного отказа. Эта информация должна быть восстановима в оперативном (on-line) режиме из удаленного местоположения для анализа, как только видеофон 15 будет перезагружен.

Видеофон 15 сохраняет файл регистрации всех действий, событий и изменений состояния с момента включения в пределах объема памяти, которая может быть распределена для обеспечения этой возможности. Это должно дать возможность сохранения по меньшей мере в течение одного месяца активности. Эти данные могут находится во множестве категорий, например безопасной категории, которая содержит данные пользователей, такие как номера, которые он набирал, должны быть разблокируемыми только этим пользователем. Общие данные, такие как количество вызовов, состояние вызова (то есть количество экземпляров вызова и оконечных точек в расчете на экземпляр, характеристики кодера 36 и декодера 34, сообщения об ошибках однонаправленного канала и так далее), не являются такой чувствительной информацией. Может быть полезно записывать каждое нажатие клавиши в качестве способа помощи для диагностирования проблемы на уровне системы 10 и восстановления цепочки событий.

Существует возможность для видеофона 15 копировать обмены на уровне плоскости управления как на уровне IP, так и уровне SIP на удаленный диагностический терминал (эквивалент наличия контрольного устройства, удаленно подсоединенного к терминалу видеофона 15). Управление терминалом должно контролировать ряд параметров, например качество сети 40. Должно быть возможно устанавливать пороги и генерировать оповещения, когда эти пороги превышены. И АТМ интерфейс и интерфейс Ethernet имеют стандартные средства измерения (например, подобные rmon - средствам удаленного мониторинга), которые должны быть доступны для видеофона 15. Видеофон 15 должен быть способен посылать эти оповещения к одной или более системам управления сетью.

Аудиосмеситель

Что касается смесителя аудио, первый узел 80, который может формировать поток аудио и поток видео, и который является частью сети АТМ, имеющей характеристику качества услуг, желает сформировать вызов от точки к точке со вторым узлом 82. Второй узел 82 имеет возможность только аудио и является, например, телефоном PSTN. Второй узел 82 не является частью сети АТМ.

Первый узел 80 начинает формирование вызова к второму узлу 82 посредством посылки информации сигнализации на SIP-сервер, также часть сети АТМ, которая идентифицирует для сервера, что второй узел 82 является адресатом вызова, который инициализирует первый узел 80. Сервер, который уже имеет адресную информацию относительно второго узла 82, добавляет эту адресную информацию к информации сигнализации, принятой от первого узла 80, и передает информацию сигнализации с адресной информацией второго узла 82 на аудиосмеситель 20, который является также частью сети АТМ.

Когда смеситель 20 принимает информацию сигнализации, которая исходила из первого узла 80, он определяет на основе этой информации, что он является вторым узлом 82, с которым первый узел 80 желает установить соединение. Смеситель 20 затем посылает приглашение на второй узел 82, через который он так или иначе находится в связи, например, посредством линии Т1 или Ethernet, но не посредством сети АТМ, чтобы идентифицировать себя в отношении своих функциональных возможностей и формы, в которой данные должны быть ему предоставлены так, чтобы он мог понимать данные. В ответ второй узел 82 идентифицирует для смесителя 20 конкретную форму, в которой должны быть данные, так, чтобы второй узел 82 мог понимать данные, и также указывает микшеру 20, что все готово, чтобы посылать данные к нему, так что соединение может быть сформировано.

Смеситель 20 затем посылает сигнал первому узлу 80, что он готов сформировать соединение. Для первого узла 80 смеситель 20, который является частью сети АТМ, представляет второй узел 82 и дает информацию к первому узлу 80, что второй узел 82 является частью сети АТМ и аналогичен первому узлу 80. Второму узлу 82 смеситель 20, который является также частью этой сети или связности, к которой принадлежит второй узел 82, представляет первый узел 80 и дает информацию второму узлу 82, что первый узел 80 является частью той же самой сети или связности, к которой принадлежит второй узел 82, и является аналогичным второму узлу 82.

Первый узел 80 затем инициализирует потоковую передачу данных, которая включает в себя данные аудио, и одноадресным образом вещает пакеты данных на смеситель 20, как хорошо известно в данной области техники. Когда смеситель 20 принимает пакеты, он буферизует данные в пакетах, как известно в данной области техники, фактически завершая соединение в отношении пакетов от первого узла 80, которые предназначены для второго узла 82. Смеситель 20, будучи информированным ранее посредством приглашения, которое было послано второму узлу 82, о форме данных, в которой они должны быть, так, чтобы второй узел 82 мог понимать их, преобразует буферизированные данные в необходимый формат и затем подвергает надлежащим ограничениям по времени, посылает должным образом переформатированные данные, по существу, по новому и отдельному соединению от смесителя 20 к первому узлу 80. Таким образом, формируется вызов точка-точка, хотя он в действительности содержит два различных соединения, и ни первый узел 80 ни второй узел 82 не "осознают", что используются два соединения, чтобы создать желательный вызов точка-точка между первым узлом 80 и вторым узлом 82. Точно так же, когда данные посылают от второго узла 82 назад к первому узлу 80, процесс повторяется, хотя наоборот, так чтобы после того, как данные от второго узла 82 принимаются микшером 20, смеситель 20 переформатирует данные в форму, которую первый узел 80 может понимать, и одноадресным образом вещает данные от второго узла 82, которые были буферизированы в смесителе 20, к первому узлу 80. Если используется IP вместо АТМ, то смеситель 20 посылает одноадресным образом вещаемые IP пакеты первому узлу 80, как хорошо известно в данной области техники.

Сценарий, использующий конференц-связь, иначе известный как соединение точка-многоточка, описан ниже, используя настоящее изобретение. Продолжая описание, используя соединение точка-точка, как описано выше, первый узел 80 желает участвовать в соединении, чтобы сформировать конференцию, третий узел 84, который является частью сети АТМ и имеют по существу те же самые характеристики, как и первый узел 80. Первый узел 80 посылает приглашение сигнализации на главный узел 22, который должен быть главным узлом конференции. Главным узлом 22 может быть первый узел 80 или им может быть отличный узел. Первый узел 80 обменивается с главным узлом 22 через сервер, чтобы сформировать конференцию и присоединить третий узел 84 в конференцию. Главный узел 22 приглашает и затем формирует соединение для целей сигнализации с микшером 20 и вызывает завершение первоначального соединения сигнализации между первым узлом 80 и микшером 20. Главный узел 22 также приглашает и формирует соединение с третьим узлом 84 в ответ на запрос от первого узла 80 к третьему узлу 84, чтобы соединиться в соединение. В каждом случае, когда узел, который является частью сети АТМ, должен быть присоединен в соединение, сигнализация проходит через сервер и должным образом маршрутизируется, как известно в данной области техники. Главный узел 22 действует как типичный главный узел для соединения конференц-связи в сети АТМ. Смеситель 20 представляет любые узлы, которые не являются частью сети АТМ, но должны быть частью полного соединения конференц-связи.

В отношении любого из узлов в сети АТМ смеситель 20 делает любые узлы, которые являются частью соединения, но не являются частью сети АТМ, кажущимися, как если бы они были точно такими же как другие узлы в сети АТМ. Через соединения сигнализации, которые сформированы между главным компьютером и микшером 20, и микшером 20 и вторым узлом 82 (как представляются микшером 20), требуемая информация от всех узлов соединения выдается к каждому из узлов так, чтобы они могли понимать и связываться со всеми другими узлами соединения. Фактически, главный узел 22 сообщает всем другим узлам не только информацию о характеристиках других узлов, но также и возвращает информацию к узлам, которую они первоначально выдали ведущему узлу 22, так, чтобы, по существу, каждый узел получил свою собственную информацию назад. Как только эта информация распределена, выполняется передача потоковой информации, как обычно имеет место в любой типичной ситуации конференц-связи. В сценарии сети АТМ первый узел 80 и третий узел 84 будут выполнять АТМ многоадресное вещание, используя PMP дерево, информации в пакетах друг к другу и на смеситель 20. В IP-среде первый узел 80 и третий узел 84 будут выполнять IP многоадресное вещание пакетов ко всем узлам (смеситель 20 является узлом для этой цели) в сети, и только те узлы, которые являются частью соединения, смогут понять и использовать информацию этого конкретного пакета, которая была частью этого соединения.

Смеситель 20 принимает пакеты от первого узла 80 и третьего узла 84 и буферизует их, как описано выше. Пакеты от различных узлов, которые приняты смесителем 20, переформатируются, когда они принимаются, и смешиваются или суммируются вместе согласно стандартным алгоритмам, хорошо известным специалистам в данной области техники. В заранее определенный момент времени, как известно в данной области техники, переформатированные смесителем 20 данные затем передают ко второму узлу 82. Таким же образом, но только наоборот, данные от второго узла 82 принимаются смесителем 20 и буферизируются. Они затем подвергаются мультивещанию (многоадресному распространению) в переформатированной форме к первому узлу 80 и третьему узлу 84.

Когда четвертый узел, который имеет возможность только аудио, подобно второму узлу 82, и который не является частью сети АТМ, присоединяется к конференции, главный узел 22 формирует второе соединение сигнализации со смесителем 20. Смеситель 20, в свою очередь, формирует другое соединение с четвертым узлом, отдельным от соединения, которое смеситель 20 сформировал со вторым узлом 82. Смеситель 20 поддерживает список сеансов связи, которые он поддерживает. В сеансе связи, вовлекающем подчиненную конференцию, он идентифицирует два кросс-соединения через смеситель 20. Первое кросс-соединение осуществляется через соединение сигнализации от ведущего узла 22 ко второму узлу 82, и второе кросс-соединение осуществляется от ведущего узла 22 к четвертому узлу. Таким образом, первый и третий узлы 80, 84, так же как и главный узел 22, полагают, что имеются два отдельных узла, представляющих собой второй узел 82 и четвертый узел, с которыми они поддерживают связь. Фактически, смеситель 20 представляет и второй узел 82, и четвертый узел и отдельно выполняет многоадресное вещание данных от каждого из них, чтобы поддерживать эту иллюзию, так же, как и иллюзию, что второй узел 82 и четвертый узел являются аналогичными первому узлу 80 и третьему узлу 84, к первому узлу 80 и третьему узлу 84.

Система ViPr является значительно усовершенствованной системой проведения видеоконференций, обеспечивающая качество конференц-связи как "Виртуальное Присутствие", которое значительно превышает возможности любых систем проведения видеоконференций, имеющихся сегодня на рынке. Система ViPr полагается на вещание SVC «точка-многоточка» (PMP-SVC) и IP многоадресное вещание, чтобы установить потоки точка-многоточка для мультимедийной информации аудио/видео среди участников конференции. В то время как пользователи, участвующие в конференции ViPr, наслаждаются конференцией с беспрецедентным качеством аудио и видео, имеется потребность дать возможность другим не-ViPr пользователям присоединиться к конференции ViPr. Система 10 допускает добавление одноадресного вещания только речевого телефонного вызова (то есть PSTN, мобильных телефонов и телефонов SIP) к многосторонней конференции ViPr.

Современная система ViPr обеспечивает поддержку для систем телефонной связи посредством цифровых и аналоговых шлюзов телефонной связи, основанных на SIP. Эти функциональные возможности дают возможность пользователям ViPr выполнять/принимать вызовы «точка-точка» на/из пользователей телефонов. Однако они не позволяют пользователю ViPr добавлять телефонный вызов к конференции ViPr. Это имеет место ввиду природы одноадресного вещания телефонных вызовов и неспособности шлюзов телефонной связи преобразовать их в PMP/многоадресные потоки. UAM ViPr расширяет поддержку ViPr систем для телефонной связи, позволяя пользователям ViPr добавлять телефонные вызовы одноадресного вещания к конференциям ViPr.

Чтобы поддерживать эти функциональные возможности, UAM ViPr «гладко» добавляет функциональные возможности конференц-связи между терминалами ViPr и пользователями телефонов (то есть PSTN, мобильных телефонов и телефонов SIP) посредством преобразования восходящего одноадресного потока аудио телефонной связи в потоки аудио точка-многоточка (то есть PMP-SVC или IP многоадресного вещания) и смешивая/преобразуя нисходящие ViPr потоки аудио PMP/многоадресного вещания в одноадресный поток аудио телефонной связи, а также выполняя транскодирование нисходящего аудио для ViPr аудио из широкополосного 16 бит/16 кГц ИКМ-кодирования в G.711 или G.722.

Дополнительные функциональные возможности, обеспеченные UAM, являются функциональными возможностями шлюза Intermedia, который преобразовывает IP/UDP потоки аудио в АТМ SVC потоки аудио, и наоборот. Эти функциональные возможности допускают возможность к взаимодействию между системами ViPr, развернутыми в средах АТМ и основанных на SIP шлюзах телефонной связи «речь-через-IP» (VoIP) в сетях Ethernet.

UAM позволяет одному или более ViPr-телефонам работать с одним или более телефонных шлюзов.

UAM поддерживает ViPr вызовы конференц-связи с устройствами одноадресного вещания аудио, присутствующими в следующих конфигурациях:

= Тип 1: Поддержка одного вызова конференц-связь только с одним устройством одноадресного вещания аудио, присутствующим в качестве участника.

= Тип 2: Поддержка множества вызовов конференц-связи. Каждый вызов конференц-связи может потенциально иметь множество устройств одноадресного вещания аудио, присутствующих в качестве участника.

= Тип 3: Поддержка множества вызовов конференц-связи, причем каждый вызов конференц-связи имеет точно одно устройство одноадресного вещания аудио, присутствующее в качестве участника.

Предпочтительно, 20 участников (устройства одноадресного вещания плюс телефоны ViPr) могут обслуживаться единственным приложением Администрирования одноадресным вещанием.

Устройство одноадресного вещания должно использоваться в конфигурации, показанной на фиг.1.

Как показано на фиг.1, все вызовы к и от устройства одноадресного вещания для ViPr всегда посылается к UAM. UAM реализует SIP B2B UA, чтобы подключить устройство одноадресного вещания к ViPr.

Пример: Пользователь А в POTS1 вызывает Пользователя В в ViPr V1. Следующая последовательность событий имеет место:

1. UD1 (Mediatrics или какое-либо еще устройство одноадресного вещания) принимает вызов от Пользователя А, чтобы соединиться с Пользователем В.

2. UD1 посылает ПРИГЛАШЕНИЕ К UAM. Поле «К» или «Название дисплея» в ПРИГЛАШЕНИИ идентифицирует вызов для Пользователя B.

3. UAM принимает ПРИГЛАШЕНИЕ как входящий вызов C1.

4. UAM извлекает SIP-адрес Пользователя В из ПРИГЛАШЕНИЯ в C1 и инициализирует вызов C2 этому пользователю, посылая ПРИГЛАШЕНИЕ к V1.

5. UAM также выполняет кросс-соединение C1 с C2.

6. V1 видит входящее ПРИГЛАШЕНИЕ от UAM, которое идентифицировано посредством SDP как устройство класса ViPr. Таким образом программное обеспечение на V1 знает, что равноправное программное обеспечение способно поддерживать все функциональные возможности, ожидаемые от устройства ViPr, включая Заменить/Обратиться и т.д.

7. Скажем Пользователь B в V1 отвечает «OK» в ответ на ПРИГЛАШЕНИЕ.

8. UAM отмечает соединение C2 как Установленное. Он затем посылает «OK» на C1.

Потоки мультимедийной информации в этом примере

Потоки мультимедийной информации между V1 и UD1 посылают любым из следующих способов:

1. Мультимедийная информация посылается непосредственно от V1 к UD1. Это может быть сделано посредством UAM, записывающим правильный SDP. Таким образом, во время посылки ПРИГЛАШЕНИЯ на V1, оно помещает IP адрес, порт UD1 для приема. И во время посылки «OK» к UD1 оно помещает IP адрес, порт V1 в качестве адреса приема.

2. Мультимедийная информация передается посредством UAM. В этом случае UAM передает данные от V1 к UD1, и наоборот. Легко увидеть, что если UAM и ViPr связаны через облако АТМ, то может быть установлен канал SVC между V1 и UAM. Таким образом UAM действует как АТМ для шлюза Ethernet для трафика мультимедийной информации.

Продолжая пример 1 далее, Пользователь A решает присоединяться к Пользователю B в V2 для конференции. Следующие события имеют место:

1. Соединение SIP между UAM и V1 заменяется вызовом C3 конференц-связи А с V1, V2 и UAM в качестве участников. Таким образом, B2B UA теперь является кросс-соединением вызова C3 конференц-связи с одноадресным вызовом (C1).

2. UAM всегда передает трафик между C3 и C4. Опция 11 выше. Он смешивает трафик от V1 и V2 и передает его к UD1. Он также выполняет многоадресное вещание трафика от UD1 к V1 и V2.

Функциональные возможности, выполняемые UAM, могут быть разделены на следующие компоненты:

= Модуль SIP B2B UA [SBU]. Этот модуль выполняет сигнализацию SIP, требуемую для осуществления SIP B2B UA.

= Кросс-соединение мультимедийной информации и смесителя [MCMU].

Функциональные возможности UAM должны быть разрешены посредством трех процессов: SBU, Администратор смесителя одноадресного вещания и стек SIP, как показано на фиг.2.

Процесс SipServer будет осуществлять функциональные возможности SIP и обеспечивать SBU абстрагированным API сигнализации (Интерфейсом Ia). Интерфейс Ia также остается неизменным.

SBU реализует управление вызовом и логику «склеивания» для реализации B2B UA. Этот модуль выводит основу кода из Callmanager/Vupper. SBU является также ответственным за установку правильных потоков смесителя. Для этой цели SBU взаимодействует с процессом UMM через RPC.

UMM реализует функциональные возможности для кросс-соединения потоков мультимедийной информации, а также для реализации функциональных возможностей смешивания аудио.

SBU реализует управление вызовом и логику «склеивания» для реализации B2B UA. SBU также является ответственным за установку правильных потоков смесителя. Для этой цели SBU взаимодействует с процессом UMM через RFC.

Сеанс связи

Class MediaSession

{

Int SelfId	// собственный ИД
CVString GUID	// ИД Конференц-связи
CVList XIDList;	// Список кросс соединений

GUID

}

SIPB2BCrossConnect

Class SIPB2BCrossConnect

{

Int SelfID	// собственный ИД
Int SessionID	// ИД сеанса связи, элементом которого он является
Int ViPrLegID	//SiPCallLeg, ассоциированный с ViPr
Int UDLegID	//Ветвь, ассоциированная с устройством одноадресного вещания.

}

SIPB2BCallLeg

Class SIPB2BCrossConnect

{

Int SelfID	// собственный ИД возвращен от callmanager
Int XID	// ИД кросс-соединения, которое имеет эту ветвь
SipCallLeg ViPrLeg	// Ветвь, соединенная с ViPr
SipCallLeg UDLeg	// Ветвь, соединенная с устройством одноадресного вещания.

}

SBU модуль внутренне структурирован следующим образом.

Как можно видеть из фиг.3, структура для SBU повторно использует и расширяет интерфейс SIP/поток мультимедийной информации, предлагаемый CallManager, чтобы реализовать сигнализацию логики управления вызовом для UAM.

Следующий текст представляет поток управления, когда Пользователь А инициализирует вызов Пользователю В.

Ниже SipServer относятся к SipServer в UAM, SBU относятся к SBU в UAM, и UMM относятся к UMM в UAM.

Чтобы пояснить пример, следующий ниже, предполагается следующее:

- полная сеть является сетью Ethernet

- IP адрес V1 равен 172.19.64.101

- IP адрес V2 равен 172.19.64.101

- IP адрес интерфейса UAM, который подсоединен к облаку V1/V2, равен 172.19.64.51, IP интерфейс UAM, подсоединенного к облаку UD1, равен 169.144.50.100

- IP адрес UD1 равен 169.144.50.48

- адрес представляется как кортеж <IpAddress, порт>

- все адреса и порты в примере являются иллюстративными, не требуется, чтобы они были фиксированными, но вместо этого назначаются посредством ОС.

- в нижеследующем примере все SIP события, принятые SBU (в UAM), фактически принимаются посредством SipServer и затем передаются в SBU. Однако Sipserver, принимающий событие и передающий его к SBU, не показывается для краткости.

№	Место положение	Действие
1	UD1	ПРИГЛАШЕНИЕ посылают от UD1 к SD1. Это приглашение содержит Адрес <169.144.50.48, 50000> для приема потока от UD1 для этого вызова.
2	SBU	SBU получает входящий вызов С1. SBU исследует вызов и видит, что он от устройства одноадресного вещания. Он затем выполняет следующие действия. - Извлекает адрес (Пользователь В) оконечного адресата, которое UD1 пытается достичь. - Он назначает адрес <172.19.64.51,40002> для приема потока мультимедийной информации от V1. - Он инициализирует исходящий вызов (C2) к Пользователю В, запрашивая sipserver послать ПРИГЛАШЕНИЕ Пользователю В. Это приглашение содержит адрес <172.19.64.51, 40002>. - Он также назначает SIP кросс-соединение (XID=1) и связывает С1 и C2 с XID=1. В этот момент SIP кросс-соединение XID=1 С1 и C2 в качестве взаимных вызовов. Он также сохраняет XID=1 в вызовах С1 и C2. Это должно разрешить извлечение XID из ИД (идентификатора) вызова.
3	V1	V1 принимает входящее ПРИГЛАШЕНИЕ и принимает вызов, посылая «OK» к UAM. «OK» содержит адрес <172.19.64.101,10002> для приема трафика от UAM.
4	SBU	SBU Получает «OK» (событие приема вызова) по C2. Он выполняет следующие этапы: - Принимает кросс-соединение (XID=1), элементом которого является C2. - Распределяет адрес для использования C2. <169.144.50.100,40001> - Дает команду SipServer послать «OK» в отношении вызова C2. Этот «OK» содержит адрес <1169.144.50.100,40001> для приема мультимедийной информации от UD1. - Распределяет Сеанс связи с ИД (скажем, SID=100). Этот ИД сеанса связи сохранен в XID=1 SIP кросс-соединения. SIP кросс-соединение с XID=1 также добавляется к списку части Кросс-соединений этого сеанса связи. В этот момент в списке имеется только одно SIP кросс-соединение. - SBU затем назначает канал мультимедийной информации, который нужно использовать для приема и посылки данных от DD1, скажем CHID=0. - SBU назначает канал мультимедийной информации, который нужно использовать для посылки и приема данных от V1, скажем CHID-1. - SBU затем информирует UMM установить каналы для посылки и приема данных от V1 и UD1 следующим образом: = SBU информирует UMM, что канал = 0 должен быть использован, чтобы посылать/принимать данные на/из UD1. Это делается посредством запроса UMM ассоциировать канал = 0 с адресом <169.144.50.48, 50000> посылки и адресом <169.144.50.100,40001> приема. = SBU информирует UMM, что канал = 1 должен использоваться, чтобы посылать/принимать данные на/из V1. Это делается посредством запроса UMM ассоциировать канал = 0 с адресом <172.19.64.101, 10001> посылки и адресом <172.19.64.51, 40002> приема. - SBU затем инструктирует UMM создать кросс-соединение мультимедийной информации посредством информирования UMM, что каналы CID=0 и CID=1 являются частью одного и того же сеанса связи SID=100. Должно быть отмечено, что UMM не информирован (и при этом не заботится) относительно SIP вызовов С1 и C2.
5	UD1	Принимает «OK» от UAM. Оно узнает из «OK», что для посылки аудио мультимедийной информации к UAM оно должно использовать адрес <169.144.50.100,40001>.

Поток управления для P2P вызова между UD1 и V1

Вышеприведенная таблица объясняет, что случается во время прохождения вызова. Ниже приведен поток управления, когда этот вызов преобразуется в вызов конференции. В этом случае, скажем, Пользователь B объединяет в конференцию пользователя C в V2 в вызов.

Далее предполагается следующее:

- IP адрес V2 равен 171.19.64.102

№	Место положение	Действие
6	V1	V1 # Посылает ПРИГЛАШЕНИЕ на Хост (ведущий узел) H конференции (в V1), чтобы инициализировать конференцию. ПРИГЛАШЕНИЕ содержит IP адрес <239.192.64.101, 10002> многоадресного вещания, по которому V1 может вещать свой поток аудио.
7	H	Хост принимает ПРИГЛАШЕНИЕ для запуска вызова конференции. Он посылает «OK» назад в V1. H также создает глобально уникальный ИД для этого вызова конференции (скажем, GUID=900).
8	V1	Направляет UAM в конференцию (с Replaces=C2).
9	Н	Посылает ПРИГЛАШЕНИЕ к UAM со следующей информацией: - GUID=900 - Replaces=С1 - Информация потока для V1 (Пользователь B) <239.192.64.101, 10002>
10	SBU	По получении приглашения для конференц-вызова (C3) SBU выполняет следующее: - Видит что ИД Replace = C2. Оно таким образом знает, что V1 хочет внести POTS1(UD1) в Конференцию GUID=100. - Оно извлекает XID=1 SIP кросс-соединения из C2. - оно извлекает ИД сеанса связи из Sip кросс-соединения, SID=100. И устанавливает элемент GUID сеанса связи равным GUID=900. - Оно устанавливает QUID в XID=1 SIP кросс-соединения равным GUID=100. - оно освобождает SIP соединение C2, информируя SipServer послать «Bye» (до свидания) на C2. - Удаляет C2 из XID=1 SIP кросс-соединения и заменяет его на C3. - оно также устанавливает ИД SIP кросс-соединения в C3 равным XID=1. Оно также устанавливает элемент XID в C3, чтобы указать на XID=1. - Оно назначает адрес <239.192.64.51, 40003> для передачи данных от имени UD1. - Оно информирует UMM удалить канал CID=1. Таким образом UMM теперь останавливает передачу мультимедийной информации на адрес <172.19.64.101, 10001> и останавливает прием мультимедийной информации от адреса <172.19. 64.51, 40002>. - Оно посылает «OK» назад в Хост. OK содержит информацию, что каждый в конференции должен посылать, принимать потоки мультимедийной информации от POTS1 (UD1) по адресу <239.192.64.51, 40003>. - SBU затем инструктирует UMM установить правильные потоки аудио для конференции (GUID=900) с V1 и UD1, представленных в качестве участников, следующим образом: = SBU информирует, что канал = 2 должен использоваться, чтобы посылать/принимать данные на/из V1. Таким образом, канал = 2 ассоциирован с адресом <239.192.64.51, 40003> посылки и адресом <239.192.64.101, 10002> приема. = SBU информирует UMM ассоциировать канал = 2 с SID=100 сеанса связи. = SBU информирует UMM установить поле адреса пересылки для канала = 0 равным <239.192.64.51, 40003>. Должно снова быть отмечено, что UMM не знает ни о присутствии SIP вызовов С1 и C3, ни о том, что имеется конференц-вызов с GUID=900. Внутренне, UMM действительно не смотрит на адрес посылки в канале = 2, чтобы передать данные от UD1 к конференции. Вместо этого, он смотрит на адрес пересылки в канале ИД = 2.
11	Хост	Получает OK от UAMD. Оно посылает ПОВТОРНОЕ ПРИГЛАШЕНИЕ на V1, указывающее присутствие потока от Пользователя А, на <239.192.64.51, 40003>.
12	V1	Направляет Пользователя C в V2 в конференцию.
13	Н	Посылает ПРИГЛАШЕНИЕ к V2, указывая присутствие потоков от Пользователя A и Пользователя В.
14	V2	V2 посылает OK. OK содержит IP адрес <239.192.64.102, 20001> многоадресного вещания, по которому V1 может осуществлять многоадресное вещание своего потока аудио. В этот момент Пользователь C может начать прослушивание аудио от Пользователя A и Пользователя В посредством регистрации с соответствующими адресами многоадресного вещания.
15	Н	Посылает ПОВТОРНОЕ ПРИГЛАШЕНИЕ на V1 и UAMD, указывающее присутствие нового участника Пользователя С, посылающего аудио по адресу <239.192.64.102, 20001>.
16	V1	Получает ПОВТОРНОЕ ПРИГЛАШЕНИЕ и видит, что сторона Пользователь С теперь в состоянии вызова. Оно посылает "OK" обратно к H.
17	SBU	Получает ПОВТОРНОЕ ПРИГЛАШЕНИЕ и видит, что новая сторона Пользователь С также в состоянии конференц-вызова с GDID=900. Оно затем выполняет следующие этапы: - Посылает OK назад в Хост через SIP-сервер. - Назначает канал мультимедийной информации CID = 3 для приема трафика от Пользователя С. - Информирует UMM присоединить мультимедийную информацию от Пользователя С в конференц-вызов, идентифицированный посредством GUID=900 следующим образом: = SBU информирует UMM, что канал = 3 должен быть использован, чтобы посылать/принимать данные к/из (Пользователя С) в V2. Таким образом, канал = 3 ассоциирован с адресом <239.192.64.51, 40003> посылки и адресом <239.192.64.102, 20001> приема. = SBU информирует UMM, чтобы ассоциировать канал = 2 с SID сеанса связи=100. Должно быть снова отмечено, что весь UMM знает, что имеются три канала (CID=0, 2 и 3), которые все принадлежат одному и тому же сеансу связи. UMM знает, что CID=2 и 3 являются потоками от ViPr телефона, а CID=0 - от устройства одноадресного вещания. Таким образом, UMM считывает данные многоадресного вещания из каналов CID=2 (<239.192.64.102, 20001> и CID=3 (<239.192.64.101, 10002>), смешивает их и посылает их на канал = 0 <169.144.50.48, 50000>. Также данные, считанные из канала CID = 0, ретранслируется на адрес ретрансляции, ассоциированный с CID=0 <239.192.64.51, 40003>. Подробности того, как UMM выполняет это соответствующее смешивание, находятся в другом разделе.
18	Н	Получает OK для ПОВТОРНЫХ ПРИГЛАШЕНИЙ, посланных на этапе 16.

Инициирование конференц-связи с пользователем на устройстве одноадресного вещания.

Чтобы добавить другого пользователя ViPr к конференции, повторяются этапы 12-18. Рассмотрим этапы, которые требуются другому пользователю устройства одноадресного вещания, скажем, Пользователю D на POTS2.

Предполагается следующее:

S Пользователь С на V2 ViPr решает объединить конференцию в Пользователе D на POTS2 в конференцию.

№	Место положения	Действие
19	V2	Обращается к Пользователю D в POTS2 в конференцию.
20	H	Посылает ПРИГЛАШЕНИЕ к UAM со следующей информацией: - Пользователь A, Пользователь В и Пользователь С делают вызов вместе с адресами, по которым они генерируют потоки мультимедийной информации. - GUID = 900
21	SBU	Получает запрос о входящем вызове конференции (C4) с -QUID = 900 - на адрес = Адрес Пользователя D, Оно затем выполняет следующие задачи: - оно назначает SIP кросс-соединение с ИД, XID=2. - оно добавляет C4 к XID=2 SIP кросс-соединения. Оно также устанавливает элемент XID в C4 равным XID=2. - оно ищет все структуры сеанса связи, чтобы просмотреть, имеется ли сеанс связи с QUID = 900. Оно находит, что сеанс связи с ID=100 ассоциирован с этим конференц-вызовом. - оно затем добавляет SIP кросс-соединение с XID=2 к списку кросс-соединений, присоединенных к SID = 100 сеанса связи. В этот момент имеются два SIP кросс-соединения (XID=1, и XID =2), которые являются частью SIP сеанса связи SID=100. - оно также сохраняет информацию в SIP кросс-соединении XID=2, чтобы указать, что оно ассоциировано с сеансом связи = 100. - оно назначает адрес <169.144.50.51, 40011> для приема трафика от Пользователя D. - оно назначает канал мультимедийной информации CHID=4 для приема трафика от Пользователя D <239.192.64.51, 40012>. - оно инициализирует соединение C5 посредством посылки ПРИГЛАШЕНИЯ к UD1 для Пользователя D. Это ПРИГЛАШЕНИЕ содержит информацию, которую UD1 должен послать в виде потоков аудиомультимедийной информации для этого вызова по адресу <169.144.50.51, 40004>. - оно добавляет C5 к SIP кросс-соединению с XID=2. Таким образом, XID=2 теперь является соединением CID=4 и CID=5 как взаимные вызовы SIP. - оно также устанавливает элемент XID C5, равным XID=2.
22	UD1	Принимает ПРИГЛАШЕНИЕ от UAM и посылает OK назад к UAM. Оно указывает в OK, что адрес, по которому оно должно посылать данные для вызова C5, равен <169.144.50.48, 50002>.
23	SBU	Принимает OK от UAM для C5. Оно затем выполняет следующие этапы: - оно извлекает SIP кросс-соединение, элементом которого является C5, XID=2. - оно извлекает сеанс связи из SIP кросс-соединения, SID=100. - оно затем назначает адрес <239.192.64.51, 40012>, чтобы передавать данные, принятые в отношении Пользователя D в конференции, GUID=900. - оно затем посылает OK в Хост, указывающее, что Пользователь D будет формировать трафик по адресу <239.192.64.51, 40012>. - оно затем назначает каналы для приема трафика Пользователя A (CHID=5), Пользователя В (CHID=6) и (CHID=7). - оно затем запрашивает UMM добавить Пользователя D в конференцию следующим образом: = SBU информирует UMM, что канал = 4 должен быть использован для посылки/приема данных на/из Пользователя D. Таким образом канал = 3 ассоциирован с адресом <169.144.50.51, 40011> посылки и адресом <169.144.50.48, 50002> приема. - SBU также информирует UMM, чтобы установить адрес ретрансляции CHID=4 равным <239.192.64.51, 40012>. = SBU информирует UMM, что Каналы =5, 6 и 7 должны использоваться для обмена трафиком с Пользователем А, Пользователем В и Пользователем С. Следующая информация предусматривается для этих каналов. -CHID=5 [Rx=<239.192.64.102, 20001>, Tx=<239.192.64.51, 40012> -CHID=6 [Rx=<239.192.64.101, 10001>, Tx=<239.192.64.51, 40012> -CHID=7 [Rx=<239.192.64.51, 40012>, Tx=<239.192.64.51, 40012> = SBU информирует UMM ассоциировать канал =4, 5, 6, 7 с SID=100 сеанса связи {Пожалуйста, обратите внимание, что CHID=5 информация для приема пакетов от Пользователя А является той же, что и информация, присутствующая на CHID=2, и будет видна как ненужная и ненадежная, но она имеет, фактически, желаемый эффект, не требуя какого-либо изменения в администраторе вызовов и также устраняет потребности в хранении заказа (регистрации) в SBU. То же сохраняется для CHID=3 и CHID=6. UMM никогда не будет принимать что-либо на CHID=7, потому что многоадресное вещание не принято посредством Хоста, который их передал.} В UMM имеются два канала CHID=2 и 5, которые ссылаются на один и тот же адрес приема многоадресного вещания, так как теперь оба канала принадлежат одному и тому же сеансу связи = 100, это не является проблемой. Так как UMM не должен считывать пакеты с дублированных каналов. Однако, если Канал = 2 удаляется, затем UMM должен выполнять операции далее и считывать пакеты из CHID=5.
24	Н	Хост принимает OK на C5 (от UAM) с информацией, добавленной для приема потоков аудио от Пользователя D. Он посылает ПОВТОРНОЕ ПРИГЛАШЕНИЕ на Пользователя А, Пользователя В и Пользователя С, указывающее присутствие нового потока от Пользователя D.
25	SBU	Получает ПОВТОРНОЕ ПРИГЛАШЕНИЕ на C3, указывающее присутствие другого пользователя Пользователь D, передающего по адресу многоадресного вещания - <239.192.64.51, 40012> Оно затем выполняет следующие задачи: - Посылает OK назад в Хост по C3 через SIP-сервер. - оно извлекает SIP кросс-соединение, элементом которого является C3, XID=1. - оно извлекает сеанс связи SID=100 из SIP кросс-соединения XID=1. - оно назначает канал CHID = 8 для приема аудио от Пользователя D. - оно затем дает команду UMM принимать и смешивать трафик от Пользователя D в сеанс связи SID=100 следующим образом: - SBU информирует UMM, что канал = 8 должен использоваться для посылки/приема данных на/из Пользователя D. Таким образом канал =8 ассоциирован с адресом посылки и адресом приема <239.192.64.51, 40012>. -SBU также устанавливает ИД сеанса связи для канала CHID=8 равным SID=100. [Следует заметить: так как UAMD программирует IP-сокеты никогда не принимать пакеты, которые он передал по адресу многоадресного вещания, никакой трафик не будет принят на CHID=8. Что является точно тем, что требуется.].
26	V1 и V2	Посылает OK на ПОВТОРНОЕ ПРИГЛАШЕНИЕ, посланное Хостом
27	Н	Принимает OK от всех участников, конференц-связь теперь имеет 4 стороны в вызове. Два из которых являются одноадресными устройствами.

Поток управления для добавления второго пользователя одноадресного вещания к конференции.

UMM осуществляет функциональные возможности для кросс-соединения потоков мультимедийной информации, а также осуществления функциональных возможностей смешивания аудио.

Сценарий 1 развертывания

Со ссылками на фиг.4 этот сценарий охватывает два случая:

Пользователь ViPr в многосторонней ViPr конференции аудио/видео, добавляющей пользователя телефона одноадресного вещания только с аудио к конференции:

В этом случае пользователи ViPr в многосторонней конференции ViPr решают добавить телефонного пользователя одноадресного вещания к конференции. В результате, один из участников инициирует вызов на телефонный номер адресата. SIP сервер ViPr переадресовывает вызов на UAM ViPr. UAM ViPr прерывает вызов ViPr "только аудио" и устанавливает сквозной (взаимный) вызов на телефон адресата через шлюз телефонной связи.

Как только вызов установлен, UAM ViPr преобразовывает поток одноадресного вещания аудио G.711/G.722, принятый от телефона, в поток PMP/многоадресного вещания и передает его на терминалы ViPr без какого-либо транскодирования. С другой стороны, UAM ViPr выполняет транскодирование и смешивание широкополосных 16 бит/16 кГц ИКМ потоков аудио ViPr, принятых от различных терминалов ViPr, в один поток одноадресного вещания аудио G.711 или G.722 и передает его телефонному адресату.

Пользователь ViPr в двухточечной "только аудио" конференции с телефонным пользователем добавляет другого пользователя ViPr к конференции:

В этом случае пользователь ViPr (V1) в двухточечном только аудио вызове с телефонным пользователем (T) решает добавить другого пользователя ViPr (V2) к конференции. В результате пользователь ViPr V1 инициализирует вызов аудио/видео пользователю V2 адресату ViPr. Система ViPr разрывает установленный двухточечный вызов между V1 и UAM ViPr и восстанавливает вызов PMP/многоадресного вещания между V1, V2 и UAM ViPr.

UAM ViPr завершает новый ViPr вызов аудио/видео и подсоединяет его к уже установленному взаимному телефонному вызову. В течение этого процесса телефонный вызов остается активным и переключение является прозрачным для пользователя телефона.

Как только вызов установлен, UAM ViPr преобразовывает поток одноадресного вещания аудио G.711/G.722, принятый от телефона, в поток PMP/многоадресного вещания и передает его на терминалы ViPr без какого-либо транскодирования. С другой стороны, UAM ViPr выполняет транскодирование и смешивание широкополосных 16 бит/16 кГц ИКМ ViPr потоков аудио, принятых от различных терминалов ViPr, в один поток одноадресного вещания аудио G.711 или G.722 и передает его телефонному адресату.

ViPr использует Протокол Инициирования Сеанса связи (SIP) в качестве средства установления, изменения и очистки многопотоковых мультимедийных сеансов связи. UAM добавляет возможности конференц-связи между терминалами ViPr и телефонными пользователями (то есть PSTN, мобильные телефоны и телефоны SIP), преобразовывая восходящие только голосовые телефонные потоки одноадресного вещания в потоки связи точка-многоточка (то есть, PMP-SVC или IP многоадресного вещания) и преобразовывая нисходящие ViPr потоки аудио многоадресного вещания/PMP в телефонные только голосовые потоки одноадресного вещания, а также выполняя транскодирование нисходящего аудио для ViPr аудио из широкополосного 16 бит/16 кГц кодирования ИКМ в G.711 или G.722.

Сценарий 2 развертывания

Со ссылками на фиг.5 этот сценарий охватывает два случая:

Пользователь телефона вызывает пользователя ViPr:

В этом случае пользователь телефона инициализирует вызов (только аудио) пользователю ViPr. Шлюз телефонной связи переадресовывает вызов к UAM ViPr. UAM ViPr завершает телефонный вызов и устанавливает взаимный только аудиовызов ViPr к терминалу ViPr места назначения.

Как только вызов установлен, UAM ViPr передает поток аудио G.711/G.722, принятый от телефона, на ViPr терминал без какого-либо транскодирования. С другой стороны, UAM ViPr выполняет транскодирование потока аудио ViPr из широкополосного 16 бит/16 кГц ИКМ в G.711 или G.722 и передает это телефонному адресату.

Пользователь ViPr вызывает пользователя телефона:

В этом случае пользователь ViPr инициализирует вызов пользователю телефона. SIP-сервер ViPr переадресовывает вызов к UAM ViPr. UAM ViPr завершает вызов ViPr только аудио и устанавливает взаимный вызов PSTN на телефон адресата через шлюз телефонной связи. Транскодирование выполняется таким же образом, как описано в предыдущем параграфе.

Фиг.6 дает типичный контекст использования для UAM. Функциональными особенностями, обеспечиваемыми UAM, являются следующие.

Функциональная особенность 1

Пусть ViPr V1 и V2 находится в вызове "точка-точка", и они желают привлечь устройство UD1 одноадресного вещания в конференц-вызов. Другими словами, намерение заключается в том, чтобы сформировать конференц-связь с UD1, V1 и V2 в конференции. Пусть пользователь в V1 запрашивает, чтобы пользователь в UD1 был подсоединен в конференц-вызов с V1 и V2 в качестве других сторон. Этот вызов отправляется одним из SIP-серверов к UAM.

UAM затем выполняет следующие задачи:

- оно присоединяется к конференц-вызову от имени UD1. Назовем этот конференц-вызов С1.

- оно также делает вызов "точка-точка" с устройством одноадресного вещания. Назовем этот конференц-вызов C2.

- оно передает данные аудио, принятые на C2, к С1.

- оно принимает данные аудио от сторон V1 и V2 в вызове C2, смешивает и передает эти данные к UD.

Функциональная особенность 2

Рассмотрим случай, где ViPr-сеть на чертеже, рассмотренном выше, является АТМ, и UD-сеть является сетью IP. Также предположим, что желательно, чтобы до возможной степени, для аудио использовались только SVC по сети АТМ вместо LANE/CLIP. Это может быть реализовано для обеспечения вопросов защиты или для решения проблем производительности.

В этом случае, если V1 ViPr на ViPr-сети желает, чтобы устройство одноадресного вещания (UD1) участвовало в аудиоразговоре, то UAM используется для обеспечения функциональных возможностей, чтобы использовать SVC в сети АТМ и IP в сети IP.

Чтобы сделать это, все вызовы от V1 к UD1 разбиваются на два вызова от V1 к UAMD и от UAMD к V2.

Конфигурация, требуемая для функциональных особенностей, поддерживаемых UAM, может быть разбита на следующие категории:

- конфигурация для вызовов ViPr к UD.

- конфигурация для вызовов UD к ViPr.

- Общая конфигурация

Общая конфигурация

UA SIP B2BUA выполнен так, чтобы работать на любом желательном порте (отличном от 5060). Это выполняется посредством изменения файла vipr.ini, включая в него следующий параметр:

SIP_Port=7070 [любой действительный номер порта]

Конфигурация для вызовов ViPr к UD

Для типичного ViPr вызова, когда пользователь набирает "номер", его "вызов" посылается SIP-серверу, который затем передает его соответствующим адресатам. Однако этот случай отличается. В этом случае, когда пользователь говорит "Я желаю говорить с устройством (UD1) одноадресного вещания", SIP-сервер передает вызов к UAM. Кроме того, он также помещает информацию в вызов, чтобы идентифицировать, что этот вызов должен быть отправлен к UD1. Таким образом, SIP-сервер запрограммирован так, чтобы направлять вызовы, сделанные к SIP-URI, обслуживаемым UAM устройствами, на соответствующий UAMD Сервер.

Также возможно задать заданный по умолчанию SIP-адрес устройства одноадресного вещания, чтобы отправлять все вызовы, принятые UAM. Этот заданный по умолчанию адрес может быть определен в файле vipr.ini посредством добавления следующих строк:

UD_SERVER_ADDRESS=169.144.50.48

X_FORWARD_AVAILABLE=0

Следует отметить, что когда вызов делают от устройства одноадресного вещания к ViPr, вызов должен быть доставлен к UAM. Чтобы это выполнить, соответствующая конфигурация выполняется в устройстве одноадресного вещания, см. соответствующую документацию для устройства одноадресного вещания для этой цели.

Конфигурация для вызовов UD к ViPr

Вызовы, исходящие в UD к ViPr, направляются к UAM. Один способ достичь этого заключается в программировании UD так, чтобы направить/отправить все вызовы к UAM. Также, возможный адресат вызовов (скажем, V1) задается в запросе вызова к UAM. Как правило, этот адрес должен быть в поле "К" в SIP-сообщении. Эти конфигурации выполняются в UD или сервере SIP.

Кроме того, когда UAM принимает вызов от UD, оно передает его на сервер шлюза Marshall для выполнения проверки готовности к работе в отношении вызываемого абонента. Этот адрес шлюза может быть определен в файле vipr.ini

GatewayMarshallServer=sip.eng.fore.com:5065

Список Акронимов

АТМ - Режим асинхронной передачи

ISDN - Цифровая сеть с предоставлением комплексных услуг

IP - Интернет Протокол

LAN - Локальная сеть

MC - Многоадресное вещание (IP)

MCMU - Модуль кросс-соединения и смешивания мультимедийной информации

MCU - Модуль конференц-связи мультимедийной информации

PBX - Частная АТС (коммутатор частных телефонов)

РСМ - ИКМ

PMP - Точка-многоточка (АТМ)

POTS - "Простая старая телефонная система"

PRI - Цифровой первичный интерфейс (ISDN)

PSTN - Коммутируемая телефонная сеть общего пользования

SBU - Пользовательский агент взаимного SIP

SIP - Протокол инициирования сеанса связи

SVC - Коммутируемый виртуальный канал (АТМ)

UAM - Смеситель аудио одноадресного вещания

ViPr™ - Система виртуального присутствия

WAN - Глобальная сеть

Хотя изобретение было подробно описано в вышеприведенных вариантах осуществления с целью иллюстрации, должно быть понятно, что такие подробности приводятся исключительно для этой цели, и что изменения могут быть сделаны специалистами в данной области техники без отрыва от объема и контекста изобретения за исключением того, что может быть описано следующей формулой изобретения.

Claims

1. Система организации телеконференций, содержащая
сеть; и
множество узлов, обменивающихся друг с другом через упомянутую сеть потоками аудио реального разговора, причем узлы выполняют передачу друг к другу, чтобы сформировать конференцию, при этом каждый узел способен обнаружить состояние перегрузки, при котором имеются более заранее определенного количества одновременных потоков аудио реального разговора, передаваемых узлами, и вместе с другими узлами управлять количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки.

2. Система по п.1, в которой каждый узел определяет, должен ли он прекратить передавать свой поток аудио, когда состояние перегрузки обнаружено, на основании потока аудио, который он передает, и потоков аудио, передаваемых другими узлами.

3. Система по п.2, в которой каждый узел приходит к одному и тому же решению независимо от других узлов относительно состояния перегрузки без каких-либо сообщений синхронизации от сети.

4. Система по п.3, в которой каждый узел является видеофоном.

5. Система по п.4, в которой имеются по меньшей мере 3 узла.

6. Система по п.5, в котором имеются по меньшей мере 10 узлов.

7. Способ обеспечения телеконференции, содержащий этапы:
выполняют обмен для множества узлов друг с другом через сеть потоками аудио реального разговора, которые узлы передают друг к другу, чтобы сформировать конференцию;
обнаруживают каждым узлом состояние перегрузки, при которой имеются более заранее определенного количества одновременных потоков аудио реального разговора, передаваемых узлами; и
управляют количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки.

8. Способ по п.7, в котором этап управления включает в себя этап управления каждым из узлов количеством потоков аудио, передаваемых одновременно к нему, и состояния перегрузки.

9. Способ по п.8, в котором этап управления включает в себя этап определения каждым узлом, должен ли он прекратить передавать свой поток аудио, когда состояние перегрузки обнаружено, на основании потока аудио, который он передает, и потоков аудио, передаваемых другими узлами.

10. Способ по п.9, в котором этап управления включает в себя этап, на котором каждый узел приходит к одному и тому же решению независимо от узлов относительно состояния перегрузки без каких-либо сообщений синхронизации от сети.

11. Способ по п.10, в котором имеются по меньшей мере 3 узла.

12. Способ по п.11, в котором имеются по меньшей мере 10 узлов.

13. Способ по п.12, включающий в себя этап разрешения узлам, имеющим наиболее недавно передаваемые аудиопотоки разговора, продолжать передавать их потоки аудио.

14. Способ по п.13, в котором этап разрешения включает в себя этап оценки каждого узла с узлами, имеющими самые высокие оценки, продолжающими передавать.

15. Способ по п.14, в котором этап оценки включает в себя этап использования подсчета пакетов аудио для каждой стороны за прошлые 60 с, чтобы определить оценку.

16. Узел организации телеконференций для сети с другим узлами, содержащий
сетевой интерфейс, который обменивается с другими узлами, чтобы сформировать конференцию реального разговора; и
контроллер, который обнаруживает состояние перегрузки, при котором имеется более заранее определенного количества одновременных потоков аудио реального разговора, передаваемых узлами, и вместе с другими узлами управляет количеством потоков аудио, передаваемых одновременно, чтобы завершить состояние перегрузки.

17. Узел по п.16, включающий в себя динамик для воспроизведения потоков аудио и приемник аудио, чтобы принять разговор.

18. Узел по п.17, включающий в себя устройство отображения, чтобы захватывать живые изображения.