ES2539031T3 - Inhibición de una perturbación de una conferencia mono o multimedia - Google Patents

Inhibición de una perturbación de una conferencia mono o multimedia Download PDF

Info

Publication number
ES2539031T3
ES2539031T3 ES09179584.9T ES09179584T ES2539031T3 ES 2539031 T3 ES2539031 T3 ES 2539031T3 ES 09179584 T ES09179584 T ES 09179584T ES 2539031 T3 ES2539031 T3 ES 2539031T3
Authority
ES
Spain
Prior art keywords
conference
message
user
telephone
stage
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
Application number
ES09179584.9T
Other languages
English (en)
Inventor
Bertrand Bouvet
Emmanuel Gustin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Application granted granted Critical
Publication of ES2539031T3 publication Critical patent/ES2539031T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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
    • 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
    • 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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • 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/428—Arrangements for placing incoming calls on hold
    • H04M3/4285—Notifying, informing or entertaining a held party while on hold, e.g. Music On Hold

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procedimiento de comunicación que pone en relación al menos a tres usuarios en el seno de una conferencia, que comprende: - una etapa (E1) de recepción de flujos de datos (fA1, fB1, fD1) emitidos por dichos usuarios, - una etapa (E2) de mezcla de dichos flujos de datos, caracterizada por que comprende además: - una etapa (E3) de detección de un paso a comunicación monodireccional en dirección a la conferencia, de uno de dichos usuarios, - activación de una etapa (E4) de inhibición de un canal de comunicación que comprende un flujo de datos (fM) emitido por dicho usuario y recibido durante dicha etapa (E1) de recepción.

Description

15
25
35
45
55
65 E09179584
09-06-2015
DESCRIPCIÓN
Inhibición de una perturbación de una conferencia mono o multimedia
La presente invención se relaciona de manera general con el campo de las telecomunicaciones y más precisamente con los equipos que permiten poner en relación a más de dos personas en el seno de una misma conversación, también denominadas puentes de conferencia.
Un puente de conferencia de ese tipo se interrelaciona con una red de telecomunicación a la que se conectan unos usuarios. Comprende un gestor de la conferencia, que permite gestionar un número predefinido de conferencias telefónicas o multimedia en paralelo. Este gestor identifica un organizador de la conferencia por la secuencia DTMF (del inglés “Dual Tone Multi Frequency”) cuando se conecta a esta conferencia previamente reservada. Cuando se inicia la conferencia, un autómata de llamada entrante acepta automáticamente las llamadas de los participantes en la conferencia con un límite predefinido por el organizador de la conferencia. Estas llamadas se dirigen hacia una función de adquisición de los flujos de datos emitidos por los participantes en la conferencia, y posteriormente se mezclan por una función avanzada de mezcla que integra una función de detección de actividad vocal en los diferentes flujos de datos adquiridos por la función de adquisición. Los flujos así mezclados se difunden a continuación al conjunto de los participantes.
Un inconveniente de estos puentes de conferencia existentes es que estos puentes no permiten desconectar a un participante a una conferencia cuando introduce una perturbación en una conferencia telefónica, principalmente cuando se encuentra en situación de doble llamada.
En efecto, cuando un participante que dispone de los servicios de “llamada en espera” (denominada “call waiting” en inglés) y “señal de llamada”, recibe una llamada de un comunicante mientras está en conferencia telefónica o multimedia, es notificado mediante un bip sonoro. El número del comunicante se presenta sobre su terminal si no está enmascarado. Si el participante decide aceptar la llamada poniendo la conferencia en espera, los otros participantes a la conferencia reciben una música de espera difundida por la red durante toda la conversación entre este participante y su comunicante, lo que perturba grandemente la conferencia. El único medio para el organizador de la conferencia de detener esta música de espera es desconectarse entonces de la conferencia, lo que desconecta a todos los participantes, y posteriormente reconectarse sobre el puente de conferencia, para que los otros participantes se reconocen de nuevo, lo que es largo y poco práctico.
Igualmente, cuando un participante que dispone del servicio de “doble llamada” inicia una llamada saliente hacia un comunicante mientras está en conferencia telefónica o multimedia, los otros participantes en la conferencia reciben una música de espera durante toda la conversación entre este participante y su comunicante, lo que perturba la conferencia de la misma manera.
El documento US 2003/142662 A1 describe un terminal que permite a un usuario poner en conferencia varias sesiones de comunicación y poner en espera las sesiones de comunicación con el fin de comunicar con un único participante. Un inconveniente es que los participantes ya no están entonces en conferencia.
Uno de los objetivos de la invención es solucionar al menos una parte de los inconvenientes de la técnica anterior proporcionando un procedimiento de comunicación así como un dispositivo que permita inhibir unas perturbaciones sobrevenidas durante una conferencia telefónica o multimedia y causadas por los participantes que se encuentran en una situación de doble llamada.
Con este fin, la invención propone un procedimiento de comunicación que pone en relación al menos a tres usuarios en el seno de una conferencia, que comprende:
-una etapa de recepción de flujos de datos emitidos por dichos usuarios, -una etapa de mezcla de dichos flujos de datos,
caracterizada por que comprende además:
-una etapa de detección de un paso a comunicación monodireccional en dirección a la conferencia, de uno de
dichos usuarios, -activación de una etapa de inhibición de un canal de comunicación que comprende un flujo de datos emitido por
dicho usuario y recibido durante dicha etapa de recepción.
De ese modo, un dispositivo que implementa el procedimiento según la invención, tal como un puente de conferencia, detecta las situaciones de doble llamada, e impide en una situación de ese tipo que la música de espera ligada a una doble llamada y transmitida de modo monodireccional hacia ese dispositivo, perturbe una conferencia en curso. Los participantes en la conferencia que no están ligados en otra conversación están así en condiciones de continuar su reunión telefónica o multimedia, sin que sea necesaria la intervención del organizador de la conferencia.
15
25
35
45
55
65 E09179584
09-06-2015
Ventajosamente, dicha etapa de detección utiliza el valor de un parámetro del mensaje de señalización, indicativo de una conmutación al modo unidireccional de dicho canal de comunicación establecido con dicho usuario y que comprende dicho flujo de datos.
Se utiliza por ejemplo el valor de “Advertencia” de un elemento de información (en inglés “Information Element”) del mensaje “ISUP (del inglés “Integrated Services User Part”) PRG”, indicando que se conecta a una entidad de la red que difunde una música de espera, o de un atributo SDP (del inglés “Session Description Protocol”) de un mensaje “SIP (del inglés “Session Initiation Protocol”) Re-Invite” indicando que uno de los participantes no hará más que emitir unos datos en su canal de comunicación con el puente de conferencia, o incluso el valor “SendOnly” de un atributo en un mensaje “MGCP (del inglés “Media Gateway Control Protocol”) Modify Connection” procedente de uno de los participantes. La utilización de estos valores existentes en los mensajes de señalización permite liberarse de modificar los equipos que difunden la música de espera en la red para que estos equipos envíen por ejemplo unos DTMF específicos que señalicen el comienzo o el final de la transmisión de una música de espera. En efecto en esta alternativa de implementación se utilizan unos DTMF específicos, es más fácil en el puente de conferencia detectar la llegada de una perturbación en la conferencia.
Ventajosamente, el procedimiento de comunicación según la invención comprende además:
-una etapa de detección de una conmutación hacia la conferencia por dicho usuario, -activación de una etapa de reactivación de dicho canal de comunicación previamente inhibido.
Esta característica ventajosa del procedimiento de comunicación según la invención permite a un participante en doble llamada volver a conmutar a la conferencia sin tener que desconectarse de ésta y posteriormente volverse a conectar a ella. En efecto cuando el puente de conferencia detecta una situación de doble llamada, bloquea el flujo de datos procedente del participante en esta situación. Es necesario por tanto que el puente de conferencia reactive el canal de comunicación que comprende el flujo de datos emitidos por el participante para que éste pueda ponerse de nuevo en relación con los otros participantes.
Ventajosamente, dicha etapa de detección de una conmutación hacia la conferencia utiliza el valor de un parámetro del mensaje de señalización, indicativo de una conmutación a modo bidireccional de dicho canal de comunicación establecido con dicho usuario.
Simétricamente a la detección de la difusión de una música de espera por una entidad de red ligada a la doble llamada, se utiliza por ejemplo el valor “Levantamiento de la advertencia” de un elemento de información del mensaje “ISUP PRG”, cuando el puente de conferencia dialoga con la red utilizando este protocolo.
La invención se refiere igualmente a un dispositivo que comprende unos medios de puesta en relación de al menos tres usuarios en el seno de una conferencia, comprendiendo dichos medios de puesta en relación unos medios de recepción de flujos de datos emitidos por dichos usuarios, y unos medios de mezcla de dichos flujos de datos, estando dicho dispositivo caracterizado por que comprende además unos medios de detección de un paso a comunicación monodireccional en dirección a la conferencia, de uno de dichos usuarios, activando unos medios de inhibición de un canal de comunicación que comprende un flujo de datos emitidos por dicho usuario en la salida de dichos medios de recepción.
La invención se refiere finalmente a un programa de ordenador que comprende unas instrucciones para poner en práctica el procedimiento de comunicación según la invención, cuando se ejecuta en un ordenador.
El dispositivo y el programa de ordenador según la invención presentan unas ventajas análogas a las del procedimiento de comunicación según la invención.
Surgirán otras características y ventajas con la lectura de un modo de realización preferido descrito con referencia las figuras en las que:
-la figura 1 representa una red de telecomunicaciones en la que se implementa el procedimiento de comunicación
según la invención, -la figura 2 representa unas etapas del procedimiento de comunicación según la invención en este modo de
realización de la invención, -la figura 3 representa la primera parte de un diagrama de flujo que ilustra un caso de uso del procedimiento de
comunicación según la invención, -la figura 4 representa la segunda parte de este diagrama de flujo, -y la figura 5 representa la tercera y última parte de este diagrama de flujo.
Según un modo preferido de realización de la invención, el procedimiento de comunicación según la invención se implementa en un puente de conferencia multimedia CONF, representado en la figura 1, y conectado a una red RES2 de voz sobre IP (del inglés “Internet Protocol”), que utiliza el protocolo SIP. La red RED2 se conecta a una red RED1, que es una red RTC (Red Telefónica Conmutada)-RDSI (Red Digital de Servicios Integrados). La interfaz
15
25
35
45
55
65 E09179584
09-06-2015
entre estas dos redes RED1 y RED2 se asegura mediante:
-una pasarela MGW de conversión de flujos de medios, denominada comúnmente “Media Gateway”, -y una pasarela de interconexión MGCF que implementa la función denominada comúnmente “Media Gateway
Control Function”, que efectúa la conversión protocolaria entre estas dos redes, y que controla la pasarela MGW.
La red RED1 se conecta igualmente a una red móvil RED3 de segunda o tercera generación por medio de una pasarela GMSC (del inglés Gateway Mobile Switching Center).
El puente de conferencia CONF comprende varios módulos de programa y/o materiales:
-un gestor GC de conferencia, que permite gestionar varias conferencias en paralelo sobre el puente de
conferencia CONF; este gestor GC identifica una conferencia mediante un número de teléfono y una secuencia
DTMF que le comunica el organizador de esta conferencia, -una interfaz de Ethernet IE que implementa la capa de transporte de IP, -un autómata AA de procesamiento de la llamada entrante, que dialoga en protocolo SIP con la red RED2, -un módulo AF de adquisición de flujos de medios, que permite adquirir los flujos de medios emitidos por unos
participantes en una conferencia, -un módulo MF que implementa una función de mezcla de los flujos de medios que le transmite el módulo AF para
una misma conferencia, utilizando esta función de mezcla una función de detección de actividad vocal en cada
uno de los flujos. El módulo MF difunde a continuación los flujos mezclados hacia los puertos de salida,
correspondiendo cada uno a un participante en la conferencia.
Los módulos AF de adquisición de flujos de medios, y MF de mezcla, forman parte de un módulo TF de procesamiento del flujo de medios.
Se ha de observar que se pueden concebir otras implementaciones de la invención. Por ejemplo como variante, si el puente de conferencia CONF se interrelaciona con la red RED1, comprende una interfaz RDSI T2 en lugar de una interfaz Ethernet, y un autómata de procesamiento de llamada que utiliza el protocolo RDSI para procesar las llamadas entrantes. Igualmente si como variante el puente de conferencia CONF se interrelaciona con una red de voz sobre IP utilizando el protocolo H.323 en lugar del protocolo SIP, el autómata de procesamiento de llamada del puente de conferencia CONF dialoga entonces en H.323 con esta red. Además, en este modo de realización de la invención, la invención se implementa en un puente de conferencia multimedia interconectado a la red RED2, pero en otros modos de realización, la invención se implementa por ejemplo en la pasarela MGW, o en un PBX (Private Branch Exchange) o en una pasarela doméstica (por ejemplo: Livebox Orange), o incluso en un terminal. Finalmente la invención es aplicable tanto a las conferencias multimedia como a las conferencias telefónicas mono-media.
Se considera ahora un caso de utilización del procedimiento de comunicación según la invención, durante una conferencia telefónica entre el usuario de un teléfono fijo TA, conectado a la red RED1 por medio de un autoconmutador telefónico privado PBX, el usuario de un teléfono fijo TB conectado directamente a la red RED1, y el usuario de un teléfono fijo TD conectado a la red RED2. El auto-conmutador PBX y el usuario del teléfono TB se unen en la red RED1 al Conmutador de Autonomía de Encaminamiento CAA.
Con referencia a la figura 2, el procedimiento de comunicación según la invención se representaba bajo la forma de un algoritmo que comprende unas etapas E1 a E6.
La etapa E1 es la recepción, por el puente de conferencia CONF, de los flujos de datos procedentes de los usuarios de los teléfonos TA, TB y TD conectados al puente de conferencia CONF. Se considera en efecto en esta etapa que la conferencia telefónica ya está establecida entre estos tres usuarios. En esta etapa E1, los flujos de datos son unos flujos de voz transportados sobre RTP (del inglés “Real-time Transport Protocol”) y son adquiridos por el módulo AF de adquisición de los flujos. El módulo AF, envía, durante esta etapa E1 de recepción, los flujos de datos adquiridos de ese modo y no inhibidos al módulo de mezcla MF.
Se denomina flujo de datos “inhibido”, en este modo de realización de la invención, a un flujo de datos para el que el autómata AA tiene bloqueado el puerto de entrada a la altura del módulo MF de mezcla. Al comienzo de la conferencia telefónica entre los tres usuarios de los teléfonos TA, TB y TD, ninguno de los flujos de datos procedentes de estos usuarios están inhibidos, no efectuándose el bloqueo de un puerto de entrada en el módulo MF por el autómata AA más que durante la etapa E4, condicionalmente a la detección de un evento.
Se ha de observar que se pueden concebir varias implementaciones de los medios de inhibición del flujo de datos procedentes de un participante en una conferencia según la invención. En efecto, es suficiente para inhibir este flujo de datos, bloquear no importa dónde en su camino en el puente de conferencia CONF, siempre que no entre en el módulo MF de mezcla. De ese modo es suficiente que el autómata AA bloquee el puerto de entrada de este flujo a la altura del módulo de mezcla MF, o también el puerto de salida del módulo AF de adquisición.
La etapa E2 es la mezcla de los flujos de datos recibidos por el módulo MF de mezcla durante la etapa E1. Esta
15
25
35
45
55
65 E09179584
09-06-2015
etapa tiene lugar durante la etapa E1 y utiliza una detección de actividad vocal en cada uno de los flujos correspondientes a los usuarios de los teléfonos TA, TB y TD. El módulo MF transmite continuamente los flujos mezclados de ese modo hacia cada uno de los usuarios de los teléfonos TA, TB y TD sobre uno de los puertos de salida apropiados. Más precisamente, el módulo MF envía:
-un flujo de datos que corresponde a la mezcla de los flujos de datos recibidos desde los teléfonos TA y TB al
usuario del teléfono TD, -un flujo de datos que corresponde a la mezcla de los flujos de datos recibidos desde los teléfonos TB y TD al
usuario del teléfono TA, -y un flujo de datos que corresponde a la mezcla de los flujos de datos recibidos desde los teléfonos TA y TD al
usuario del teléfono TB.
Se supone ahora que el usuario de un teléfono móvil TC, conectado a la red móvil RED3, llama al usuario del teléfono fijo TB, estando éste abonado al servicio “llamada en espera”, y que el usuario del teléfono fijo TB acepta la llamada. La etapa siguiente es entonces la etapa E3.
Se ha de observar que en la hipótesis de que no hubiera una situación de doble llamada durante la conferencia telefónica, el puente de conferencia CONF no implementaría más que las etapas E1 y E2, y el procedimiento de comunicación según la invención no se utilizaría.
La etapa E3 es la detección de un paso a doble llamada de uno de los usuarios. Esta etapa se implementa por el autómata AA de procesamiento de la llamada entrante, mediante análisis de los mensajes de señalización SIP procedentes de los teléfonos TA, TB y TD, durante toda la duración de la conferencia telefónica. Más precisamente, el autómata AA detecta una situación de doble llamada cuando recibe un mensaje SIP “Re-Invite” que tenga por origen una situación de doble llamada en al menos uno de los teléfonos TA, TB o TD, comprendiendo este mensaje en sus parámetros SDP un atributo que tiene el valor “SendOnly”. En el caso del uso presentemente descrito, el autómata AA detecta la recepción de un mensaje SIP de ese tipo que tiene por origen la situación de doble llamada del teléfono TB. Este mensaje es de hecho la traducción por la pasarela MGCF de un mensaje “ISUP PRG” (del inglés “PROGRESS”) enviado por el conmutador CAA a la pasarela MGCF para señalizar la difusión unidireccional de una música de espera, hacia el primer interlocutor del usuario del teléfono TB, es decir el puente de conferencia CONF. La pasarela MGCF traduce este mensaje mediante una renegociación de códigos según el procedimiento SIP “Re-Invite”, que indica al punto de la conferencia CONF que la comunicación se convierte en unidireccional hacia el puente de conferencia CONF.
Se ha de observar que en esta etapa E3, el puerto de salida del módulo de mezcla MF que corresponde al usuario del teléfono TB está igualmente bloqueado, puesto que la conexión correspondiente a este usuario se ha convertido en mono-direccional desde el conmutador CAA hacia el puente de conferencia CONF, a continuación de la renegociación de códigos.
Además durante esta etapa E3, el gestor de conferencia GC presenta por ejemplo en una interfaz de control dedicada al master de la conferencia, una indicación de que el usuario del teléfono TB ha salido temporalmente de la conferencia.
En una variante en la que el puente de conferencia CONF se interrelaciona con la red RED1 mediante una interfaz RDSI T2, en esta etapa E3, el autómata AA de procesamiento de la llamada detecta una situación de doble llamada cuando recibe de la red un mensaje “ISUP PRG” que comprende el elemento de información “Advertencia”, que indica una conexión a una entidad de la red que difunde una música de espera.
Igualmente en otra variante en la que el puente de conferencia CONF está integrado en la pasarela MGW, en esta etapa E3 el autómata AA de procesamiento de la llamada detecta una situación de doble llamada cuando recibe de uno de los participantes en la conferencia un mensaje “MGCP Modify Connection” que contiene un atributo que tenga al valor “SendOnly”.
Finalmente en una variante en la que el puente de conferencia CONF se interrelaciona con una red de voz sobre IP utilizando el protocolo H.323, en esta etapa E3, el autómata AA de procesamiento de llamada detecta una situación de doble llamada cuando uno de los participantes en la conferencia le implica en un procedimiento de renegociación de capacidad denominado procedimiento “TerminalCapabilitySet = Null” con negociación de capacidad en modo “SendOnly”.
La etapa siguiente E4 es de inhibición del canal de comunicación correspondiente al flujo de datos emitidos por el participante para el que el autómata AA ha detectado una situación de doble llamada en la etapa E3. Para ello, el autómata AA de procesamiento de la llamada inhibe el puerto de entrada del módulo MF de mezcla correspondiente al flujo de datos emitido por este participante, en este caso el usuario del teléfono TB. Esta etapa E4 es activada por la etapa E3 y tiene lugar en paralelo con las etapas E1 de recepción y E2 de mezcla de los flujos de datos no inhibidos. Se supone ahora que el usuario del teléfono fijo TB conmuta a la conferencia telefónica, o bien poniendo al usuario
15
25
35
45
55
65 E09179584
09-06-2015
del teléfono TC en espera, o bien liberando la comunicación con el usuario del teléfono TC.
La etapa E5 siguiente es entonces la detección de la conmutación del usuario del teléfono TB a la conferencia telefónica. Para ello, el autómata AA de llamada entrante detecta la recepción del mensaje SIP “Re-Invite” de parte del teléfono TB, comprendiendo este mensaje en sus parámetros SDP un atributo que tiene el valor “SendRecv”. Este mensaje es de hecho la traducción por la pasarela MGCF de un mensaje “ISUP PRG” que incluye el elemento de información “Levantamiento de la advertencia” enviado por el conmutador CAA a la pasarela MGCF para señalizar la retoma de una comunicación bidireccional con el puente de conferencia CONF. La pasarela MGCF traduce este mensaje por una renegociación de códigos según el procedimiento SIP “Re-Invite”, que indica al puente de conferencia CONF que la comunicación vuelve a hacerse bidireccional con el puente de conferencia CONF.
Durante esta etapa E5, el gestor de la conferencia GC señaliza al master de la conferencia en la interfaz de control dedicada, que el usuario del teléfono TB ha vuelto a la conferencia.
En la variante en la que el puente de conferencia CONF se interrelaciona con la red RED1 mediante una interfaz RDSI T2, en esta etapa E5, el autómata AA de procesamiento de la llamada detecta la conmutación del usuario del teléfono fijo TB a la conferencia cuando recibe de éste un mensaje “ISUP PRG” que incluye el elemento de información “Levantamiento de la advertencia”, que indica que se retoma una comunicación bidireccional.
Igualmente en la variante en la que el puente de conferencia CONF está integrado en la pasarela MGW, en esta etapa E5 el autómata AA de procesamiento de la llamada detecta la conmutación del usuario del teléfono fijo TB a la conferencia cuando recibe de éste un mensaje “MGCP Modify Connection” que contiene un atributo que tenga el valor “SendRecv”.
Finalmente en la variante en la que el puente de conferencia CONF se interrelaciona con una red de voz sobre IP utilizando el protocolo H.323, en esta etapa E5 el autómata AA de procesamiento de la llamada detecta la conmutación del usuario del teléfono fijo TB a la conferencia cuando éste le implica en un procedimiento de renegociación de capacidad “TerminalCapabilitySet = Null” con negociación de capacidad en modo “SendReceive”.
La etapa siguiente E6, activada por la etapa E5, es la reactivación del canal de comunicación que transporta un flujo de datos procedente del usuario del teléfono TB, en la entrada del módulo MF de mezcla. Para ello, el autómata AA de procesamiento de la llamada reactiva el puerto de entrada del módulo MF de mezcla correspondiente al flujo de datos recibido por el puente de conferencia CONF procedente del usuario del teléfono TB. Se ha de observar que paralelamente a estas etapas E5 y E6, el puerto de salida del módulo MF de mezcla correspondiente al usuario del teléfono TB es reactivado igualmente por el autómata AA de procesamiento de la llamada entrante, debido al cambio de la conexión con este usuario a modo bidireccional, que tiene lugar en paralelo a estas etapas.
Por supuesto las etapas E5 y E6 del procedimiento de comunicación según la invención no tienen lugar más que cuando uno de los participantes en una conferencia telefónica en situación de doble llamada retoma la conferencia telefónica. Además se ha de observar que en este ejemplo de utilización de la invención, las etapas E3 y E4 se activan cuando una llamada entrante hacia uno de los usuarios de los teléfonos TA, TB y TD es aceptada por este usuario, pero las etapas E3 y E4 se activan igualmente por una llamada saliente de uno de estos usuarios, cuando éste está abonado al servicio “doble llamada”.
Además en este ejemplo de utilización de la invención, el procedimiento de comunicación según la invención se utiliza por unos usuarios de teléfono fijo en conferencia telefónica, pero el procedimiento de comunicación según la invención es utilizable igualmente por unos usuarios de otros tipos de terminales, por ejemplo unos terminales móviles o unos ordenadores personales, en conferencia telefónica o multimedia.
Se describe ahora, en relación con las figuras 3, 4 y 5, un diagrama de flujo que corresponde al caso de utilización descrito anteriormente en relación con la figura 2.
Se describe inicialmente el establecimiento de la conferencia telefónica. El usuario del teléfono TA, que se le supone en este caso organizador de la conferencia telefónica, compone un número reservado para esta conferencia, lo que provoca el envío de un mensaje m1 propietario hacia el auto-conmutador PBX. Este mensaje m1 se representa en trazo recto en la figura 3, los mensajes en trazo recto indican una comunicación digital en oposición a los mensajes en trazo ondulado que indican una comunicación analógica.
Con la recepción del mensaje m1, el auto-conmutador PBX envía un mensaje m2 “RDSI Setup” hacia el conmutador CAA, que transmite en respuesta al auto-conmutador PBX un mensaje m3 “RDSI Call Proceeding” y transmite en paralelo un mensaje m4 “ISUP Initial Address Message” a la pasarela MGCF.
Con la recepción del mensaje m4, la pasarela MGCF solicita a la pasarela MGW la creación de una conexión en modo recepción y le envía un mensaje m5 “MGCP Create Connection (RecvOnly, G.711 A, G.729A, RFC4733)” que comprende en los atributos una indicación "RecvOnly" del modo de recepción, los códigos compatibles de una indicación del procesamiento de los DTMF según la norma RFC4733. La pasarela MGW responde positivamente a
15
25
35
45
55
65 E09179584
09-06-2015
la pasarela MGCF mediante un mensaje m6 “MGCP 200 OK (SDP MGW, a=RecvOnly)” que comprende los parámetros de sesión SDP de la pasarela MGW.
Posteriormente la pasarela MGCF envía un mensaje m7 “SIP Invite” de parte del usuario del teléfono TA, que comprende principalmente una oferta de los parámetros SDP que corresponden a la pasarela MGW, una indicación de una conexión bidireccional gracias al atributo “SendRecv”, el número reservado para la conferencia y una indicación del procesamiento de los DTMF según la norma RFC4733, al puente de conferencia CONF. En el puente de conferencia CONF, este mensaje, como los otros mensajes procedentes de la red RED2, son procesados por el autómata AA de procesamiento de la llamada entrante. El puente de conferencia CONF responde a la pasarela MGCF mediante un mensaje m8 “SIP Trying”, y posteriormente mediante un mensaje m9 “SIP 200 OK” que contiene una respuesta SDP que corresponde al puente de conferencia CONF, y una indicación de una conexión bidireccional gracias al atributo “SendRecv” para establecer la conexión con el teléfono TA.
Con la recepción del mensaje m9, la pasarela MGCF envía un mensaje m10 “ISUP CON” al conmutador CAA, que transmite este mensaje bajo la forma de un mensaje m11 “RDSI Connect” al auto-conmutador PBX, que transmite a su vez este mensaje bajo la forma de un mensaje propietario m12 al teléfono TA.
En paralelo al envío del mensaje m10, la pasarela MGCF envía a la pasarela MGW un mensaje m13 “MGCP Modify Connection” que comprende el atributo “SendRecv” para que ésta modifique la conexión anteriormente creada entre la red RED1 y la red RED2, con el fin de convertirla en bidireccional. La pasarela MGW responde positivamente a este mensaje m13 mediante un mensaje m14 “MGCP 200 OK”. Con la recepción de este mensaje m14, la pasarela MGCF envía un mensaje de acuse de recibo m15 “SIP ACK” al puente de conferencia CONF.
Se establece entonces una conexión bidireccional entre el teléfono TA y el puente de conferencia CONF. Sobre esta conexión, el puente de conferencia CONF recibe un flujo de datos fA1 procedentes del teléfono TA, y transmite un flujo de datos fACC al teléfono TA. Los flujos de datos se transmiten utilizando el códec G.711 en la red RED1, efectuando la pasarela MGW una conversión de los flujos de datos en medios RTP codificados utilizando el códec G711 o G.729 en función de las capacidades del puente de conferencia CONF y del resultado de la negociación de los códec antes de transmitirlos a la red RED2, e inversamente.
El flujo fACC corresponde a un anuncio de recepción que invita al usuario del teléfono TA a componer un código de acceso para entrar en conferencia.
El usuario del teléfono TA numera este código de acceso (DTMF), lo que corresponde al flujo de datos fA2 que se recibe el puente de conferencia CONF procedente del usuario del teléfono TA.
El flujo de datos fA1 representa las palabras pronunciadas por el usuario del teléfono TA durante toda la conferencia telefónica en la conexión bidireccional que acaba de ser creada. Su duración es por tanto la de la conferencia telefónica, contrariamente al flujo fACC y fA2 cuya duración es más puntual.
Posteriormente otro usuario, por ejemplo el usuario del teléfono TB, llama al número reservado para la conferencia, lo que da lugar a la transmisión del mensaje m16 en el formato V.23 (protocolo definido por el CCITT (“Comité Consultivo Internacional Telegráfico y Telefónico”)) entre el teléfono TB y el conmutador CAA. Éste transmite entonces un mensaje m17 “ISUP Initial Address Message” a la pasarela MGCF, que solicita a la pasarela MGW crear una conexión entre el teléfono TB y el puente de conferencia CONF, inicialmente en modo recepción y posteriormente bidireccional, de manera equivalente a la creación de la conexión entre el puente de conferencia CONF y el usuario del teléfono TA descrita anteriormente. Debido a ello la creación de esta nueva conexión se detalla un poco menos a continuación.
Para crear esta conexión, la pasarela MGCF envía un mensaje m18 MGCP “Create Connection” a la pasarela MGW con el atributo de dirección “RecvOnly”, la pasarela MGW responde positivamente a este mensaje mediante un mensaje m19 “MGCP 200 OK”. Posteriormente la pasarela MGCF envía un mensaje m20 “SIP Invite” al puente de conferencia CONF, que comprende en el atributo una indicación de una conexión bidireccional gracias al atributo “SendRecv”, el puente de conferencia CONF le responde mediante un mensaje m21 “SIP Trying” y posteriormente mediante un mensaje m22 “SIP 200 OK” que comprende una respuesta SDP con sus propios parámetros y el atributo “SendRecv”. Con la recepción del mensaje m22, la pasarela MGCF envía un mensaje m23 “ISUP CON” al conmutador CAA, que transmite este mensaje bajo la forma del mensaje m24 en el formato V.23 al teléfono TB. En paralelo, la pasarela MGCF envía un mensaje m25 “MGCP Modify Connection” para hacer bidireccional la conexión anteriormente creada por la pasarela MGW, respondiendo ésta positivamente al mensaje m25 mediante un mensaje m26 “MGCP 200 OK”. Con la recepción del mensaje m26, la pasarela MGCF envía un mensaje de acuse de recibo m27 “SIP ACK” al puente de conferencia CONF, lo que acaba de establecer la conexión entre el teléfono TB y el puente de conferencia CONF.
En esta conexión, el puente de conferencia CONF recibe un flujo de datos fB1, representado en la figura 4, procedente del teléfono TB. El flujo de datos fB1 representa las palabras pronunciadas por el usuario del teléfono TB desde su entrada en la conferencia telefónica y hasta la difusión de una música de espera por el conmutador CAA
15
25
35
45
55
65 E09179584
09-06-2015
cuando conmuta, más adelante, a una situación de doble llamada.
Los flujos de datos fA1 y fB1 son transmitidos por el módulo AF de adquisición al módulo MF de mezcla, que a su vez transmite:
-un flujo de datos fAB que corresponde a las palabras del usuario del teléfono TA, al usuario del teléfono TB, -y un flujo de datos fBA que corresponde a las palabras del usuario del teléfono TB, al usuario del teléfono TA.
Posteriormente el usuario del teléfono TD llama al número reservado para la conferencia, lo que se traduce en la transmisión del mensaje m28 “SIP Invite” entre el teléfono TD y el puente de conferencia CONF, este mensaje m28 comprende un atributo “SendRecv” que indica que se requiere una conexión bidireccional. Con la recepción del mensaje m28, el puente de conferencia CONF responde al teléfono TD mediante un mensaje m29 “SIP Trying” y posteriormente mediante un mensaje m30 “SIP 200 OK” que comprende una respuesta SDP con sus propios parámetros y el atributo “SendRecv”. El teléfono TD acusa recibo a continuación del mensaje m30 mediante un mensaje m31 “SIP ACK”, lo que acaba de establecer una conexión bidireccional entre el teléfono TD y el puente de conferencia CONF.
En esta conexión, el puente de conferencia CONF recibe un flujo de datos fD1, procedentes del teléfono TD. El flujo de datos fD1 representa las palabras pronunciadas por el usuario del teléfono TD durante toda la duración de la conferencia telefónica. Este flujo fD1 se transmite por el módulo AF de adquisición al módulo MF de mezcla, que transmite de vuelta:
-un flujo de datos fABD1 que corresponde a las palabras de los usuarios de los teléfonos TA y TB, al usuario del
teléfono TD, -un flujo de datos fBDA1 que corresponde a las palabras de los usuarios de los teléfonos TB y TD, al usuario del
teléfono TA, -y un flujo de datos fADB1 que corresponde a las palabras de los usuarios de los teléfonos TA y TD, al usuario del
teléfono TB.
Los nuevos flujos de datos fBDA1 y fADB1 transmitidos respectivamente al usuario del teléfono TA y al usuario del teléfono TB, a continuación de la llegada del usuario del teléfono TD a la conferencia telefónica, sustituyen a los flujos de datos respectivos fBA y fAB que se estaban transmitiendo anteriormente al usuario del teléfono TA y al usuario del teléfono TB por parte del módulo MF de mezcla.
Estando ahora los tres usuarios de los teléfonos TA, TB y TD en conferencia telefónica, el usuario del teléfono TC compone el número de teléfono del usuario del teléfono TB, lo que se traduce en el conmutador CAA por la recepción del mensaje m32 “ISUP IAM”. Puesto que el usuario del teléfono TB está abonado al servicio “señal de llamada” y este último está activo, el conmutador CAA notifica entonces esta doble llamada al usuario del teléfono TB en un mensaje m33 en el formato V.23, lo que provoca la emisión por parte del teléfono TB de un bip sonoro acompañado de la presentación del número del teléfono TC si este último no está enmascarado.
El usuario del teléfono TB acepta esta doble llamada presionando sobre la tecla “R2” de su teléfono TB, que envía entonces un mensaje m34 al conmutador CAA para notificarle esta elección. El conmutador CAA envía entonces a la pasarela GMSC un mensaje m35 “ISUP CON”, lo que acaba de establecer una conexión con el usuario del teléfono TC. Esta conexión se materializa por el flujo de datos fBC bidireccional en la figura 4.
En paralelo al envío del mensaje m35, el conmutador CAA envía un mensaje m36 “ISUP PRG” que incluye el elemento de información “Advertencia” a la pasarela MGCF, representada en la figura 5, para transformar la conexión bidireccional entre el usuario del teléfono TB y el puente de conferencia CONF en una conexión unidireccional del conmutador CAA hacia el puente de conferencia CONF. En efecto, el conmutador CAA difunde por sí mismo, o por medio de un equipo dedicado, una música de espera hacia el puente de conferencia CONF. Este mensaje m36 contiene una indicación de advertencia gracias al elemento de información “Advertencia”. Esta advertencia se asocia en general a la difusión de una música de espera generada por el CAA o alguna otra entidad de la red.
La pasarela MGCF traduce este mensaje m36 en un mensaje m37 “SIP Re-Invite” que comprende en sus parámetros SDP un atributo que tiene el valor “SendOnly”, y lo envía al puente de conferencia CONF. Es el contenido de este mensaje m37 lo que permite al autómata AA de procesamiento de la llamada entrante detectar la recogida de otra llamada por el usuario del teléfono TB, mientras pone en espera al puente de conferencia CONF. En paralelo al envío del mensaje m37, la pasarela MGCF envía un mensaje m38 “MGCP Modify Connection” que comprende un atributo “SendOnly” a la pasarela MGW con el fin de modificar la conexión para convertirla en unidireccional hacia el puente de conferencia CONF. Con la recepción de este mensaje m38, la pasarela MGW modifica la conexión y responde positivamente al mensaje m38 enviando un mensaje m39 “MGCP 200 OK” a la pasarela MGCF.
En paralelo al diálogo entre la pasarela MGCF y la pasarela MGW, el puente de conferencia CONF responde
10
15
20
25
30
35
40
45
50
E09179584
09-06-2015
positivamente al mensaje m37 mediante el envío de un mensaje m40 “SIP 200 OK” que contiene una respuesta SDP con el atributo “RecvOnly” a la pasarela MGCF, que reconoce este mensaje m40 mediante el envío del mensaje m41 “SIP ACK” al puente de conferencia CONF.
El flujo de datos fM unidireccional enviado a continuación por el conmutador CAA al puente de conferencia CONF y que corresponde a una música de espera se bloquea a la altura del puente de conferencia CONF en la entrada del módulo de mezcla MF, como se representa en la figura 5.
El módulo de mezcla MF no transmite entonces más al teléfono TD que un flujo de datos fAD, que corresponde a las palabras del usuario A, y al teléfono TA un flujo de datos fDA, que corresponde a las palabras del usuario D. Los flujos fABD1, fBDA1 y fADB1 anteriormente mezclados por el módulo de mezcla MF ya no se envían por tanto a los teléfonos TD, TA y TB. Los nuevos flujos fAD y fDA duran hasta que el usuario del teléfono TB vuelve a conmutar a la conferencia telefónica.
El usuario del teléfono TB vuelve a conmutar a la conferencia telefónica presionando sobre la tecla “R1” de su teléfono, lo que provoca el envío de un mensaje m42 al conmutador CAA para notificarle esta elección. El conmutador CAA envía entonces a la pasarela GMSC un mensaje m43 “ISUP REL”, lo que pone fin a la conexión con el usuario del teléfono TC. El conmutador CAA envía a continuación un mensaje m44 “ISUP PRG” que contiene el elemento de información “Liberación del advertencia” ligado a la conexión entre el usuario del teléfono TB y el puente de conferencia CONF, a la pasarela MGCF. Este elemento de información indica que la conexión vuelve a pasar al modo “full dúplex”, y es por tanto indicativa del carácter bidireccional de la conexión.
Con la recepción de este mensaje m44, la pasarela MGCF traduce este mensaje en un mensaje m45 “SIP Re-Invite” que comprende en sus parámetros SDP el atributo “SendRecv”, y lo envía al puente de conferencia CONF. El autómata AA de procesamiento de la llamada entrante analiza este mensaje m45 y detecta de ese modo la retoma de la conferencia telefónica por parte del usuario del teléfono TB, lo que tiene como consecuencia la reactivación del puerto de entrada correspondiente a la conexión con el usuario del teléfono TB, en el módulo MF de mezcla.
En paralelo al envío del mensaje m45, la pasarela MGCF envía un mensaje m46 “MGCP Modify Connection” que comprende un atributo “SendRecv” a la pasarela MGW con el fin de modificar esta conexión para convertirla de nuevo en bidireccional hacia el puente de conferencia CONF. Con la recepción de este mensaje m46, la pasarela MGW modifica la conexión y responde positivamente al mensaje m46 enviando un mensaje m47 “MGCP 200 OK” a la pasarela MGCF.
En paralelo al diálogo entre la pasarela MGCF y la pasarela MGW, el puente de conferencia CONF responde positivamente al mensaje m45 mediante el envío de un mensaje m48 “SIP 200 OK” que contiene una respuesta SDP con el atributo “SendRecv” a la pasarela MGCF, que acusa recibo de este mensaje m48 mediante el envío de un mensaje m49 “SIP ACK” al puente de conferencia CONF.
Una vez haya vuelto a convertirse la conexión entre el usuario del teléfono TB y el puente de conferencia CONF en bidireccional, las palabras del usuario del teléfono TB se transmiten en un flujo de datos fB2 con destino al puente de conferencia CONF, que transmite:
-un flujo de datos fABD2 que corresponde a las palabras de los usuarios de los teléfonos TA y TB, al usuario del
teléfono TD, -un flujo de datos fBDA2 que corresponde a las palabras de los usuarios de los teléfonos TB y TD, al usuario del
teléfono TA, -y un flujo de datos fADB2 que corresponde a las palabras de los usuarios de los teléfonos TA y TD, al usuario del
teléfono TB.
Los nuevos flujos de datos fBDA2 y fABD2 reemplazan a los flujos fDA y fAD anteriormente transmitidos por el módulo MF de mezcla.

Claims (5)

  1. REIVINDICACIONES
    1. Procedimiento de comunicación que pone en relación al menos a tres usuarios en el seno de una conferencia, que comprende:
    5 -una etapa (E1) de recepción de flujos de datos (fA1, fB1, fD1) emitidos por dichos usuarios, -una etapa (E2) de mezcla de dichos flujos de datos,
    caracterizada por que comprende además:
    10 -una etapa (E3) de detección de un paso a comunicación monodireccional en dirección a la conferencia, de uno de dichos usuarios, -activación de una etapa (E4) de inhibición de un canal de comunicación que comprende un flujo de datos (fM) emitido por dicho usuario y recibido durante dicha etapa (E1) de recepción.
    15
  2. 2. Procedimiento de comunicación según la reivindicación 1, caracterizado por que dicha etapa (E3) de detección utiliza el valor de un parámetro del mensaje (m37) de señalización, indicativo de una conmutación a modo unidireccional de dicho canal de comunicación establecido con dicho usuario y que comprende dicho flujo de datos (fM).
    20
  3. 3. Procedimiento de comunicación según la reivindicación 1 o 2, caracterizado por que comprende además:
    -una etapa (E5) de detección de una conmutación hacia la conferencia por dicho usuario, -activación de una etapa (E6) de reactivación de dicho canal de comunicación previamente inhibido. 25
  4. 4. Procedimiento de comunicación según la reivindicación 3, caracterizado por que dicha etapa (E5) de detección de una conmutación hacia la conferencia utiliza el valor de un parámetro del mensaje (m45) de señalización, indicativo de una conmutación a modo bidireccional de dicho canal de comunicación establecido con dicho usuario.
    30 5. Dispositivo (CONF) que comprende unos medios para poner en relación a al menos tres usuarios en el seno de una conferencia, comprendiendo dichos medios de puesta en relación unos medios de recepción (AF) de flujos de datos emitidos por dichos usuarios, y unos medios de mezcla (MF) de dichos flujos de datos, estando dicho dispositivo (CONF) caracterizado por que comprende además unos medios de detección (AA) de un paso a comunicación monodireccional en dirección a la conferencia, de uno de dichos usuarios, activando unos medios de
    35 inhibición de un canal de comunicación que comprende un flujo de datos (fM) emitidos por dicho usuario en la salida de dichos medios de recepción (AF).
  5. 6. Programa de ordenador que comprende unas instrucciones para implementar el procedimiento según una
    cualquiera de las reivindicaciones 1 a 4, cuando se ejecuta en un ordenador. 40
    10
ES09179584.9T 2008-12-18 2009-12-17 Inhibición de una perturbación de una conferencia mono o multimedia Active ES2539031T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0858787 2008-12-18
FR0858787 2008-12-18

Publications (1)

Publication Number Publication Date
ES2539031T3 true ES2539031T3 (es) 2015-06-25

Family

ID=40846956

Family Applications (1)

Application Number Title Priority Date Filing Date
ES09179584.9T Active ES2539031T3 (es) 2008-12-18 2009-12-17 Inhibición de una perturbación de una conferencia mono o multimedia

Country Status (3)

Country Link
EP (1) EP2200255B1 (es)
ES (1) ES2539031T3 (es)
PL (1) PL2200255T3 (es)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6438216B1 (en) * 1998-07-30 2002-08-20 Siemens Information And Communication Networks, Inc. Nonintrusive call notification method and system using content-specific information
US7130280B2 (en) * 2002-01-30 2006-10-31 Lucent Technologies Inc. Enhanced call service packet data terminal

Also Published As

Publication number Publication date
EP2200255A1 (fr) 2010-06-23
PL2200255T3 (pl) 2015-08-31
EP2200255B1 (fr) 2015-03-18

Similar Documents

Publication Publication Date Title
US7940705B2 (en) Method and system for blocking communication within a conference service
US8218457B2 (en) Apparatus and method for providing communication services using multiple signaling protocols
US20180077282A1 (en) Methods and systems for routing emergency service calls background
US8149261B2 (en) Integration of audio conference bridge with video multipoint control unit
US7778206B2 (en) Method and system for providing a conference service using speaker selection
EP1246395B1 (en) Token passing arrangement for a conference call bridge arrangement
US8560717B2 (en) Method and system for implementing video call service and video interworking gateway device
US8244229B2 (en) Mobile video call response
EP1026861B1 (en) System and method for distributed call signalling in telephony-over-lan networks
TWI451746B (zh) 視訊會議系統及視訊會議方法
US8116442B2 (en) Method and apparatus for audio conference bridge initiated remote device muting
KR20010104222A (ko) 펄베이시브 음성 핸드셋 시스템
US8681199B2 (en) Method of providing video-call service using general voice-call terminal and private branch exchange for performing the method
EP1863256A1 (en) A media stream bridging device and a media service system
ES2539031T3 (es) Inhibición de una perturbación de una conferencia mono o multimedia
US20060153108A1 (en) VoIP terminal capable of facsimile communication and communication method thereof
CN1976376B (zh) 一种呼叫会话的方法、ip电话系统及ip电话终端
JP2007166393A (ja) Ｉｐ電話交換装置
CN105245537A (zh) 通过开关量控制的电话系统与广播系统对接的方法及系统
CN101764896B (zh) 多方会议中增加或者拆除会议参与方的方法、设备及系统
CN101119212B (zh) 通过信令适配实体传输isdn用户-用户应用信息的方法
JP2007274201A (ja) サーバ装置
JP2011239015A (ja) ネットワーク装置及び電話システム
US8296361B1 (en) Method and system for managing conference resources
KR100393633B1 (ko) 웹폰시스템에 있어서 인터넷 호와 전화망 호 간의 외부 호포워딩방법