ES2327288T3 - Sistema, metodo y nodo para limitar el numero de flujos de audio en u teleconferencia. - Google Patents
Sistema, metodo y nodo para limitar el numero de flujos de audio en u teleconferencia. Download PDFInfo
- Publication number
- ES2327288T3 ES2327288T3 ES07252427T ES07252427T ES2327288T3 ES 2327288 T3 ES2327288 T3 ES 2327288T3 ES 07252427 T ES07252427 T ES 07252427T ES 07252427 T ES07252427 T ES 07252427T ES 2327288 T3 ES2327288 T3 ES 2327288T3
- Authority
- ES
- Spain
- Prior art keywords
- video
- audio
- call
- node
- nodes
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
- H04M3/567—Multimedia conference systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
- H04L12/1827—Network arrangements for conference optimisation or adaptation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
- H04L65/4046—Arrangements for multi-party communication, e.g. for conferences with distributed floor control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/752—Media network packet handling adapting media to network capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/762—Media network packet handling at the source
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0062—Provisions for network management
- H04Q3/0091—Congestion or overload control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
- H04M2201/50—Telephonic communication in combination with video communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Telephonic Communication Services (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Stereophonic System (AREA)
Abstract
Un sistema de teleconferencia (10) que comprende: una red (40); y una pluralidad de nodos configurados para comunicarse con cada uno de los otros a través de la red con flujos de audio de conversación en vivo, estando los nodos configurados para transmitir entre ellos con el fin de formar una conferencia, siendo cada nodo capaz de detectar un estado de sobrecarga en el que hay más de un número predeterminado de flujos de audio simultáneos de conversación en vivo que están siendo transmitidos por los nodos y junto con los otros nodos configurados para controlar el número de flujos de audio que se están transmitiendo simultáneamente para acabar con el estado de sobrecarga.
Description
Sistema, método y nodo para limitar el número de
flujos de audio en una teleconferencia.
Esta aplicación se refiere a solicitudes de
patente provisionales de U.S. presentadas contemporáneamente: El
número de serie 60/814,476, titulado "Conference Layout Control
and Control Protocol", por Richard E. Huber y Arun Punj, que
tiene expediente FORE-120; el número de serie
60/814,491, titulado "Associating Independent Multimedia Sources
Into a Conference", por Arun Punj, Richard E. Huber y Gregory H.
Smith, que tiene expediente FORE-121, relativo a la
solicitud de patente Europea EP 1868347.
La presente invención se refiere a una
teleconferencia donde el número de flujos de audio que se están
transmitiendo simultáneamente es controlado para acabar con un
estado de sobrecarga, conocido de otra manera como una tormenta de
audio. Más específicamente, la presente invención se refiere a una
teleconferencia en la que el número de flujos de audio que se están
transmitiendo simultáneamente está controlado, para acabar con un
estado de sobrecarga en el que cada terminal llega a la misma
decisión independientemente de los otros terminales con respecto al
estado de sobrecarga, sin ningún mensaje de sincronización de la
red.
Cuando se participa en una conferencia grande,
la suma de todos los canales de audio potenciales puede sobrecargar
los recursos de red y de CPU. El uso de VAD (Voice Activity Detect -
Detección de Actividad de Voz) es la manera estándar para mantener
estadísticamente limitado el número de flujos de audio simultáneos.
No obstante, hay momentos en los que cuando un elevado número de
participantes puede generar una respuesta de audio eso provocaría
que casi todos los nodos empezasen a transmitir.
El máximo número de participantes en la
conferencia para una conferencia grande presenta un problema de
tratamiento de audio no presente en una conferencia de
15-participantes. Supóngase que una conferencia de
100 participantes ha sido moderada pero ninguno de los
participantes remotos está en silencio y por ello son capaces de
transmitir audio en cualquier momento. El altavoz principal hace un
comentario al que todos responden y en un tiempo bastante corto de
100-300 ms, cada terminal de ViPr empieza a enviar
datos de audio creando así una "Tormenta de Paquetes de
Audio". El efecto de tal tormenta en la conferencia sería un
aumento en el umbral mínimo de ruido recibido y permaneciendo el
resto constante un salto de 20 dB en la salida de audio. El terminal
está tratando 5000 paquetes de RTP de audio por segundo. Cualquier
enlace de bajo ancho de banda que se conecta a un terminal de ViPr
para el resto de la conferencia tendría que competir con un flujo de
datos de audio de 8 Mbps. (Obsérvese que: la cifra de 8 Mbps
procede de cada terminal de ViPr que está transmitiendo 64 kbps
para datos de audio, 4,8 kbps para información suplementaria de RTP,
e información suplementaria de IP de aproximadamente 4 kbps.) La
presente invención describe cómo detectar que la conferencia está
entrando en este estado de sobrecarga y controlar qué emisores
deben dejar de enviar. Esta invención proporciona un mecanismo para
limitar los efectos de demasiados flujos de audio simultáneos.
El documento US 6697341 describe un aparato para
proporcionar una conferencia de multimedios con parámetros de
rendimiento selectivo, que proporciona una representación diferente
de las mismas señales de video para cada uno de una pluralidad de
usuarios que dependen de las limitaciones de hardware, limitaciones
de software, limitaciones de red y preferencias de usuario de cada
dispositivo de usuario.
La presente invención pertenece a un sistema de
teleconferencia. El sistema comprende una red. El sistema comprende
una pluralidad de nodos que se comunican entre sí a través de la red
con flujos de audio que los nodos se transmiten entre ellos para
formar la conferencia. Cada nodo capaz de detectar un estado de
sobrecarga en el que hay más de un número predeterminado de flujos
de audio simultáneos que están siendo transmitidos por los nodos y
junto con los otros nodos, controlan el número de flujos de audio
que se están transmitiendo simultáneamente, para acabar con el
estado de sobrecarga.
La presente invención pertenece a un método para
proporcionar una teleconferencia. El método comprende las etapas de
una pluralidad de nodos comunicándose entre sí a través de una red
con los flujos de audio que los nodos se transmiten entre ellos
para formar la conferencia. Existe la etapa de detección por cada
nodo de un estado de sobrecarga en el que hay más de un número
predeterminado de flujos de audio simultáneos que están siendo
transmitidos por los nodos. Existe la etapa de controlar el número
de flujos de audio que se están transmitiendo simultáneamente, para
acabar con el estado de sobrecarga.
La presente invención pertenece a un nodo de
teleconferencia para una red con otros nodos. El nodo comprende una
interfaz de red que se comunica con los otros nodos para formar la
conferencia. El nodo comprende un controlador que detecta un estado
de sobrecarga en el que hay más de un número predeterminado de
flujos de audio simultáneos que están siendo transmitidos por los
nodos, y junto con los otros nodos controlan el número de flujos de
audio que se están transmitiendo simultáneamente, para acabar con el
estado de sobrecarga.
En los dibujos que se acompañan, se ilustran la
realización preferida de la invención y los métodos preferidos de
practicar la invención, en los cuales:
La Figura 1 es una representación esquemática de
un sistema para la presente invención.
La Figura 2 es una representación esquemática de
una red para la presente invención.
La Figura 3 es una representación esquemática de
un video teléfono conectado a un PC y a una red.
La Figura 4 es una representación esquemática
del sistema para la presente invención.
Las Figuras 5a y 5b son representaciones
esquemáticas de vistas frontales y laterales del video teléfono.
La Figura 6 es una representación esquemática de
un panel de conexión del video teléfono.
La Figura 7 es una representación esquemática de
una configuración de multi-pantalla para el video
teléfono.
La Figura 8 es un diagrama de bloques del video
teléfono.
La Figura 9 es un diagrama de bloques de la
arquitectura del video teléfono.
La Figura 10 es una representación esquemática
del sistema.
La Figura 11 es una representación esquemática
del sistema.
La Figura 12 es una representación esquemática
de un sistema de la presente invención.
La Figura 13 es una representación esquemática
de otro sistema de la presente invención.
La Figura 14 es una representación esquemática
de un mezclador de audio de la presente invención.
La Figura 15 es un diagrama de bloques de la
arquitectura para el mezclador.
La Figura 16 es un diagrama de bloques de una
SBU.
La Figura 17 es una representación esquemática
de un video teléfono UAM en una conferencia mediante video
teléfono.
La Figura 18 es una representación esquemática
de un video teléfono UAM en una llamada telefónica
bidireccional.
La Figura 19 es una representación esquemática
de una red para un mezclador.
La Figura 20 es un diagrama de bloques de la
presente invención.
En referencia ahora a los dibujos en los que
números de referencia iguales se refieren a partes similares o
idénticas en varias vistas, y más específicamente a la Figura 20 de
las mismas, se muestra un sistema 10 de teleconferencia. El sistema
10 comprende una red 40. El sistema 10 comprende una pluralidad de
nodos, tales como terminales o video teléfonos que se comunican
entre sí a través de la red 40 con flujos de audio de conversación
en vivo que los terminales se transmiten entre ellos para formar la
conferencia. Cada terminal capaz de detectar un estado de
sobrecarga en el que hay más de un número predeterminado de flujos
de audio simultáneos de conversación en vivo que están siendo
transmitidos por los terminales, y junto con los otros terminales,
controlan el número de flujos de audio que se están transmitiendo
simultáneamente, para acabar con el estado de sobrecarga.
Preferiblemente, cada terminal determina si debe
dejar de transmitir su flujo de audio cuando se detecta el estado
de sobrecarga basándose en el flujo de audio que transmite y en los
flujos de audio que están siendo transmitidos por los otros
terminales. Cada terminal llega preferiblemente a la misma decisión
independientemente de los otros terminales con respecto al estado
de sobrecarga, sin ningún mensaje de sincronización desde la red
40.
La presente invención pertenece a un método para
proporcionar una teleconferencia. El método comprende las etapas de
una pluralidad de terminales comunicándose entre sí a través de una
red 40 con flujos de audio de conversación en vivo que los
terminales se transmiten entre ellos para formar la conferencia.
Existe la etapa de detección por cada terminal de un estado de
sobrecarga en el que hay más de un número predeterminado de flujos
de audio simultáneos de conversación en vivo que están siendo
transmitidos por los terminales. Existe la etapa de controlar el
número de flujos de audio que se están transmitiendo
simultáneamente, para acabar con el estado de sobrecarga.
Preferiblemente, la etapa de control incluye una
etapa de control del número de flujos de audio a los que se está
transmitiendo simultáneamente y del estado de sobrecarga con cada
uno de los terminales. La etapa de control incluye preferiblemente
la etapa de que cada terminal determina si debe dejar de transmitir
su flujo de audio cuando el estado de sobrecarga es detectado
basándose en el flujo de audio que está transmitiendo y en los
flujos de audio que están siendo transmitidos por los otros
terminales. Preferiblemente, la etapa de control incluye la etapa
de que cada terminal llega a la misma decisión independientemente de
los terminales con respecto al estado de sobrecarga, sin ningún
mensaje de sincronización desde la red 40.
El método incluye preferiblemente la etapa de
permitir que los nodos que tengan los flujos de audio más recientes
de la conversación transmitida continúen transmitiendo sus flujos de
audio. Preferiblemente, la etapa de permiso incluye una etapa de
puntuar cada nodo, continuando la transmisión los nodos que tienen
la puntuación más alta. La etapa de puntuación incluye
preferiblemente la etapa de usar una cuenta de los paquetes de audio
para cada uno de los participantes en los últimos 60 segundos con
el fin de determinar la puntuación.
La presente invención pertenece a un nodo de
teleconferencia 12 para una red 40 con otros nodos. El nodo
comprende una interfaz de red 40 que se comunica con los otros
nodos para formar una conferencia de conversación en vivo. El nodo
comprende un controlador 19 que detecta un estado de sobrecarga en
el que hay más de un número predeterminado de flujos de audio
simultáneos de conversación en vivo que están siendo transmitidos
por los terminales y junto con los otros terminales controlan el
número de flujos de audio que se están transmitiendo
simultáneamente, para acabar con el estado de sobrecarga.
Preferiblemente, el nodo incluye un receptor de audio 58 para
recibir la conversación y un dispositivo de imagen para capturar
imágenes en vivo en los nodos y altavoces 64 para interpretar los
flujos de audio recibidos desde los otros nodos.
En la operación de la realización preferida, el
máximo número de participantes en la conferencia para una
conferencia en vivo grande presenta un problema de tratamiento de
audio no presente en una conferencia de 15 participantes. Supóngase
que una conferencia de 100 participantes fuese moderada pero que
todos los participantes remotos estuviesen no silenciosos y por
ello fuesen capaces de transmitir audio en cualquier momento. El
altavoz 64 principal hace un comentario al que todo el mundo
responde y en un tiempo bastante corto de 100-300
ms, cada punto de extremo empieza a enviar datos de audio y por
ello a crear una "tormenta de paquetes de audio". El efecto de
tal tormenta en la conferencia sería un aumento en el umbral mínimo
de ruido recibido y permaneciendo el resto constante, un salto de
20 dB en la salida de audio. El punto de extremo está tratando 5000
paquetes RTP de audio RTP por segundo. Cualquier enlace de bajo
ancho de banda que conecta un punto de extremo con el resto de la
conferencia tendría que competir con un flujo de datos de audio de 8
Mbps. (Obsérvese que: la cifra de 8 Mbps se deriva de cada
dispositivo que está transmitiendo 64 kbps para datos de audio, 4.8
kbps para información suplementaria de RTP, e información
suplementaria de IP de aproximadamente 4 kbps).
La detección compara la velocidad de los
paquetes de audio recibidos con un umbral. Cada punto de extremo
determina independientemente si una tormenta está presente y si debe
continuar enviando datos de audio o auto silenciarse. Lo que tienen
en común los puntos de extremo es que cada punto de extremo puede
estimar las estadísticas de conversación de los otros puntos de
extremo puesto que recibirán los datos de audio de cada uno de
ellos.
Partiendo de las simulaciones, se puede esperar
que el número de canales de audio transmitidos exceda el límite
para un tiempo corto, normalmente menos de 300 ms. La razón para
ello es que hay un retardo en la red 40 que afectará a cuándo
cualquier punto de extremo puede detectar una tormenta. Si el
retardo es 50 ms, entonces hasta tres paquetes pueden ser
encaminados antes de que un punto de extremo haya detectado la
tormenta. Además cada punto de extremo debe decidir si debe
auto-silenciarse. Dadas las típicas variaciones en
las estadísticas debido a las diferencias en el punto del tiempo en
el que cada punto de extremo detecta una tormenta y decide cómo
mitigarla, habrá más o menos puntos de extremo en silencio de los
esperados. Algunos se silenciarán un poco más tarde si no hay
suficientes puntos de extremo en silencio para sofocar la tormenta.
En este proceso, existe aleatoriedad inducida por los diferentes
momentos en los que los puntos de extremo llevan a cabo el proceso
de detección y de mitigación de la tormenta así como por la
aleatoriedad del canal o de la fluctuación.
Se detecta (o declara) una tormenta cuando el
número de paquetes de audio recibidos en un momento dado excede el
umbral de detección.
El objetivo es evitar que una tormenta de audio
bloquee el terminal de ViPr puesto que el proceso de audio tiene la
prioridad más alta. Sólo se invoca si el Modo de Protección de la
Calidad de Audio no está activo y se envía un excesivo número de
paquetes de audio. Este modo evita también el rechazo a los ataques
al servicio.
Los paquetes entrantes son contados durante un
período de tiempo relativamente pequeño (100-200 ms)
y si se excede un umbral entonces ningún otro paquete recibido es
borrado durante ese período de tiempo.
El objetivo es limitar el envío de paquetes de
audio para evitar una sobrecarga de la red 40 con el fin de evitar
un ruido y un volumen de audio excesivos en cada uno de los
terminales remotos.
- 1.
- Todos los terminales recogen estadísticas en todos los flujos de audio incluyendo el terminal local.
- 2.
- Todos los terminales detectan independientemente la aparición de una tormenta de audio siguiendo el número de canales entrantes que están enviando datos activamente.
- 3.
- Cada terminal decide independientemente si dejar o no de enviar su flujo de audio basándose en la puntuación de su transmisión de audio local y la de los terminales remotos.
\vskip1.000000\baselineskip
Características claves que son nuevas sobre la
detección y mitigación de la tormenta de audio de ViPr.
Cada terminal es completamente autónomo de los
otros terminales en decidir si enviar o no datos de audio.
Lo que une a los procesos de decisión de todos
los terminales es que todos los terminales calculan aproximadamente
las mismas estadísticas para cada canal.
Lo siguiente es básicamente una descripción
para: Cómo construir un dispositivo de "Detección y Recuperación
de una Tormenta de Audio".
Cada participante en la conferencia envía
paquetes de audio de conversación en vivo a intervalos regulares a
todos los demás participantes en la llamada. El método primario para
limitar la carga de la red 40 y del procesador es que cada
participante deje de enviar estos paquetes de audio durante los
períodos de silencio. En una llamada típica sólo unos pocos
participantes estarán hablando a la vez y todos los demás
participantes estarán en modo de "silencio". Así, cada
participante sólo estará recibiendo paquetes activamente de esos
pocos participantes. Cuando un nuevo participante responde a una
pregunta la lógica de Detección de Actividad de Voz permitirá la
transmisión de paquetes de audio desde ese punto de extremo. Del
mismo modo, cuando un participante detiene la conversación la
lógica de Detección de Actividad de Voz activará una vez más el modo
de "silencio" para detener el flujo de
paquetes.
paquetes.
Cuandoquiera que se produce una situación que
crea una gran respuesta de audio simultánea cada participante
empezará a transmitir paquetes a medida que salen del modo de
"silencio". Cuando muchos flujos de audio están activos al
mismo tiempo, la función de mezcla de audio dada en cada punto de
extremo resultará ser de tratamiento más intensivo. Hay también un
aumento substancial en la carga de la red 40. Esta es la condición a
la que se apela en una "tormenta de audio" y la siguiente
descripción detalla un dibujo para detectar y detener tormentas de
audio.
Debido al hecho de que cada participante está
procesando paquetes de audio entrantes en tiempo real y a que
durante una tormenta de audio existe ya un tráfico de red 40 mucho
mayor, NO existe un modo sencillo de usar una señalización de red
40 secundaria para intercambiar información sobre la tormenta de
audio entre cada participante. Esto requiere que cada punto de
extremo detecte independientemente una tormenta de audio. Esto
requiere también que cada punto de extremo en la llamada mantenga su
propia historia de paquetes de audio a corto plazo de cada
participante en la llamada incluido él mismo.
La detección inicial de una tormenta de audio es
relativamente fácil. Una tormenta de audio se declara simplemente
cuandoquiera que un participante está recibiendo datos de audio de
manera activa desde al menos "nStormThreshold" número de
participantes. Lo difícil es decidir cómo controlar esta tormenta.
La situación ideal es que al mismo participante o participantes que
habían estado hablando antes de la tormenta se le oiga todavía. Todo
el mundo debe ser capaz aún de oír a un número de participantes
adicionales de manera que ellos puedan oír también su
respuesta.
La historia de los paquetes de audio previos que
vienen de cada participante se usa para crear una "puntuación"
que decidirá entonces qué participantes fueron los hablantes más
recientes. El "nSimultaneousTalkers" número de participantes
en la parte superior de la lista puede entonces ser usado para
decidir cuáles son los pocos elegidos para continuar transmitiendo
después de que la tormenta de audio ha sido detectada. Puesto que
todos los puntos de extremo mantienen exactamente la misma historia
de paquetes de audio, deben tener siempre exactamente la misma
lista de puntuaciones. Si un punto de extremo particular está dentro
de la parte superior de la lista, entonces debe continuar
transmitiendo; de otro modo, debe dejar de transmitir
inmediatamente. El otro uso de esta lista es limitar qué
participantes están descodificados y mezclados para reproducción de
audio. Los efectos de la tormenta de audio disminuirán y sólo los
pocos participantes de la parte superior de la lista continuarán
transmitiendo y serán oídos.
Lo último que queda es esperar hasta que la
tormenta de audio haya terminado para reanudar la operación normal
de la conferencia. Puesto que habrá exactamente "n
SimultaneousTalkers" número de participantes que están
transmitiendo inicialmente, se necesita esperar hasta que haya menos
"nStormEndThreshold" número de participantes que están
transmitiendo antes de declarar que la tormenta de audio ha
pasado.
Un algoritmo de puntuación típico es usar la
cuenta de los paquetes de audio para cada participante en los
últimos 60 segundos. Esta cuenta es entonces incrementada en 100
para cada intervalo de 500 milisegundos anterior en el que al menos
un paquete fue recibido desde este participante. Esto continúa para
cada participante de nuevo en la historia de 60 segundos hasta que
el primer intervalo de 500 milisegundos no contiene ningún paquete.
Este método de puntuación favorece a los hablantes más recientes
primero y después a los participantes que no han dicho nada en los
últimos 60 segundos.
Pueden usarse otras técnicas de puntuación más
complicadas, tales como identificar manualmente a ciertos
participantes como "key presenters" (presentadores clave) que
siempre puntuaría a los participantes de la parte superior de la
lista y por lo tanto que están siempre audibles.
La solución propuesta para la tormenta de audio
asume que los terminales deben actuar independientemente para
detectar y mitigar la tormenta de paquetes de audio. La detección
compara la velocidad de los paquetes de audio recibidos con un
umbral. Cada terminal determina independientemente si una tormenta
está presente y si debe continuar enviando datos de audio o
auto-silenciarse. El que tienen en común los
terminales de ViPr es que cada terminal puede estimar las
estadísticas de la actividad de conversación de los otros terminales
puesto que recibirá los datos de audio de cada uno de los
demás.
A partir de las simulaciones, uno puede esperar
que el número de canales de audio transmitidos exceda el límite
durante un corto espacio de tiempo normalmente menor de 300 ms. La
razón para ello es que hay un retardo en la red 40 que afectará a
cuándo podrá un terminal cualquiera detectar una tormenta. Si el
retardo es 50 ms, entonces hasta tres paquetes pueden estar en ruta
antes de que un terminal haya detectado la tormenta. También cada
terminal debe decidir si debe auto-silenciarse.
Dadas las típicas variaciones en las estadísticas debido a las
diferencias en el punto del tiempo en el que cada terminal detecta
una tormenta y decide cómo mitigarla, habrá más o menos terminales
en silencio de los esperados. Algunos estarán en silencio un poco
más tarde si no se callan suficientes terminales como para dominar
la tormenta. En este proceso, existe aleatoriedad inducida por los
diferentes momentos en los que los terminales llevan a cabo el
proceso de detección y mitigación de la tormenta así como la
aleatoriedad o la fluctuación del canal.
Una conferencia grande con más de 50
participantes está teniendo lugar. Uno o dos participantes están
hablando activamente y el resto están escuchando. Se expone algo
gracioso y de repente más de 50 participantes empiezan a reírse. En
cada terminal de ViPr, el algoritmo de VAD empieza a detectar el
aumento del nivel de audio mic y si continúa durante 60 ms entonces
se envía una ráfaga de 4 ó 5 paquetes y se envían paquetes a
intervalos de 20 ms. Los terminales que reciben la ráfaga la usarán
para precargar la memoria temporal de fluctuación y empezarán a
interpretar el audio recibido. Una vez que la risa se apaga, el VAD
detectará el silencio y empezará una cuenta de dos segundos antes
de desconectar los paquetes.
Una conferencia moderada en la que se usa un
silencio remoto es menos exigente porque el moderador da la palabra
a los participantes. Sólo los participantes que tienen la palabra
pueden enviar paquetes de audio.
Los paquetes son transmitidos si se cumplen las
siguientes condiciones
El algoritmo de VAD detecta conversación
Y
Se trata de una conferencia moderada y el
moderador ha sacado del silencio a este participante
O
Se trata de una conferencia no moderada y se
cumple lo siguiente.
No se detecta ninguna tormenta de paquetes de
audio
O
Se detecta una tormenta de paquetes de
audio,
El participante es un hablante significativo
O
La clasificación de participantes basándose en
los últimos datos de audio fue enviada comparada con los últimos
datos de audio que fueron recibidos de cada uno de los otros
participantes.
Se detecta (o declara) una tormenta cuando el
número de paquetes de audio recibidos en un momento dado excede el
umbral de detección. El algoritmo es como sigue.
Cada vez que se recibe un paquete, la variable
global g_nPktsRcvd es incrementada.
Cada 100 ms,
Si no se detecta ninguna tormenta de audio,
bStormDetected es puesto en verdadero si
g_nPktsRcvd > m_nPktsStormDeclared
Si se detecta una tormenta de audio,
bStormDetected es puesto en falso si g_nPktsRcvd
< m_nPktsStormOver
Set g_nPktsRcvd es 0.
\vskip1.000000\baselineskip
La actividad de una conversación se mide de una
de dos maneras. El primer método calcula el porcentaje de tiempo
invertido en hablar típicamente en un intervalo de un minuto. Esto
es calculado para el hablante local solamente y utiliza el
siguiente algoritmo.
Inicializar la memoria temporal circular
TT_local a todo ceros y el índice indxTT a 0.
Cada dos segundos y si no se detecta ninguna
tormenta de paquetes de audio,
Poner en 1 TT_local[indxTT] si el
participante local está hablando o si no, ponerlo en 0. Incrementar
el indxTT.
El número de unos en la matriz TT_local dividido
por el tamaño de la matriz es el porcentaje de tiempo de
conversación. El intervalo de muestra de 2 segundos se basa en que
el VAD tiene un tiempo de ON mínimo de 2 segundos. La matriz
TT_local está dimensionada para muestrear el último minuto. El
hablante local es clasificado como significativo si se detectó
conversación durante el 25% del último minuto.
El segundo método para medir la actividad de
conversación utiliza el último momento en el que se recibió o se
transmitió un paquete. Considerando la génesis de una tormenta de
paquetes, simplemente usar el tiempo de llegada del último paquete
no conducirá a resultados útiles. Lo que es más interesante es el
último tiempo en el que un paquete de audio fue enviado antes de
empezar la tormenta de paquetes de audio actual. El siguiente
algoritmo rastrea el tiempo de llegada de ese paquete.
Si PktRcvTime > PktRcvTimeLast + 1
segundo
El último paquete recibido como anterior a la
tormenta de paquetes de audio actual y por consiguiente
PktRcvTimeLast es copiado en PktRcvTimeLast1.
PktRcvTimeLast = PktRcvTime
El mismo algoritmo se usa para la transmisión de
paquetes de audio pero PktXmtTime reemplaza a PktRcvTime.
\vskip1.000000\baselineskip
En AudioMan, se llama a la función de acceso
SetTalkTimeLast () si EncoderRdy () devuelve un verdadero en el
encoder_decoder_loop() en AudioMan.cpp. El estado de la devolución
de EncoderRdy es controlado por el VAD. SetXmtTimeLast () es
encontrado en AudioStorm.cpp.
Cada 2 segundos, UpdateTalkerActivity () es
llamado en el encoder_decoder_loop en AudioMan.cpp.
UpdateTalkerActivity() mira al estado de conversación del VAD
eVADstate usando la función de acceso IsTalking () para determinar
si el participante local está hablando. Si se detecta conversación
entonces un "1" es cargado en una memoria temporal circular,
TT_local.
Para cada paquete recibido, se llama a la
función SetRecTimeLast (iChannel). El último tiempo de paquete
recibido para ese canal es grabado usando la función de acceso
SetRecTimeLast(iChannel) y el número de paquetes recibidos,
nPktsRcvStorm, para detectar que una tormenta de paquetes de audio
se ha incrementado.
Cada 100 ms, StormDetect() utiliza nPktRcvStorm
para detectar si una tormenta de paquetes está teniendo lugar.
StormDetect() está situado en la parte superior del bucle del
intervalo de tiempo (1) en encoder_decoder_loop(). Si se detecta
una tormenta, entonces StormDetect() llamará a la función de acceso
de VAD SetStormMute (verdadero) a menos que el participante local
sea un hablante significativo o esté suficientemente alto en la
clasificación.
\vskip1.000000\baselineskip
AudioMan se ejecuta en el kernel en tiempo real
y si está cargado con más de 40 flujos G.722 entrantes ocupará el
100% del tiempo de CPU. El panel táctil no podrá responder hasta que
el número de paquetes de audio entrantes cae por debajo de 40. (El
valor 40 es una aproximación grosera.) Estos números son posibles en
una conferencia grande si alguien dice algo a lo que la mayoría de
los participantes reacciona, como contar un chiste. AudioMan cuenta
el número de paquetes recibidos en un período de tiempo
especificado. Si la cuenta de paquetes excede un umbral
especificado, los paquetes de audio que llegan antes de que el
período expire son simplemente borrados. El número de paquetes
borrados son seguidos por g_npPacketsPoliced y si es mayor que cero
son mostrados en la pantalla de Mostrar Estado, Help.
Como con todo en AudioMan, los ajustes del
servidor son
Audio_MaxReceivedPackets=70
Audio_MaxReceivedPacketsPeriod=40
En este ejemplo, los primeros 70 paquetes de
audio recibidos en un período de 40 ms son descodificados.
Cualesquiera paquetes recibidos después del 70^{avo} son borrados
hasta que el período de 40 ms expira y entonces el proceso empieza
de nuevo.
Una de las "únicas" cosas claves acerca del
tratamiento de la tormenta de audio es que cada terminal llega
"exactamente" a la misma decisión independientemente "sin"
ningún mensaje de sincronización extra. Esto resulta posible puesto
que todos reciben los mismos flujos de audio y todos utilizan las
mismas reglas de puntuación.
Las siguientes solicitudes están todas
referenciadas:
La solicitud de patente de U.S. 10/114,402
titulada VIDEOPHONE AND METHOD FOR A VIDEO CALL (patente de U.S.
no. 7.404.001)
La solicitud de patente de U.S. 10/871.852
titulada AUDIO MIXER AND METHOD (publicación de U.S. no.
2005-0041646)
La solicitud de patente de U.S. 11/078.193
titulada método y METHOD AND APPARATUS FOR CONFERENCING WITH STREAM
(publicación de U.S. no. 2005-0237931)
Un nodo puede incluir un miembro, grupo,
terminal, o participante de una conferencia. Una conferencia
comprende típicamente al menos tres nodos, y podría tener 10 ó 20 ó
incluso 50 ó 100 ó 150 ó nodos mayores.
El ancho de banda de audio total no debe NUNCA
exceder 1000 Kbps o el video puede resultar afectado.
El método de control del ancho de banda de la
Tormenta de Audio limita el número máximo de hablantes a 10 para
evitar una degradación del audio y del video.
\vskip1.000000\baselineskip
En referencia a las Figuras 8, 9, 10 y 11, un
dispositivo de captación de imagen 30, tal como una cámara analógica
32 convencional suministrada por Sony con video S, convierte las
imágenes de una escena a partir del dispositivo de captación de
imagen 30 en señales eléctricas que son enviadas junto con un cable
a un descodificador de video 34, tal como un descodificador SAA7114
NTSC/PAL de Philips. El descodificador de video 34 convierte las
señales eléctricas en señales digitales y las transmite como un
flujo de píxeles de la escena, tal como en formato BT 656. El flujo
de píxeles es transmitido desde el descodificador de video 34 y
dividido en un primer flujo y un segundo flujo idéntico al primer
flujo. Un codificador 36, preferiblemente un codificador eNV 420 de
IBM, recibe el primer flujo de píxeles, opera sobre el primer flujo
y produce un flujo de datos en formato de MPEG-2.
El flujo de datos producido por el codificador de video 36 es
comprimido aproximadamente al 1/50 de su tamaño comparado con los
datos tal como se han producido en la cámara. El flujo de
MPEG-2 es un flujo digital codificado y no está
sujeto a almacenamiento temporal de tramas antes de ser
subsiguientemente organizado en paquetes con el fin de minimizar
cualquier retardo. El flujo digital de MPEG-2
codificado es organizado en paquetes usando un RTP mediante una
Field Programmable Gate Array (FPGA - Matriz de Puerta Programable
por Campos) 38 y un software al que se le proporciona el flujo de
MPEG-2, y es transmitido a una red 40, tal como una
Ethernet 802.p o una ATM a 155 megabits por segundo, usando una
interfaz de red 42 a través de una interfaz PLX 9054 PCI 44. Si se
desea, el descodificador 34 puede recibir un flujo de video asociado
a un VCR o a un programa de televisión, tal como la CNN o una
película, y proporcionarlo directamente al controlador de
visualización 52 para su visualización. Un controlador de
descodificador 46 situado en la FPGA 38 y conectado con el
descodificador 34, controla la operación del descodificador 34.
Alternativamente, si se usa una cámara digital
47, el flujo resultante que es producido por la cámara está ya en
un formato digital y no necesita ser proporcionado al descodificador
34. El flujo digital de la cámara digital 47, que está en formato
BT 656, es dividido en los flujos primero y segundo directamente
desde la cámara, sin pasar a través de ningún descodificador de
video 34.
En otra alternativa, una cámara de fire wire 48,
tal como una cámara de fire wire 48 con interfaz 1394, puede ser
usada para proporcionar una señal digital directamente a la FPGA 38.
La cámara de fire wire 48 proporciona la ventaja de que si la
producción del flujo de datos va a ser para algo más que para una
distancia muy corta desde la FPGA 38, entonces las señales
digitales pueden ser soportadas sobre esta distancia más larga, por
ejemplo, cableando, desde la cámara de fire wire 48. La FPGA 38
proporciona la señal digital desde la cámara de fire wire 48 al
codificador 36 para su tratamiento como se ha descrito
anteriormente, y también crea un flujo de velocidad de trama, como
se describe a continuación.
El segundo flujo es proporcionado a la FPGA 38
donde la FPGA 38 y el software producen un flujo de velocidad de
trama baja, tal como un flujo de JPEG de movimiento, lo que requiere
un bajo ancho de banda comparado con el primer flujo. La FPGA 38 y
un controlador principal 50 con software llevan a cabo la
codificación, la compresión y la organización en paquetes en este
flujo de velocidad de trama baja y lo proporcionan a la interfaz PCI
44, que a su vez lo transfiere a la interfaz de red 42 a través de
una tarjeta de interfaz de red 56 para su transmisión a la red 40.
El flujo digital de MPEG-2 codificado y el flujo de
velocidad de trama baja son los dos flujos de datos esencialmente
idénticos pero independientes, excepto porque el flujo de datos de
velocidad de trama baja es reducido comparado con el flujo de datos
de MPEG-2 para proporcionar una menor vista de la
escena con respecto al flujo de MPEG-2 y requiere
menos recursos de la red 40.
En la red 40, cada flujo digital es transportado
a un video teléfono 15 receptor deseado, o a video teléfonos
receptores 15 si está implicada una conferencia de más de dos
participantes. Los datos son encaminados usando SIP. La tarjeta de
interfaz de red 56 del video teléfono 15 receptor recibe los
paquetes asociados con los flujos de datos primero y segundo y
proporciona los datos de los paquetes y del flujo de video (primero
o segundo) elegidos por el controlador principal a una memoria
recibida. Un controlador principal 50 del video teléfono 15
receptor con software descodifica y expande el flujo de datos
recibido elegido y lo transfiere a un controlador de visualización
52. El controlador de visualización 52 muestra las imágenes
recreadas en un visualizador de panel plano digital de VGA usando
un hardware de escalado estándar. El usuario del video teléfono 15
receptor puede elegir qué flujo de los dos flujos de datos ver con
una pantalla táctil 74, o si se desea, elige que se visualicen
tanto imágenes grandes como pequeñas de la escena, aunque la
visualización de ambos flujos del video teléfono transmisor 15 no
ocurriría normalmente. Una explicación sobre los protocolos para
visualización es explicada a continuación. Teniendo la opción de
elegir bien la vista más grande de la escena o bien la vista más
pequeña de la escena, el usuario tiene la posibilidad de asignar los
recursos del sistema 10 de manera que pueden elegirse los
individuos que en ese momento sean más importantes para que el
espectador los vea en una imagen más grande y más clara; mientras
que aquéllos que el usuario quiere ver también, pero que no son tan
importantes en ese momento, pueden verse
todavía.
todavía.
El controlador de visualización 52 hace que cada
flujo de video distinto, si hay más de uno (si está teniendo lugar
una multi conferencia) aparezca uno al lado del otro en el
visualizador 54. Las imágenes que se forman una a cada lado del
visualizador 54 son cortadas y no reducidas de manera que las
propias dimensiones de los objetos en la escena no cambien, sólo se
eliminan los intervalos más exteriores a cada lado de la escena
asociados a cada flujo de datos. Si se desea, las imágenes de
flujos asociadas a imágenes de escenas más pequeñas pueden ser
visualizadas una a cada lado en la esquina inferior derecha de la
pantalla del visualizador 54. El controlador de visualización 52
proporciona video digital estándar al controlador de LCD 72, como se
muestra en la Figura 9. El controlador de visualización 52
producido por la ATI o Nvidia, es un controlador de VGA estándar. El
controlador de LCD 72 toma el video digital estandarizado del
controlador de visualización 52 y hace la imagen apropiada para el
panel particular usado, tal como un Philips para panel de
Fujistu.
Para mejorar también el corte de la imagen, en
lugar de eliminar simplemente porciones de la imagen empezando por
el borde exterior y moviéndose hacia el centro, la porción de la
imagen que no muestra información relevante es cortada. Si la
persona que está hablando aparece en el lado izquierdo o derecho de
la imagen, entonces se desea cortar desde el lado izquierdo hacia
el interior si la persona está al lado derecho de la imagen, o
desde el lado derecho hacia el interior si la persona está en el
lado izquierdo de la imagen, en lugar de cortar sólo desde cada
borde exterior hacia el interior, lo que podría hacer que una
porción de la persona se pierda. El uso de rastreo de video mira la
imagen que se forma y analiza dónde ocurren cambios en la imagen
con el fin de identificar dónde está una persona en la imagen. Se
asume que la persona se estará moviendo más con respecto a las
otras áreas de la imagen, e identificando el movimiento relativo,
puede determinarse la situación de la persona en la imagen. A
partir de este rastreo de video, puede hacerse que el corte tenga
lugar en el borde o bordes en los que hay menos cantidad de cambio.
Alternativamente, o en combinación con el rastreo de video, también
puede usarse rastreo de para guiar el corte de la imagen que tiene
lugar. Puesto que el video teléfono 15 tiene matrices de
micrófonos, se usan técnicas de triangulación estándar basadas en
los diferentes tiempos que le lleva a un sonido dado alcanzar los
diferentes elementos de la matriz de micrófonos para determinar
dónde está situada la persona con respecto a la matriz de
micrófonos, y puesto que la situación de una matriz de micrófonos
es conocida con respecto a la escena que está siendo visualizada en
imágenes, la situación de la persona en la imagen es de este modo
conocida.
Las funcionalidades del video teléfono 15 son
controladas con una pantalla táctil 74 en el monitor. La pantalla
táctil 74, que es una pantalla de vidrio estándar, proporciona
señales no tratadas al controlador de pantalla táctil 76. Las
señales no tratadas son detectadas por las ondas ultrasónicas que se
crean en el vidrio cuando el usuario toca el vidrio en un lugar
dado, como es bien conocido en la técnica. El controlador de
pantalla táctil 76 toma entonces las señales no tratadas y las
convierte en información con significado con respecto a una
posición X e Y en el visualizador y pasa esta información al
controlador principal 50.
Si una conexión de televisión o de VCR está
disponible, la alimentación para la televisión o la película es
proporcionada al descodificador 34, en el cual la alimentación es
controlada como en cualquier otra señal de video recibida por el
video teléfono 15. La televisión o película puede aparecer a un lado
de la escena de una conexión de video con otro video teléfono 15 en
el visualizador 54.
El flujo de audio de la escena sigue
esencialmente una ruta paralela y similar al flujo de audio video,
excepto porque el flujo de audio es proporcionado desde un receptor
de audio 58, tal como un micrófono, tarjeta de sonido, auriculares
o auricular a una interfaz de audio 4201 de cristal CS 60 o tal como
un Codec, que lleva a cabo la conversión de las señales analógica a
digital y digital a analógica, y controla también el volumen y la
mezcla, que digitaliza la señal de audio y la proporciona a un TCI
320C6711 o a un 6205 DSP 62. El DSP 62 organiza entonces en
paquetes el flujo de audio digitalizado y transfiere el flujo de
audio a la FPGA 38. La FPGA 38 a su vez lo proporciona a la
interfaz PCI 44, donde es pasado a continuación a la tarjeta de
interfaz de red 56 para su transmisión a la red 40. El flujo de
audio que es recibido por el video teléfono 15 receptor, es pasado
a la FPGA 38 y al DSP 62 y a continuación a la interfaz de audio 60
que convierte la señal digital en una señal analógica para su
reproducción en altavoces 64.
La tarjeta de interfaz de red 56 marca el tiempo
en cada paquete de audio y paquete de video que es transmitido a la
red 40. La velocidad a la cual el audio y el video que es recibido
por el video teléfono 15 es procesado es suficientemente rápida
para que el ojo y el oído humanos, escuchándolo, no puedan discernir
ningún desalineamiento del audio con el video de la escena asociado
en el tiempo. La restricción de menos de 20-30
milisegundos es situada en el tratamiento de la información de
audio y de video de la escena para mantener esta asociación del
video y del audio de la escena. Para asegurar que el audio y el
video de la escena están en sincronización cuando son recibidos en
un video teléfono 15 receptor, se revisa el marcado de tiempo de
cada paquete, y los correspondientes paquetes basados en audio y
paquetes basados en video son alineados por el video teléfono 15
receptor y de manera correspondiente reproducidos esencialmente al
mismo tiempo, de manera que no hay ningún desalineamiento que sea
discernible por el usuario en el video teléfono 15 receptor del
video y audio de la escena.
Un panel ENC-DSP contiene el
codificador de IBM eNV 420 MPEG-2 y su circuitería
de soporte, el DSP 62 para codificación y descodificación de audio,
y la interfaz de PCI 44. Contiene el hardware que es necesario para
una completa funcionalidad de terminal de video teléfono 15 dado un
sistema 10 de plataforma PC 68 y visualizador 54 de alto
rendimiento. Es un diseño de acuerdo con un PCI 2.2 de tamaño
completo. La cámara, micrófono o micrófonos, y altavoces 64 son la
interfaz con este panel. El DSP 62 llevará a cabo la codificación de
audio, descodificación, mezcla, colocación en estéreo, control de
nivel, llenado de huecos, organización en paquetes, y otras
funciones de audio, tales como AEC en estéreo, dirección de rayo,
cancelación de ruido, cancelación de clic de teclado, o eliminación
de la reverberación. La FPGA 38 es desarrollada usando las
herramientas de Celoxia (Handel-C), y es totalmente
reconfigurable. El diseño soporta partes en el intervalo de
1-3 millones de puertas.
Este panel incluye una interfaz de chip de
cámara digital 47, hardware o "video DSP" basados en una
interfaz de descodificador de video 34 de
multi-canal, superposición de video usando los
conectores de entrada y salida de DVI, hasta la posibilidad de
almacenamiento temporal de trama muda completa con superposición de
video.
Usando una señal de video NTSC o PAL, el
codificador 36 debe producir un flujo de video de una resolución de
640 X 480, y preferiblemente de 720 X 480 o mejor, de alta calidad.
La velocidad de bits debe ser controlada de manera que el número
máximo de bits por trama esté limitado con el fin de evitar el
retardo de la transmisión sobre la red 40. El descodificador 34
debe empezar a descodificar una fracción al recibir el primer macro
bloque de datos. Puede ser necesario un cierto almacenamiento
temporal para absorber una fluctuación menor y mejorar así
la
imagen.
imagen.
El MPEG-2 es ampliamente usado y
desplegado, siendo la base para la codificación de DVD y VCD,
dispositivos de VCR's digitales y desplazamiento de tiempo tales
como TiVo, así como distribución de DSS y otras TV digitales.
Normalmente se considera que es la elección para la transmisión de
video a 4 a 50 Mbit/segundo. Debido a su amplio uso, soluciones
altamente integradas, de relativamente bajo coste, para
descodificar, y más recientemente, codificar, están disponibles
ahora comercialmente.
El MPEG-2 debe considerarse como
una sintaxis para video codificado en lugar de un método de
compresión estándar. Mientras que la especificación define la
sintaxis y los métodos de codificación, está muy extendido el uso
de los métodos siempre que se siga la sintaxis definida. Por esta
razón, generalizaciones sobre el MPEG-2 son
frecuentemente engañosas o inexactas. Es necesario acceder a niveles
de detalle más bajos sobre métodos de codificación específicos y de
aplicación particular con el fin de evaluar el rendimiento del
MPEG-2 para una aplicación específica.
De interés para el proyecto del video teléfono
15 son las cuestiones de codificación y descodificación de bajo
retardo, así como las cuestiones relativas a la red 40. Hay tres
cuestiones primarias en el algoritmo de MPEG-2 que
necesitan ser comprendidas para alcanzar un video de bajo retardo y
alta calidad sobre una red 40:
- \equiv
-
\vtcortauna
- \equiv
-
\vtcortauna
- \equiv
-
\vtcortauna
\vskip1.000000\baselineskip
El MPEG-2 define 3 clases de
tramas codificadas: I, P, y B. La estructura del GOP más común en
uso es de 16 tramas de longitud: IPBBPBBPBBPBBPBB. El problema con
esta estructura es que cada trama B consecutiva, puesto que el
movimiento de la trama B es estimado a partir de la trama previa y
la trama siguiente, requiere que las siguientes tramas sean
capturadas antes de que la codificación de la trama B pueda empezar.
Como cada trama es de 33 msec, ello añade un mínimo de 66 msec de
retardo adicional para esta estructura del GOP sobre uno sin
ninguna trama B. Esto conduce a una estructura del GOP de bajo
retardo que contiene sólo tramas I y/o P, definida en la
especificación de MPEG-2 como codificación de SP@ML
(Perfil Simple).
\vskip1.000000\baselineskip
Una vez que las tramas B son eliminadas para
minimizar el retardo de codificación, el GOP es construido con las
tramas I y las tramas P correspondientes a las tramas I. Debido a
que una trama I es completamente codificada dentro de la trama,
lleva muchos bits hacer esto, y menos bits para las siguientes
tramas P.
Obsérvese que una trama I puede ser 8 veces más
larga que la trama P, y 5 veces la velocidad de bits nominal. Esto
tiene un impacto directo en los requisitos sobre la red 40 y sobre
el retardo: si hay un ancho de banda límite, la trama I será
almacenada temporalmente en la restricción de la red 40, provocando
un retardo adicional de múltiples tiempos de trama sobre el
segmento restringido. Esta memoria temporal debe estar de acuerdo
con el receptor porque la velocidad de reproducción es establecida
por el video, no por el ancho de banda de la red 40. La muestra
usada para los datos anteriores fue un escenario de oficina a cámara
lenta; En un contenido de alto movimiento con cambios de escena, a
las tramas se les asignarían más o menos bits dependiendo del
contenido, teniendo lugar algunas tramas P grandes en cambios de
escena.
Para controlar este comportamiento, el
MPEG-2 implementa el almacenamiento temporal del VBV
(Video Buffering Verifier - Verificador de la Memoria Temporal del
Video), que permite un grado de control sobre la relación entre el
máximo tamaño de trama codificada y la velocidad de bits nominal.
Restringiendo muy estrechamente el VBV de manera que las tramas I
estén limitadas a menos de 2X el tamaño indicado por la velocidad de
bits nominal, el retardo por almacenamiento temporal añadido puede
ser limitado a 1 tiempo de trama adicional. El coste de restringir
el tamaño del VBV es la calidad de la imagen: la razón para tramas I
grandes es proporcionar una buena base para las siguientes tramas
P, y la calidad se degrada seriamente a menores velocidades de bits
(<4 Mbit) cuando el tamaño de las tramas I está restringido.
Considérese que a 2 Mbit, el tamaño medio de trama es 8 Kbytes, e
incluso dos veces este tamaño no es suficiente para codificar una
imagen JPEG de 320X240 con buena calidad, que es comprimido en DCT
de manera similar a una trama I.
Yendo a la trama I sólo codificar permite un
tamaño de trama codificada más consistente, pero con más degradación
de la calidad. Sólo la codificación de tramas I de baja velocidad
de bits no aprovecha el volumen de la capacidad de compresión del
algoritmo de MPEG-2.
La especificación de MPEG-2
define los modos de CBR (Constant Bit Rate - Velocidad de Bits
Constante) y VBR (Variable Bit Rate - Velocidad de Bits Variable),
y permite una estructura de GOP variable dentro de un flujo. El
modo de CBR se define para generar un número de bits consistente
para cada GOP, usando relleno si es necesario. El VBR pretende
permitir una calidad consistente, pero permitiendo una variación en
el ancho de banda de codificación, permitiendo que el flujo asigne
más bits a áreas de difícil codificación siempre que esto esté
compensado mediante velocidades de bits más bajas en secciones más
simples. El VBR puede ser implementado con técnicas de dos pasos o
de un paso. La estructura de GOP variable permite, por ejemplo, la
colocación de tramas I en las fronteras de transición de la escena
con el fin de eliminar artefactos de compresión visibles. Debido al
bajo requisito de retardo y a la necesidad de mirar un poco más
hacia adelante con el fin de implementar el VBR o el GOP variable,
estos modos son de bajo interés para la aplicación del video
teléfono 15.
Debido a que las tramas P y B en una estructura
de GOP típica son dependientes de la trama I y de las tramas P y B
precedentes, la pérdida de datos afecta a todas las tramas que
siguen al error hasta la siguiente trama I. Esto afecta también a
la latencia de inicio, tal como cuando canales de inversión en un
sistema de DSS 10, donde el descodificador 34 espera por una trama
I antes de que pueda empezar a visualizar una imagen. Por esta
razón, la longitud del GOP, estructura, y velocidad de bits
necesitan ser sintonizados para el sistema 10 de la aplicación y
suministro. En el caso de colaboración en tiempo real usando el IP,
se usa un protocolo de transporte no fiable tal como el RTP o el
UDP porque un último paquete debe ser tratado como perdido, puesto
que uno no se puede permitir el retardo requerido para tratar con un
acuse de recibo y una retransmisión de protocolo fiable. Se han
realizado varios análisis sobre el efecto de la pérdida de paquetes
en calidad de video, mostrando los resultados que para una
estructura de IPB típica de GOPs, una pérdida de paquetes del 1%
provoca una pérdida de trama del 30%. Estructuras de GOP más cortas
y finalmente flujos sólo de trama I (con pérdida de calidad),
ayudan algo a esto, y técnicas de FEC (Forward Error Correction -
Corrección de Error de Transmisión) pueden ayudar un poco cuando
ocurre una pérdida, pero ciertamente uno de los problemas con el
MPEG-2 es que no es muy tolerante con la pérdida de
datos.
Una estructura de GOP llamada codificación de
trama P Continua dirige todas las cuestiones mencionadas
anteriormente y proporciona una excelente calidad de video a
velocidades de bits relativamente bajas para el video teléfono 15.
La codificación P continua hace uso de la posibilidad de los
macro-bloques de codificación dentro de la trama de
una trama dentro de una trama P. Codificando unos
macro-bloques de conjuntos de 16X16 píxeles
pseudo-aleatoriamente, y codificando en movimiento
los otros, los bits de trama-I equivalentes son
distribuidos en cada trama. Implementar la selección de
macro-bloques pseudo-aleatoria
asegura que todos los bloques estén actualizados en una escala de
tiempos frecuentes, el inicio y el cambio de escena son manejados de
una manera razonable.
IBM ha implementado este algoritmo para el
codificador S420, ajustando la velocidad de actualización de trama
DCT completa a 8 tramas (3,75 tiempos por segundo). Los resultados
para un contenido de oficina y conferencia típicos son bastante
impresionantes. El retardo de codificación, la variación de tamaño
de trama codificada, y el comportamiento de la pérdida de paquetes
es casi ideal para el video teléfono 15. La revisión de las
muestras codificadas muestra que para cambios de escena y un
contenido altamente dinámico los artefactos de codificador 36 son
evidentes, pero para el contenido de colaboración de los cascos
típicos, la calidad es muy buena.
El audio de alta-calidad es un
pre-requisito esencial para comunicaciones
efectivas. La alta-calidad está definida como
completa-bidireccional, un ancho de banda de 7 kHz,
(la del teléfono es 3,2 kHz), > 30 dB de relación
señal-a-ruido, no eco, corte o
distorsión perceptibles. La instalación será muy simple implicando
el menor número de cables posible. Un diagnóstico en pantalla
indicará el problema y cómo solucionarlo. El sonido desde los
altavoces 64 estará libre de chasquidos audibles y de niveles de
sonido demasiado altos o demasiado bajos.
Una señal de audio de paquetes faltantes o
retrasados puede ser "llenada" basándose en la señal de audio
precedente. La memoria temporal de audio debe ser aproximadamente
de 50 ms de media entre una fluctuación de red 40 y añadiendo
retardo al audio. El tamaño de paquete actual de 320 muestras ó 20
ms podría disminuir la latencia de codificación y descodificación.
No obstante, 20 ms es una longitud de datos estándar para paquetes
de RTP.
Algunos de los procesos descritos a continuación
están disponibles en productos comerciales. No obstante, por
razones de coste e integración, serán implementados en un DSP 62. En
otra realización, un segundo DSP 62 puede llevar a cabo una
cancelación del eco acústico en lugar de que solamente un DSP 62
lleve a cabo también esta función.
El sistema 10 de audio tiene una sección de
transmisión y una sección de recepción. La sección de transmisión
está comprendida de lo siguiente:
\vskip1.000000\baselineskip
Una de las principales quejas del aparato
telefónico con teclado es el sonido hueco que se oye en el extremo
remoto. Este sonido hueco es debido a la reverberación de la
habitación y se concibe mejor como la relación entre la potencia
del sonido reflejado (reverberante) con respecto a la potencia del
sonido directo. Actualmente, el mejor método para mejorar la
recuperación es colocar micrófonos cerca de un altavoz y aumentar
así la potencia del sonido directo. En un entorno de oficina,
podrían colocarse micrófonos en el monitor del PC 68, o en el
terminal de video teléfono 15 y en una pizarra blanca.
\vskip1.000000\baselineskip
La ganancia para el preamplificador para cada
micrófono es ajustada automáticamente de manera que se use
completamente el intervalo de ADC. La ganancia de preamplificación
tendrá que ser enviada a otros procesos de audio tales como AEC y
reducción de ruido.
\vskip1.000000\baselineskip
En su forma más simple, este es un dispositivo
de ADC. No obstante, varias empresas tales como Texas Instruments y
Analog Devices Inc tienen CODECS con amplificadores analógicos y
multiplexadores analógicos. También, residente en el chip existe
una DAC con similares controles. El control automático de ganancia
descrito en la sección previa es implementado en el CODEC y
controlado por el DSP 62.
\vskip1.000000\baselineskip
Pueden usarse dos métodos de reducción de ruido
para mejorar la SNR. El primer método es llamado comúnmente control
de ruido, que conecta y desconecta el canal dependiendo del nivel de
señal presente. El segundo método es cancelación de ruido
adaptativa (ANC) y extrae ruido no deseado de la señal de micrófono.
En un entorno de oficina, sería posible usar ANC para eliminar
anuncios de PA, ruido de ventiladores y en algunos casos, incluso
clics de teclado.
Algoritmos de reducción o de control de ruido
están disponibles en paquetes de edición comerciales tales como
Cool Edit and Goldwave que pueden aplicar efectos especiales,
eliminar ruido de chasquidos de las grabaciones y también eliminar
silbidos de grabaciones de cinta.
\vskip1.000000\baselineskip
Se oye eco cuando la voz del hablante vuelve al
hablante después de más de 50 ms. El eco es muy molesto y por ello
necesita ser eliminado. Las dos fuentes de eco son eco de línea y
eco acústico. El eco de línea es debido a características de un
sistema 10 telefónico de dos líneas. La PSTN elimina este eco usando
un line echo canceller (LEC - Cancelador de Eco de Línea). Cuando
se usa un sistema 10 de teléfono de altavoz, el eco acústico tiene
lugar entre el altavoz del teléfono y el micrófono. El sonido del
altavoz remoto es recogido por el micrófono remoto y devuelto al
hablante. Acoustic echo cancellation (AEC - Cancelación de Eco
Acústico) es más difícil que el LEC puesto que es más complicado
crear un modelo de la acústica de la habitación y puede cambiar
repentinamente con el movimiento de las personas. Hay muchos
productos de AEC que varían desde los dispositivos independientes
tales como ASPI EF1210 a módulos de objeto de Signal Works
optimizados para ejecutarse sobre plataformas DSP 62.
\vskip1.000000\baselineskip
El auto mezclado es seleccionar qué señales de
micrófono mezclar entre sí y enviar la salida monaural del
mezclador al codificador 36. Los criterios de selección se basan en
usar el micrófono cerca de la fuente más fuerte o usar micrófonos
que están recibiendo sonido que está por encima del nivel de umbral.
Diferentes auto mezcladores están disponibles comercialmente de
varios vendedores y se usan en sistemas de teleconferencia y de
tele-educación.
\vskip1.000000\baselineskip
Para reducir el ancho de banda de transmisión de
datos, la señal de audio es comprimida a una velocidad de bits
menor aprovechando las características típicas de la señal y nuestra
percepción de la conversación. Actualmente, el codec G.722 ofrece
la mejor calidad de audio (7 kHz ancho de banda @ 14 bits) a una
velocidad de bits razonable de 64 kbits/s.
\vskip1.000000\baselineskip
Los datos de audio codificados son segmentados
en segmentos de 20 ms y enviados como paquetes de RealTime Protocol
(RTP - Protocolo de Tiempo Real). El RTP fue específicamente
diseñado para el intercambio de datos en tiempo real requerido para
aplicaciones de VoIP y teleconferencia.
\global\parskip0.930000\baselineskip
La sección de recepción es:
Los paquetes de RTP que contienen flujos de
audio de uno o más lugares remotos son colocados en sus respectivas
memorias temporales. Los paquetes faltantes o retrasados son
detectados y esa información es pasada al Gap Handler - Gestor de
Huecos. Los paquetes mal ordenados son un caso especial de paquetes
retrasados y como los paquetes retrasados es probable que sean
descartados. La alternativa es tener una memoria temporal para
reproducción retardada de la señal de audio para al menos una
longitud de paquete. El tamaño de la memoria temporal tendrá que
estar restringido de tal manera que el retardo de extremo a extremo
no sea mayor de 100 ms.
\vskip1.000000\baselineskip
El flujo de audio de G.722 es descodificado a
muestras de PCM para el CODEC.
\vskip1.000000\baselineskip
En cualquier red, se perderán o corromperán
paquetes de RTP. Por lo tanto, el Gestor de Huecos "rellenará"
los datos faltantes basándose en el espectro y en las estadísticas
de los paquetes previos. Como mínimo, debe rellenarse con ceros el
flujo de datos para construir datos pero puede usarse un algoritmo
de interpolación o extrapolación espectral para rellenar los
datos.
\vskip1.000000\baselineskip
La fluctuación de la red requerirá un
almacenamiento en memoria temporal para permitir una reproducción de
audio continua. Esta memoria temporal ajustará probablemente su
tamaño (y por ello su latencia) basándose en un compromiso entre
las estadísticas de fluctuación a corto plazo y el efecto de
latencia.
\vskip1.000000\baselineskip
La velocidad de muestreo nominal para un
terminal de video teléfono 15 es 16 kHz. No obstante, existirán
ligeras diferencias que necesitan ser manejadas. Por ejemplo,
supóngase que el video teléfono 15 North muestrea precisamente a
16,001 Hz mientras que el video teléfono 15 South muestrea a 15,999
Hz. De este modo, el terminal South acumulará 1 muestra más por
segundo de lo que transmite al hablante y el terminal North llevará
a cabo un déficit de igual cantidad. Las estadísticas a largo plazo
en la memoria temporal receptora serán capaces de determinar cuál
es la velocidad de muestreo diferencial y la interpolación apropiada
(para el video teléfono 15 North) o puede calcularse el factor de
decimación (para el video teléfono 15 South).
\vskip1.000000\baselineskip
Ajustar el volumen que viene de los altavoces 64
es típicamente realizado por los oyentes remotos. Una manera mejor
podría ser ajustar automáticamente el sonido de los altavoces 64
basándose e cómo suena de fuerte para los micrófonos de la
habitación. Otros factores tales como el ruido de fondo y la propia
preferencia del oyente pueden ser tenidos en cuenta.
\vskip1.000000\baselineskip
Hablantes remotos de diferentes lugares pueden
estar situados en el campo del auditorio. Así, una persona de la
situación A vendría en general de la izquierda, la persona de la
situación B del medio y la persona de la situación C de la derecha.
Esta colocación facilita realizar el seguimiento de quién está en la
conversación.
\vskip1.000000\baselineskip
La calidad del sonido hasta cierto punto está
determinada por la calidad de los altavoces 64 y del recinto. En
cualquier caso, se usan altavoces 64
auto-amplificados para el terminal de video teléfono
15.
\vskip1.000000\baselineskip
Los actuales sistemas para llevar a cabo
conferencias tal como la estación de sonido PolyCom ofrecen
satisfactoriamente pero con banda limitada calidad de audio
completamente bidireccional. No obstante, el ancho de banda está
limitado a 3500 Hz y la calidad de sonido resultante aguza al oído y
especialmente para distinguir sonidos fricativos.
\global\parskip1.000000\baselineskip
El video teléfono 15 extiende el ancho de banda
a 7 kHz y auto-mezcla múltiples micrófonos para
minimizar la reverberación de la habitación. Cuando tres o más
personas están hablando, cada uno de los participantes remotos
estará situado en un único lugar en el campo de sonido estéreo.
Combinado con la alta calidad de la captación del audio y con el
mayor ancho de banda, una conferencia sobre la red 40 se aproximará
rápidamente a la de estar allí en persona.
El sistema 10 de audio utiliza múltiples
micrófonos para una mejor captación del sonido y un codificador de
banda ancha (G.722) para una mejor fidelidad de lo que se ofrece
normalmente para sistemas tollgrade. Adicionalmente, para
conferencias de múltiples participantes, se implementará la
colocación en estéreo de hablantes remotos y un sistema 10 de
cancelación de eco acústico para permitir la operación de manos
libres. El ajuste del volumen en la habitación estará controlado
automáticamente con un sólo control para el usuario final con el fin
de ajustar el nivel global del sonido.
En la red 40 del video teléfono 15, una pasarela
70 conecta algo no-SIP con el entorno de SIP. A
menudo hay diferencias tanto eléctricas como de protocolo. La
mayoría de las pasarelas 70 conectan otros dispositivos de teléfono
o video conferencia con el sistema 10 de video teléfono 15.
Las pasarelas 70 se distinguen por interfaces;
un lado es una red 40, para video teléfono 15 esta es Ethernet o
ATM. El lado externo puede ser una línea telefónica analógica o un
puerto RS-232. El tipo, número y características
del puerto distingue una pasarela 70 de otra. En el lado de la red
40, hay protocolos de transporte tales como RTP o AAL2, y
protocolos de señalización tales como SIP, Megaco o MGCP.
En el lado externo, puede haber una amplia
variedad de protocolos dependiendo de las interfaces proporcionadas.
Algunos ejemplos serían señalización de ISDN (Q.931) o de POTS. Las
pasarelas 70 de PSTN conectan líneas de PSTN con el sistema 10 de
video teléfono 15 in situ. Las pasarelas 70 de PBX permiten a
un sistema 10 de video teléfono 15 emular un teléfono propietario
para proporcionar compatibilidad a una PBX in situ existente.
Las pasarelas 70 de POTS conectan teléfonos analógicos en silencio
con un sistema 10 de video teléfono 15. Las pasarelas 70 de H.323
conectan un sistema 10 de H.323 con el sistema 10 de video teléfono
15 basado en SIP. Esta es una pasarela 70 sólo de señalización-- el
servidor de medios 66 hace la conversión de H.261 a MPEG.
Tres tecnologías que permiten el video teléfono
15 son el Session Initiation Protocol (SIP - Protocolo de
Iniciación de Señalización), el Session Description Protocol (SDP -
Protocolo de Descripción de Sesión) y el Real-Time
Transport Protocol (RTP - Protocolo de Transporte en Tiempo
Real).
SIP es un protocolo de señalización para
iniciar, gestionar y finalizar sesiones de voz y de video sobre
redes de paquetes.
El SDP está pensado para describir sesiones de
multimedia con fines de anuncio de sesión, invitación a sesión, y
otras formas de iniciación de sesión de multimedios. El SIP utiliza
el SDP para describir sesiones de medios.
El RTP proporciona funciones de transporte de
extremo a extremo en la red 40 adecuadas para aplicaciones que
transmiten datos en tiempo real, tales como datos de audio, video o
de simulación, sobre servicios de red 40 multidifusión o
unidifusión. El SIP utiliza el RTP para transporte de sesión de
medios de comunicación.
El video teléfono 15 puede llevar a cabo
conferencias con tres o más participantes sin el uso de ningún
puente de conferencia o MCU. Esto es realizado usando flujos de
punto a multipunto de ATM como los establecidos mediante el SIP.
Más específicamente, cuando el flujo de MPEG-2 y el
flujo de velocidad de trama baja es organizado en paquetes para su
transmisión en la red 40, la información de cabecera para cada uno
de los paquetes identifica las direcciones de todos los video
teléfonos 15 receptores de la conferencia, como es bien conocido en
el sector. A partir de esta información, cuando los paquetes son
transmitidos a la red 40, el SIP establece la capacidad de conexión
necesaria para que los diferentes paquetes alcancen sus destinos de
video teléfono 15 deseados.
Como ejemplo de una conferencia que no utiliza
ningún puente de conferencia, sean 10 video teléfonos 15 en
posiciones discretas que son participantes en una conferencia. Cada
video teléfono 15 produce un flujo basado en audio, y un flujo
basado en MPEG-2 y un flujo basado en una velocidad
de trama baja. No obstante, cada video teléfono 15 no devolverá
ninguno de estos flujos a sí mismo, así que de manera efectiva, en
una conferencia de 10 participantes de video teléfonos 15, cada uno
se comunica con los otros nueve video teléfonos 15. Mientras que
podría darse el caso de que el video teléfono 15 se comunique
consigo mismo, para maximizar la utilización del ancho de banda, el
video producido por cualquier video teléfono 15 y, si se desea, el
audio producido por un video teléfono 15 puede mostrarse u oírse
como aparece esencialmente en los otros video teléfonos 15, pero a
través de un canal interno, que se describirá a continuación, que no
requiere la utilización de ningún ancho de banda de la red 40.
En la conferencia, cada video teléfono 15 recibe
nueve flujos de datos basados en audio. Tres flujos de datos
basados en MPEG-2 y seis flujos de datos basados en
velocidad de trama baja. Si se desea, el receptor podría elegir
hasta nueve flujos del tipo de flujos basados en velocidad de trama
baja así que el visualizador 54 sólo muestra las imágenes más
pequeñas de cada video teléfono 15, o hasta cuatro de los flujos de
datos basados en MPEG-2 en los que el visualizador
54 es llenado con cuatro imágenes de cuatro de los video teléfonos
15 de la conferencia sin que se muestre la imagen de ningún flujo
basado en velocidad de trama baja, puesto que no hay sitio para
ellos en el visualizador 54 si se visualizan cuatro flujos basados
en MPEG-2. Mostrándose tres flujos basados en
MPEG-2, se permite que se muestren seis de los
flujos basados en velocidad de trama baja. Cada uno de los flujos
se forma como se ha explicado anteriormente, y se recibe como se ha
explicado anteriormente en los diferentes video teléfonos 15.
Si se desea que se muestren más de cuatro
imágenes grandes de una conferencia, entonces la manera de que esto
se lleve a cabo es que video teléfonos 15 adicionales sean
conectados entre sí de manera que los visualizadores de los
diferentes video teléfonos 15 estén alineados uno al lado de otro,
como se muestra en la Figura 7. Un video teléfono 15 puede ser el
principal, y a medida que se añade cada video teléfono adicional, se
convierte en esclavo para el video teléfono 15 principal, el cual
controla el visualizador 54 de las imágenes grandes y pequeñas a
través de los diferentes video teléfonos 15.
En términos de los protocolos para determinar
quién es mostrado como una imagen grande y quién es mostrado como
una imagen pequeña en los visualizadores de los video teléfonos 15
de la conferencia, un protocolo preferido es que los tres hablantes
más recientes sean visualizados en grande, y los otros participantes
se muestren en pequeño. Esto es, el participante que está hablando
actualmente y los dos hablantes previos se muestran en grande.
Puesto que cada video teléfono 15 de la conferencia recibe todos los
flujos basados en audio de la conferencia, cada video teléfono 15
con su controlador principal 50 puede determinar dónde está teniendo
lugar la conversación en un momento dado y hace que la tarjeta de
interfaz de red 56 acepte el flujo de MPEG-2
asociado con el video teléfono 15 desde el cual tiene lugar la
conversación, y no acepte el flujo de velocidad de trama baja
asociado. En otro protocolo, un video teléfono 15 es establecido
como el teléfono 15 director o moderador, y el video teléfono 15
director recoge lo que todos los demás video teléfonos 15 ven en
términos de imágenes en grande y en pequeño. En otro protocolo más,
la elección de las imágenes sobre quién es grande y quién es
pequeña está fijada y permanece igual durante toda la conferencia.
El protocolo puede ser que cada video teléfono 15 pueda recoger
cómo quiere que se visualicen las imágenes recibidas. Tanto el flujo
basado en MPEG-2 como el flujo de velocidad de
trama baja son transmitidos en la red 40 a los video teléfonos
receptores de la conferencia. De acuerdo con esto, ambos flujos
basados en video están disponibles para cada video teléfono 15
receptor para ser mostrados dependiendo del protocolo para el
visualizador 54 que es
elegido.
elegido.
Con respecto a los flujos basados en audio que
son transmitidos por cada video teléfono 15, para usar además de
manera efectiva el ancho de banda, y para asistir en el tratamiento
del audio disminuyendo las demandas de tratamiento situadas en
cualquier video teléfono 15 transmisor o video teléfono 15 receptor,
un flujo basado en audio puede sólo ser transmitido por un video
teléfono 15 cuando existe audio por encima de un umbral de
decibelios predeterminado en el video teléfono 15 transmisor.
Transmitiendo sólo flujos basados en audio que tienen un sonido
suficientemente fuerte, con la asunción de que el umbral sería
calibrado para ser cumplido o excedido está teniendo lugar la
conversación, esto no sólo elimina la necesidad de que el ruido
ambiente extraño tenga que ser enviado y recibido, lo que no
contribuye esencialmente en nada sino que utiliza ancho de banda,
pero asiste en elegir el flujo de MPEG-2 asociado
con la conversación puesto que sólo los flujos de audio que tienen
conversación están siendo recibidos.
Como se ha mencionado anteriormente, si un video
teléfono 15 dado desea ver su propia imagen que está siendo enviada
a los otros video teléfonos 15, entonces el flujo de velocidad de
trama baja que es formado por la FPGA 38 es enviado a una memoria
local en el video teléfono 15, pero sin ninguna compresión, como
sería el caso para el flujo de velocidad de trama baja que va a ser
organizado en paquetes y enviado a la red 40 desde el video
teléfono 15. Desde esta memoria local, el procesador principal con
software operará sobre ella y hará que sea visualizada como una
imagen pequeña en el visualizador 54.
Además, el video teléfono 15 proporciona el
control de qué flujos de audio o video que recibe de la red 40 van
a ser oídos o vistos. En situaciones en las que la conferencia tiene
más participantes de los que un usuario del video teléfono 15 desea
ver u oír, el usuario del video teléfono 15 puede elegir sólo ver u
oír a un subconjunto de los flujos de video o de audio que
comprende la conferencia total. Por ejemplo, en una conferencia de
100 participantes, el usuario elige ver a tres de los flujos de
video en imágenes grandes en la pantalla, y 20 de los flujos de
video como imágenes en pequeño, para un total de 23 imágenes de las
posibles 100 imágenes que podrían ser mostradas. El usuario del
video teléfono 15 elige que los tres hablantes que hablan más fuerte
aparezcan como imágenes en grande, y a continuación elige a través
de la pantalla táctil 74 de los participantes en la conferencia,
que están listados en una página de la pantalla táctil, que sean
visualizados también como imágenes en pequeño. Pueden elegirse
otros protocolos, tales como que las 20 imágenes que se muestran
como imágenes en pequeño puedan ser los últimos 20 hablantes en la
conferencia empezando desde que comenzó el tiempo de la conferencia
y cada participante hizo sus presentaciones. Controlando el número
de flujos de video mostrados, se aplica organización a la
conferencia y la utilización de los recursos del video teléfono 15
está mejor asignada.
Con respecto a las diferentes imágenes que se
muestran en la pantalla, puede asociarse una elección a cada
imagen. Por ejemplo, una imagen puede ser seleccionada por un
moderador de la conferencia, dos de las imágenes pueden basarse en
los últimos hablantes que hablan más fuerte en el momento real de la
conferencia, y las otras imágenes puede estar asociadas con una
persona que el usuario selecciona de entre todos los demás
participantes de la conferencia. De esta manera, cada participante
o usuario de la conferencia podría potencialmente ver una selección
de imágenes diferente de entre el número total de participantes en
la conferencia. El ancho de banda máximo que se necesita entonces
es para que un flujo de video que se envíe a la red, y cuatro flujos
de video se reciban de la red, independientemente del número de
participantes de la conferencia.
Con respecto a los flujos de audio, la
limitación puede situarse en el video teléfono 15, de que sólo se
elige oír los flujos de audio asociados con los tres hablantes que
hablan más fuerte, mientras que sus imágenes respectivas son
mostradas en la pantalla. El DSP 62 puede analizar los flujos de
audio que son recibidos, y permite que se reproduzcan sólo los tres
flujos de audio asociados con los hablantes que hablan más fuerte,
y al mismo tiempo, dirigiendo la interfaz de red 42 sólo a los
primeros flujos de video recibidos de las imágenes en grande
asociados con los tres flujos de audio que tienen los hablantes que
hablan más fuerte. En general, cuantas más personas estén hablando
al mismo tiempo, más confusión existe y se entiende menos. Así, se
llevan a cabo controles por el usuario sobre los flujos de audio
para introducir algún nivel de organización en ellos.
Como parte de los controles con respecto a los
flujos de audio, como se ha mencionado anteriormente, cada video
teléfono 15 enviará sólo un flujo de audio si el ruido cerca del
video teléfono 15 está por encima de un umbral. Preferiblemente, el
umbral es dinámico y está basado en el nivel de ruido de los tres
flujos de audio más fuertes asociados con los tres hablantes que
hablan más fuerte en un momento dado. Ocurre esto, puesto que para
que el flujo de audio se considere como uno de los flujos de audio
con los tres hablantes que hablan más fuerte, el nivel de ruido de
otros flujos de audio debe ser monitorizado e identificado con
respecto a su nivel de ruido. El DSP 62 a la recepción de los flujos
de audio desde la interfaz de red 42 a través de la red 40, revisa
los flujos de audio e identifica los tres flujos que tienen el ruido
más fuerte, y también compara el nivel de ruido de los tres flujos
de audio recibidos que han sido identificados con los tres
hablantes que hablan más fuerte con el nivel de ruido de la escena
cerca del video teléfono 15. Si el nivel de ruido de la escena
cerca del video teléfono 15 es mayor que cualquiera de los flujos de
audio recibidos, entonces el video teléfono 15 envía sus flujos de
audio a la red 40. Este tipo de análisis independiente realizado
por el DSP 62 tiene lugar en cada uno de los video teléfonos de la
conferencia, y es de este modo un análisis que se distribuye a
través de toda la conferencia. Cada video teléfono,
independientemente de los demás video teléfonos, hace su propio
análisis con respecto a los flujos de audio que recibe, que por
definición sólo han sido transmitidos por el video teléfono 15
respectivo después de que el video teléfono 15 respectivo ha
determinado que el ruido cerca de su escena sea suficientemente
fuerte para garantizar que en un momento dado es uno de los tres
más fuertes. Cada video teléfono 15 toma entonces esta información
del flujo de audio recibida y la utiliza como base para una
comparación de su propio nivel de ruido. Cada video teléfono 15 está
de este modo haciendo su propia determinación de umbral.
Una manera alternativa de llevar a cabo este
análisis distribuido es que cada video teléfono, después de
determinar lo que él cree que es el umbral que debe haber con su
DSP 62, pueda enviar este umbral a todos los demás video teléfonos
de la conferencia, de manera que todos los demás video teléfonos
puedan revisar lo que todos los demás video teléfonos consideran
que es el umbral, y pueda, por ejemplo, promediar los umbrales, para
identificar un umbral que aplicará a su escena.
Usando la técnica de elegir los flujos de video
de los tres hablantes que hablan más fuerte, puede haber momentos
en los que los participantes empiezan a hablar alto todos a la vez,
y crean confusión e incapacidad para que se entienda, pero haciendo
esto se eleva el ruido en el nivel de umbral, lo que provoca que muy
rápidamente se eliminen los flujos de audio que no están
produciendo tanto ruido como los demás, de manera que sólo los
flujos de audio de los tres hablantes mayores serán de nuevo
elegidos y serán oídos, no siendo los demás elegidos, y eliminando
de este modo algo del ruido al que los otros flujos de audio podrían
estar contribuyendo. Esto implica que puede haber momentos en los
que más de tres flujos de audio están siendo recibidos por el video
teléfono 15 puesto que más de tres video teléfonos pueden tener un
nivel de ruido por encima del umbral en un momento dado,
permitiendo que cada uno de tales video teléfonos produzca un flujo
de audio en ese momento y lo envíe a la red 40. No obstante, como
se acaba de explicar, una vez que se cambia el umbral, la situación
parará. Este análisis distribuido con respecto a los flujos de
audio, no está limitado al video teléfono 15 descrito aquí sino que
es aplicable también a cualquier tipo de audio conferencia, tanto si
existen flujos de video como si no.
De acuerdo con el énfasis en conservar el uso de
ancho de banda, y para enviar sólo lo necesario para conservar el
ancho de banda, el recorte de una imagen tiene lugar en el
codificador 36 en lugar de en el video teléfono 15 receptor. En los
casos en los que el transmisor del video teléfono 15 no sabe cómo
aparecerá su imagen en los video teléfonos 15 receptores, el
codificador 36 recorta la imagen grande de la escena antes de que
sea transmitida, así que hay mucha menos imagen para transmitir y
utilizar ancho de banda. Si el recorte va a tener lugar en el
receptor del video teléfono 15, entonces el principal procesador con
software operará en la imagen recibida antes de que sea
proporcionada al controlador de visualización 52.
Una segunda cámara puede ser conectada al video
teléfono 15 para proporcionar una vista alternativa de la escena.
Por ejemplo, en una habitación, la primera cámara, o cámara
primaria, puede estar dispuesta para enfocar la cara del espectador
o del hablante. No obstante, puede haber individuos adicionales en
la habitación que la persona que controla el video teléfono 15 en
la habitación desea mostrar a los otros espectadores en los video
teléfonos 15 receptores. La segunda cámara, por ejemplo, puede estar
dispuesta en una esquina superior de la habitación de manera que la
segunda cámara puede ver esencialmente una porción mucho mayor de la
habitación que la cámara primaria. La alimentación de la segunda
cámara puede ser proporcionada al descodificador 34. El
descodificador 34 tiene varios puertos para recibir alimentaciones
de video. Alternativamente, si el flujo de la segunda cámara está
ya digitalizado, puede ser proporcionado a los elementos de
tratamiento del video teléfono 15 a través de canales similares a
los de la cámara primaria. Preferiblemente, cada video teléfono 15
controla cualquier cosa que sea transmitida desde él, así que la
elección de qué alimentación de cámara va a ser transmitida es
decidida por el espectador que controla el video teléfono 15.
Alternativamente es posible proporcionar al video teléfono 15
receptor remoto la posibilidad de controlar y elegir qué flujo de
qué cámara de un video teléfono 15 dado va a ser transmitido. Las
señales de control desde el video teléfono de control 15 se
transmitirían sobre la red 40 y serían recibidas por el video
teléfono 15 respectivo que proporcionará entonces el flujo elegido
para su transmisión. Además de una segunda cámara, algunos otros
tipos de alimentación de video pueden ser también proporcionados a
través del video teléfono 15, tal como la alimentación de video
desde un DVD, VCR o cámara de panel electrónico.
En una realización preferida, el video teléfono
15 opera en modo de pico. En el modo de pico, la cámara del video
teléfono 15 toma una imagen fija de la escena delante de ella y
transmite esta imagen a otros video teléfonos 15 que han sido
identificados previamente para recibirla, tal como en una lista de
los video teléfonos 15 en su menú de marcación rápida.
Alternativamente, en el modo de pico, la imagen fija que es tomada
se mantiene en el video teléfono 15 y es proporcionada a petición
de cualquiera que está mirando para llamar a ese video teléfono 15.
Idealmente, de acuerdo con el uso del video teléfono 15, cada
usuario de video teléfono 15 controla cualquier cosa que se
transmite desde el video teléfono 15, y puede simplemente elegir
desconectar el modo de pico, o controlar qué imagen es enviada.
Cuando tiene lugar una llamada activa, el modo de pico es
desconectado de manera que no hay ningún conflicto entre el modo de
pico y la llamada activa en la cual un flujo de imagen continuo es
tomado por la cámara. El modo de pico puede hacer que la imagen fija
de la escena sea tomada a intervalos de tiempo predeterminados, por
ejemplo con incrementos de un minuto, incrementos de cinco minutos,
incrementos de 30 minutos, etc. En el modo de pico, en un momento
predeterminado antes de que la imagen fija sea tomada, tal como
cinco o diez segundos antes de que la imagen sea tomada, puede
presentarse una cola audible para alertar a cualquiera que esté
delante de la cámara de que una imagen está a punto de ser tomada y
de que debe estar presentable. La cola audible puede ser un bip, un
ping u otro ruido o mensaje grabado. De esta manera, cuando se usa
el modo de pico, un pico en la escena delante de la cámara del video
teléfono 15 se hace disponible para otros video teléfonos 15 y
proporciona una indicación de la presencia de personas delante de
la cámara para los otros video teléfonos 15.
Como otro ejemplo de un sensor de presencia, la
situación de la lente automática de la cámara en frente del campo
delante de ella puede actuar como un sensor de presencia. Cuando
nadie está delante de la cámara, entonces la lente automática de la
cámara enfocará a un objeto o pared que está en su campo. Cuando una
persona está delante de la cámara, la lente automática enfocará a
esa persona, lo que hará que la lente esté en una posición
diferente de cuando la persona no está delante de la lente. Una
señal de la cámara indicativa del foco de la lente puede ser
enviada desde la cámara a la FPGA 38 que entonces hará que la
información del foco que va a ser enviada a una lista de video
teléfonos 15 receptores predeterminada, tal como los de la lista de
marcación rápida del video teléfono 15 transmisor, informe a los
video teléfonos receptores 15 sobre si el espectador está delante
del video teléfono 15 para indicar que alguien está presente.
El video teléfono 15 proporciona también video
correo. En el caso de que una video llamada sea intentada desde un
video teléfono 15 a otro video teléfono 15, y que el video teléfono
15 receptor no responda a la video llamada después de un tiempo
predeterminado, por ejemplo 4 llamadas, entonces un servidor de
video 66 asociado con el video teléfono 15 receptor responderá a la
video llamada. El servidor de vídeo 66 responderá a la video
llamada desde el video teléfono 15 transmisor y enviará al video
teléfono 15 transmisor un mensaje de audio grabado, o un mensaje de
audio con una imagen de video grabada desde el video teléfono 15
receptor que no respondió, que ha sido grabado previamente. El
servidor de vídeo 66 interpretará el mensaje y proporcionará una
cola de audio o una cola de audio y video al llamante para dejar su
mensaje después de una indicación predeterminada, tal como un bip.
Cuando la indicación predeterminada ocurre, el llamante dejará
entonces un mensaje que incluirá una frase de audio así como una
imagen de video del llamante. El mensaje de video y de audio será
almacenado en la memoria en el servidor de vídeo 66. El mensaje
puede ser tan largo como se desee, o estar limitado a un período de
tiempo predeterminado para que se defina el mensaje. Después de que
el período de tiempo predeterminado ha pasado, o de que el llamante
ha terminado de hablar y ha cortado la llamada, el servidor de
vídeo 66 guarda el mensaje de video, y envía una señal al video
teléfono 15 receptor que no respondió a la llamada original, de que
hay un mensaje de video esperando para el espectador del video
teléfono 15 receptor. Este mensaje puede ser un texto o una imagen
de video que aparece en el visualizador 54 del video teléfono 15
receptor, o es simplemente una luz de mensaje que es activada para
alertar al espectador del video teléfono 15 receptor de que hay un
video correo para el espectador.
Cuando el espectador desea ver el video correo,
el espectador puede elegir en la pantalla táctil 74 el área para
activar el video correo. Al usuario se le presenta una variedad de
opciones de manejo de correo, que incluyen lectura de video correo,
que envía una señal al servidor de vídeo 66 con el fin de
interpretar el video correo para el espectador del visualizador 54
del video teléfono 15. El flujo de imagen que es enviado desde el
servidor de vídeo 66 sigue la ruta explicada anteriormente para los
flujos basados en video y a través del video teléfono 15 receptor
para ser mostrados. Para que el espectador del video teléfono 15
grabe un mensaje en el servidor de vídeo 66 para responder a las
llamadas de video cuando el espectador no responde a las llamadas
de video, el espectador toca un área en la pantalla táctil 74 lo que
activa el servidor de vídeo 66 para instar al espectador a que
grabe un mensaje bien de audio o de audio y video, en un momento
predeterminado, lo que el espectador realiza, para crear el
mensaje.
El video teléfono 15 proporciona operación de
los altavoces 64 a un nivel predeterminado sin ningún control de
volumen por el usuario. Los altavoces 64 del video teléfono 15
pueden estar calibrados con el micrófono de manera que si el
micrófono está recogiendo ruido que es demasiado fuerte, entonces el
controlador principal 50 y el DSP 62 disminuye el nivel de salida
de audio de los altavoces 64 para disminuir el nivel de ruido.
Estableciendo un nivel predeterminado y deseable, el video teléfono
15 automáticamente controla la elevación del volumen sin que el
espectador tenga que hacer nada.
El video teléfono 15 puede ser programado para
reconocer una pregunta para hacerle a una persona específica, y
usar entonces el patrón de conversación predeterminado que se usa
para el reconocimiento como el tono o señal en el video teléfono 15
receptor con el fin de informar al espectador en el video teléfono
15 receptor de que una llamada está siendo solicitada con el video
teléfono 15 receptor. Por ejemplo, el término "Hola Craig"
puede ser usado para que el video teléfono 15 reconozca que se va a
iniciar una llamada para Craig con el video teléfono 15 transmisor.
El espectador, diciendo "Hola Craig" hace que el video teléfono
transmisor inicie automáticamente una llamada a Craig que a
continuación envía el término "Hola Craig" al video teléfono
15 receptor de Craig. En lugar de que al video teléfono 15 receptor
de Craig se le solicite un timbrazo para indicar una llamada a
Craig, el término "Hola Craig" es anunciado en el video
teléfono 15 de Craig intermitentemente en lugar del timbrazo que
ocurriría normalmente para obtener la atención de Craig. La
funcionalidad para llevar a cabo esta operación sería ejecutada por
el controlador principal 50 y por el DSP 62. La frase "Hola
Craig" sería anunciada por el espectador y transmitida, como se
ha explicado anteriormente, al servidor 66. El servidor 66, al
analizar las frases, reconocería el término como una orden para
iniciar una llamada al participante nombrado de la orden. El
servidor 66 utilizaría entonces la información sobre la dirección
del video teléfono 15 de Craig para iniciar la llamada con el video
teléfono 15 de Craig, y hacer que la señal o tono que se produce en
el video teléfono 15 de Craig sea "Hola Craig".
Como es bien conocido en el sector, el
codificador 36 es incapaz de identificar el inicio y el final de
cada trama. Cuando el codificador 36 recibe los datos, codifica los
datos para una trama y almacena los datos hasta que la trama está
completa. Debido al algoritmo que utiliza el codificador 36, la
trama almacenada se usa como base para formar la siguiente trama.
La trama almacenada actúa como una trama de referencia para la
siguiente trama que va a ser codificada. Esencialmente esto es
porque los cambios a la trama desde una trama a la siguiente son el
foco para la codificación, y no toda la trama desde el principio. La
trama codificada es entonces enviada directamente para su
organización en paquetes, como se ha explicado anteriormente, sin
ningún almacenamiento en memoria temporal, excepto para propósitos
de organización en paquetes, con el fin de minimizar cualquier
retardo. Alternativamente, como el codificador 36 codifica los datos
para la trama, con el fin de acelerar también incluso la
transmisión de los datos, los datos codificados son ordenados para
propósitos de organización en paquetes sin esperar que toda la trama
sea codificada. Los datos que son codificados también son
almacenados con vistas a formar la trama, por las razones explicadas
anteriormente, de manera que una trama de referencia está
disponible para el codificador 36. No obstante, separadamente, los
datos a medida que son codificados son enviados para el propósito
de su organización en paquetes y se conforman en una trama mientras
se prepara también para su organización en paquetes, aunque si el
paquete está listo para su transmisión y sucede así, sólo una
porción de la trama se ha hecho parte del paquete, la porción de la
trama restante será transmitida con un paquete separado, y la trama
no será formada hasta que ambos paquetes con la información de la
trama sean recibidos en el video teléfono 15 receptor.
En referencia a la Figura 1, varios video
teléfonos 15 están conectados a la red 40. Los video teléfonos 15
soportan 10/100 conexiones de ethernet y opcionalmente conexiones de
ATM a 155 Mbps, bien de cobre o de Fibra Multimodo. Cada terminal
de video teléfono 15 está normalmente asociado con un PC 68 de
usuarios. La función del video teléfono 15 es proporcionar aspectos
de audio y de Video de una (conferencia) llamada. El PC 68 se usa
para cualesquiera otras funciones. Estableciendo una llamada por
medio del video teléfono 15 puede automáticamente establecerse una
sesión de Microsoft Netmeeting entre PCs 68 asociados de manera que
los usuarios pueden colaborar en programas basados en Windows, por
ejemplo, una presentación de Power Point, o una hoja de cálculo,
intercambiar gráficos en un panel electrónico, transferir ficheros,
o usar un programa de tertulia basado en texto, etc. El PC 68 puede
ser conectado a Ethernet independientemente de cómo esté conectado
el terminal de video teléfono 15. Puede, por supuesto, ser
conectado también a una ATM LAN. El PC 68 y el video teléfono 15
transmisor asociado se comunican entre ellos a través de la red 40.
El PC 68 y el video teléfono 15 transmisor asociado se comunican
entre ellos de manera que el PC 68 sabe con quién está hablando el
video teléfono 15 transmisor. El PC 68 puede entonces comunicarse
con el PC 68 del video teléfono 15 receptor con quien el video
teléfono 15 transmisor está hablando. El PC 68 puede también hacer
una llamada al video teléfono 15.
La mayoría de las funcionalidades del sistema 10
están basadas en un servidor, y se ejecutan sobre un software del
Servidor de Proximidad del video teléfono 15, el cual es
preferiblemente un Servidor de Proximidad de SIP. Se necesita un
servidor 66 para proporcionar una funcionalidad básica, se requiere
un segundo para una operación flexible, es decir la preservación de
servicios en el caso de que un servidor 66 falle. El Software en
los servidores y en el terminal de video teléfono 15 cambiará
automáticamente al servidor 66 de reserva en este caso. Con esta
configuración, los terminales de video teléfono 15 pueden hacer o
recibir llamadas a cualesquiera otros terminales de video
teléfono 15 de la red 40 y a cualesquiera teléfonos, que sean preferiblemente teléfonos de SIP, registrados en la red.
teléfono 15 de la red 40 y a cualesquiera teléfonos, que sean preferiblemente teléfonos de SIP, registrados en la red.
Los Servidores de Medios de Comunicación
proporcionan un conjunto de servicios a los usuarios en un conjunto
de flujos de comunicación. El servidor 66 de medios de comunicación
está controlado por un servidor 66 de servicios (preferiblemente un
servidor se servicios 66). Se emplea proporcionar fuentes y
receptores para flujos de comunicación como parte de varias
funciones de usuario invocable. Los servicios proporcionados en el
servidor de medios de comunicación 66 son:
Establecimiento de Puente de Conferencia
Grabación y Reproducción
Transcodificación
Tonos y anuncios.
El servidor de medios de comunicación 66 es una
caja que se asienta en la LAN o en la WAN. En general, no tiene
ninguna otra conexión con él. Es preferiblemente un dispositivo de
SIP. Los servidores de servicios están en la ruta de señalización
desde los terminales de video teléfono 15. La ruta de comunicación,
no obstante, iría directamente desde el servidor de medios de
comunicación 66 al aparato.
En operación, el usuario puede solicitar una
función, tal como video-correo. El servidor de
servicios 66 proporcionaría la interfaz de usuario y la función de
señalización, el servidor de medios de comunicación 66
proporcionaría mecanismos para indicaciones de multimedios (si se
usan) y la grabación y reproducción de mensajes.
Para permitir que un terminal de video teléfono
15 haga o acepte llamadas a cualquier teléfono sin protocolo o
estándar (tal como SIP) (video), se añade una pasarela 70, tal como
una pasarela de SIP. Una pasarela 70 de cuatro líneas analógicas
puede ser conectada bien directamente a las líneas de PSTN, o
analógicas de la PBX local. Las reglas normales para proporcionar
líneas salientes son aplicables. Típicamente se proporciona una
línea de conferencia para cada seis usuarios, es decir se asume que
cualquier usuario utiliza su teléfono para marcar una conexión
externa 10 minutos cada hora. Si el terminal de video teléfono 15 va
a actuar como una extensión en una PBX actual por lo que se refiere
a llamadas entrantes entonces se necesita una línea analógica para
cada video teléfono 15.
Fuentes de TV, tales como CNN, están disponibles
para el usuario del video teléfono 15. El servidor de vídeo 66 del
video teléfono 15 permite este servicio. El Servidor 66 soporta la
conexión de un único canal de Video que es entonces accesible por
cualquier usuario de video teléfono 15 de la red 40. El canal de
Video es el equivalente a dos sesiones de conferencia normal. Un
sintonizador puede seleccionar el canal que está disponible. Debe
añadirse un nuevo servidor de vídeo 66 de video teléfono 15 a la
configuración para cada canal diferente que el cliente desea tener
disponible simultáneamente.
El servidor 66 del video teléfono 15
(preferiblemente de SIP) contiene también una base de datos para los
datos del usuario, que incluye una memoria local de la información
de contacto de los usuarios. Esta base de datos puede estar
sincronizada con la base de datos de contactos principal de los
usuarios. Puede utilizarse la sincronización, por ejemplo, con
usuarios de Outlook/Exchange y para usuarios de Lotus Notes. Un
programa separado se ejecutará en cualquier plataforma de servidor
66 basada en NT realiza la sincronización. Sólo se requiere un
servidor 66 independientemente del número de sitios servido.
Como se muestra en la Figura 2, normalmente los
terminales de video teléfono 15 serán distribuidos en varios
sitios, unidos por una red 40 de Área Extendida. Un servidor 66 es
suficiente para servir hasta 100+ video teléfonos 15 en un único
campus. A medida que el número total de video teléfonos 15 en un
sitio aumenta, en algún estado se necesita instalar más
servidores.
Con video teléfonos 15 distribuidos en varios
sitios, es posible que operen basándose en servidores centrales,
pero esta no es una configuración recomendada, debido al ancho de
banda de la WAN usado y a la dependencia de la WAN.
Preferiblemente, cada sitio tiene al menos un servidor 66, que es
preferiblemente un servidor 66 de SIP cuando se usa el SIP. Para
los más prudentes, la configuración más simple y más fácil es si
cada sitio tiene servidores duplicados, siendo cada uno de ellos
preferiblemente servidores de SIP. No obstante usar un servidor 66
central como alternativa a los servidores de sitio remotos
funcionará también.
Los Video teléfonos 15 de cualquier lugar de la
red 40 pueden hacer llamadas salientes basadas en PSTN o en PBX
desde una única pasarela 70 central. No obstante, si existe la
necesidad de que el video teléfono 15 sea también una extensión en
una PBX local para aceptar llamadas entrantes entonces necesita
proporcionarse una pasarela 70 de PSTN a cada ubicación. Es
necesario que exista un puerto en la pasarela 70 para cada video
teléfono 15 en ese sitio.
Un servidor 66 de central de CNN puede
distribuir un canal de TV a cualquier video teléfono 15 de la red
40. No obstante, puede ser preferible incluir servidores
específicos de sitio que tomen ese ancho de banda en la WAN.
Un video teléfono 15 está disponible para
conectarse bien a una red 40 de 10/100 Ethernet o a una red 40 de
ATM a 155 Mbits/s (tanto con opciones de Fibra como de Cobre). Un
video teléfono 15 conectado a ATM utiliza un plano de control de IP
para establecer las direcciones de ATM de los puntos de extremo para
una llamada, y utiliza entonces señalización de ATM para establecer
el canal portador entre esos puntos de extremo. El canal portador
es establecido como un Switched Virtual Circuit (SVC - Circuito
Virtual Conmutado), con los requisitos de QoS completos
especificados.
Cada flujo de video está entre 2Mbps y 6Mbps
bidireccionales como se determina mediante la negociación de
ajustes y de ancho de banda. Como los medios de visualización pueden
mostrar más de un único flujo de video, el ancho de banda de la
conexión total requerida para cada video teléfono aumenta con el
número de participantes en la llamada. Transmitir el recorte de
extremo asegura que el máximo ancho de banda requerido es
aproximadamente 2,5 veces el ancho de banda del único flujo de
video que está en uso. Si hay varios video teléfonos 15 en un
sitio, la relación de teléfono normal entre usuarios y conferencias
aplicará a las sesiones de video teléfono 15. En otras palabras, se
espera que un usuario de video teléfono 15 hable por término medio
con otras dos personas en cada llamada, es decir dos flujos y usará
el video teléfono 15 por término medio 10 minutos cada hora. Para
la velocidad de codificación media de 3 Mbps, esto proporciona una
necesidad de ancho de banda de WAN de 6 Mbps que puede esperarse
que soporte hasta 6 usuarios.
Como se muestra en la Figura 3, el video
teléfono 15 opera en una red 40 de Ethernet "p" permitida,
cuando hay una baja densidad de terminales de video teléfono 15. El
sistema 10 de video teléfono 15 establecerá un SVC en la porción de
la red 40 de ATM que une los dos video teléfonos 15 entre sí, y hace
uso de la Ethernet "p" permitida para asegurar que se
proporciona una Calidad de Servicio suficiente en la parte de
Ethernet de la conexión.
Los elementos esenciales del sistema 10 de video
teléfono 15 se muestran en la Figura 4. Juntos crean herramientas
de colaboración de multimedios que mejoran enormemente la
posibilidad de interacción de equipos dispersos geográficamente.
Tales equipos son cada vez más comunes en casi todas las grandes
empresas, aunque las herramientas para ayudarlos a trabajar
efectiva y eficientemente han cambiado poco desde hace una década y
son en muchos aspectos insatisfactorios. El video teléfono 15
aborda los muchos problemas de los sistemas existentes de una
manera comprensiva con el fin de crear una mejora discontinua en la
colaboración remota. Mediante la nueva tecnología disponible se
permite una Calidad de Servicio diferenciada y la mezcla correcta de
funciones, que se hace utilizable mediante el desarrollo de una
excelente interfaz de usuario, y que está diseñada para ser
extensible usando una arquitectura basada en estándares.
Los flujos de audio y de video, como se ha
explicado anteriormente, son transmitidos desde el video teléfono
15 de origen hasta los video teléfonos 15 de finalización de la red
usando, por ejemplo, técnicas de SIP bien conocidas. Los mensajes
de SIP pueden ser encaminados a través de redes heterogéneas usando
técnicas de encaminamiento de IP. Es deseable para flujos de
comunicación en redes heterogéneas tener una ruta más directa.
Preferiblemente, en casos en los que el video teléfono 15 de origen
de una conferencia está conectado a una Ethernet, y un video
teléfono 15 de finalización de la conferencia está conectado a una
red de ATM, como se muestra en la Figura 15, tiene lugar el
siguiente direccionamiento de los paquetes que cruzan la red entre
los video teléfonos de origen y de finalización. El video teléfono
15 de origen envía un paquete a la Ethernet con la cual está en
comunicación con la dirección de IP del video teléfono. El paquete
alcanza una pasarela de origen 80 que conecta la Ethernet con la
red de ATM. En la pasarela 80 de origen, la dirección de IP del
video teléfono 15 de origen es salvada del paquete, y la pasarela
de origen 80 añade al paquete la dirección de ATM de la pasarela de
origen 80 y envía el paquete al video teléfono 15 de finalización.
Cuando el video teléfono 15 de finalización recibe el paquete,
almacena la dirección de ATM de la pasarela de origen 80 del
paquete, y devuelve a la pasarela de origen 80 un paquete de
retorno que indica que ha recibido el paquete, con la dirección de
ATM del video teléfono 15 de finalización. La pasarela 80 de origen,
cuando recibe el paquete de retorno salva la dirección de ATM del
video teléfono 15 de finalización y añade la dirección de IP de la
pasarela de origen 80 al paquete de retorno. El paquete de retorno
es enviado entonces desde la pasarela de origen 80 de vuelta al
video teléfono 15 de origen.
De esta manera, las direcciones específicas de
cada nodo crítico de la ruta global entre y con el video teléfono
15 de origen y el video teléfono 15 de finalización son conocidas
para cada nodo crítico de la ruta. Como mínimo, cada nodo de la
ruta conoce la dirección del siguiente nodo de la ruta, y si se
desea, pueden mantenerse direcciones adicionales con los
respectivos paquetes a medida que se mueven a lo largo de la ruta de
manera que cada nodo de la ruta sabe más con respecto a las
direcciones de los nodos críticos y a continuación al siguiente
nodo al que el paquete va. Esto es porque mientras el paquete se
mueve de nodo a nodo, y específicamente en el ejemplo, del video
teléfono 15 de origen a la pasarela 80 de origen, al video teléfono
15 de finalización y a continuación de nuevo a la pasarela de
origen 80 y después al video teléfono 15 de origen, cada nodo salva
la dirección crítica del nodo previo desde la cual de los
respectivos paquetes fue recibido, e introduce su propia dirección
relativa al tipo de red del cual el siguiente nodo forma parte.
Consecuentemente, todas las direcciones críticas que cada nodo
necesita para enviar el paquete al siguiente nodo son distribuidas a
través de la ruta.
Este ejemplo de transferir un paquete desde un
video teléfono 15 de origen de una Ethernet a un video teléfono 15
de finalización de una red de ATM también es aplicable para lo
contrario, donde el terminal o video teléfono 15 de origen está en
comunicación con una red de ATM y el video teléfono 15 de
finalización está en comunicación con una Ethernet.
De manera similar, la ruta puede implicar un
video teléfono 15 de origen en comunicación con una Ethernet y un
video teléfono 15 de finalización en comunicación con una Ethernet
donde existe una red de ATM atravesada por el paquete entre ellos,
como se muestra en la Figura 16. En tal caso, habría dos pasarelas
en cada borde donde hay una interfaz entre la Ethernet y la red de
ATM. Como se ha explicado anteriormente, el proceso implicaría
añadir un nodo adicional a la ruta, donde la pasarela de origen 80
introduce su propia dirección de ATM en el paquete y la envía a la
pasarela de finalización 82 que salva la dirección de ATM de la
pasarela de origen y añade la dirección de IP de la pasarela de
finalización al paquete, que envía a continuación al video teléfono
15 de finalización de la Ethernet. Con el paquete de retorno, ocurre
lo mismo al contrario, y cada pasarela salva la información de
dirección respectiva de la pasarela o video teléfono 15 de
finalización previos, y añade su propia dirección al paquete de
retorno que envía en último lugar al video teléfono 15 de origen,
salvando la pasarela de origen 80 y el video teléfono 15 de origen
la dirección de ATM de la pasarela de finalización 82 o la pasarela
80 de origen, respectivamente, de manera que las direcciones
respectivas en cada enlace de la ruta global son almacenadas para
enviar más eficiente y rápidamente subsiguientes paquetes de una
conexión.
Por ejemplo, el controlador principal 50 y la
interfaz de red 42 del video teléfono 15 pueden añadir la dirección
del video teléfono 15 a cada paquete que envía a la red 40 usando
las mismas técnicas que son bien conocidas para un experto, de
colocar información de encaminamiento de SIP (o cualquier
información de encaminamiento estándar que se use) con el paquete.
La interfaz de red 42 almacena también la información de la
dirección que recibe de un paquete de un nodo de la red en una
memoria local. De manera similar, para una pasarela de la red 40,
puede aplicarse lo mismo. Como es bien conocido, la pasarela tiene
medios de control y un medio de tratamiento de datos para mover un
paquete a su último destino. Una interfaz de red 42 y un controlador
principal 50 del mecanismo de control de la pasarela, que opera con
técnicas bien conocidas con respecto a la información de
encaminamiento de SIP, almacena información de la dirección recibida
de un paquete y coloca su propia información de la dirección
relativa a una red 40 a la cual se va a enviar el paquete, con el
paquete. Por ejemplo, la información de la dirección de la
pasarela, o el video teléfono 15, puede ser colocada en un campo
que está en la porción de cabecera asociada con el paquete. Debe
observarse, que mientras el ejemplo habla del uso de video
teléfonos 15 como fuentes de finalización o de origen, puede usarse
cualquier tipo de dispositivo que produce y recibe paquetes como
nodo en este esquema
global.
global.
El Virtual Presence Video-Phone
(Video Teléfono de Presencia Virtual) (video teléfono) 15 es una
aplicación de red 40 de sobremesa que es un terminal de
comunicaciones personal. Reemplaza el teléfono en el escritorio de
los usuarios, proporcionando todos los servicios de un terminal PBX
moderno con la simplicidad de la interfaz de usuario y facilidad de
uso permitidas por la gran pantalla táctil 74 de los video teléfonos
15.
El video teléfono 15 añade la dimensión del
video a todas las comunicaciones interpersonales, cambiando la
experiencia a la de la presencia virtual. En el pasado la calidad de
video en los sistemas de video conferencia no ha sido
suficientemente alta para que la tecnología fuese transparente. El
video teléfono 15 es el primer video teléfono personal en enviar
calidad de video suficientemente alta para crear la experiencia
correcta. Para una comunicación mediante video en tiempo real
efectiva la calidad de la imagen tiene que estar cerca de la
calidad de la emisión de TV, sino que debe mantenerse la latencia
muy baja. La Sincronización Labial también es importante para que
fluya una conversación natural. Todos estos asuntos deben ser
abordados en el diseño del subsistema del video teléfono 15. El
Video teléfono 15 utiliza la última tecnología de codificador 36 y
descodificador 34 configurada específicamente para esta aplicación.
En otras palabras, el video teléfono 15 llega lo más cerca posible
de "estar allí".
El video teléfono 15 mejora también enormemente
en el rendimiento de sonido del altavoz convencional a través del
uso de un canal de alta fidelidad, con calidad de audio cercana al
CD que proporciona una voz cristalina. Los canales de audio en
estéreo proporcionan una diferenciación espacial del audio de cada
uno de los participantes. La cancelación de eco de estéreo avanzada
cancela no sólo todo el sonido de los altavoces 64 de las unidades
sino que permite al hablante llevar a cabo una conversación a
niveles conversacionales normales, incluso cuando está en una
habitación ruidosa.
El video teléfono 15 soporta directamente el
establecimiento de llamadas de video conferencia de hasta 4 (es
decir 5 vías) participantes remotos y/o audio conferencias de hasta
10 participantes. Cada usuario tiene visibilidad de la
disponibilidad de todos los demás miembros de su grupo de trabajo.
El video teléfono 15 utiliza preferiblemente Session Initiation
Protocol (SIP - Protocolo de Iniciación de Sesión) como medio de
establecer, modificar y limpiar sesiones de
multi-medios de multi-flujo. El
video teléfono 15 puede establecer una llamada de audio a
cualesquiera otros teléfonos de SIP o a cualquier otro teléfono por
medio de una pasarela 70.
El video teléfono 15 sitúa altas demandas en la
red 40 a la cual está unido. Las llamadas de video de video
teléfono 15 demandan una red 40 que puede proporcionar un alto ancho
de banda continuo, con garantías en el ancho de banda, la latencia
y la fluctuación. Marconi plc se especializa en proporcionar redes
que soportan aplicaciones de alta Calidad de Servicio. También está
disponible una versión de video teléfono 15 para sala de
conferencias.
El video teléfono 15 es un terminal de
comunicaciones (plataforma) que tiene la posibilidad de integrar
completamente con el PC 68 de un usuario, la plataforma
informática. Una aplicación de video teléfono 15 para el PC 68
proporciona varios servicios de integración entre el PC 68 y el
terminal de video teléfono 15 asociado. Esto incluirá el
establecimiento automático de sesiones de NetMeeting entre los
participantes en una conferencia de video teléfono 15, si está
permitido de esta forma, con el propósito de compartir aplicaciones
tales como panel electrónico, o presentaciones, etc. incluyendo
otras capacidades el marcado mediante "arrastrar y soltar"
mediante el video teléfono 15 de un número en el PC 68.
Un conjunto de servidores, siendo cada uno de
ellos preferiblemente servidores de SIP, proporciona control de
llamada e implementación de servicios a las aplicaciones de la red
40. Éstos son servidores de software que se ejecutan en plataformas
informáticas estándar, capaces de redundancia. Estos servidores
ejecutan también una copia local de la base de datos de información
de contacto de los usuarios y de la base de datos de preferencias
de usuario. Las aplicaciones disponibles en estos servidores
proporcionan acceso a directorios corporativos u otros accesibles
mediante LDAP.
Un servidor 66 de sincronización mantiene la
sincronización entre la principal base de datos de contactos de
usuarios y la copia local en el servidor 66 (preferiblemente de
SIP). La sincronización de Outlook Exchange o Lotus Notes está
soportada. Un conjunto de Pasarelas de Medios de Comunicación 70 se
usan para la red 40 de PSTN analógica o digital. Un conjunto de
Pasarelas de Medios de Comunicación 70 se comunica mediante
interfaces con el equipo de PABX más común, incluyendo los sistemas
de correo por voz asociados con esas PABX's.
El servidor de medios de comunicación 66
proporciona varios servicios al terminal de video teléfono 15. Actúa
como un servidor 66 de Puente de Conferencia para video conferencia
entre 4 participantes, si se desea. También puede proporcionar
transcodificación entre los estándares de video teléfono 15 y otros
formatos de audio o video comunes, tales como H320/H323. Puede
proporcionar funciones de registro y reproducción, que permiten que
las sesiones sean registradas y reproducidas. Puede proporcionar la
fuente de tonos y anuncios.
Se requiere un Cortafuegos de acuerdo con el
estándar que se está usando, tal como un cortafuegos de SIP, para
pasar de manera segura los flujos de RTP creados dinámicamente bajo
el control de un software de proximidad estándar (tal como el
software de proximidad SIP). Un servidor 66 de TV actúa como una
fuente de distribución de TV, que permite que los usuarios del
video teléfono 15 selecciones cualquier canal soportado, por ejemplo
CNN.
El video teléfono 15 es para ordenadores de
sobremesa de Ethernet y ATM. El terminal de video teléfono 15
soportará ATM SVC's de extremo a extremo y los utiliza para
establecer conexiones con el nivel de Calidad de Servicio del
requisito. El video teléfono 15 soportará también capacidad de
conexión de IP por medio de servicios LANE. Para que esto garantice
la QoS requerida, se necesita LANE 2. El video teléfono 15
proporciona un paso de ATM hacia la ATM unida al PC 68 de
sobremesa, o un paso de ATM a Ethernet para conectar el PC 68 por
medio de Ethernet.
El video teléfono 15 requiere el soporte de la
QoS de extremo a extremo. Para un video teléfono 15 conectado a
Ethernet la conexión de usuario necesita soportar 802.1p, DiffServ
y/o IntServ o mejor. Si se puede alcanzar el destino por medio de
una red de ATM 40, se proporcionará una pasarela 70 de Ethernet a
ATM. El servidor 66 de proximidad de SIP y la señalización de SIP
establecerá el punto de extremo de ATM más cercano al terminal de
video teléfono 15 de destino, es decir su dirección de ATM si está
conectado con una ATM, o a la pasarela 70 de Ethernet a ATM que
esté más cerca. La señalización establecerá un SVC a través de la
porción de ATM de la red 40 con la QoS apropiada. Este SVC se
conectará con el flujo de Ethernet específico que genera la
indicación de prioridad adecuada en el extremo remoto.
La línea de producto del video teléfono 15
consiste en varios terminales de extremo (aparatos), un conjunto de
servidores que proporcionan servicios no incorporados en los
aparatos, y un conjunto de pasarelas 70 que conectan los productos
con instalaciones existentes y servicios de PSTN de exterior. La
funcionalidad básica proporcionada por el sistema 10 es:
- \equiv
-
\vtcortauna
- \equiv
-
\vtcortauna
- \equiv
-
\vtcortauna
- \equiv
-
\vtcortauna
- \equiv
-
\vtcortauna
\vskip1.000000\baselineskip
El video teléfono 15 es un teléfono con una
funcionalidad radicalmente nueva, sin que ningún ordenador intente
hacer lo que hace el teléfono. Esto permite un completo uso
concurrente de un ordenador para aquéllo en lo que es bueno,
mientras que proporciona un aparato flexible pero para una
aplicación específica para comunicación. La interfaz de usuario y
el diseño físico pueden ser ajustados para esta aplicación,
proporcionando un dispositivo de comunicaciones altamente fiable al
instante como los teléfonos actuales, algo que el PC 68 no será
nunca. Este planteamiento también proporciona control sobre el
entorno operativo del dispositivo, eliminando los problemas de
soporte relativos a los aspectos de configuración de hardware y
software del PC 68.
Estudios del factor humano han demostrado una y
otra vez que la calidad del audio es el único factor más importante
para una comunicación transparente, efectiva. Aunque se necesita un
auricular de mano, el audio de manos libres de excelente calidad
incluyendo Acoustic Echo Cancellation (AEC - Cancelación del Eco de
Audio), el Automatic Gain Control (AGC - Control de Ganancia
Automático), la posibilidad de audio de banda ancha (G.722 8 KHz de
ancho de banda o mejor), la salida estéreo, y la integración con la
salida de sonido del PC 68 proporcionan nuevos niveles de
colaboración remota efectiva. Una matriz de micrófonos de alta
calidad, diseñada y procesada para limitar los efectos de sonido
metálico está también presente.
\newpage
Se usa una plataforma completamente flexible,
intuitiva, limpia, simple para salida visual y entrada de
selección/botón. En el primer modelo de video teléfono, éste es una
pantalla en color completa de alta calidad de TFT, con pantalla de
16 por 9, diagonal de 17'' con resolución de 1260 x 768 o mejor,
superpuesta con panel táctil de larga vida de resolución media. Un
panel de matriz activo brillante (>200 nit), con ángulo de visión
extendida (>+-60º) es usado para visualizar un video de
movimiento total para visualidad de manera confortable en un
entorno de oficina. Pueden usarse pantallas más grandes, más
brillantes, más rápidas, de mayor contraste, y de mayor ángulo de
visualización.
El video teléfono 15 utiliza una LCD en color de
TFT, que tiene arquitectura del tipo de PC 68 con una interfaz de
visualizador 54 del tipo de VGA basada en un controlador de Intel
Celeron/440 MMX y un controlador de Lynx VGA.
Se usa una cámara de rastreo progresiva de 480
líneas digital de alta calidad para proporcionar 30 tramas por
segundo de un video de al menos 640x480. El video teléfono 15
utiliza codificación de MPEG2 que aprovecha la tecnología del
codificador de video 36 para equipos de sobremesa. Puede generarse
una variedad de velocidades de bits diferentes, que permiten que la
calidad del video se adapte a los recursos disponibles para llamadas
de uno a uno, y a la más alta calidad participante para llamadas de
uno o muchos a muchos. Un módulo de cámara de alta calidad
integrado es colocado cerca de la pantalla, proporcionándose una
entrada de video externa (Firewire) para permitir el uso de
cámaras, VCRs, u otras fuentes de video adicionales.
Una conexión de Ethernet de 10/100BaseT
existente con el ordenador de sobremesa es la única conexión
necesaria para la comunicación con la LAN, WAN, ordenador de
sobremesa PC 68, y varios servidores, servidores de proximidad, y
pasarelas 70. Flujos de RTP críticos con el tiempo para audio y
video son marcados con prioridad usando 802.1p, suministrando el
mecanismo dentro del dominio de Ethernet de la LAN para QoS.
DiffServ está también soportado, con RSVP opcionalmente. Con el fin
de eliminar la necesidad de cableado de edificio adicional hasta el
ordenador de sobremesa, el video teléfono 15 incluirá un pequeño
interruptor de Ethernet 10/100, que permite que el puerto del
ordenador de sobremesa existente se use tanto para el teléfono como
para el PC 68.
El video teléfono 15 también soporta una
interfaz de ATM. La interfaz está basada en usar la tarjeta de HE155
Mbits/s bien con una interfaz de fibra o bien de cobre. El video
teléfono 15 proporciona un puerto de paso de ATM para conectar con
un ordenador de sobremesa conectado a una ATM o para conectar un PC
68 conectado a una Ethernet con el video teléfono 15 conectado a la
ATM.
Los compromisos de coste y rendimiento para el
entorno de la sala de conferencias son obviamente diferentes de los
del ordenador de sobremesa. Proyección de video, múltiples cámaras
con Control Panorámico/Inclinación/Control de Tamaño remoto,
múltiples micrófonos, múltiples canales de video, paneles
electrónicos de retro proyección, y otros productos apropiados para
el entorno de la sala de conferencias están integrados en un video
teléfono 15 de una sala de conferencias. El trabajo conjunto del
entorno de la sala de conferencias y el ordenador de sobremesa es
fluido y transparente. Este entorno utilizará enormemente el equipo
de OEM que se comunica con la misma infraestructura y estándares
dispuestos para el ordenador de sobremesa. El diseño de hardware es
esencialmente el mismo, con soporte de audio adicional para
múltiples micrófonos, y soporte de video adicional para múltiples
cámaras y visualizadores. Alternativamente, puede usarse una
aplicación de PC 68, activada bien mediante ratón o mediante
pantalla táctil 74, si el PC 68 tiene una pantalla táctil 74, que se
conecta con un teléfono de SIP de bajo coste. Para aquellos
ordenadores de sobremesa y otros lugares que no requieren las
capacidades de colaboración descritas anteriormente, puede usarse un
teléfono estándar que trabaja con el sistema 10 sin requerir un
cableado adicional o una PBX.
Usando el estándar de SIP (sesión Initiation
Protocol - Protocolo de Iniciación de Sesión), los dispositivos
terminales son soportados por uno o más servidores que proporcionan
registro, ubicación, perfil de usuario, presencia, y varios
servicios de proximidad. Estos servidores son máquinas de Linux o
BSD baratas conectadas con la LAN.
El video teléfono 15 es el teléfono, así que
debe proporcionarse un conjunto clave de funciones de PBX,
incluyendo transferencia, emisión, realización de conferencia con 3
(y 4, 5, ...) participantes, llamante ID +, historial de llamadas,
etc. Algunos de estos servicios pueden estar incorporados en la
parte superior de un mecanismo de extensión de SIP llamado
"CPL", que es realmente un lenguaje para proporcionar manejo de
llamadas de una manera segura, extensible.
El video teléfono 15 proporciona presencia
activa y creación de mensaje instantáneo. Quizás la presencia de la
herramienta más revolucionaria para mejorar el trabajo en
colaboración con un grupo distribuido diario, permite a las
personas saber quién está dentro y qué están haciendo. Proporciona
la base para llamadas de muy baja información suplementaria,
eliminando la marca del teléfono y el marcado del número
tradicional, animando a los grupos a comunicarse como grupo en
lugar de hacerlo a través de las conversaciones de teléfono de uno
a uno separadas que son ahora comunes. La integración con Instant
Messaging (correo electrónico en tiempo real) proporciona una
manera sin retardo de intercambiar mensajes de texto cortos,
probablemente haciendo uso del teclado del PC 68 para
introducirlos.
El video teléfono 15 proporciona una
arquitectura distribuida/redundante. Este es el sistema 10 de
teléfono y debe ser fiable. Debe ser también capaz de ser manejado
centralmente con extensiones locales, con servidores distribuidos
que proporcionan una respuesta "instantánea" a todos los
usuarios. Cada una de las diferentes funciones de proximidad de
SIP, por ejemplo, si se usa el SIP, serán desplegadas de manera que
puedan ser combinadas arbitrariamente en un conjunto de servidores
físicos, con versiones redundantes situadas en la red 40.
Microsoft NetMeeting se usa para funcionalidad
de superficie compartida y aplicación compartida. Puede usarse
Computer/Telephony Interface (CTI) (Interfaz de Ordenador/Telefonía
para el PC 68 y la PDA, con servicios tales como listas de
contactos integradas, marcación automática de números de teléfono o
nombres seleccionados, registro de calendario de histórico de
llamadas, entrada de contactos automática, etc.
El SIP presenta retos para los cortafuegos
porque los flujos de RTP usan puertos UDP asignados dinámicamente,
y la información de dirección/puerto es transportada en mensajes de
SIP. Esto significa que el Cortafuegos tiene que seguir los
mensajes de SIP, y abrir "micro orificios" en el cortafuegos
para las combinaciones de dirección/puerto adecuadas. Además, si se
emplea NAT, los mensajes deben ser alterados para tener las
direcciones/puertos traducidos adecuados. Hay dos maneras de llevar
a cabo tal tarea. Una es construir la posibilidad en el cortafuegos.
Los 3 mayores vendedores de cortafuegos (Checkpoint, Network
Associates y Axxent) proporcionan esto. Una alternativa es tener un
cortafuegos especial que trata sólo con SIP en paralelo con el
cortafuegos principal. Hay versiones comerciales de tal
cortafuegos, por ejemplo, el de MicroAppliances. Debe observarse que
SIP o NetMeeting son realizaciones preferidas que están disponibles
para llevar a cabo su funcionalidad respectiva necesaria. Pueden
utilizarse alternativas a ellas, si se proporciona la funcionalidad
necesaria.
La Figura 5 muestra los principales componentes
físicos del terminal de video teléfono 15. El soporte proporciona
un medio de ajustar fácilmente la altura del panel del visualizador
54 principal y de fijar el panel a esa altura. El intervalo de
ajuste de altura va a ser al menos 6 pulgadas de recorrido para
adaptarse a las diferentes alturas de usuario. Se asume que el
soporte descansará sobre un escritorio y que las alturas del
ordenador de sobremesa están estandarizadas. El enlace entre el
soporte y la unidad principal debe proporcionar un grado limitado
de inclinación fuera de la vertical para adaptarse a la preferencia
del usuario y debe ser fácilmente bloqueado en ese ángulo. La
cantidad de inclinación que se necesita -0 + 15E desde la vertical.
La unidad principal puede montarse directamente en una pared sin la
necesidad del conjunto de soporte opcionalmente.
La maleta de la unidad principal proporciona el
alojamiento para todos los demás elementos del diseño del video
teléfono 15 incluyendo todos los mostrados en la Figura 5 y toda la
electrónica interna. La maleta proporciona el montaje a izquierdas
o a derechas del auricular. Las personas diestras tienden a
descolgar el micrófono con la mano izquierda (porque activarán la
pantalla táctil 74 y escribirán con la derecha) y las personas
zurdas al contrario. Aunque la colocación a izquierdas será la
normal, debe ser posible colocar el auricular en su sitio en la
derecha. Se proporciona una clavija de Altavoz en la maleta para
permitir que los altavoces 64 sean montados de manera remota desde
el video teléfono 15. Se proporcionan entradas para manejar las
salidas del altavoz desde el PC 68 asociado, de manera que el video
teléfono 15 puede controlar el audio del PC 68 y del video teléfono
15. Puede usarse la implementación de una conexión inalámbrica a los
altavoces 64 (por medio de Bluetooth, o por medio de los estándares
de SONY).
Se proporciona un auricular con la unidad y debe
conectarse usando un cable helicoidal RJ9 estándar y una clavija de
conectador. Cuando está colgado el auricular debe ser fácil de
descolgar sin ser muy grande. Una opción de auricular proporciona
un teclado estándar en el auricular. Puede usarse un auricular
inalámbrico para mejorar la movilidad del terminal usuario.
Se proporciona una clavija para la conexión de
unos auriculares + micrófono estereofónicos. El uso de auriculares
para conversaciones telefónicas normales está aumentando. El usuario
podrá elegir entre usar unos auriculares + micrófono montado en
brazo, o unos auriculares sólo, que emplean la matriz de micrófonos
como dispositivo de entrada. Hay una opción de unos auriculares
inalámbricos para mejorar la movilidad del terminal de usuario.
Se proporciona un puerto de IR para comunicar
las PDA's y otros dispositivos de IR, en una posición en la maleta
principal con el fin de permitir un fácil acceso. Por el momento las
interfaces de IR en los teléfonos y las PDA's son los más comunes y
por lo tanto por las mismas razones que se requiere una interfaz de
bluetooth se requiere también una interfaz de IR.
Un micrófono de matriz está incorporado en la
carcasa. La matriz no debe generar ruidos extraños como consecuencia
de la operación normal del terminal. Específicamente, no debe ser
posible detectar la acción de un usuario en el panel táctil. El
micrófono de matriz permite que el usuario hable en niveles de
conversación normales dentro de un arco (por ejemplo 6 pies)
alrededor de las unidades frontales y 110E en el plano horizontal y
en presencia de dbs predefinidos de ruido de ambiente. La unidad
debe proporcionar una indicación sin ambigüedad de que el micrófono
está activo/no activo, es decir el equivalente de "colgado" o
"descolgado". Un usuario de video teléfono 15 querrá seguridad
de que no está siendo escuchado sin su conocimiento. Este es el
equivalente de audio del disparador de la cámara mecánico.
La unidad de video teléfono 15 principal puede
tener una opción de lector de tarjeta inteligente para proporcionar
un acceso seguro al terminal para servicios personales. El acceso al
video teléfono 15 necesitará una matriz de servicios de control de
acceso, desde una simple entrada de clave en la pantalla, hasta
fob's de seguridad. Un lector de tarjeta inteligente proporciona
uno de estos métodos de acceso.
Existe claramente una ventaja si la inclinación
y el control panorámico son controlables desde la pantalla, y
preferiblemente, si el Control panorámico y la Inclinación son sólo
electrónicos y no necesitan mecanismos mecánicos. El soporte de la
cámara debe ser montado lo más cerca posible de la parte superior de
la pantalla principal con el fin de mejorar el contacto visual.
La cámara debe ser una cámara digital 47 capaz
de generar 480p salidas. La salida de la cámara alimenta a un
codificador 36 de MPEG-2. debe ser posible
configurar dinámicamente la cámara de manera que la salida de la
cámara esté optimizada para alimentar al codificador 36 a la
velocidad de salida de datos del codificador 36 elegida. La mayoría
de las entradas que la cámara recibirá son caras, y por lo tanto la
captura exacta en un amplio intervalo de condiciones de iluminación
del tono de la piel es una característica esencial.
La cámara debe operarse en un amplio intervalo
de condiciones de iluminación hasta un valor de 3 lux. La cámara
debe proporcionar equilibrio de blanco automático. Los cambios en el
equilibrio de blanco deben ser lentos, de manera que los
transitorios de la imagen capturada no causen una perturbación
indebida de la imagen. Sólo los cambios que duren más de 5 segundos
deben cambiar el balance de blancos. La cámara debe enfocar desde
18 pulgadas a 10 pies, es decir tener una gran profundidad de campo
y deseablemente enfocar a 20 pies. Tanto el usuario como la
información si existe en su panel electrónico necesitan estar
enfocadas. El Auto-enfoque, en el que la cámara
trata de encontrar el mejor enfoque de manera continua a medida que
el usuario se mueve, produce una imagen distorsionada en el extremo
receptor y debe evitarse.
La cámara debe permitir una capacidad de
acercamiento o alejamiento limitada, desde una situación en la que
un usuario está directamente delante de la cámara, a otra situación
en la que unos pocos usuarios están simultáneamente en un video
teléfono 15. Como alternativa, pueden proporcionarse diferentes
lentes Esto puede especificarse en términos de campo de visión de
la lente, por ejemplo desde un campo de visión de 30E hasta un campo
de visión de
75E.
75E.
La cámara debe ser capaz de recoger una imagen
más grande de la que se necesita para su transmisión, por ejemplo
una imagen de 1280 x 960. Esto permitiría un control de tamaño y un
control panorámico horizontal y vertical limitado electrónicamente,
eliminando la necesidad de controles
electro-mecánicos asociados con la cámara. La
cámara debe ser físicamente pequeña, de manera que un fácil montaje
"en-la pantalla" no sea eliminado simplemente
por el tamaño de la cámara.
Un panel táctil de vida útil larga de resolución
media forma el método de comunicación primario con el video
teléfono 15 y forma el frente del visualizador 54 principal. El
panel recibirá mucho contacto de dedos y por lo tanto debe soportar
una limpieza frecuente para eliminar manchas y otras huellas de
dedos que de otro modo afectarían a la calidad del visualizador 54.
Debe ser sencillo calibrar el panel táctil, es decir asegurar que
el alineamiento entre el área tocada en el panel táctil y el
visualizador 54 que está debajo cumpla el requisito de "falso
toque".
La superficie de la pantalla táctil 74 debe
minimizar los reflejos en la superficie de manera que el
visualizador 54 esté claro incluso cuando esté en frente de una
ventana. El requisito es que los "falsos toques" sean casos
raros. El requisito de resolución en el panel táctil es por lo tanto
fuertemente dependiente del área táctil más pequeña del
visualizador 54 que está tratando de distinguir. La resolución y el
error de paralaje combinados deben ser tales que la posibilidad de
un "falso toque" debido a estos factores para el usuario
entrenado medio sea menor de 5%. (Un falso toque en 20
selecciones). Es deseable que esta tasa de falsos toques sea menor
de 2%, es decir un falso toque en 50 selecciones.
Cuando sea apropiado, debe proporcionársele al
usuario información audible y o visible de un toque correcto. Estos
tonos pueden variar dependiendo de lo que está en el visualizador 54
de la pantalla táctil 74 en cada momento. Por ejemplo cuando se usa
un teclado, sonidos de tipo teclado son apropiados, cuando se usa un
teclado de marcación son relevantes diferentes sonidos y así
sucesivamente. Una información audible puede no ser necesaria en
cualquier circunstancia, aunque normalmente alguna indicación
audible o visible de un toque correcto resulta de ayuda para el
usuario. Debe ser posible que el usuario sea capaz de poner o quitar
los tonos y de elegir los tonos, duración del tono y nivel de
volumen asociado con el toque en alguna pantalla de ajustes. Deben
proporcionarse valores por defecto. La pantalla táctil 74 puede
usarse también con un bolígrafo al igual que con el dedo.
El panel del visualizador 54 debe ser un panel
plano de al menos 17'' de diagonal (o mejor) tecnología de
visualizador 54 a todo color con una relación de aspecto preferida
de 16 x 9 pero siendo aceptable una relación de aspecto de 16 x
10.
La resolución de pantalla debe ser al menos 1280
x 768. El ángulo visible debe ser al menos 6E con respecto al eje
tanto en el plano horizontal como en el vertical. La relación de
contraste de pantalla debe ser mejor que 300:1 típicamente. La
resolución del color debe ser al menos 6 bits por color, es decir
capaz de visualizar 262K colores de 6 bits por color es aceptable
para las unidades del prototipo. Se prefiere 8 bits por color,
permaneciendo el resto constante, para las unidades de producción.
El panel del visualizador 54 debe tener un brillo suficientemente
alto para que se vea cómodamente incluso en una habitación bien
iluminada o con luz natural. El brillo debe ser al menos
300cd/m<2>. El visualizador 54 y la electrónica de
descodificación deben ser capaces de mostrar imágenes de alta
resolución de 720P de fuentes de tales imágenes apropiadas de la
red 40.
La retro iluminación tendrá una vida mínima de
50% del brillo mínimo de al menos 25000 horas. Si la retro
iluminación es apagada debido a inactividad en el terminal de video
teléfono 15, entonces debe encenderse automáticamente si hay una
llamada entrante y cuando el usuario toca en cualquier lugar de la
pantalla táctil. El período de inactividad después del cual la
pantalla táctil es apagada debe ser ajustable por el usuario, hasta
el "no apagar".
Las conexiones requeridas en el área de conexión
del video teléfono 15 son como se muestra en la figura 6. Cada
requisito de conectador se describirá brevemente en los párrafos que
siguen.
Dos conectadores de Ethernet RJ 45 10/100 son
para la conexión a la red 40 y desde el PC 68 asociado.
Se proporcionará un enchufe opcional en el
módulo de personalidad de ATM que permite al video teléfono 15
soportar fácilmente interfaces de 155 Mbits/s tanto para interfaces
ópticos como de cobre.
Se proporcionará un puerto de USB para permitir
que se conecten fácilmente varios equipos periféricos opcionales,
por ejemplo un teclado, un ratón, una cámara de bajo coste, etc.
Debe proporcionarse una interfaz 1394
(Cortafuegos) para permitir la conexión a cámaras externas
(firewire) o a otras fuentes de video. La interfaz debe permitir un
completo control de la cámara dentro del intervalo sobre la
interfaz del cortafuegos. Donde sea necesario deben usarse
convertidores externos para convertir por ejemplo de
S-Video a entrada de firewire. Debe ser posible usar
esta fuente en lugar de la fuente de cámara principal en la salida
del video teléfono 15 a la conferencia. Debe ser posible también
especificar un modo normal o "CNN" es decir recortable o no
recortable en esta fuente de video. Debe proporcionarse una salida
de video XVGA para permitir que el video teléfono 15 active
proyectores externos con una imagen que refleje la mostrada en el
visualizador 54
principal.
principal.
Debe proporcionarse una entrada de audio por
cada salida de PCAudio. Para asegurar la integración del audio del
PC 68 y del audio del video teléfono 15, sólo se utilizará un
conjunto de altavoces 64. El sonido del PC 68 pasará a través del
canal de audio del video teléfono 15. Se proporcionará una clavija o
un par de clavijas para conectar a unos auriculares y a un
micrófono de brazo unido a ellos. Debe ser posible también la
operación sólo de auriculares, usando la matriz de micrófonos
incorporada. Si la clavija de los auriculares es relativamente
inaccesible, debe ser posible dejar los auriculares conectados, y
seleccionar por medio de un control de usuario si hay audio en los
auriculares o no. Se proporcionan conexiones a los altavoces 64
externos de la izquierda y de la derecha. Es posible usar una, dos
o tres unidades de video teléfono 15 como si fueran una única unidad
funcional, como se ilustra en la figura 7.
En configuraciones de más de un video teléfono
15, sólo una unidad actúa como panel de control principal, la otra
o las otras unidad o unidades muestran video y los controles
directamente asociados con el video que se está mostrando. Sólo se
necesita un conjunto de altavoces 64 para cualquiera de estas
configuraciones.
Se proporcionarán varias opciones por lo que
respecta a las entradas de micrófono y a los flujos de audio, desde
usar una única entrada de micrófono común, hasta transmitir el audio
desde cada matriz de micrófonos a las fuentes del video de ese
video teléfono 15.
Se proporcionarán varias opciones para entradas
de Video. La opción por defecto será transmitir la vista del video
teléfono 15 con panel de control'. Si está disponible más ancho de
banda entonces cada usuario puede obtener el Video desde la
pantalla en la cual se visualiza el usuario, lo que produce un
resultado más natural. Una completa coordinación de los múltiples
terminales de video teléfono 15 puede ser alcanzada mediante la
conexión de LAN, es decir sin necesidad de ningún cableado especial
entre unidades.
El video teléfono 15 del video teléfono
proporciona a su usuario varias funciones principales:
- \quad
- - Es el teléfono de oficina
- \quad
- - Es el teléfono de los usuarios
- \quad
- - Es un video teléfono
- \quad
- - Es un teléfono para conferencias
- \quad
- - Es un teléfono de video conferencia
- \quad
- - Proporciona un fácil acceso a y una gestión de los detalles de contacto
- \quad
- - Proporciona un acceso y una gestión del correo de voz/video
\vskip1.000000\baselineskip
Las unidades se dividen funcionalmente en dos
categorías, funciones de usuario y funciones de sistemas.
Las funciones de usuario son cualquier función a
la cual tendrá acceso el usuario.
Las funciones de sistema 10 son las requeridas
por la I.T. para ajustar el monitor y mantener el terminal de video
teléfono 15 y que son invisibles para el usuario normal. Desde
luego, un objetivo importante del diseño global es asegurar que al
usuario se le presenta una interfaz muy simple en la cual puede usar
el video teléfono 15 virtualmente sin ningún aprendizaje.
Lo siguiente define el conjunto de servicios
básicos que es el mínimo conjunto de servicios que deben estar
disponibles.
El video teléfono 15 del video teléfono actúa
como un teléfono convencional cuando ningún usuario es grabado en
el terminal. Su funcionalidad no debe depender en absoluto de que
haya un PC 68 asociado.
Lo siguiente describe la funcionalidad de video
teléfono 15 como un teléfono convencional en una oficina.
El terminal es capaz de tener un número de
extensión convencional en la PABX que sirve al sitio.
El terminal es capaz de aceptar una llamada
entrante desde cualquier teléfono, si está en la PABX, en el la red
40 del video teléfono 15 o en cualquier teléfono externo sin
discriminación.
El video teléfono 15 es capaz de aceptar
llamadas desde otros teléfonos de SIP compatibles.
Una llamada entrante generará un tono de llamada
como esté configurado (véanse los requisitos de ajuste de pantalla
a continuación). Específicamente, el tono de llamada para llamadas
de video teléfono 15 que incluye Video tendrá una opción para una
llamada distintiva de las llamadas sólo de audio, procedan de
terminales de video teléfono 15 o no.
Una llamada entrante generará una indicación de
llamada entrante en el área de estado en el visualizador 54. Este
visualizador 54 debe proporcionar tanta información de ID del
Llamante como la proporcionada por la llamada entrante, o indicar
que no hay ninguna disponible.
Es posible aceptar la llamada entrante:
- a)
- Pulsando el botón de aceptación de llamada en el visualizador 54 de estado de llamada entrante.
- b)
- Descolgando el auricular - que aceptará siempre todas las opciones ofrecidas es decir video y audio.
Es posible que el usuario conmute fácilmente
entre operación de teléfono de mano y manos libres (teléfono de
altavoz) dentro de una llamada. Descolgar el auricular dentro de una
llamada conmutará automáticamente al modo de teléfono de mano desde
el modo de teléfono de altavoz. Colgar el auricular sin seleccionar
de nuevo el modo de teléfono de altavoz desconectará la
llamada.
Debe proporcionarse en una pantalla una
indicación del modo, es decir teléfono de mano o manos libres.
La barra de estado de la llamada puede mostrar
la duración de la llamada.
Es posible ajustar el volumen de la llamada
entrante mediante controles disponibles directamente en el
visualizador 54 principal. Los volúmenes de los auriculares y del
altavoz deben ser ajustables de manera independiente.
Cuando se está en modo de teléfono en altavoz,
es posible colocar de nuevo el auricular en el soporte de auricular
sin desconectar la llamada.
Una llamada es finalizada:
- \textdollar
- Si el usuario pulsa el botón de finalización de llamada en el visualizador 54 de estado de llamada.
- \textdollar
- Si el usuario recoloca el auricular cuando está en modo de auricular y el modo de manos libres no está seleccionado.
- \textdollar
- \textdollar Si los participantes remotos cuelgan la llamada siempre que se indique de manera fiable en el video teléfono 15.
RETENER- Debe ser posible poner una llamada EN
ESPERA y recuperar de nuevo la llamada EN ESPERA. El estado de EN
ESPERA debe ser mostrado en el visualizador 54 de estado, con un
botón que permita que la llamada mantenida sea recuperada.
Llamada EN ESPERA - Llamadas entrantes
adicionales deben generar una indicación de llamada entrante en el
área de estado del visualizador 54. No debe generar un tono de
llamada, a menos que esté permitido en el menú de ajustes.
Es posible aceptar una nueva llamada entrante en
el modo de operación actual, es decir de auricular o de manos
libres, desde el botón de aceptación de llamada en el visualizador
54 de estado.
Aceptar otra llamada entrante pondrá
automáticamente las llamadas actuales EN ESPERA.
Pulsar el botón de "cancelar retener" en
cualquier llamada debe transferir automáticamente cualquiera de las
otras llamadas al estado EN ESPERA.
El número de llamadas entrantes simultáneas que
puede ser manejado es establecido por la disponibilidad de espacio
en el visualizador 54 de estado. No debe ser menos de dos
llamadas.
Cuando el número de llamadas actuales excede el
número que puede ser manejado, cualquiera de las otras llamadas
entrantes:
- a)
- Obtienen un tono de ocupado o
- b)
- Son inmediatamente desviadas a un correo de voz
- c)
- Son inmediatamente desviadas al número de desviación configurado
- d)
- Se les envía un mensaje grabado.
\vskip1.000000\baselineskip
Según está determinado por los ajustes de los
usuarios "desviación de llamada ocupada".
Si las llamadas entrantes que están dentro del
límite aceptable no son contestadas dentro de un intervalo
(configurable), las llamadas son:
- a)
- desviadas a un correo de voz
- b)
- desviadas al número de desviación configurado
- c)
- se les envía un mensaje grabado.
\vskip1.000000\baselineskip
Según lo determinado por los ajustes de llamada
desviada del usuario "llamada desviada sin respuesta".
TRANSFERENCIA DE LLAMADA - Es posible que el
usuario transfiera fácilmente cualquier llamada a cualesquiera
otros números. La función de transferencia pondrá la llamada EN
ESPERA y permitirá que se marque un nuevo número. Una vez que se
oye el tono de llamada, el usuario tendrá la opción de completar la
transferencia. Alternativamente, el usuario podrá hablar con el
nuevo número y a continuación iniciar la transferencia o primero
juntar a todos (tres) los participantes en una conferencia. En el
último caso, se proporcionará una función para que el usuario salga
de la conferencia. En el caso de que no haya respuesta o sólo un
correo de voz desde el terminal llamado, el usuario tendrá la
opción de volver a la llamada original.
DESVIACIÓN DE LLAMADA - Debe ser posible ajustar
el teléfono para que desvíe automáticamente las llamadas entrantes
a un número pre-configurado. La desviación de
llamada puede ser:
- a)
- incondicional
- b)
- desviar en ocupado
- c)
- desviar en No Respuesta
\vskip1.000000\baselineskip
MULTI CONFERENCIAS - Es posible llevar a cabo
multi conferencia en una conferencia sólo de audio,
independientemente del origen de la llamada de voz. Es posible
llevar a cabo una conferencia entre al menos 3 llamadas, es decir
una conversación de cuatro-vías. Se requiere
soportar sólo una única conferencia en cada momento, pero pudiendo
aceptar otra llamada entrante como se describe en la llamada en
espera anterior. Es aceptable que el prototipo sólo pueda aceptar
una llamada entrante para una conferencia particular, es decir se
necesitará un puente externo para llamadas sin video teléfono.
Las opciones asociadas con el visualizador 54 de
estado de llamada entrante permitirán al usuario añadir o eliminar
una llamada de una conexión de la conferencia.
Es posible añadir llamadas a una conferencia
independientemente de si son llamadas entrantes o salientes.
Si el usuario de conferencia remoto cuelga, esa
parte de la llamada debe ser eliminada automáticamente.
Las llamadas pueden hacerse de manos libres o
mientras se utiliza el auricular de mano. Descolgar el auricular
debe presentar el dispositivo de marcación si no está en una llamada
y conectar el audio con el auricular. Se requiere un dispositivo de
marcación de tono en la pantalla (es decir números 1 a 0 más
"*" y "#"). Además, debe haber un botón de pausa para
insertar una pausa en una sucesión de números marcada (para pasar a
través de PABXs a menos que la pasarela o pasarelas 70 pueda o
puedan ser programada o programadas para eliminar este requisito).
Debe tenerse en consideración añadir una tecla de + y disponer que
el signo + sea traducido automáticamente en una sucesión de números
de acceso internacional para esa posición.
Se requiere también una tecla para corregir
errores de entrada (por ejemplo tecla de [VOLVER] y una tecla para
borrar la entrada. Una pulsación corta del [VOLVER] debe eliminar el
último número introducido, una pulsación más larga continúa
eliminando números, una pulsación mantenida eliminará el registro
del número.
Al visualizador 54 del número debe aplicársele
automáticamente un formato igual al formato del número local. [Esto
puede requerir un ajuste de usuario para seleccionar el país de
operación puesto que cada país tiene un estilo diferente o si se
introduce un código internacional ese código debe usarse como base
de aplicación de formato a la restante parte del número].
Cuando se conecta a servicios que hacen uso del
dispositivo de número de tono para seleccionar servicios, deben
generarse los tonos correctos en la dirección de ese servicio,
cuando se usa el dispositivo de marcación de la pantalla o el
dispositivo de marcación del auricular. El dispositivo de marcación
debe ser capaz de proporcionar esta función independientemente de
cómo se inicie la llamada.
REMARCACIÓN - Es posible remarcar el último
número marcado mediante un único toque en una función identificada
apropiada.
REMARCACIÓN AUTOMÁTICA - Es posible activar un
mecanismo de remarcación automática, por ejemplo manteniendo
pulsado el botón de [REMARCACIÓN]. La remarcación automática
repetirá automáticamente la llamada si los intentos previos
devuelven una señal de ocupado en varios intentos.
ESPERA EN CASO DE OCUPADO - Cuando se hace una
llamada a un dispositivo que permite su soporte, está disponible
una función de "Espera en caso de ocupado". La función de
espera en caso de ocupado devuelve la llamada al usuario una vez
que el participante llamado está disponible. Se generará un mensaje
para decir "este servicio no está disponible" si el número
llamado no puede soportar el servicio de Espera en caso de
ocupado.
Puede haber un registro apropiado en la pantalla
que se muestra cuando ningún usuario es introducido en el video
teléfono 15.
Un registro de llamadas frecuentes y perdidas
entrantes y salientes debe ser mostrado en una vista apropiada de
las pantallas de marcación integradas. Una o dos funciones de
teclas de acceso a "remarcación del último número" deben estar
siempre disponibles en las pantallas de marcación. Otras
definiciones de estos registros se proporcionan a continuación.
Para acceder a todo el conjunto de servicios
disponibles en el terminal de video teléfono 15, un usuario debe
registrarse en el terminal. Se proporciona una pantalla de entrada
en la cual el usuario puede introducir su nombre y clave. Pueden
ser los mismos que su nombre y clave de acceso a la red 40 normales.
El terminal de video teléfono 15 utilizará por lo tanto los
servicios de validación de usuario de los sitios. Cualquier
pantalla que se necesite para permitir que el personal de IT
configure el video teléfono 15 para usar estos servicios de
validación debe ser proporcionada. Existen métodos alternativos de
identificar al usuario, por ejemplo, el uso de una tarjeta
inteligente o ID fob. No hay ningún requisito de que el usuario ya
esté registrado en un PC 68 antes de registrarse en un terminal de
video teléfono 15.
Múltiples usuarios puede estar registrados en un
único video teléfono 15 y pueden proporcionarse tonos de llamada
entrante diferentes para cada usuario. La indicación de llamada
entrante debe también identificar el nombre de los participantes
llamados así como el nombre de los participantes llamantes. Si
múltiples usuarios están registrados en un único video teléfono 15,
todas las funciones de envío de llamada son específicas para el
usuario al cual está dirigida la llamada.
Si el usuario ya está registrado en su PC 68, la
acción de registrarse en el video teléfono 15 creará una asociación
entre el PC 68 en el que el usuario estaba registrado y el terminal
de video teléfono 15 con tal de que éste sea confirmado desde el PC
68. Es posible que un usuario se registre en múltiples terminales de
video teléfono 15 simultáneamente. El video teléfono 15 activo es
aquél en el cual cualquier llamada para ese usuario es contestada
primero.
La pantalla de la página principal contiene un
área de estado que es visible en todas las pantallas (excepto en el
modo de pantalla completa). El estado incluye el nombre del usuario
registrado- o "ningún usuario registrado". El estado de
"Presencia" de Usuario, iconiza para la transmisión de video y
de audio, un correo de Voz con la indicación "Mensaje" y la
fecha y la hora.
Una indicación de "mensaje" se enciende y
parpadea si hay un correo de voz no oído en el sistema 10 del correo
de voz del usuario. Pulsando el indicador aparece la ventana de
manejo del Correo de voz.
Tocando el área de tiempo de Fecha se da acceso
a las funciones de Calendario.
La página de inicio tiene un área de barra de
control que es visible a través de todas las pantallas (excepto en
el modo de pantalla completa).
La barra de control proporciona un acceso
directo a los servicios de control de llamada usados más
frecuentemente y acceso a todas las demás funciones. Deben usarse
iconos en los botones, pero también puede usarse texto para
enfatizar el propósito funcional.
El panel de control también tiene controles
globales para el micrófono, la Cámara y los Altavoces 64. Los
controles deben indicar claramente su estado operacional, por
ejemplo ENCENDIDO o APAGADO y donde sea posible deben usarse
Iconos.
Está disponible una auto-imagen
que indica tanto la imagen que está siendo tomada por la cámara como
la porción que es visible para el estreno remoto de la llamada
activa. Es posible encender y apagar la auto-imagen
y determinar si siempre está encendido o sólo una vez que la
llamada activa ha sido establecida.
Es posible visualizar la imagen de la cámara en
el área de video principal de la pantalla en cualquier momento, es
decir en una llamada, no en una llamada, etc. La imagen debe ser la
de una sola llamada de Video y debe superponerse a cualquiera de
los otros videos presentes. Debe ser posible solicitar una versión
de pantalla completa de ese video. Esto puede pensarse como un
espejo digital y permite al usuario o usuaria asegurarse de que
está satisfecho o satisfecha con lo que la cámara mostrará o está
mostrando.
Es deseable para propósitos de diagnosis que el
usuario puede también ver la imagen después de la codificación y la
descodificación, de manera que es consciente de la calidad de la
imagen que se verá en el otro extremo. Si este modo es soportado
entonces tanto la cámara directa como la imagen codificada
descodificada una al lado de otra. El usuario puede capturar su
propia imagen, para su uso como imagen asociada con su información
de contacto.
La mayor parte de la pantalla de Inicio está
asignada a funciones de Marcación Integrada. Hay cuatro
sub-funciones principales, un visualizador 54
marcación rápida, un visualizador 54 de acceso a directorios, un
dispositivo de marcación y acceso a registros de llamadas. El
dispositivo de marcación y el acceso a los registros de llamadas
van a ocupar la mínima área de pantalla compatible con la facilidad
de uso, maximizando el área disponible para la Marcación
Rápida/páginas de Contactos. El área de marcación rápida está
detallada primero, cualesquiera otros requisitos comunes en todas
las principales sub-funciones sólo son detalladas
bajo marcación rápida y son implicadas para las otras tres
funciones. La función del área de Marcación es seleccionar un
usuario a quien se le va a hacer una llamada.
El área de marcación rápida es lo más grande
posible, consistente con los otros requisitos para la pantalla de
marcación. >20 lugares de marcación rápida son adecuados. Cada
lugar debe ser suficientemente grande para hacer que la
identificación de las personas detalladas almacenada en ese lugar
sea legible muy fácilmente a la distancia de operación normal desde
la pantalla, por ejemplo 3 pies.
La información de usuario almacenada en un lugar
de marcación rápida incluye el nombre de las personas, "estado de
presencia" si se conoce, el número al que se llama si se
selecciona la marcación rápida y un icono para indicar si el
usuario soporta llamadas de video. La información detallada también
almacena qué clase de video es, por ejemplo video teléfono 15,
compatible con MPEG2, H261 etc.
El área proporciona un área clara para tocar con
el fin de iniciar una llamada. Se incluye una vista en miniatura de
la persona si está disponible. Se proporciona un método de manejar
nombres largos (es decir nombres que no caben en el espacio
asignado en el botón de marcación rápida).
Números de teléfono convencionales en formato
internacional estándar es decir. "+ área de código del país
número de código" son traducidos automáticamente al acceso
externo más los códigos de acceso internacionales que se necesitan
para hacer una llamada a este número.
Todos los detalles de contacto asociados con una
persona en la página de marcación rápida están disponibles. Los
detalles de contacto proporcionan todos los números en los cuales el
usuario puede ser localizado y un medio de seleccionar uno de los
números como el número por defecto que se usa en la página de
marcación rápida. Es posible seleccionar y marcar un número
alternativo para ese usuario por medio de este enlace a la página
de contactos.
La información de Usuario incluye la historia de
las llamadas más recientes a esa persona, por ejemplo las últimas
10 llamadas bien sean entrantes, perdidas o salientes. Proporcionar
sólo la información de la "última llamada" podría ser una
funcionalidad mínima aceptable.
Es posible editar los detalles de contacto
asociados con la entrada de marcación rápida y o crear una nueva
entrada de contacto en la página de Marcación Rápida. Es posible
copiar una entrada de las pantallas de contactos, agendas o
registros de llamadas en la página de Marcación Rápida. Es posible
copiar una entrada desde la página de Marcación Rápida a las
pantallas de contactos o de Agenda. Es posible borrar una entrada de
Marcación Rápida, o mover esa entrada a otra página de contactos.
(es decir copiar y a continuación borrar el original).
Es posible controlar la colocación de los
usuarios en la página de Marcación Rápida. Debe ser también posible
de alguna manera (codificación de color) distinguir entre diferentes
clases de usuarios de Marcación Rápida, es decir trabajo, familia,
amigos, suministradores, clientes. La página de marcación rápida
page puede fácilmente contener nombres de otras múltiples
categorías en la información de los contactos. Alguna forma de
organización automática está disponible, por ejemplo, último nombre
primer nombre empresa o por clase seguido de último nombre primer
nombre empresa etc.
Es posible definir un grupo de usuarios como una
única entrada de marcación rápida. Es aceptable si el tamaño del
grupo está limitado al tamaño de la máxima conferencia. Es posible
seleccionar la vista de las Agendas desde la página de Marcación
Rápida. Las Agendas ocuparán la misma área de pantalla que la página
de Marcación Rápida. Es posible seleccionar del intervalo de
agendas en línea a qué video teléfono 15 tener acceso. La opción
por defecto será la agenda de Outlook y o la de Lotus Notes que
contiene los detalles de contacto principales de los usuarios. El
nombre de la agenda seleccionada debe visualizarse.
Las categorías establecidas por el usuario en su
lista de contactos de Outlook o Notes está disponible como
selecciones. Si el número de categorías no cabe en el área del
visualizador 54, se proporcionan botones para desplazar la lista
hacia arriba o hacia abajo. La lista debe estar organizada
alfabéticamente.
La categoría de Marcación Rápida es la categoría
usada para rellenar la página de Marcación Rápida. Hay alguna
indicación de cuándo la página de Marcación Rápida está llena y ya
no es posible añadir más nombres a esta categoría de contactos, a
menos que sustituyan a alguna entrada existente. La posibilidad de
ordenar las entradas de Marcación Rápida en orden de la llamada más
reciente, es decir la entrada de Marcación Rápida menos usada
estaría al final. Esto se usaría para ver qué entrada era la mejor
candidata para borrado con el fin de permitir que entre un número
más usado.
Es posible encontrar y seleccionar fácilmente
una entrada de la categoría seleccionada, con la mínima entrada por
parte del usuario. Los mecanismos de selección de entrada deben
trabajar para listas relativamente cortas y para listas muy largas
(decenas de miles de nombres). Los mecanismos deben incluir la
posibilidad de introducir una secuencia de texto en la cual buscar.
Es posible seleccionar el orden de clasificación para los datos
presentados, por último nombre, primer nombre u organización. Existe
un método de corregir errores de entrada, y empezar de nuevo la
búsqueda completa rápidamente.
Sería deseable que cada orden de búsqueda de las
claves de búsqueda fuese significativa y pudiese ser cambiada por
el usuario. En otras palabras por ejemplo pulsar y mantener la tecla
de búsqueda de más a la izquierda permite al usuario seleccionar
para buscar en Último Nombre, primer Nombre o Empresa (o una lista
extendida de atributos. Esto es útil por ejemplo para encontrar a
alguien en un departamento particular, o en una situación
particular - "quién está en Korea"). La segunda clave califica
entonces la búsqueda de la primera clave y así sucesivamente. De
este modo, las claves son establecidas Empresa, Último Nombre Primer
Nombre; por ejemplo Marconi, a continuación hacer una búsqueda de
usuario alfabética dentro de los últimos nombres en Marconi.
Claramente cuando cada categoría de clasificación es seleccionada
hay alguna sub-ordenación de entradas implicada con
el mismo valor en ese campo de categoría. Así que para el último
nombre seleccionado, el sub-orden implicado es
primer nombre y a continuación empresa, para empresa el orden de
clasificación implicado es último nombre primer nombre, y para
primer nombre, por ejemplo último nombre empresa.
La pantalla de registro de llamadas visualiza
las entradas más recientes de tres categorías de llamadas, llamadas
salientes, entrantes, y perdidas, con una clara indicación de qué
categoría es seleccionada. Además debería haber una categoría
"frecuente", que liste los números por la frecuencia de uso,
sobre las últimas (<200) llamadas de cualquier tipo. Debería
haber acceso al Dispositivo de Marcación desde la pantalla de
registro de llamadas. El análisis del valor de proporcionar un
grado de manejo de los datos del registro de llamadas es
pospuesto.
Como mínimo, cuando se toca el "mensaje" se
establece una conexión con el sistema 10 de correo de voz de los
usuarios, el correo de voz para este usuario es introducido y el
dispositivo de marcación es mostrado para controlar el correo de
voz usando las pulsaciones de teclas del teléfono convencionales. La
parte más grande de la pantalla del "correo de voz" debe
presentar botones para acceder a cada servicio del sistema 10 de
correo, por ejemplo Mensaje Siguiente, Mensaje Previo, Reproducir
Mensaje, Transmitir Mensaje, Responder a Mensaje, emisor de
llamada, etc. con todas las equivalencias de pulsaciones de teclas
dentro de cada función, por ejemplo iniciar grabación, detener
grabación, volver a ver grabación, borrar grabación, etc. Todas las
funciones necesitan estar en botones, convertidos en los tonos de
DMF respectivos.
Es deseable que el número de "Enviar a" o
cualquier orden de correo de voz que requiera que se introduzca una
lista de números de usuarios pueda ser seleccionado desde las vistas
de Marcación Rápida o Agenda y que la selección inserte
automáticamente sólo la parte apropiada del número del usuario. Esto
podría ser particularmente útil para enviar un mensaje de voz a un
grupo. Es posible que el usuario establezca el tiempo y fecha en el
video teléfono 15. Es deseable que el tiempo y fecha puedan ser
establecidos automáticamente mediante servicios de la red 40
adecuados.
adecuados.
\newpage
Es deseable que la funcionalidad de Calendario
esté disponible que esté integrada con la aplicación de
Outlook/Palm/Planificación de Notas/Calendario de los usuarios. El
requisito mínimo sería ver las citas en cualquier fecha, por día,
semana o mes (de acuerdo con las pantallas de Outlook o Palm) siendo
los cambios y nuevas entradas posibles sólo por medio de la base de
datos Outlook o Palm.
Es probable que relativamente pocos usuarios no
mantengan sus propios calendarios y desde luego pueden NO tener PCs
68 en su escritorio, pero necesitan ver la información. Tocar el
área de Estado del Usuario de la parte de estado de la pantalla
permite al usuario establecer su estado. El usuario tendrá un
intervalo de opciones de Estado de las que elegir, que incluye:
- i)
- Disponible
- ii)
- Ocupado - está en una llamada en la que otra llamada no será aceptada
- iii)
- No molestar - no está en una llamada pero no puede ser interrumpido
- iv)
- De vuelta en cinco minutos
- v)
- Fuera de la oficina
- vi)
- De Vacaciones
Un solo caso de llamada en el terminal de video
teléfono 15 soporta desde un flujo entrante hasta el máximo número
de flujos en una conferencia. Para establecer una Video conferencia,
el Terminal soportará al menos cuatro conexiones con otros
participantes como parte de una sola conferencia. Es posible aceptar
al menos dos llamadas sólo de audio independientes, incluso cuando
existe un tamaño máximo de video conferencia, de manera que una
llamada de audio puede ser transferida mediante retención de
consulta. El video teléfono 15 es capaz de soportar al menos tres
"casos de llamada" simultáneos, es decir hasta tres llamadas
independientes. Sólo una llamada puede estar activa, es decir los
controles de llamada pueden ser aplicados sólo para una llamada
cada vez. Puede aceptarse más de una llamada, es decir se están
transmitiendo el audio y el video de los usuario en cada llamada
aceptada, esté activa o no. Llamadas en progreso pueden ser también
dispuestas EN ESPERA, cuando el audio y el video de los usuarios no
se está transmitiendo al usuario EN ESPERA y el audio y el video de
ese usuario es también suprimido.
El estado de las llamadas entrantes es mostrado
en el área de de Control del visualizador 54. Las propias llamadas
y los controles de en-llamada son mostrados en la
sección principal del visualizador 54.
Los estados de la llamada son:
- i)
- Llamada entrante
- ii)
- Aceptada y activa - el audio del usuario (y el video si es una video llamada) están, sujetos a los diferentes controles en silencio, conectados a esta llamada. Los controles de llamada se aplican a esta llamada.
- iii)
- Aceptada y no activa - como anteriormente, pero los controles de llamada no se aplican a esta llamada.
- iv)
- Aceptada y en espera - el audio de los usuarios (y el video si es una video llamada) no están siendo transmitidos a esta llamada.
- v)
- Aceptada y siendo transferida
Los estados de llamada son indicados en cada
llamada. Sólo una llamada aceptada puede estar activa. Una llamada
aceptada se hace activa tocando el área de llamada del visualizador
54 asociada con esa llamada, o el estado de la llamada en el panel
de control. Cualquier llamada activa previa se pone en no activa. Un
segundo toque desconectará el estado activo. Una indicación de
llamada entrante indica si la llamada está ofreciendo una conexión
de video. Ninguna indicación implica una llamada sólo de audio. La
indicación de llamada entrante mostrará el nombre o los nombres de
los participantes asociados con esa llamada entrante. Esto muestra
inmediatamente si el usuario está siendo llamado en modo de uno a
uno, o está siendo invitado a unirse a una conferencia.
El usuario tiene las siguientes opciones de
manejar una llamada entrante:
- i)
- Aceptar la llamada como una llamada sólo de voz
- ii)
- Aceptar la llamada como una video llamada (implica voz)
- iii)
- Enviar al correo de voz
\newpage
Un ajuste está disponible para ajustar el
terminal de video teléfono 15 para llamadas entrantes de respuestas
automáticas, hasta el número máximo de llamadas soportadas. La
respuesta automática crea una conexión de audio y de video si se
ofrece una. Una vez que una llamada está en progreso, el estado de
los Usuarios debe cambiar automáticamente a "En una llamada".
El estado de los Usuarios volverá a su estado previo (típicamente
"Disponible") una vez que no hay llamadas activas.
El usuario es capaz de configurar si los datos
de usuario de llamada están también distribuidos. Si el usuario ya
ha aceptado una o más llamadas y si todas las llamadas están EN
ESPERA o no activas, esta llamada creará un nuevo caso de llamada,
si se acepta. Todas las llamadas aceptadas pero no activas
continuarán viendo y oyendo al usuario mientras trata con esta
nueva llamada. Si una de las llamadas aceptadas está aceptada y
activa, la nueva llamada se unirá a esa llamada y todos los
participantes en la llamada serán puestos en conferencia con el
nuevo llamante, si la llamada es aceptada.
Si el usuario no descuelga después (>10)
segundos, la llamada será desviada automáticamente de acuerdo con
los ajustes de "Desviación si No hay Respuesta". Como
anteriormente la desviación es específica para el usuario a quien
está dirigida la llamada. Si el estado de los usuarios está marcado
como "No Molestar" u "Ocupado" o el estado "Ocupado"
ha sido establecido porque se está manejando el número máximo de
llamadas, la llamada es desviada "inmediatamente" de acuerdo
con los ajustes de "Desviar si está Ocupado" y "Desviar si
está en No Molestar", de acuerdo con la modificación por el
ajuste "mostrar llamadas desviadas" si está implementado.
Dependiendo de los ajustes de "mostrar
llamadas desviadas", el usuario puede elegir ver la indicación de
llamada entrante indicación durante (>5 segundos) antes de que
sea desviada. (Esto significa que el usuario no necesita realizar
ninguna acción a menos que desee responder a la llamada, en lugar de
una acción positiva requerida durante una llamada anteriormente.)
Esto no funciona si el estado Ocupado es debido a que el video
teléfono 15 ya está manejando el máximo número de llamadas.
La posibilidad de generar un mensaje de texto
(muy corto) que es enviado con la llamada es una manera útil de
transportar más información acerca de la importancia de la llamada y
de cuánto tiempo durará. Los requisitos asociados con generar y
añadir un mensaje a una llamada saliente son tratados a
continuación. Si está presente, el mensaje de texto de la llamada
entrante debe mostrarse asociado con la llamada entrante. El
visualizador 54 trata con el visualizador de mensajes de texto en
múltiples llamadas entrantes simultáneamente. El mensaje de texto
también es almacenado en el registro de llamadas entrantes o
perdidas.
La negociación de los parámetros de la llamada
está limitada a la necesidad de establecer la llamada dentro de los
parámetros de la política de la red 40 y del uso actual de la red
40. Se proporcionan ajustes para permitir al usuario especificar su
preferencia para llamadas a otros terminales de video teléfono 15,
por ejemplo ofrecer siempre Video, no ofrecer nunca video,
preguntar a cada llamada si quiere ofrecer video o no.
Esperar en caso de Disponible está soportado
para llamadas a otros usuarios de video teléfono 15. Esto iniciará
una llamada al usuario una vez que su estado cambia a
"disponible". Si el usuario al que se llama es un grupo, las
llamadas sólo serán iniciadas una vez que todos los miembros del
grupo están "Disponible".
Una conferencia es cuando una posición en la
Marcación Rápida o en la lista de Agendas representa a un grupo de
personas, cada una de las cuales son participantes en una llamada.
El proceso sugerido de implementar este servicio es hacer cada
llamada cada vez y una vez que hay una confirmación de petición
activa de que la llamada debe ser añadida a la conferencia. Esto
proporciona una ruta de escape si la llamada transcurre a través de
un correo de voz. Una vez que las acciones en el primer llamante se
han completado, es decir en la llamada o rechazado el siguiente
número es procesado.
Es posible crear una llamada saliente que es
semi-bidireccional, en otras palabras que requiere
audio y o video del participante llamado, pero no transmite ninguno
de estos tipos de llamada. Este es el modo de tirar. Igualmente, es
posible crear un modo de empujar, donde la llamada saliente no envía
audio y o video, pero no requiere que se devuelva audio o video.
Este modo puede ser usado para emitir selectivamente contenido a
terminales no atendidos, o terminales con usuarios que realizan sólo
una función pasiva en la conferencia.
El volumen global de los altavoces 64, el
auricular y los auriculares son de ajuste independiente. El hablante
puede ser conectado o desconectado. Desconectar al hablante también
desconectará el micrófono. Los indicadores de estado muestran el
estado del hablante y del micrófono.
El micrófono puede ser desconectado y conectado
de nuevo. Los indicadores de estado muestran el estado del
micrófono que está en silencio.
La cámara puede ser desconectada y conectada de
nuevo. Los indicadores de estado muestran el estado de la cámara
que no está emitiendo.
Los controles de dentro de llamada funcionan
sólo en la llamada activa. Una llamada aceptada se hace activa si
no está activa, bien tocando el indicador de estado del progreso de
la llamada en el panel de control, o en cualquier lugar en el área
del visualizador 54 de la llamada excepto por las áreas de función
de control de dentro de llamada específicas. Cualquier otra llamada
activa actual es puesta como activa. La llamada activa puede ser
puesta en activa-dentro mediante una pulsación
subsiguiente en la misma área. Se proporciona un control que cuelga
la llamada activa. En una multi conferencia borra todos los
elementos del caso de llamada.
Una llamada debe ser aceptada y activa para que
el control de la Conferencia funcione. Tocar el control de la
conferencia conectará el caso de llamada activa actual con la
siguiente llamada que se hace activa. El control de la conferencia
indicará que está activa bien hasta que es pulsado de nuevo,
haciéndola inactiva, o bien hasta que otro caso de llamada se hace
activo. Después de que todas las llamadas en la ahora activa
llamada son unidas a la multi conferencia la llamada se convierte en
una única llamada de conferencia y la indicación activa del control
de la Conferencia desaparece. Recapitulando, la conferencia
selecciona la llamada a la que se unirán otras llamadas y a
continuación selecciona la llamada que se va a unir a esa
llamada.
El método de que un participante finalice una
conferencia es que ese participante cuelgue. Por varias razones, el
usuario puede desear tener un control independiente en cada parte de
un caso de llamada. Esto puede alcanzarse mediante una función de
salir de la conferencia. Por ejemplo, tocando el caso de llamada
durante más de tres segundos, aparece un sub-menú
que permite que los miembros individuales del caso de llamada sean
identificados y seleccionados para salir de la conferencia. Esta
llamada es a continuación eliminada de la conferencia y establecida
como un caso de llamada separado, en el que aplican los controles
normales, específicamente puede ser
borrada.
borrada.
La función de transferencia transfiere la
llamada activa. Cuando el control de transferencia es tocado, la
pantalla de marcación integrada es visualizada y la llamada activa
es situada en espera, pero indicando que está acoplada en una
operación de dentro de la llamada. El control de Transferencia
indica que está activa, hasta que es presionado una segunda vez,
cancelando la Transferencia, o hasta que el usuario selecciona y
pulsa marcar en el número al cual desea que la llamada sea
transferida.
Una vez que la llamada saliente ha sido
iniciada, el control de Transferencia indica un cambio de estado,
de manera que tocar el control provoca una transferencia
"ciega" y el caso de llamada es eliminado de la pantalla.
Alternativamente, el usuario puede esperar hasta que el número
llamado contesta, en cuyo momento se crea uno caso de llamada,
permitiendo al usuario hablar con el participante llamado, y la
función de transferencia cambia el estado de nuevo, para indicar
que presionándola otra vez completará la transferencia y finalizará
las dos llamadas. De otra forma, el requisito es volver a la
conversación con el llamante que es transferido y empezar de nuevo
el proceso de transferencia o finalizar la llamada. La Transferencia
es el principal mecanismo por el que un "administrativo"
establece una llamada y a continuación la transfiere al "jefe".
En este caso, es esencial que no sea posible que el administrador
continúe "escuchando" la llamada transferida. Esto será
especialmente cierto en un entorno seguro.
La llamada activa puede ser puesta EN ESPERA
tocando el control de RETENER. EN ESPERA, los flujos de video y
audio salientes son suspendidos y se proporciona una indicación al
extremo remoto de que está EN ESPERA. Los flujos de audio y video
entrantes ya no se muestran. El estado de EN ESPERA es indicado en
el visualizador 54 de estado de llamada en la barra de control. El
control de RETENER indica que RETENER está activo si alguna llamada
está EN ESPERA. Presionar de nuevo RETENER cuando la llamada activa
está en EN ESPERA elimina el RETENER y devuelve la llamada al
estado visualizado.
Existe un control en el panel principal de
control que presenta la pantalla de inicio y da acceso a todas las
demás funciones de no-llamada. Existe una indicación
de que Principal ha sido seleccionado. Pulsar Principal una segunda
vez restablece las visualizaciones de llamada actual y deselecciona
Principal. Se proporcionan controles separados para cada
participante aceptado dentro de una llamada, y para cada llamada
visualizada. Se requiere ajustar el volumen del audio de cada
usuario particular. Es posible silenciar individualmente el audio y
o video de cada usuario mostrado en la pantalla. Existe un indicador
de estado para indicar si silenciar el audio o el video está
ACTIVADO.
Si más de un caso de llamada puede ser
visualizado en cada momento, por ejemplo, una multi conferencia con
otros dos, más una nueva llamada a otro usuario, entonces es posible
silenciar el audio y o el video para un caso de llamada completo,
por ejemplo silenciar la conferencia de dos participantes para
audio, mientras se habla con la segunda llamada.
Se proporciona solicitar video en una conexión
sólo de audio que podría soportar video. Se proporciona aceptar o
rechazar una petición de video. Se establece una conexión de video
si la conexión está acordada. Un elemento de página de ajustes
permite al usuario aceptar siempre o rechazar siempre peticiones de
video.
Es posible visualizar los parámetros del canal
portador para cada conexión, es decir las velocidades de
codificación entrantes y salientes para video si existe y audio. En
una llamada los controles funcionan sólo en la llamada activa. Una
llamada aceptada se convierte en activa si no está activa.
Es posible permitir un "monitor de calidad del
canal portador" para cualquier usuario. Este monitor, un poco
como un medidor de fuerza de señal en un teléfono móvil, mostraría,
por ejemplo, una barra Verde al 100% cuando no hay errores o
paquetes perdidos en los canales de audio y de video, una barra
amarilla una vez que la tasa de pérdidas o la latencia excede una
tasa predeterminada y una barra roja una vez que se excede una tasa
mayor. El tiempo total debe ser corto, por ejemplo 50 milisegundos
puesto que los errores en este intervalo de tiempo afectarán al
video de los usuarios. Así, por ejemplo, si el receptor ve
aberraciones de video, pero al mismo tiempo ve que la barra de
monitor se mueve en amarillo o rojo, sabe que se ha inducido una
congestión en la red 40.
Se proporciona solicitar un cambio en los
parámetros de codificación del video, es decir aumentar o disminuir
la tasa de codificación, dentro de la llamada. Se proporciona
aceptar o rechazar esta petición y un método de cambiar la tasa de
video saliente. El video teléfono 15 genera una única tasa de
codificación saliente para todos los participantes. Es posible que
acepte diferentes tasas entrantes en todos los flujos entrantes.
Se proporciona una petición de barra lateral con
la posibilidad de aceptar o rechazar la petición. Si se acepta, la
barra lateral desconecta el flujo de audio desde los dos
participantes hacia cualquier otro, de manera que pueden tener una
conversación privada, mientras que continúa oyendo toda la discusión
y continúa viendo y siendo visto por todos los participantes. Se
proporciona la posibilidad de enviar mensajes cortos en los dos
sentidos con las peticiones de video y de barra lateral.
Independientemente de si la llamada es una
llamada entrante o saliente, la transición de la pantalla a la
vista del video debe ser suave. El audio puede anticipar al video.
El video no debe ser visualizado hasta que esta transición pueda
hacerse. (Es decir no debería haber imágenes que saltan, tramas a
medio formar, etc. en la transición al video.) La transición a la
pantalla de video del visualizador 54 del usuario sólo debe empezar
después de que la llamada está "en progreso" y no en el momento
en que se inicia la llamada. La visualización del video del usuario
debe hacer un máximo uso del área del visualizador 54 asignada al
visualizador 54 de usuario. Un control en el visualizador 54 es
capaz de convertir este visualizador 54 de usuario único de caso de
llamada única en un visualizador 54 de pantalla completa. Tocando en
cualquier lugar dentro del visualizador 54 de "pantalla
completa" revertirá al visualizador 54 estándar. Además de los
controles de llamada ya mencionados, el nombre de los usuarios debe
ser visualizado. El visualizador 54 y el caso de llamada en el
panel de control debe indicar si la llamada está activa o no, es
decir si los controles generales internos de la llamada operarán o
no. Con un abonado de caso de llamada, activo inactivo es pulsando
en el caso de llamada o en cualquier lugar en el visualizador 54
principal aparte de desde las áreas de control específicas internas
de la llamada.
La transición desde un caso de llamada a una
llamada de dos participantes debe ser suave y debe ser iniciada una
vez que la segunda llamada está "en progreso". El visualizador
54 debe hacer un máximo uso del área del visualizador 54 asignada
al visualizador 54 de usuario. Si es necesario, los videos pueden
ser recortados en cada borde, en lugar de escalados, para adaptarse
al área disponible. No hay ningún requisito para un visualizador 54
de pantalla completa para dos o más abonados. Además de los
controles internos de la llamada ya mencionados, el nombre del
usuario debe visualizarse para cada participante. Debe haber una
indicación de que los dos participantes son parte de un único caso
de llamada. El visualizador 54 y el caso de llamada en el panel de
control deben indicar si la llamada está activa o no. El video
entrante puede ser progresivamente recortado para adaptarse al área
del visualizador 54 disponible a medida que se añaden más
participantes a la llamada de video.
En dos casos de llamada que son ambos llamadas
de un único participante, hay dos llamadas separadas a usuarios
únicos, siendo ambos mostrados. El visualizador 54 en la pantalla y
la indicación de control de llamada indican claramente que éstas
son dos llamadas separadas e independientes y también indican cuál,
si es que hay una, está activa. Si alguna llamada está EN ESPERA,
esa llamada ya no se muestra y el visualizador 54 vuelve a un
visualizador 54 de llamada única de único caso de llamada.
El área de usuario debe ser capaz de mostrar
cualquiera de las siguientes combinaciones además de las descritas
anteriormente.
Cuatro casos de llamada, siendo cada uno
llamadas de un solo participante;
Tres casos de llamada en los que una llamada
puede ser de dos participantes y las otras son llamadas de un solo
participante;
Dos casos de llamada en los que una puede ser de
hasta tres participantes o dos pueden ser llamadas de dos
participantes.
Los requisitos de un visualizador 54 de estilo
"CNN" son los del único caso de llamada de un solo
participante anterior, que incluyen la posibilidad de tener un
visualizador 54 de pantalla completa. También es posible mostrar
una llamada de estilo "CNN" en la mitad de la pantalla y usar
la otra mitad para las áreas de visualización de uno o dos
usuarios, esto último como dos casos de llamada independientes o un
único caso de llamada de dos partici-
pantes.
pantes.
Se proporciona la posibilidad de proporcionar
varios niveles de encriptación para los flujos de voz y datos. El
acceso a los servicios de diagnóstico, prueba, medición y gestión
hará uso de SMF (Simple Management Framework - Estructura de
Gestión Simple), en otras palabras, será posible el acceso a todos
los servicios de tres maneras, por medio de SNMP, por medio de la
web y por medio de una interfaz de craft. El terminal de video
teléfono 15 debe ser gestionable de manera remota, sin requerir
ninguna experiencia de IT en el sitio para la operación diaria, o
para actualizaciones de software que solucionan problemas. Un
diagnóstico de fallos es también posible remotamente y es capaz de
determinar si el problema es con el hardware de la unidad, la
configuración de las unidades, el software de las unidades, la red
40 o los servicios de la red 40. La gestión puede asumir capacidad
de conexión de IP, pero debe asumir una conexión de ancho de banda
relativamente bajo con el video teléfono 15.
En operación normal, el video teléfono 15 debe
llevar a cabo una versión simplificada de la prueba del sistema 10
de hardware cuando es alimentado. Si esto falla, el video teléfono
15 debe mostrar un mensaje de fallo de arranque en la pantalla
principal. El terminal puede ser forzado a un modo de diagnóstico de
hardware extendido. Esto podría hacerse conectando un teclado a un
puerto USB, o pulsando en la esquina superior derecha de la
pantalla táctil 74 cuando la unidad se alimenta. Este modo dará
acceso al sistema 10 de operación subyacente y a diagnósticos más
potentes, para determinar si hay un fallo de hardware o no.
Pueden incluirse una serie de pruebas simples
que el usuario puede ejecutar en el caso de que el video teléfono
15 pase la prueba de arranque pero no proporcione la funcionalidad
correcta al usuario. El terminal proporciona una interfaz técnica,
en asociación con un teclado local (y ratón) para asistir en
diagnosticar problemas de la unidad o del sistema 10. Esto daría
acceso a varios diagnósticos para audio y video, etc.
Es posible descargar son seguridad nuevas
versiones del software del terminal de video teléfono 15 por control
remoto. Por "de manera segura", se quiere decir siendo capaz
de volver a la versión previa si ocurren fallos en la versión
descargada, sin intervención local (es decir teniendo alguien que
instalar un CD). Es posible leer el número de versión de software
del software en un terminal de video teléfono 15 particular, y el
número de serie del hardware de las unidades, el número de revisión
del conjunto y el número de serie y el número de revisión del
conjunto de los sub-conjuntos claves por medio de
las interfaces de gestión. En el caso de una rotura del sistema 10,
el video teléfono 15 debe almacenar o haber almacenado información
para asistir en la diagnosis de la causa de esa rotura. Esta
información debe ser extraíble en línea desde un sitio remoto para
su análisis una vez que el video teléfono 15 ha arrancado de
nuevo.
El video teléfono 15 mantiene un registro
continuo de todas las acciones, casos y cambios de estado desde que
se enciende, dentro de los límites de almacenamiento que pueden
estar asignados a este servicio. Debe permitir que se almacene al
menos la actividad de un mes. Estos datos pueden necesitar estar en
varias categorías, por ejemplo una categoría segura que contiene
los datos de los usuarios, tales como los números a los que ha
llamado y que sólo son extraíbles por el usuario. Datos genéricos,
tales como número de llamadas, estado de las llamadas (es decir
número de casos de llamada y puntos de extremo por caso,
características del codificador 36 y del descodificador 34,
informes de errores de canal portador y así sucesivamente no son
información sensible. Puede resultar útil poder grabar cada
pulsación de tecla como modo de ayudar a diagnosticar un problema al
nivel del sistema 10 y re-crear la cadena de
sucesos.
Es posible que el video teléfono 15 copie los
intercambios en el nivel del plano de control tanto en el nivel de
IP como en el nivel de SIP, en un terminal de diagnóstico remoto (el
equivalente de tener un monitor en línea conectado de manera remota
con el terminal de video teléfono 15). La gestión del terminal
monitorizará un número de parámetros, por ejemplo, calidad de la
red 40. Debe ser posible establecer umbrales y generar alarmas
cuando esos umbrales se exceden. Tanto la interfaz de ATM como la
interfaz de Ethernet tienen mediciones estándar (como rmon, por
ejemplo) que deben estar disponibles para el video teléfono 15. El
video teléfono 15 debe poder enviar esas alarmas a uno o más
Sistemas de Gestión de Red.
\vskip1.000000\baselineskip
Con respecto al mezclador de audio, un primer
nodo 80 que puede producir un flujo de audio y un flujo de video, y
que forma parte de una red de ATM que tiene capacidad de calidad de
servicio, desea formar una llamada de punto a punto con un segundo
nodo 82. El segundo nodo 82 sólo tiene posibilidad de audio y es,
por ejemplo, un teléfono de PSTN. El segundo nodo 82 no forma parte
de la red de ATM.
El primer nodo 80 empieza la formación de la
llamada al segundo nodo 82 enviando información de señalización a
un servidor de SIP, también parte de la red de ATM, que identifican
al servidor que el segundo nodo 82 es el destino de la llamada que
el primer nodo 80 está iniciando. El servidor, que tiene ya
información de la dirección que concierne al segundo nodo 82, añade
la información de la dirección a la información de señalización
recibida desde el primer nodo 80, y transmite la información de
señalización con la información de la dirección del segundo nodo 82
a un mezclador de audio 20 que es también parte de la red de
ATM.
Cuando el mezclador 20 recibe la información de
señalización que se ha originado desde el primer nodo 80, determina
a partir de esta información que es el segundo nodo 82 con el cual
el primer nodo 80 desea formar una conexión. El mezclador 20 envía
a continuación una invitación al segundo nodo 82 a través de la cual
está de alguna manera en comunicación, tal como mediante una línea
de T1 o de ethernet pero no por medio de la red de ATM, para
identificarse con respecto a sus servicios y la forma en la cual los
datos necesitan ser proporcionados para que pueda entender los
datos. En respuesta, el segundo nodo 82 identifica al mezclador 20
la forma específica en la cual los datos necesitan estar para que el
segundo nodo 82 pueda entender los datos, y también indica al
mezclador 20 que es CORRECTO enviarle datos de manera que pueda
formarse la conexión.
\newpage
El mezclador 20 envía a continuación una señal
al primer nodo 80 de que está listo para formar la conexión. Para
el primer nodo 80, el mezclador 20, que es parte de la red de ATM,
representa el segundo nodo 82 y da la impresión al primer nodo 80
de que el segundo nodo 82 es parte de la red de ATM y es similar al
primer nodo 80. Para el segundo nodo 82, el mezclador 20, que es
también parte de la red o capacidad de conexión a la cual el
segundo nodo 82 pertenece, representa al primer nodo 80 y da la
impresión al segundo nodo 82 de que el primer nodo 80 es parte de
la misma red o capacidad de conexión a la cual el segundo nodo 82
pertenece y es similar al segundo nodo 82.
El primer nodo 80 inicia a continuación un flujo
de datos, que incluye datos de audio, y paquetes unidifusión al
mezclador 20, como es bien conocido en el sector. Cuando el
mezclador 20 recibe los paquetes, almacena temporalmente los datos
en los paquetes, como es bien conocido en el sector, terminando de
manera efectiva la conexión con respecto a los paquetes desde el
primer nodo 80 que están destinados al segundo nodo 82. El
mezclador 20, habiendo sido informado previamente a través de la
invitación que fue enviada al segundo nodo 82, de la forma en la
cual los datos necesitan estar de manera que el segundo nodo 82
pueda comprenderlos, sitúa los datos almacenados temporalmente en
el formato necesario, y a continuación los somete a restricciones
de tiempo apropiadas, envía los datos reformateados adecuadamente
efectivamente en una nueva y separada conexión desde el mezclador
20 hasta el primer nodo 80. De esta manera, se forma una llamada de
punto a punto, aunque realmente comprende dos conexiones distintas,
y ni el primer nodo 80 ni el segundo nodo 82 perciben que se
utilizan dos conexiones para crear la llamada de punto a punto
deseada entre el primer nodo 80 en el segundo nodo 82. De manera
similar, cuando se devuelven datos desde el segundo nodo 82 al
primer nodo 80, el proceso se repite, aunque al contrario de manera
que después de que los datos desde el segundo nodo 82 son recibidos
por el mezclador 20, el mezclador 20 reformatea los datos en una
forma que el primer nodo 80 puede comprender y difunde los datos
desde el segundo nodo 82, que han sido almacenados temporalmente en
el mezclador 20, al primer nodo 80. Si se usa IP en lugar de ATM,
entonces el mezclador 20 envía paquetes de IP de unidifusión al
primer nodo 80, como es bien conocido en el sector.
Un escenario que implica participar en una
conferencia, conocido de otro modo como una conexión de punto a
multi punto, se describirá ahora usando a presente invención.
Continuando la explicación que se refiere a la conexión de punto a
multi punto anterior, el primer nodo 80 desea unirse a la conexión
para formar una conferencia, un tercer nodo 84 que es parte de la
red de ATM y tiene esencialmente las mismas características que el
primer nodo 80. El primer nodo 80 envía una invitación de
señalización a un nodo anfitrión 22 que será el anfitrión de la
conferencia. El nodo anfitrión 22 puede ser el primer nodo 80 o
puede ser un nodo distinto. El primer nodo 80 se comunica con el
nodo anfitrión 22 a través del servidor para formar una conferencia
y unir al tercer nodo 84 a la conferencia. El nodo anfitrión 22
invita y a continuación forma una conexión para propósitos de
señalización con el mezclador 20 y hace que la conexión de
señalización original entre el primer nodo 80 y el mezclador 20
termine. El nodo anfitrión 22 también invita y forma una conexión
con el tercer nodo 84 en respuesta a la petición desde el primer
nodo 80 para que el tercer nodo 84 se una a la conexión. En cada
caso en el que un nodo que es parte de la red de ATM va a unirse a
la conexión, la señalización se transmite a través del servidor y
es encaminada adecuadamente, como es bien conocido en el sector. El
nodo anfitrión 22 actúa como un nodo anfitrión típico para una
conexión de conferencia en la red de ATM. El mezclador 20
representa cualesquiera nodos que no son parte de la red de ATM,
pero que van a ser parte de la conexión de conferencia global.
Con respecto a cualquiera de los nodos de la red
de ATM, el mezclador 20 hace a los nodos que son parte de la
conexión pero no parte de la red de ATM aparecer como si fuesen como
los otros nodos de la red de ATM. A través de las conexiones de
señalización, que están formadas entre el anfitrión y el mezclador
20, y el mezclador 20 y el segundo nodo 82 (como representa el
mezclador 20), la información requerida desde todos los demás nodos
de la conexión es proporcionada a cada uno de los nodos de manera
que pueden comprenderse y comunicarse con todos los demás nodos de
la conexión. En realidad, el nodo anfitrión 22 informa a los demás
nodos, no sólo de la información de las características de los demás
nodos, sino también devuelve la información que ellos habían
proporcionado originalmente al nodo anfitrión 22 a los nodos, de
manera que esencialmente cada nodo recibe de nuevo su propia
información. Una vez que esta información es distribuida, la
información del flujo es transportada como lo sería normalmente en
el caso de cualquier situación de conferencia típica. En un
escenario de red de ATM, el primer nodo 80 y el tercer nodo 84
podrían difundir en ATM la información en paquetes, usando un árbol
de PMP, entre sí y al mezclador 20. En un entorno de IP, el primer
nodo 80 y el tercer nodo 84 difundirían según IP paquetes a todos
los nodos (siendo el mezclador 20 un nodo para este propósito) de
la red, y sólo aquellos nodos que forman parte de la conexión
comprenderían y utilizarían la información del paquete específico
que era parte de la conexión.
El mezclador 20 recibe los paquetes desde el
primer nodo 80 y el tercer nodo 84 y los almacena temporalmente,
como se ha descrito anteriormente. Los paquetes desde los diferentes
nodos que son recibidos por el mezclador 20 son reformateados a
medida que son recibidos y mezclados o añadidos juntos de acuerdo
con algoritmos estándar bien conocidos para un experto. En un
momento predeterminado, como es bien conocido en el sector, los
datos reformateados por el mezclador 20 son transmitidos a
continuación al segundo nodo 82. De la misma manera, sólo que al
contrario, los datos desde el segundo nodo 82 son recibidos por el
mezclador 20 y almacenados temporalmente. Son a continuación
difundidos de una forma reformateada al primer nodo 80 y al tercer
nodo 84.
Cuando existe un cuarto nodo, que sólo tiene
posibilidad de audio, como el segundo nodo 82, y que no forma parte
de la red de ATM, es unido a la conferencia, el nodo anfitrión 22
forma una segunda conexión de señalización con el mezclador 20. El
mezclador 20 a su vez forma una conexión distinta con el cuarto nodo
separado desde la conexión que el mezclador 20 ha formado con el
segundo nodo 82. El mezclador 20 mantiene una lista de sesiones que
está soportando. En la sesión que implica a la conferencia objeto,
identifica dos conexiones cruzadas a través del mezclador 20. La
primera conexión cruzada tiene lugar a través de la conexión de
señalización desde el nodo anfitrión 22 hacia el segundo nodo 82, y
la segunda conexión cruzada es desde el nodo anfitrión 22 hacia el
cuarto nodo. De esta manera, los nodos primero y tercero 80, 84, así
como el nodo anfitrión 22, creen que hay dos nodos separados, que
representan al segundo nodo 82 y al cuarto nodo, con los cuales se
están comunicando. En realidad, el mezclador 20 representa tanto al
segundo nodo 82 como al cuarto nodo y difunde separadamente datos
desde cada uno de ellos para mantener esta ilusión, así como la
ilusión de que el segundo nodo 82 y el cuarto nodo son como el
primer nodo 80 y el tercer nodo 84, para el primer nodo 80 y el
tercer nodo 84.
\global\parskip0.900000\baselineskip
El sistema de ViPr es un sistema de realizar
videoconferencia altamente avanzado que proporciona una calidad de
conferencia "Presencia Virtual" que excede en mucho las
posibilidades de cualquier sistema de realizar videoconferencia
heredado en el mercado actual. El sistema de ViPr descansa sobre los
SVCs de punto a multipunto (PMP-SVC) y la
multi-difusión de IP para establecer flujos de
medios de comunicación de audio/video de punto a multipunto entre
los participantes en la conferencia. Mientras que los usuarios que
participan en una conferencia de ViPr disfrutan una conferencia con
calidad de audio y video sin precedentes, existe una necesidad de
permitir que otros usuarios no-ViPr se unan a la
conferencia de ViPr. El sistema 10 permite que una llamada
telefónica sólo de voz de difusión a uno (es decir PSTN, teléfonos
Móviles y teléfonos de SIP) sea añadida a una multi conferencia de
ViPr.
El sistema de ViPr actual proporciona soporte
para sistemas de telefonía a través de pasarelas de telefonía
analógica y digital basadas en SIP. Esta funcionalidad permite a los
usuarios de ViPr hacer/recibir llamadas de punto a punto
hacia/desde usuarios de teléfono. No obstante, no permiten que un
usuario de ViPr añada una llamada telefónica a una conferencia de
ViPr. Esto es debido a la naturaleza de uni-difusión
de las llamadas telefónicas y a la imposibilidad de las pasarelas
de telefonía de convertirlas en flujos de PMP/multidifusión. El UAM
de ViPr mejorará el soporte del sistema de ViPr de telefonía
permitiendo que los usuarios de ViPr añadan llamadas telefónicas de
unidifusión a conferencias de ViPr.
Con el fin de soportar esta funcionalidad, el
UAM de ViPr añade la funcionalidad de realizar conferencias fluidas
entre los terminal de ViPr y los usuarios de teléfono (es decir
PSTN, teléfonos Móviles y teléfonos de SIP) convirtiendo un flujo
de audio telefónico de unidifusión ascendente en flujos de audio de
punto a multipunto (es decir PMP-SVC o IP
multidifusión) y de mezclar/convertir flujos de audio de
PMP/multidifusión ViPr descendentes en flujos de audio telefónicos
de unidifusión así como llevar a cabo una transcodificación de
audio descendente de audio de ViPr a partir de la codificación de
G.711 o G.722 de 16 bit/16 KHz PCM de ancho de banda.
Una funcionalidad adicional proporcionada por el
UAM es la de una pasarela de Intermedios que convierte flujos de
audio de IP/UDP en flujos de audio de ATM SVC y
vice-versa. Esta funcionalidad permite la
interoperatividad entre sistemas de ViPr desplegados en entornos de
ATM y pasarelas de telefonía de
Voice-over-IP (VoIP) basadas en SIP
en redes de Ethernet.
El UAM permite que uno o más teléfonos de ViPr
trabajen con una o más pasarelas de telefonía.
El UAM soportará conferencias de ViPr con
dispositivos de audio de unidifusión presentes en las siguientes
configuraciones
- \equiv
-
\vtcortauna
- \equiv
-
\vtcortauna
- \equiv
-
\vtcortauna
Preferiblemente, se puede proporcionar servicio
a 20 participantes (dispositivos de unidifusión más teléfonos de
ViPr) mediante una sola aplicación de Gestor de Unidifusión.
El dispositivo de unidifusión se usará en la
configuración mostrada en la Figura 1.
Como se muestra en la Figura 1, todas las
llamadas hacia y desde un dispositivo de unidifusión a un ViPr son
enviadas siempre hacia el UAM. El UAM implementa un B2B SIP UA para
conectar el dispositivo de unidifusión con un ViPr.
\vskip1.000000\baselineskip
El Usuario A en POTS1 llama al Usuario B en ViPr
V1. La siguiente secuencia de sucesos tiene lugar:
- 1
- El UD1 (Mediatrics o cualquier dispositivo de unidifusión) recibe la petición del Usuario_A para conectarse con el Usuario_B.
- 2
- El UD1 envía un INVITACIÓN al UAM. El campo de To o el de Mostrar Nombre en la INVITACIÓN identifica que la llamada es para el Usuario_B.
\global\parskip1.000000\baselineskip
- 3
- El UAM recibe INVITACIÓN como la llamada entrante C1.
- 4
- El UAM extrae la dirección de sip del Usuario_B desde la INVITACIÓN en C1 e inicia una llamada C2 a este usuario enviando una INVITACIÓN a V1.
- 5
- El UAM también conecta de manera cruzada a C1 con C2.
- 6
- El V1 ve una INVITACIÓN entrante desde el UAM, el cual es identificado por el SDP como un dispositivo de clase ViPr. De este modo el software en V1 sabe que el software de par es capaz de soportar toda la funcionalidad esperada de un dispositivo de ViPr incluyendo Reemplaza/Se refiere etc.
- 7
- Por ejemplo el Usuario_B en V1 responde a la INVITACIÓN con CORRECTO.
- 8
- El UAM marcará la conexión C2 como arriba. A continuación envía un CORRECTO a C1.
\vskip1.000000\baselineskip
Los flujos de medios de comunicación entre V1 y
UD1 son enviados de alguna de las maneras siguientes:
- 1.
- Los medios de comunicación son enviados directamente de V1 a UD1. Esto puede hacerse por medio de UAM escribiendo en el SDP correcto. Así mientras envía INVITACIÓN a V1 pone la dirección de IP, puerto de UD1 para recibir. Y mientras envía CORRECTO a UD1 pone la dirección de IP, puerto de V1 como dirección de recepción.
- 2.
- Los medios de comunicación son transmitidos por UAM. En este caso, el UAM transmite los datos de V1 a UD1 y vice-versa. Es fácil ver que si el UAM y el ViPr se comunican, están conectados por medio de una nube de ATM, entonces podría establecerse un SVC entre el V1 y el UAM. De este modo, el UAM actúa como una ATM a pasarela de Ethernet para tráfico de medios de comunicación.
\vskip1.000000\baselineskip
Extendiendo más el ejemplo 1, el Usuario_A
decide unir al Usuario_B en V2 a la conferencia. Ocurre lo
siguiente:
- 1.
- La conexión de Sip entre el UAM y el V1 es reemplazada por una conferencia C3 con V1, V2 y UAM como participantes. De este modo, el B2B UA está ahora conectando de manera cruzada a una conferencia (C3) con una llamada de unidifusión (C1).
- 2.
- El UAM siempre transmite tráfico entre C3 y C4. Opción 11 anterior. Mezcla el tráfico desde V1 y V2 y lo transmite al UD1. También multi-difunde tráfico de UD1 a V1 y V2.
\vskip1.000000\baselineskip
La funcionalidad llevada a cabo por el UAM puede
ser dividida en los siguientes componentes:
- \equiv
-
\vtcortauna
- \equiv
-
\vtcortauna
\vskip1.000000\baselineskip
La funcionalidad de UAM decidirá entre tres
procesos: El SBU, Gestor Mezclador de Unidifusión y pila de Sip
stack, como se muestra en la Figura 2.
El proceso de Servidor de Sip implementará la
funcionalidad de SIP y proporcionaría a la SBU un API de
señalización abstraído (Interfaz Ia). La interfaz Ia también
permanece sin cambios.
El SBU implementa el control de llamada y la
lógica de unión para implementar el B2B UA. Esta unidad se deriva
del Gestor de llamadas / base de codificación Vsuperior. La SBU es
responsable también de ajustar los flujos de mezclador correctos.
Para este propósito, la SBU se comunica con el proceso de UMM a
través del RPC.
El UMM implementa la funcionalidad para conectar
de manera cruzada los flujos de medios de comunicación así como
implementar la funcionalidad de mezcla de audio.
La SBU implementa el control de llamada y la
lógica de unión para implementar el B2B UA. La SBU es responsable
también de ajustar los flujos de mezclador correctos. Para este
propósito, la SBU se comunica con el proceso de UMM a través del
RPC.
\vskip1.000000\baselineskip
La unidad de SBU está estructurada internamente
como sigue:
Como puede verse de la Figura 3, el diseño para
SBU reutiliza y extiende la interfaz de SIP/Flujo de Medios de
Comunicación ofrecida por el Gestor de Llamadas para implementar la
lógica de control de llamadas de señalización para el UAM.
El siguiente texto presenta el flujo de control
cuando el Usuario A inicia una llamada al Usuario_B.
En el siguiente Servidor de Sip se hace
referencia al Servidor de Sip en el UAM, SBU se refiere a la SBU en
el UAM y UMM se refiere al UMM en el UAM.
Para aclarar más el ejemplo, se asume lo
siguiente:
- \quad
- - toda la red es una red de Ethernet
- \quad
- - la dirección de IP de V1 es 172.19.64.101
- \quad
- - la dirección de IP de V2 I 172.19.64.101
- \quad
- - la dirección de IP de la interfaz de UAM que está conectada a la nube de V1/V2 es 172.19.64.51, la interfaz {}\hskip0,15cm de IP del UAM conectado con la nube de UD1 es 169.144.50.100
- \quad
- - la dirección de IP de V1 es 169.144.50.48
- \quad
- - la dirección de IP está representada como la tupla<IpAddress, port>
- \quad
- - Todas las direcciones y puertos del ejemplo son ilustrativas, no se requiere que sean fijos sino que por el {}\hskip0,15cm contrario son asignados mediante OS.
- \quad
- - En el siguiente ejemplo, todos los casos de SIP recibidos por la SBU (en el UAM) son recibidos realmente {}\hskip0,15cm por el Servidor de Sip y pasados a continuación a la SBU. No obstante, el Servidor de Sip que recibe el caso y {}\hskip0,15cm lo pasa a la SBU no se muestra por brevedad.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
La tabla anterior explica lo que ocurre para una
llamada intermedia. Lo siguiente es el flujo de control cuando esta
llamada es convertida en una multi conferencia. En este caso, por
ejemplo el Usuario_B introduce al Usuario_C en V2 en la
llamada.
Además se asume lo siguiente:
- la dirección de IP de V2 es 171.19.64.102
\vskip1.000000\baselineskip
Para añadir otro usuario de ViPr a la
conferencia, se repiten las etapas 12 a 18. Deben considerarse las
etapas que se requieran para otro usuario de Dispositivo de
Unidifusión por ejemplo el Usuario_D en POTS2.
Debe asumirse lo siguiente:
El S Usuario_C en ViPr V2 decide establecer una
conferencia con el Usuario_D en POTS2 en la conferencia.
\vskip1.000000\baselineskip
El UMM implementa la funcionalidad para conectar
los flujos de medios de comunicación así como implementar la
funcionalidad de mezcla de audio.
\vskip1.000000\baselineskip
En referencia a la Figura 4, este escenario
cubre dos casos:
Un usuario de ViPr en una conferencia de
audio/video de ViPr de multi-participantes que añade
a un usuario de teléfono sólo de audio de unidifusión a la
conferencia:
En este caso, los usuarios de ViPr en una
conferencia de ViPr de multi-participantes deciden
añadir a un usuario de teléfono de unidifusión a la conferencia.
Como resultado, uno de los participantes inicia una llamada al
número de teléfono de destino. El servidor de SIP de ViPr redirige
la llamada al UAM de ViPr. El UAM de ViPr finaliza la llamada sólo
de audio de ViPr y establece una llamada sin interrupción al
teléfono de destino por medio de una pasarela de telefonía.
Una vez que se ha establecido la llamada, el UAM
de ViPr convierte el flujo de audio de unidifusión de G.711/G.722
recibido desde el teléfono en un flujo de PMP/multidifusión y lo
transmite al terminal de ViPr sin ninguna transcodificación. Por
otro lado, el UAM de ViPr lleva a cabo la transcodificación y la
mezcla de los flujos de audio de ViPr PCM de 16 bit/16 KHz de banda
ancha recibidos desde los diferentes terminales de ViPr en un flujo
de audio de unidifusión de G.711 ó G.722 y lo redirige al teléfono
de destino.
Un usuario de ViPr en conferencia sólo de audio
de punto-a-punto con un usuario de
teléfono que añade a otro usuario de ViPr a la conferencia:
En este caso, un usuario de ViPr (V1) en llamada
sólo de audio de punto-a-punto con
un usuario de teléfono (T) decide añadir a otro usuario de ViPr
(V2) a la conferencia. Como resultado, el usuario de ViPr V1 inicia
una llamada de audio/video al usuario de destino de ViPr V2. El
sistema de ViPr corta la llamada de
punto-a-punto establecida entre V1
y el UAM de ViPr y re-establece una llamada de
PMP/multidifusión entre V1, V2 y el UAM de
ViPr.
ViPr.
El UAM de ViPr finaliza la nueva llamada de
audio/video de ViPr y establece un puente con la llamada de teléfono
sin interrupción ya establecida. A través de este proceso, la
llamada de teléfono permanece activa y la conmutación es
transparente para el usuario de teléfono.
Una vez que se ha establecido la llamada, el UAM
de ViPr convierte el flujo de audio de unidifusión de G.711/G.722
recibido desde el teléfono en un flujo de PMP/multidifusión y lo
transmite a los terminales de ViPr sin ninguna transcodificación.
Por otro lado, el UAM de ViPr lleva a cabo la transcodificación y la
mezcla de los flujos de audio de ViPr PCM de 16 bit/16 KHz de banda
ancha recibidos desde los diferentes terminales de ViPr en un flujo
de audio de unidifusión de G.711 ó G.722 y lo redirige al teléfono
de destino.
El ViPr utiliza Session Initiation Protocol (SIP
- Protocolo de Iniciación de Sesión) como medio de establecer,
modificar y limpiar sesiones de multi-medios de
multi-flujo. El UAM añadirá capacidades para
establecer una conferencia entre los terminales de ViPr y los
usuarios de teléfono (es decir PSTN, teléfonos Móviles y teléfonos
de SIP) convirtiendo flujos de teléfono sólo de voz de unidifusión
ascendentes en flujos de
punto-a-multipunto (es decir
PMP-SVC o IP multidifusión) y convirtiendo flujos de
audio de multidifusión/PMP de ViPr descendentes en flujos sólo de
voz de teléfono de unidifusión así como llevando a cabo
transcodificación de audio descendente de audio de ViPr de
codificación de 16 bit/16 KHz PCM de banda ancha a G.711 ó
G.722.
\newpage
En referencia a la figura 5, este escenario
cubre dos casos:
Un usuario de teléfono que llama a un usuario de
ViPr:
En este caso, un usuario de teléfono inicia una
llamada (sólo de audio) a un usuario de ViPr. La pasarela de
telefonía redirige la llamada al UAM de ViPr. El UAM de ViPr
finaliza la llamada y establece una llamada sólo de audio de ViPr
sin interrupción al terminal de ViPr de destino.
Una vez que la llamada se ha establecido, el UAM
de ViPr transmite el flujo de audio de G.711/G.722 recibido desde
el teléfono al terminal de ViPr sin ninguna transcodificación. Por
otra parte, el UAM de ViPr lleva a cabo una transcodificación del
flujo de audio de ViPr de PCM de 16 bit/16 KHz de banda ancha a
G.711 ó G.722 y lo transmite al destino del teléfono.
Un usuario de ViPr llamando a un usuario de
teléfono:
En este caso, un usuario de ViPr inicia una
llamada a un usuario de teléfono. El servidor de SIP de ViPr
redirige la llamada al UAM de ViPr. El UAM de ViPr finaliza la
llamada sólo de audio de ViPr y establece una llamada de PSTN sin
interrupción al teléfono de destino por medio de la pasarela de
telefonía. La transcodificación se realiza de la misma manera que
se ha descrito en el párrafo previo.
La Figura 6 proporciona un contexto de uso
típico el UAM. Las características proporcionadas por el UAM son
las siguientes.
\vskip1.000000\baselineskip
Característica 1
Supongamos que ViPr V1 y V2 están en una llamada
de punto a punto y desean conectarse con el Unicast Device
(Dispositivo de Unidifusión) UD1 en una conferencia. En otras
palabras, se intenta formar una conferencia con UD1, V1 y V2 en
conferencia. Supongamos que el usuario en V1 pide que el usuario en
UD1 se una a la conferencia con V1 y V2 como otros participantes.
Esta petición es transmitida por uno de los servidores de SIP al
UAM.
El UAM lleva a cabo a continuación las
siguientes tareas:
- \quad
- - Se une a la conferencia en nombre de UD1. Llámese a esta conferencia C1.
- \quad
- - Realiza también una llamada de punto a punto con el dispositivo de unidifusión. Llámese a esta conferencia {}\hskip0,15cm C2.
- \quad
- - Transmite datos de audio recibidos en C2 a C1. Acepta los datos de audio de los participantes V1 y V2 en la {}\hskip0,15cm llamada C2, los mezcla y transmite estos datos a UD.
\vskip1.000000\baselineskip
Característica 2
Considérese el caso en el que la red de vipr en
la Figura anterior es de ATM y la red de UD es una red de IP.
También, supóngase que se desea que en la medida de lo posible sólo
se usen SVCs en la red de ATM para audio en lugar de LANE/CLIP.
Esto podría ocurrir en aras de la seguridad o por temas de
funcionamiento.
En este caso, si un ViPr V1 en la red de vipr
desea conectarse con un dispositivo de unidifusión (UD1) en una
conversación de audio, entonces se usa el UAM para proporcionar la
funcionalidad para usar un SVC en la red de ATM e IP en la red de
IP.
Para ello todas las llamadas de V1 a UD1 se
dividen en dos llamadas de V1 a UAMD y de UAMD a V2.
La configuración requerida para características
soportadas por el UAM puede ser dividida en las siguientes
categorías:
- Configuración para llamadas de ViPr a UD.
- Configuración para llamadas de UD a ViPr.
- Configuración general
- Configuración general
\newpage
El B2BUA SIP UA está hecho para ejecutarse en
cualquier puerto deseado (distinto del 5060). Esto se lleva a cabo
modificando el fichero vipr.ini para incluir el siguiente
parámetro:
SIP_Port=7070[cualquier número de puerto
válido]
\vskip1.000000\baselineskip
Para una llamada de ViPr típica cuando un
usuario marca un "número" su "petición de llamada" es
enviada al servidor de SIP que a continuación la transmite a los
destinos apropiados. No obstante, este caso es diferente. En este
caso, cuando un usuario dice que desea hablar con el dispositivo de
unidifusión (UD1) el servidor de SIP transmite la petición al UAM.
Además, pone también información en la petición para identificar que
esta llamada debe ser desviada a UD1. De este modo, el servidor de
SIP es programado para encaminar llamadas hechas a los
SIP-URIs a los que los dispositivos de UAM
proporcionan servicios, al servidor de UAMD apropiado.
También es posible especificar una dirección de
SIP del dispositivo de unidifusión por defecto a la cual desviar
todas las llamadas recibidas por el UAM. Esta dirección por defecto
puede ser especificada en el fichero vipr.ini añadiendo las líneas
siguientes:
UD_SERVER_ADDRESS=169.144.50.48
X_FORWARD_AVAILABLE=0
Debe observarse que cuando se hace una llamada
desde un dispositivo de unidifusión a una ViPr, la llamada debe ser
enviada al UAM. Para ello, se realiza la configuración apropiada en
el dispositivo de unidifusión, véase para ello la documentación
específica del dispositivo de unidifusión.
\vskip1.000000\baselineskip
Las llamadas que se originan en el UD a un ViPr
son encaminadas al UAM. Una manera de alcanzar esto es programando
el UD para dirigir/desviar todas las llamadas al UAM. También, el
eventual destino de las llamadas (por ejemplo V1) es especificado
en la petición de llamada al UAM. Típicamente, esta dirección será
la Al campo en el mensaje de SIP. Estas configuraciones son
realizadas en el UD o en el servidor de SIP.
Además, cuando el UAM recibe una petición de
llamada desde un UD, la envía a un servidor Marshall de pasarela
para llevar a cabo comprobaciones de validez del participante
llamado. Esta dirección de pasarela puede ser especificada en el
fichero de vipr.ini
GatewayMarshallServer=sip.eng.fore.com:5065
\vskip1.000000\baselineskip
- ATM
- Asynchronous Transference Mode (Modo de Transferencia Asíncrona)
- ISDN
- Integrated Services Digital Network (Red Digital de Servicios Integrados)
- IP
- Internet Protocol (Protocolo de Internet)
- LAN
- Local Area Network (Red de Área Local)
- MC
- Multicast (Multidifusión) (IP)
- MCMU
- Media Cross Connect and Mixer (Conexión Cruzada y Mezclador de Medios de Comunicación)
- MCU
- Media Conferencing Unit (Unidad para Realizar una Conferencia con Medios de Comunicación)
- PBX
- Private Branch Exchange (Central Secundaria Privada) (panel de conmutación telefónica privado)
- PCM
- Pulse-Code Modulation (Modulación por Codificación de Impulsos)
- PMP
- Point-to-Multipoint (Punto a Multipunto) (ATM)
- POTS
- "Plain Old Telephone System" (Sistema Telefónico Antiguo Plano)
- PRI
- Primary Rate Interface (Interfaz para Velocidad de Tansmisión Primario) (ISDN)
- PSTN
- Public Switched Telephone Network (Red Telefónica Conmutada Pública)
- SBU
- SIP back-to-back user agent (Agente de usuario ininterrumpido de SIP)
- SIP
- Session Initiation Protocol (Protocolo de Iniciación de Sesión)
- SVC
- Switched Virtual Circuit (Circuito Virtual Conmutado) (ATM)
- UAM
- Unicast Audio Mixer (Mezclador de Audio de Unidifusión)
- ViPr^{TM}
- Virtual Presence System (Sistema de Presencia Virtual)
- WAN
- Wide Area Network (Red de Área Extendida)
Aunque la invención se ha descrito con detalle
en las realizaciones anteriores para propósitos de ilustración, se
debe entender que tal detalle es únicamente para ese propósito y que
los expertos pueden hacer variaciones sin separarse del espíritu y
alcance de la invención excepto como puede describirse mediante las
siguientes reivindicaciones.
Claims (18)
-
\global\parskip0.950000\baselineskip
1. Un sistema de teleconferencia (10) que comprende:una red (40); yuna pluralidad de nodos configurados para comunicarse con cada uno de los otros a través de la red con flujos de audio de conversación en vivo, estando los nodos configurados para transmitir entre ellos con el fin de formar una conferencia, siendo cada nodo capaz de detectar un estado de sobrecarga en el que hay más de un número predeterminado de flujos de audio simultáneos de conversación en vivo que están siendo transmitidos por los nodos y junto con los otros nodos configurados para controlar el número de flujos de audio que se están transmitiendo simultáneamente para acabar con el estado de sobrecarga. - 2. Un sistema como el descrito en la reivindicación 1 en el que cada nodo está configurado para determinar si debe dejar de transmitir su flujo de audio cuando se detecta el estado de sobrecarga basándose en el flujo de audio que transmite y en los flujos de audio transmitidos por los otros nodos.
- 3. Un sistema como el descrito en la reivindicación 2 en el que cada nodo está configurado para llegar a una misma decisión independientemente de los otros nodos a la vista del estado de sobrecarga sin ningún mensaje de sincronización de la red.
- 4. Un sistema como el descrito en la reivindicación 3 en el que cada nodo es un video teléfono.
- 5. Un sistema como el descrito en la reivindicación 4 en el que hay al menos 3 nodos.
- 6. Un sistema como el descrito en la reivindicación 5 en el que hay al menos 10 nodos.
- 7. Un método de proporcionar una teleconferencia que comprende las etapas de:una pluralidad de nodos que se comunican entre sí a través de una red (40) con flujos de audio de conversación en vivo que los nodos se transmiten entre sí para formar una conferencia;detección por cada nodo de un estado de sobrecarga en el que hay más de un número predeterminado de flujos de audio simultáneos de conversación en vivo que están siendo transmitidos por los nodos; ycontrolar el número de flujos de audio que se están transmitiendo simultáneamente para acabar con el estado de sobrecarga.
- 8. Un método como el descrito en la reivindicación 7 en el que la etapa de control incluye una etapa de controlar el número de flujos de audio que se están transmitiendo simultáneamente y el estado de sobrecarga con cada uno de los nodos.
- 9. Un método como el descrito en la reivindicación 8 en el que la etapa de control incluye la etapa de que cada nodo determine si debe dejar de transmitir su flujo de audio cuando se detecta el estado de sobrecarga basándose en el flujo de audio que transmite y en los flujos de audio transmitidos por los otros nodos.
- 10. Un método como el descrito en la reivindicación 9 en el que la etapa de control incluye la etapa de que cada nodo llegue a la misma decisión independientemente de que los nodos miren el estado de sobrecarga sin ningún mensaje de sincronización de la red.
- 11. Un método como el descrito en la reivindicación 10 en el que hay al menos 3 nodos.
- 12. Un método como el descrito en la reivindicación 11 en el que hay al menos 10 nodos.
- 13. Un método como el descrito en la reivindicación 12 que incluye la etapa de permitir que los nodos transmitan los flujos de audio de conversación más recientes para continuar transmitiendo sus flujos de audio.
- 14. Un método como el descrito en la reivindicación 13 en el que la etapa de permiso incluye una etapa de puntuar cada nodo, continuando la transmisión los nodos que tienen la puntuación más alta.
- 15. Un método como el descrito en la reivindicación 14 en el que la etapa de puntuación incluye la etapa de usar una cuenta de los paquetes de audio para cada uno de los participantes en los últimos 60 segundos con el fin de determinar la puntuación.
- 16. Un nodo de teleconferencia para una red (40) con otros nodos que comprende:una interfaz de red (42) que está configurada para comunicarse con los otros nodos con el fin de formar una conferencia de conversación en vivo; y
\global\parskip1.000000\baselineskip
un controlador (19) que está configurado para detectar un estado de sobrecarga en el que hay más de un número predeterminado de flujos de audio simultáneos de conversación en vivo que están siendo transmitidos por los nodos y junto con los otros nodos configurados para controlar el número de flujos de audio que se están transmitiendo simultáneamente para acabar con el estado de sobrecarga. - 17. Un nodo como el que se describe en la reivindicación 16 que incluye un altavoz (64) para reproducir los flujos de audio y un receptor de audio (58) para recibir conversación.
- 18. Un nodo como el descrito en la reivindicación 17 que incluye un dispositivo de captación de imagen para capturar imágenes en vivo.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US81447706P | 2006-06-16 | 2006-06-16 | |
| US814477P | 2006-06-16 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2327288T3 true ES2327288T3 (es) | 2009-10-27 |
Family
ID=38512535
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07252427T Active ES2327288T3 (es) | 2006-06-16 | 2007-06-14 | Sistema, metodo y nodo para limitar el numero de flujos de audio en u teleconferencia. |
Country Status (8)
| Country | Link |
|---|---|
| EP (1) | EP1868363B1 (es) |
| JP (1) | JP2008042889A (es) |
| CN (1) | CN101090329A (es) |
| AT (1) | ATE432588T1 (es) |
| CA (1) | CA2591732C (es) |
| DE (1) | DE602007001164D1 (es) |
| ES (1) | ES2327288T3 (es) |
| RU (1) | RU2398361C2 (es) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103152499B (zh) * | 2008-06-11 | 2014-12-10 | 三菱电机株式会社 | 回声消除器 |
| US8494841B2 (en) | 2008-10-09 | 2013-07-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Common scene based conference system |
| CN101459886B (zh) * | 2008-12-23 | 2011-09-21 | 中兴通讯股份有限公司 | 一种彩信网关及其实现流量控制的方法 |
| US8842152B2 (en) * | 2011-05-03 | 2014-09-23 | Mitel Networks Corporation | Collaboration appliance and methods thereof |
| NZ595638A (en) * | 2011-10-07 | 2013-09-27 | Let S Powow Ltd | Collaboration Extension System |
| CN102917201B (zh) * | 2012-07-18 | 2017-12-26 | 北京博惠聚通科技有限责任公司 | 一种基于物联网和云计算的物流调度方法及系统 |
| US8994781B2 (en) | 2013-03-01 | 2015-03-31 | Citrix Systems, Inc. | Controlling an electronic conference based on detection of intended versus unintended sound |
| EP3011564B1 (en) | 2013-06-21 | 2018-01-31 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Time scaler, audio decoder, method and a computer program using a quality control |
| ES2642352T3 (es) | 2013-06-21 | 2017-11-16 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Control de búfer de fluctuación, decodificador de audio, método y programa informático |
| EP2852092A1 (en) * | 2013-09-24 | 2015-03-25 | Alcatel Lucent | Method and system for videoconferencing |
| RU2580396C2 (ru) * | 2014-04-04 | 2016-04-10 | Александр Львович Шведов | Способ проведения виртуальных совещаний, система для проведения виртуальных совещаний, интерфейс участника виртуального совещания |
| CN106331578A (zh) * | 2015-06-26 | 2017-01-11 | 中兴通讯股份有限公司 | 一种视频会议网络流量控制方法和系统 |
| CN105141880B (zh) * | 2015-07-31 | 2018-10-02 | 小米科技有限责任公司 | 呼叫应答方法及装置 |
| WO2017068926A1 (ja) * | 2015-10-21 | 2017-04-27 | ソニー株式会社 | 情報処理装置及びその制御方法、並びにコンピュータ・プログラム |
| CN108616487B (zh) * | 2016-12-09 | 2021-09-21 | 视联动力信息技术股份有限公司 | 基于视联网的混音方法和装置 |
| WO2018126487A1 (zh) | 2017-01-09 | 2018-07-12 | 华为技术有限公司 | 一种媒体下行传输控制方法及相关设备 |
| CN109672946B (zh) * | 2019-02-15 | 2023-12-15 | 深圳市昊一源科技有限公司 | 一种无线通话系统、转发设备、终端设备及转发方法 |
| EP4018423B1 (en) * | 2019-08-19 | 2024-08-07 | Teamport Inc. | Multiple device conferencing with improved destination playback |
| US12009909B2 (en) * | 2020-09-19 | 2024-06-11 | Ibiquity Digital Corporation | Content linking multicast streaming for broadcast radio |
| WO2022092126A1 (ja) * | 2020-10-27 | 2022-05-05 | 株式会社Personal AI | 秘匿性会話可能なＷｅｂ会議システム |
| JP7260569B2 (ja) * | 2021-01-20 | 2023-04-18 | 華為技術有限公司 | メディアダウンリンク伝送制御方法及び関連するデバイス |
| US12113635B2 (en) * | 2022-09-15 | 2024-10-08 | Google Llc | Dynamic participant device management for hosting a teleconference |
| FR3141829B1 (fr) * | 2022-11-04 | 2025-03-21 | Streamwide | Procédé d’envoi d’un flux audio d’un terminal participant à une session de conférence impliquant une pluralité d’autres terminaux tiers |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6697341B1 (en) | 1998-12-16 | 2004-02-24 | At&T Corp. | Apparatus and method for providing multimedia conferencing services with selective performance parameters |
| US6650619B1 (en) * | 1999-03-17 | 2003-11-18 | Utstarcom Incorporated | Method and system for facilitating increased call traffic by reducing signaling load in an emergency mode |
| JP2001352326A (ja) * | 2000-06-08 | 2001-12-21 | Sony Corp | 通信装置、通信制御装置および通信方法 |
| US7404001B2 (en) * | 2002-03-27 | 2008-07-22 | Ericsson Ab | Videophone and method for a video call |
| US20050041646A1 (en) | 2003-06-27 | 2005-02-24 | Marconi Communications, Inc. | Audio mixer and method |
| US20050237931A1 (en) | 2004-03-19 | 2005-10-27 | Marconi Communications, Inc. | Method and apparatus for conferencing with stream selectivity |
| EP1868347A3 (en) | 2006-06-16 | 2010-07-14 | Ericsson AB | Associating independent multimedia sources into a conference call |
| JP5129989B2 (ja) | 2006-06-16 | 2013-01-30 | エリクソン アーベー | 会議レイアウト制御及び制御プロトコル |
| US7819305B2 (en) | 2008-05-15 | 2010-10-26 | York Container Company | Materials for and method for manufacturing packaging and resulting packaging |
| JP7180165B2 (ja) | 2018-07-23 | 2022-11-30 | セイコーエプソン株式会社 | ロボット、制御装置および制御方法 |
-
2007
- 2007-06-14 EP EP07252427A patent/EP1868363B1/en not_active Not-in-force
- 2007-06-14 ES ES07252427T patent/ES2327288T3/es active Active
- 2007-06-14 RU RU2007122372/09A patent/RU2398361C2/ru not_active IP Right Cessation
- 2007-06-14 AT AT07252427T patent/ATE432588T1/de not_active IP Right Cessation
- 2007-06-14 DE DE602007001164T patent/DE602007001164D1/de active Active
- 2007-06-14 JP JP2007156967A patent/JP2008042889A/ja active Pending
- 2007-06-15 CA CA2591732A patent/CA2591732C/en not_active Expired - Fee Related
- 2007-06-15 CN CN200710106746.0A patent/CN101090329A/zh active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| RU2007122372A (ru) | 2008-12-20 |
| EP1868363B1 (en) | 2009-05-27 |
| CA2591732A1 (en) | 2007-12-16 |
| EP1868363A1 (en) | 2007-12-19 |
| ATE432588T1 (de) | 2009-06-15 |
| CA2591732C (en) | 2015-11-10 |
| JP2008042889A (ja) | 2008-02-21 |
| CN101090329A (zh) | 2007-12-19 |
| DE602007001164D1 (de) | 2009-07-09 |
| RU2398361C2 (ru) | 2010-08-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2327288T3 (es) | Sistema, metodo y nodo para limitar el numero de flujos de audio en u teleconferencia. | |
| US7404001B2 (en) | Videophone and method for a video call | |
| RU2398362C2 (ru) | Соединение независимых мультимедийных источников в конференц-связь | |
| RU2396730C2 (ru) | Управление компоновкой конференции и протокол управления | |
| US20070291667A1 (en) | Intelligent audio limit method, system and node | |
| US20120086769A1 (en) | Conference layout control and control protocol | |
| US20070294263A1 (en) | Associating independent multimedia sources into a conference call | |
| US8379076B2 (en) | System and method for displaying a multipoint videoconference | |
| US7283154B2 (en) | Systems and methods for videoconference and/or data collaboration initiation | |
| CN101627576B (zh) | 多点会议视频切换 | |
| JP2005318535A (ja) | 帯域幅制御をして会議を開催する方法及び装置 | |
| JP2005318534A (ja) | ストリーム選択を行う会議開催方法及び装置 | |
| NO20111334A1 (no) | System and method for peek presence video conferencing | |
| MX2007006914A (es) | Metodo, sistema y nodo de limite de audio inteligentes. | |
| MX2007006910A (es) | Asociacion de fuentes de multimedia independientes en una llamada de conferencia. | |
| MX2007006912A (es) | Control de modelo de conferencia y protocolo de control. |