ES2327969T3 - Procedimiento de control del establecimiento de canales de comunicacion multimedia. - Google Patents
Procedimiento de control del establecimiento de canales de comunicacion multimedia. Download PDFInfo
- Publication number
- ES2327969T3 ES2327969T3 ES07291241T ES07291241T ES2327969T3 ES 2327969 T3 ES2327969 T3 ES 2327969T3 ES 07291241 T ES07291241 T ES 07291241T ES 07291241 T ES07291241 T ES 07291241T ES 2327969 T3 ES2327969 T3 ES 2327969T3
- Authority
- ES
- Spain
- Prior art keywords
- terminal
- protocol
- stage
- sip
- transmission
- 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
- 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/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- 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/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
Abstract
Procedimiento de control del establecimiento de canales de intercambios para permitir una transmisión de informaciones multimedia entre al menos dos terminales de comunicación (T1, T2, 4) conectados entre sí por una red (N) de telecomunicaciones, comprendiendo una etapa (51) de establecimiento de una comunicación entre un primer terminal de comunicación (T1) y un segundo terminal de comunicación (T2) mediante la utilización de aplicaciones respectivas para el control de un protocolo de señalización determinado permitiendo iniciar sesiones, el primer terminal (T1) efectuando una etapa (52) de selección de al menos un canal de intercambio de datos entre los dos terminales (T1, T2), la etapa (52) de selección se efectúa a un nivel aplicativo y la etapa (51) de establecimiento de una comunicación comprende las etapas siguientes: - una etapa (53) de emisión de al menos una solicitud por el primer terminal (T1), con destino al segundo terminal (T2), abriendo una sesión según el protocolo de señalización determinado; el procedimiento caracterizado por - una etapa (54) de envío por el segundo terminal (T2) de una respuesta representativa de una indisponibilidad para cerrar la sesión según el protocolo de señalización determinado; el procedimiento comprendiendo durante las etapas (53, 54) de emisión y de envío una etapa (55) de transmisión de informaciones adicionales además de dicho protocolo de señalización, por utilización de dicho canal de intercambio de datos seleccionado, este canal de intercambio de datos siendo accesible a través de un campo esencialmente descriptivo/explicativo de características de una sesión, dichas informaciones adicionales correspondiendo a informaciones aplicativas no necesarias a la gestión de sesiones multimedia.
Description
Procedimiento de control del establecimiento de
canales de comunicación multimedia.
La presente invención se refiere a las
telecomunicaciones que utilizan los protocolos de telefonía en IP
(Internet Protocol) o de establecimiento de sesión multimedia, y
más particularmente, con el fin de controlar el establecimiento de
canales de comunicación en una red dirigida por un operador, un
procedimiento y un sistema de gestión de sesiones multimedia.
Una red de datos bien conocida es Internet. En
un ámbito IP (Internet Protocol), la red de datos está abierta, lo
que significa que cualquier terminal puede comunicar de dos a dos,
por ejemplo utilizando un mismo protocolo de señalización. Así se
pueden crear sesiones de tipo multimedia a través de la red
Internet entre dos terminales de comunicación. La convergencia entre
las redes de voz y las redes de datos es autorizada utilizando
protocolos de señalización adaptados.
La tecnología de voz en IP o VoIP y más
generalmente las tecnologías que permiten el establecimiento de
sesiones multimedia utilizan más frecuentemente el protocolo SIP
(Session Initiation protocol), que es un estándar abierto
interoperable. Otros protocolos de señalización, por ejemplo H323,
MGCP (Media Gateway Control Protocol) y Megaco (este último
protocolo habiendo sido elegido en la norma UMTS por el 3GPP para el
control de las pasarelas Media Gateways) también pueden ser
utilizados para las sesiones multimedia.
El protocolo SIP es normalizado por el IETF
(Internet ENGINEERING Task Force) y descrito en particular por el
RFC 3261. El protocolo SIP, como los protocolos H323 y MGCP, ha
sido concebido para establecer, modificar y terminar sesiones
multimedia. Este se encarga de la autenticación y localización de
los participantes múltiples. Se encarga también de la negociación
sobre los tipos de medios utilizables por los distintos
participantes por encapsulación de los mensajes SDP (Session
Description Protocol). El protocolo SIP no transporta los datos
intercambiados durante la sesión como la voz o el video. Al ser
este protocolo independiente con respecto a la transmisión de
datos, se puede utilizar todo tipo de datos y de protocolos para
este intercambio: el protocolo RTP (Real-time
Transport Protocol) es el que asegura casi siempre las sesiones
audio y video. Un interés del protocolo SIP es que no sólo está
destinado a la voz en IP sino también a numerosas otras
aplicaciones tales como la visiofonía, la mensajería instantánea, la
realidad virtual o incluso los videojuegos.
Como todo protocolo de señalización, SIP
incorpora una fase de declaración de la red de incorporación,
posteriormente unas fases de solicitud de establecimiento de sesión
multimedia, de negociación de características del servicio
solicitado y finalmente una fase de clausura de la sesión
multimedia. El protocolo de iniciación de protocolo SIP (Session
Initiation Protocol) permite a partir de la versión v2.0
intercambios de informaciones entre las entidades en comunicación
antes de o durante la sesión multimedia. De manera conocida en sí,
estos intercambios pueden ser realizados a través de los métodos
siguientes:
- -
- INFO: permite intercambiar información que no afecte el estado de la llamada (descrito en RFC 2976). En ciertos casos este campo es utilizado para transferir tonos DTMF.
- -
- NOTIFY: permite enviar notificaciones de acontecimiento (RFC 3265).
- -
- SUBSCRIBE: permite abonarse a una notificación de acontecimientos (descrito en RFC 3265).
- -
- UPDATE: es utilizado para actualizar los parámetros de medios (véase RFC 3311);
- -
- MESSAGE: este método definido en la RFC 3428 "SIP extension for Instant Messaging" permite intercambiar mensajes instantáneos entre dos terminales.
En una red de radiotelefonía por ejemplo, la
utilización de tales protocolos (SIP/H323/MGCP) para sesiones
multimedia puede permitir intercambios de informaciones a través de
los canales de datos paralelos a los canales de voz. Pero el
inconveniente de estos métodos de intercambio de información es que
éstas no son siempre soportadas por las redes subyacentes y/o los
terminales simples.
Por lo tanto la presente invención tiene como
objeto suprimir uno o varios de los inconvenientes del estado de la
técnica anterior mientras define un procedimiento que permite
nuevas utilizaciones del protocolo de señalización al mismo tiempo
que se aprovecha al máximo las potencialidades de la
infraestructura de red que soportan este tipo de protocolo.
\newpage
Una enseñanza según la invención muestra para
ello una manera de utilizar los métodos elementales, necesarios
para el establecimiento de una sesión multimedia, y un modo de
enviarlos por el conjunto de las redes. Mediante un nuevo uso, en
conformidad con las normas, estos métodos simples son por ejemplo
capaces de resolver el problema de renegociación en tiempo real de
la calidad negociada para la sesión multimedia ya establecida.
El documento
EP-A-1650925 explica un
procedimiento de control del establecimiento de canales de
intercambios para permitir una transmisión de informaciones
multimedia entre al menos dos terminales de comunicación conectados
entre sí por una red de telecomunicaciones, comprendiendo una etapa
de establecimiento de una comunicación entre un primer terminal de
comunicación y un segundo terminal de comunicación utilizando
aplicaciones respectivas que controlan un protocolo de señalización
determinado que permite iniciar sesiones, el primer terminal
efectuando una etapa de selección de al menos un canal de
intercambio de datos entre los dos terminales, la etapa de
selección se efectúa a un nivel aplicativo y la etapa de
establecimiento de una comunicación comprende la etapa
siguiente:
- -
- una etapa de emisión de al menos una solicitud por el primer terminal, con destino al segundo terminal, abriendo una sesión según el protocolo de señalización determinado.
La invención desarrolla este procedimiento
mediante la adición de una etapa de envío por el segundo terminal
de una respuesta representativa de una indisponibilidad para cerrar
la sesión según el protocolo de señalización determinado; y el
procedimiento comprendiendo durante las etapas de emisión y de
envío una etapa de transmisión de informaciones adicionales además
de dicho protocolo de señalización, utilizando dicho canal de
intercambio de datos seleccionado, este canal de intercambio de
datos siendo accesible a través de un campo esencialmente
descriptivo/explicativo de características de una sesión, dichas
informaciones adicionales correspondiendo a informaciones
aplicativas no necesarias para la gestión de sesiones
multimedia.
La invención permite así controlar la emergencia
de soluciones a un nivel de aplicación que permite usos
inovadores/inhabituales de las infraestructuras (SIP o IMS
particularmente) de un operador de red. El funcionamiento
intrínseco del protocolo de señalización (por ejemplo SIP) se
mantiene sin cambios para poder beneficiarse de una infraestructura
de red elemental al nivel mundial. Se entiende que el procedimiento
puede permitir ampliar ventajosamente el uso de los métodos del
protocolo de señalización con el fin por ejemplo de intercambiar
informaciones de señalización con respecto al servicio y/o a su
calidad y a su entrega de otra manera que por el canal de datos
concedido (RTP) entre las entidades comunicantes. El intercambio
por esta vía inédita (a través de los campos contextuales) de
informaciones aplicativas permite asegurar un servicio en tiempo
real.
Según otra particularidad, el procedimiento
incluye una etapa de identificación por el primer terminal de al
menos un canal de intercambio de datos susceptible de ser utilizado
para la etapa de transmisión de informaciones adicionales, la
identificación siendo el resultado de una etapa de búsqueda de
canales de intercambio, en la que el primer terminal analiza al
menos una respuesta del segundo terminal a una solicitud en la que
uno de los campos esencialmente descriptivos ha sido informado con
informaciones adicionales además de dicho protocolo de
señalización.
Según otra particularidad, la etapa de búsqueda
de canales de intercambios incluye una etapa de envío por el
segundo terminal de un conjunto de mensajes de respuesta a
solicitudes del primer terminal.
Según otra particularidad, el canal de
intercambio de datos seleccionado es utilizado para difundir
informaciones multimedia de principio a fin.
Según otra particularidad, la etapa de selección
incluye una selección de varios canales de intercambio de datos
para utilizar varios métodos de transmisión de informaciones
adicionales en paralelo.
Según otra particularidad, el procedimiento
incluye una etapa de negociación de medios de comunicación en
tiempo real entre un cliente del primer terminal y un servidor a
través de una infraestructura de comunicación que posee una
capacidad para enviar datos aplicativos a través de informaciones y
de mensajes de señalización de principio a fin.
Según otra particularidad, al menos uno de los
campos sucesivos es utilizado para la etapa de transmisión de
informaciones adicionales además del protocolo SIP:
- -
- encabezamiento de los paquetes SIP donde se mencionan las características de sesión;
- -
- Descriptivo del código de respuesta;
- -
- Call ID;
- -
- Branch;
- -
- TAG.
Según otra particularidad, al menos un campo
asociado al método MENSAJE del protocolo SIP es utilizado para la
etapa de transmisión de informaciones adicionales además del
protocolo SIP.
\global\parskip0.900000\baselineskip
Según otra particularidad, al menos un campo
asociado a la información SDP de carga útil de SIP es utilizado
para la etapa de transmisión de informaciones adicionales además
del protocolo SIP, y este campo SDP en la carga útil de SIP está
definido como siendo opcional por el protocolo SIP o con una
estructura y una sintaxis que no están fijadas por el protocolo
SIP.
Según otra particularidad, un campo Call ID del
protocolo SIP es utilizado para la etapa de transmisión de
informaciones adicionales además del protocolo SIP.
Según otra particularidad, las condiciones de
consumo/uso del contenido multimedia transmitido durante dicha
etapa de transmisión son modificadas por una aplicación multimedia
consumidora del contenido multimedia sobre la recepción y la toma
en consideración de las informaciones adicionales enviadas a través
del protocolo SIP.
Según otra particularidad, las condiciones de
consumo/uso de un flujo de transmisión establecido entre los dos
terminales de comunicación son modificados por aplicaciones
multimedia consumidoras y emisoras del contenido multimedia de cada
terminal sobre la emisión, la recepción y la toma en consideración
de las informaciones adicionales enviadas a través del protocolo
SIP.
Esta toma en consideración puede ser planificada
según un protocolo compartido previamente por las dos aplicaciones
multimedia.
Según otra particularidad, el procedimiento
incluye una etapa de evaluación de una banda de paso disponible
para al menos uno de los canales de intercambios identificados
fuera de sesión.
Según otra particularidad, el procedimiento
incluye una etapa de renegociación en tiempo real de la entrega de
un servicio multimedia cuando las condiciones de uso son
modificadas a través de la emisión de información adicional a
través de la red SIP subyacente, la etapa de renegociación
comprendiendo una detección por el segundo terminal de esta
modificación de las condiciones de uso, en función de:
- -
- la evolución del entorno de redes de transporte disponibles para el segundo terminal (por ejemplo detección de una red Wifi o de redes de conectividad local y/o pervasiva);
- -
- condiciones de localización geográfica del segundo terminal (en base a una información de tipo geolocalización GPS o célula de conexión de una red móvil o red de conexión (roaming/itinerancia));
- -
- condiciones de funcionamiento del mismo segundo terminal, por ejemplo después de la modificación del entorno radio, de la energía disponible (batería), de la disponibilidad de los procesadores internos del segundo terminal (particularmente cuando este último es un terminal móvil) en función del número de tareas en ejecución en el seno de dicho terminal;
- -
- condiciones de uso y de consumo del servicio, por ejemplo pago por periodo de duración, según el horario de conexión, pago en función de la resolución visualizada y del resultado de los colores, servicio matizado según la posición geográfica, servicio que requiere un cifrado suplementario o una autenticación suplementaria ya que el segundo terminal acaba de ser localizado en una zona insegura.
Según otra particularidad, la etapa de
renegociación es realizada para modificar las condiciones de
entrega del servicio multimedia después de una acción específica
del usuario. De este modo se permite al usuario disminuir
temporalmente un consumo de banda de paso, mediante la iconificación
de un flujo de TV/Video. Dicho de otro modo, cuando las condiciones
de uso son modificadas por ejemplo al nivel del segundo terminal,
la etapa de renegociación permite modificar el tamaño de una
ventana de video visible en la pantalla.
Según otra particularidad, el procedimiento
incluye una etapa de memorización en una memoria de cada uno de los
dos terminales de una lista de los canales de intercambio
identificados y que pueden ser utilizados fuera de sesión para
transmitir informaciones multimedia.
Según otra particularidad, el protocolo de
señalización es el protocolo SIP, y la etapa de transmisión de
informaciones adicionales además de dicho protocolo incluye:
- -
- una etapa de escritura por el primer terminal de una solicitud en un formato texto;
- -
- una etapa de codificación de la solicitud;
- -
- una etapa de envío de un mensaje INVITE pasando la solicitud codificada en el campo Call-ID.
Según otra particularidad, la etapa de
transmisión de informaciones adicionales además de dicho protocolo
incluye también:
- -
- una etapa de envío de un mensaje de respuesta conteniendo una indicación de indisponibilidad temporal y en el que una respuesta a la solicitud es situada por el segundo terminal en un campo esencialmente descriptivo o explicativo;
\global\parskip1.000000\baselineskip
- -
- una etapa de confirmación de cierre de una sesión SIP, en la que el primer terminal envía al segundo terminal un mensaje de acuse de recibo ACK con el mismo campo Call-ID para indicar una buena recepción de la respuesta (definitiva) a la solicitud.
Según otra particularidad, dicho campo
esencialmente descriptivo o explicativo es el campo "Reason"
(que sirve habitualmente para el motivo de rechazo o de aceptación
de una solicitud).
Un objetivo adicional consiste en proponer en un
terminal de comunicación en red una aplicación que permite nuevas
utilizaciones del protocolo de señalización aprovechando al máximo
las potencialidades de la infraestructura de red que soporta este
tipo de protocolo.
Con este fin, la invención se refiere a un
programa de un módulo de tratamiento que puede ser cargado
directamente en la memoria de un terminal de comunicación con una
red para controlar etapas del procedimiento según la invención
cuando dicho programa está ejecutado en el terminal.
Se deducirá más claramente la invención, con sus
características y ventajas, con la lectura de la descripción
realizada en referencia a los dibujos anexos provistos en forma de
ejemplos no limitativos en los que:
- la figura 1 representa un logigrama de las
etapas del procedimiento en un modo de realización de la
invención;
- la figura 2 muestra un ejemplo de
establecimiento de intercambios de señalización propios a unas
aplicaciones de los terminales, sin interferencia con las redes SIP
subyacentes;
- la figura 3 ilustra una primera escena de
llamada que puede ser detectada utilizando un indicador de un
sistema según la invención;
- la figura 4 ilustra una segunda escena de
llamada que puede ser detectada utilizando un indicador de un
sistema según la invención;
- la figura 5 representa esquemáticamente un
contexto IP Multimedia Subsystem (IMS), en el cual una red de
operador de radiotelefonía está provista de un sistema de
vigilancia y de gestión de las solicitudes SIP según un modo de
realización de la invención.
El procedimiento según la invención tiene como
objetivo proponer métodos de intercambio de señalización a un nivel
de aplicación utilizando las especifidades del protocolo SIP u otro
protocolo de señalización, pero sin perjudicar jamás el
funcionamiento intrínseco del protocolo de señalización para poder
beneficiarse de una infraestructura de red a nivel mundial. En el
ejemplo de la figura 2, unos intercambios de señalización propios a
las aplicaciones utilizadas deben ser establecidas entre las
aplicaciones (A1, A2, A4) de los terminales (T1, T2, T4). Las
informaciones de señalización pueden ser intercambiadas entre estas
aplicaciones (A1, A2, A4) sin interferir con las redes SIP
subyacentes. El procedimiento prevé identificar una pluralidad de
posibilidades de intercambio de información en una escena sencilla
de comunicación y en forma de ejemplo no limitativo: el uso de
INVITE, respuesta y ACK y BYE.
Un método INVITE indica que la aplicación (o
usuario) correspondiente a la dirección URL SIP especificada es
invitado a participar en una sesión (el cuerpo del mensaje
describiendo esta sesión, por ejemplo: medio soportado por el
solicitante); en caso de respuesta favorable, el invitado debe
especificar los medios que soporta. Existe también el método
RE-INVITE.
El formato de los mensajes SIP se mantiene sin
cambios. Se recuerda aquí que un mensaje SIP puede ser a la vez una
solicitud de un cliente (terminal solicitante) hacia un servidor
(terminal llamado) o bien una respuesta de un servidor hacia un
cliente. Como ejemplo, una solicitud SIP de un cliente hacia un
servidor puede representarse como se indica a continuación:
Una solicitud SIP de un servidor hacia un
cliente puede representarse como se indica a continuación:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
En el caso de las solicitudes, se añade o no un
cuerpo (del mensaje) según el método utilizado. Si se trata por
ejemplo de un método INVITE, el cuerpo del mensaje de la solicitud
INVITE contiene informaciones indicando la progresión de la
solicitud. En el caso de las respuestas, el cuerpo del mensaje es
obligatorio. De esta manera, la respuesta a una solicitud INVITE
contiene en el cuerpo del mensaje una descripción de la sesión.
El abonado que utiliza una infraestructura SIP a
través de su terminal (T1) normalmente está conectado a ésta. Ha
pasado las fases de autenticación y se ha registrado ante su
servidor (3) proxy SIP. Como el abonado quiere establecer un
servicio que utiliza los principios del procedimiento según la
invención, va a lanzar una aplicación (A1) llamada cliente de su
terminal (T1) que va a "escanear" en una primera fase las
potencialidades de la infraestructura SIP utilizada. Para ello, el
cliente embarcado del abonado va a emitir una serie de solicitudes
hacia el servidor (3) de entrega del servicio o de otro abonado
(terminal T2) si el servicio solicitado es del tipo puesto a puesto
"Peer to Peer" (P2P).
El protocolo SIP se apoya en el envío de
solicitudes en el formato texto. Una solicitud utiliza un método
definido en la RFC del protocolo tal como INVITE, OPTIONS, ACK,
BYE, REGISTER, CANCEL, o MESSAGE (definido en la extensión de la
RFC). Cada solicitud contiene encabezamientos (generalmente una
decena pero el número es extensible) y eventualmente un cuerpo de
mensaje. El anexo 1 proporciona un ejemplo de solicitudes SIP
estableciendo una llamada telefónica. El proceso descrito en el
anexo 1 se refiere a la sucesión de etapas ilustradas en la figura
3. Hay que tener en cuenta que en este ejemplo se establece una
llamada: existe así un efecto sobre el comportamiento de la
infraestructura SIP.
Los campos Call-ID, branch y tag
son elegidos por el terminal emisor (T1) y enviados por la
infraestructura SIP hasta al terminal destinatario (T2). Estos
campos presentan poca exigencia de formato y pueden por lo tanto ser
utilizados fácilmente para enviar información adicional del
terminal emisor (T1) hacia el terminal destinatario (T2). En un
modo de realización de la invención, para la puesta en marcha del
procedimiento se prevén medios para utilizar este servicio previsto
por la norma. Para eso, el terminal (T1) emisor comprende un agente
de tratamiento disponiendo de scripts que permiten utilizar esos
campos.
Se entiende también que el segundo terminal (T2)
destinatario puede utilizar el campo contextual del informe para
emitir una información además del protocolo hacia el primer
terminal (T1). La recepción del mensaje de estatuto con el campo
Call ID informado con el valor emitido por el primer terminal (T1),
provee una información sobre el hecho de que el dato transmitido en
el campo "Call-ID" ha sido recibido
correctamente por el segundo terminal (T2). En paralelo, el primer
terminal (T1) puede reenviar un acuse de recibo ACK hacia el
segundo terminal (T2) para señalarle a través del TAG asociado al
campo "from" que su respuesta ha sido recibida
adecuadamente.
En referencia a la figura 2, la red (N) SIP
incluye un primer dominio (15) de protocolo IP (Internet Protocol)
que permite utilizar una topología de opciones de ruta (trazos
discontinuos) y un segundo ámbito correspondiente a una red de
radiotelefonía (16). Un dominio de tipo RTC (Red Telefónica
Conmutada) puede formar parte también de la red (N) SIP.
En un modo de realización preferido, la red (N)
SIP ilustrada en la figura 2 utiliza una arquitectura de servicio
con un subsistema IMS (IP Multimedia Subsystem), que permite
desplegar una tecnología de voz en IP. Aunque la red (N) SIP está
representada incluyendo una red de radiotelefonía (16) dotada de
estaciones y una parte con conexión alámbrica, se entiende que
cualquier conexión inalámbrica puede ser utilizada en la red (N),
la cual puede usar incluso sólo conexiones inalámbricas (radio,
Wifi, Wimax, Bluetooth®, etc.).
En el ejemplo de la figura 2, el ámbito IP (15)
dispone de una pluralidad de elementos de red, particularmente una
pasarela (2) de medios (media Gateway), un servidor (3) proxy así
como unos primero y segundo terminales de usuario (T1, T2). Cada
terminal (T1, T2) puede usar una porción de la topología de las
opciones de ruta durante el establecimiento de una comunicación con
un terminal de radiocomunicación (4), por ejemplo celular,
conectado a través de la red de radiotelefonía (16). En este caso,
el servidor (3) proxy y la pasarela (2) son utilizados. Los primero
y segundo terminales también pueden comunicar entre sí mediante la
utilización del servidor (3) proxy SIP, sin utilización de la
pasarela (2) en este caso.
En referencia a la figura 1, el procedimiento
prevé utilizar un canal de intercambio de datos, accesible a través
del protocolo de señalización, para difundir desde principio a fin
otras informaciones que las que son necesarias a la gestión de
sesiones multimedia. El procedimiento controla el establecimiento
de canales de intercambios para permitir la transmisión de
informaciones multimedia entre terminales de comunicación (T1, T2,
4) conectados entre sí por la red (N) de telecomunicaciones.
En referencia a las figuras 1 y 2, una etapa
(51) de establecimiento de una comunicación entre un primer
terminal de comunicación (T1) y un segundo terminal de comunicación
(T2) es realizada utilizando aplicaciones respectivas (A1, A2) de
gestión del protocolo de señalización. El primer terminal (T1)
efectúa una etapa (500) de búsqueda de canales de intercambios entre
los dos terminales (T1, T2). Esta etapa (500) de búsqueda de canales
de intercambios puede así permitir clasificar las posibilidades de
intercambio de informaciones aplicativas, canal de intercambio que
puede ser elegido durante una etapa ulterior (52) de selección. Una
etapa (50) de identificación por el primer terminal (T1) de al
menos un canal de intercambio puede ser realizada por el primer
terminal (T1), por ejemplo después de cada recepción de un mensaje
de respuesta a una de las solicitudes emitidas durante la etapa
(500) de búsqueda.
Durante la comunicación, el procedimiento puede
comprender:
- -
- una etapa (53) de emisión de una o varias solicitudes por el primer terminal (T1), con destino al segundo terminal (T2), abriendo una sesión según el protocolo de señalización determinada; y
- -
- una etapa (54) de envío por el segundo terminal (T2) de una respuesta representativa de una indisponibilidad para cerrar la sesión según el protocolo de señalización determinado.
\vskip1.000000\baselineskip
En un modo de realización de la invención, el
procedimiento incluye una etapa (55) de transmisión de
informaciones multimedia mediante la utilización de dicho canal de
intercambio seleccionado. Se entiende que la utilización de este
canal de intercambio no corresponde en absoluto a la vía utilizada
durante una sesión tradicional, donde la iniciación de la
transferencia de una información multimedia es efectuada mediante
el uso del cuerpo del mensaje de la solicitud SIP. De manera
ventajosa, la etapa (55) de transmisión de informaciones
adicionales a través de este canal se efectúa durante dichas etapas
(53, 54) de emisión y de envío, además de dicho protocolo de
señalización.
Esta etapa (55) de transmisión es realizada por
ejemplo después de la etapa (52) de selección del canal de
intercambio. Estas dos etapas (52, 55) son por ejemplo cada una
iniciadas a un nivel aplicativo. La etapa (500) de búsqueda de
canales de intercambios puede incluir una etapa (510) de envío por
el segundo terminal (T2) de un conjunto de mensajes de respuesta a
las solicitudes del primer terminal (T1). Esto permite identificar
y clasificar, al nivel de cada una de las aplicaciones (A1, A2),
los canales paralelos disponibles.
A continuación se describirán varios métodos
subyacentes al principio de utilización alternativo de canales de
comunicación. Aunque los ejemplos descritos se centran en el
protocolo SIP, se entenderá que esto se puede extender a otros
protocolos de señalización (SIP, H323, MGCP, Megaco).
\vskip1.000000\baselineskip
La técnica propuesta se basa en el hecho de
cambiar los datos de nivel aplicativo por encima de la señalización
utilizando de manera ingeniosa los servicios de codificación
propuestos por el protocolo SIP. Nos centramos en cuatro métodos
utilizables sólo para los intercambios combinándolos más o menos:
se pueden generalizar todos los caso de uso. Se debe entender que el
procedimiento de control no es restrictivo a estos cuatro métodos
ya que la presente solución se centra más generalmente en el hecho
de utilizar el transporte de señalización siempre presente, sea
cual sea el consumo de flujo de streaming en curso (véase el
descriptivo de los intercambios entre Bob y Alice en los anexos 1 y
2). Los cuatro métodos siguientes pueden ser citados:
- Encabezamientos de los paquetes SIP
(características de las sesiones);
- Descriptivo del código de respuesta (req 200
OK);
- Call ID (<CSeq>);
- TAG (o BRANCH).
De este modo, una multitud de encabezamientos
propuestos en un protocolo (SIP u otro) y que pueden ser incluidos
en los mensajes para precisar un poco más las características de la
sesión son susceptibles de hacer transitar información en la
señalización. De la misma manera, una respuesta a una solicitud en
un protocolo determinado, constituido por un código y una
descripción del código (por ejemplo para SIP: 200 OK, 301
Moved Permanently, 404 Not Found ...) permite
hacer transitar información en la señalización: respuesta 200
Buenos días por ejemplo.
\vskip1.000000\baselineskip
La aplicación (A1) del terminal (T1) construye
una solicitud transportada en el método MESSAGE del protocolo SIP,
cuyo formato es establecido previamente con el
servidor/destinatario al cual/con el cual desea acceder/comunicar.
El agente embarcado prueba entonces la posibilidad de comunicar con
el servidor (3) de informaciones descriptivas. Si la red (N) SIP
encamina los métodos MESSAGE, éste se define entonces como el medio
más sencillo de transportar y establecer un intercambio de datos
entre aplicaciones (A1, A2) entre dos usuarios (Bob y Alice). El
único inconveniente de los métodos MESSAGE es la posible facturación
de ésta, en caso de que la red subyacente active unos servicios de
correo electrónico instantáneo; no obstante en nuestra
problemática, la renegociación de las condiciones de calidad de la
entrega de un contenido multimedia no debe ser facturable para una
acción de señalización.
En un modo de realización de la invención, el
procedimiento de control del establecimiento de canales de
comunicación permite intercambiar informaciones de señalización
para modificar en tiempo real la naturaleza de las informaciones
intercambiadas, por consiguiente de la señalización: puede ser
perjudicial tener que utilizar un canal sometido a una facturación
para establecer e intercambiar señalización relativa a un servicio
durante la entrega.
\vskip1.000000\baselineskip
El protocolo SDP (Sesión Descripción Protocolo)
está descrito en el RFC 2327 [2.] y es utilizado para describir
sesiones multicast en los anuncios o las invitaciones de sesiones.
Esta descripción no establece obligatoriamente la estructura y la
sintaxis de todos los campos y en particular de los campos
opcionales. Entre estos campos facultativos, algunos no son
descritos sintáxicamente y por lo tanto son utilizables según la
disposición de los servicios desarrollados. Este hecho está
descrito de manera ingeniosa en el anexo 4. Como ejemplo no
limitativo, la carga útil de SIP o payload SDP contenida en los
mensajes INVITE y algunos 200 y ACK puede ser utilizada para
transferir datos, aunque no se haya establecido ninguna sesión. El
campo s= de la payload SDP es por ejemplo un nombre descriptivo de
la sesión y puede ser utilizado para transmitir datos de forma
paralela.
\vskip1.000000\baselineskip
La ausencia de formato en estos campos permite
al agente/cliente (A1) generar sus propios datos y añadirles un
dato único que permite la garantía de la unicidad del campo en su
globalidad. Es entonces fácil de imaginar, en el campo
CALL-ID, la puesta en marcha de una estructura de
tipo:
- <id única><orden/solicitud><datos asociados>
Este identificador id-único puede estar
compuesto por una información de identificación del abonado o
agente y de una variable de valor único toto
MSISDN@sfr.fr-donnée unique(temps), como
por ejemplo:
- toto_03360313130202@sfr.fr-197.118.0.10_12h3047GMT
Un ejemplo interesante es el siguiente: durante
la difusión de un contenido en streaming (establecido previamente),
el cliente (A2) del terminal (T2) que recibe el flujo de streaming
desea informar al servidor (3) o al emisor (T1) sobre la necesidad
de reducir temporalmente la calidad del flujo por razones de
disponibilidad de la unidad de tratamiento CPU al nivel del cliente
(A2). La solicitud: modificación de la calidad video al valor 7
durante 5 minutos puede ser codificada entre AA para el campo
descriptivo de la acción y PP para el campo descriptivo de los
parámetros AAvideoAAPP7_5PP.
Para transferir informaciones hacia el servidor
(3) o al cliente (A2) del abonado distante, se puede prever que el
campo call ID se escriba
toto_03360313130202@sfr.fr-197.118.0.10_12h3047GMT_AAvideoAAPP7_5PP.
El anexo 2 ilustra entonces el formato de la solicitud emitida por
la aplicación (A1) del primer terminal (T1). El interlocutor puede
reenviar entonces sus respuestas o parámetros a través del campo
Descriptivo del código de respuesta al mismo tiempo que copia el
CALL-ID. El mensaje "solicitud video 7 5 en
tratamiento" puede así ser recibido por el primer terminal (T1).
Este ejemplo puede ser más complejo mediante la integración en éste
de nociones de plazos horarios o de programación de plazos en
términos de trama RTP o de secuencias de imágenes.
El protocolo es realizado en forma de
pregunta/respuesta u orden/respuesta. La estructura
siguiente
<id única><orden/solicitud><datos asociados> permite ofrecer a cualquier nivel aplicativo un soporte (bearer) de transporte. Por lo tanto es muy sencillo reconstruir un módulo de transferencia de fichero que funcione usando los canales Call-ID y descriptivo del código de respuesta a través de los mensajes INVITE. También hay que tener en cuenta que si el informe de INVITE es negativo, ninguna sesión será establecida ni construida al nivel del servidor (3) SIP. El módulo de transferencia de fichero puede así emitir un mensaje de INVITE al nivel del Call-ID con la solicitud siguiente: <toto@MSISDN@frnce@sfr.net><modificar calidad video><7, 5>, es decir modificar la calidad de video seleccionando el nivel 7, para una duración de 5 minutos. Al final del anexo 2 se ilustra un ejemplo de respuesta del servidor.
<id única><orden/solicitud><datos asociados> permite ofrecer a cualquier nivel aplicativo un soporte (bearer) de transporte. Por lo tanto es muy sencillo reconstruir un módulo de transferencia de fichero que funcione usando los canales Call-ID y descriptivo del código de respuesta a través de los mensajes INVITE. También hay que tener en cuenta que si el informe de INVITE es negativo, ninguna sesión será establecida ni construida al nivel del servidor (3) SIP. El módulo de transferencia de fichero puede así emitir un mensaje de INVITE al nivel del Call-ID con la solicitud siguiente: <toto@MSISDN@frnce@sfr.net><modificar calidad video><7, 5>, es decir modificar la calidad de video seleccionando el nivel 7, para una duración de 5 minutos. Al final del anexo 2 se ilustra un ejemplo de respuesta del servidor.
El servidor (3) también puede pedir
espontáneamente a un usuario que active los medios de seguridad más
elevados si el cliente se encuentra en un entorno poco seguro por
medio de una solicitud INVITE en el presente ejemplo.
Se tiene en cuenta que el campo FROM también
puede ser utilizado para dialogar directamente con un servidor de
servicio, ya que está disponible para cualquier valor de alias.
Como este campo no está restringido en su contenido, puede recibir
información con cualquier estructura acordada anteriormente
respetando las obligaciones de estructura de la norma. Otro interés
del campo FROM es que, de forma general, el contenido de este campo
será visualizado a la recepción por el terminal; se puede así
establecer ofertas de servicios (con interactividad) solicitando
acciones del usuario durante la recepción de la solicitud de
tratamiento emitida, ya sea esta solicitud relativa o no a la
renegociación de la calidad de servicio del contenido multimedia
durante la difusión.
En referencia al anexo 3, otros dos campos son
también interesantes en el marco de una utilización paralela de la
señalización SIP según la invención de los campos del protocolo de
señalización: "campo warning" y "campo" Reason. La
lectura del descriptivo de la RFC permite ver que estos campos son
de tipo texto y son obligatorios durante fracasos o alertas, evento
particularmente requerido para no establecer una sesión de
intercambio de datos entre los interlocutores RTP (Real Time
Protocol).
Uno de los medios más ingeniosos consiste en
establecer una convención de formato al nivel aplicativo para el
conjunto de los campos de la norma dejados libres para proporcionar
una explicación textual (humanamente legible: "the reason phrase
should be human readable"). La información es así transmitida de
principio a fin por la infraestructura SIP sin ninguna modificación
al nivel de los servidores, gateway y proxy (2, 3) de paso. Esta
información se encuentra en las respuestas SIP y los métodos.
También hay que subrayar que se puede evitar el
hecho de emitir solicitudes que terminen en fracaso para no iniciar
el establecimiento de un canal de datos: en efecto un nuevo canal
de datos puede ser establecido ventajosamente y utilizado entre dos
terminales (T1, T2) o incluso más de dos terminales (T1, T2,
4).
La forma de realización de la figura 5 muestra
la infraestructura de dos operadores de radiotelefonía diferentes
con una comunicación entre estas redes a través de los servidores
(31, 32) CSCF (Call Session Control Function) dotados por ejemplo
de una base de datos HSS (Home Subscriber Server) para recuperar
los datos de abonados. Unas pasarelas (21, 21') y unos conmutadores
(22, 22') previstos en cada una de estas redes de radiotelefonía
(16, 16') permiten encaminar los mensajes hasta terminales móviles
de radiocomunicación (T1, T2). Un protocolo GTP (GPRS Tunnel
Protocol) permite comunicar entre una pasarela (21, 21') de tipo
GGSN (Gateway GPRS Support Node) a un conmutador (22, 22') de tipo
SGSN (Serving GPRS Support Node). Un cortafuego (FW) puede estar
dispuesto en la interfaz entre al menos una de las redes (16) de
radiotelefonía y el dominio (15) de tipo Internet.
La arquitectura IMS tal como se ilustra en la
figura 5 permite acceder a servicios multimedia desde terminales
móviles o fijos, utilizando el protocolo SIP sobre IP. El
subsistema IMS se organiza en tres niveles, que son:
- -
- el nivel de transporte que designa el medio de acceso a la IMS: GGSN para los teléfonos móviles, DSLAM para el ADSL, etc.;
- -
- el controlador de sesión (Call/Session Control Function o CSCF); este nivel comprende particularmente los servidores sucesivos:
- o bien el Proxy-CSCF que tiene la función de proxy SIP: todos los mensajes de señalización pasan por él; establece un túnel IPSec entre el GGSN y él;
- o el Serving-CSCF que permite controlar el dominio: tiene la función de Registrar SIP y permite establecer una política de señalización; asegura también las funciones de rutas (todos los mensajes pasan también por él);
- o el Interrogating-CSCF es el punto de entrada de un dominio: por éste pasan los paquetes SIP procedentes de otro dominio; su dirección está publicada en el sistema DNS (Domain Name System) los servidores de aplicación que ejecutan los servicios.
\vskip1.000000\baselineskip
La figura 3 permite recordar el desarrollo
convencional de una escena de llamada con un protocolo de
señalización. Las escenas simples de comunicación utilizan las
solicitudes SIP tales como: INVITE, ACK, BYE. Un terminal cliente
SIP (T1) llama a otro terminal (T2) utilizando el mensaje INVITE. El
mensaje enviado contiene informaciones que permiten establecer el
flujo de medios hacia el terminal cliente (T1) demandante. El
ejemplo siguiente ilustra un mensaje de invitación según el
protocolo SIP:
\vskip1.000000\baselineskip
Un servidor SIP, por ejemplo el servidor (3)
proxy del dominio "domaine.fr", responde a una solicitud SIP a
través de una o varias respuestas. La mayoría de las respuestas,
cuyos códigos están en la forma 2xx, 3xx, 4xx, 5xx, y 6xx son
respuestas "finales" y terminan la transacción corriente. Las
respuestas de la forma 1xx son respuestas provisionales. A
continuación se proporciona un ejemplo de respuesta:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
En el ejemplo de la figura 3:
- -
- el código de respuesta "100" significa "Trying" durante el tratamiento;
- -
- el código de respuesta "180" significa "Ringing" timbre en funcionamiento; y
- -
- el código de respuesta "200" significa "OK".
\vskip1.000000\baselineskip
Para entender la noción de transacciones y de
retransmisión de mensajes, hay que recordar aquí que un diálogo SIP
es identificado por la combinación de los campos "From",
"To", Call-ID y del número de secuencia
"Cseq". Cuando el diálogo es establecido, todas las solicitudes
y las respuestas deben incluir estos campos de encabezamiento. Cada
transacción es identificada por el valor común del encabezamiento
"Cseq" (el nombre del método y el número de secuencia deben
ser idénticos). El sistema según la invención puede permitir
analizar en cada transacción el tipo de solicitudes emitidas con las
respuestas asociadas y comparar las transacciones entre sí.
En referencia a la figura 4, las solicitudes
genéricas como SUBSCRIBE y NOTIFY pueden ser controladas también y
utilizadas durante la etapa (55) de transmisión de informaciones
multimedia. El hecho de utilizar las solicitudes SUBSCRIBE y NOTIFY
permite difundir de principio a fin otras informaciones que las que
se necesitan para la gestión de sesiones multimedia. Estas dos
solicitudes genéricas pueden ser encaminadas por los servidores (3)
proxy con la ayuda de los encabezamientos "From" y "To" y
son satisfechas por respuestas. La solicitud SUBSCRIBE es enviada
por el terminal cliente (T1) que desea recibir ciertos eventos hacia
un servidor (3) que genera los eventos (por ejemplo: una solicitud
de informaciones de presencia a una aplicación de tipo lista de
amigos "buddy list"). La solicitud SUBSCRIBE contiene en el
encabezamiento "Expires" que indica la duración de la
suscripción. La solicitud NOTIFY sirve para enviar notificaciones
de eventos. Estas solicitudes SUBSCRIBE y NOTIFY pueden crear un
diálogo SIP, no requieren solicitud INVITE y pueden ser enviadas de
manera asincrónica en cualquier momento.
\global\parskip0.900000\baselineskip
Por lo tanto resulta muy sencillo realizar
encima de una infraestructura SIP un sistema de comunicación con
base pregunta/respuesta. Con el ejemplo del campo
Call-ID, si un primer terminal (T1) quiere por
ejemplo emitir hacia un segundo terminal (T2) una solicitud
elemental para interrogar un banco de datos, entonces:
- -
- el primer terminal (T1) escribe su solicitud elemental en el formato texto
- -
- éste codifica después su solicitud en base-64; luego
- -
- envía un mensaje INVITE al segundo terminal (T2) pasando la solicitud codificada en el CALL-ID.
El segundo terminal (T2) responde con el código
480 (temporarily unavailable) y sitúa en el campo
reason-code la respuesta de la solicitud a una base
de datos. El primer terminal (T1) reenvía entonces un acuse de
recibo ACK con el mismo Call-ID para confirmar el
cierre de la sesión SIP y la buena recepción del resultado a la
solicitud. La infraestructura SIP va a considerar que la llamada
nunca ha tenido lugar y que la sesión está terminada, pero una
solicitud habrá sido tratada a través de la infraestructura SIP.
Se entiende que es fácil hacer que el protocolo
sea más complejo para embarcar al nivel de los campos tales como
CALL-ID una sucesión de solicitudes. El experto en
la materia apreciará que es suficiente establecer una convención
para identificar el primer paquete, identificar el paquete de orden
N y el último paquete (ver SIP INVITE definition: RFC 2543 y RFC
3261). El ejemplo de la figura 3 permite mostrar la simplicidad
relativa de la escena de comunicación, mediante el uso de
INVITE/ACK y BYE.
En un modo de realización de la invención, el
procedimiento prevé escrutar/escanear los canales abiertos. La
mayoría de los ejemplos citados previamente utilizan sencillamente
el campo Call-ID para enviar las solicitudes, y
esto de forma bidireccional gracias a la fuerza del protocolo SIP.
Pero ciertas infraestructuras SIP no encaminan la información de
Call-ID de principio a fin, en particular si un
servidor (3) proxy SIP reescribe estos datos. Eso es posible al
nivel del protocolo SIP ya que la única obligación es que la
información constituida de TO, FROM y CALL ID debe identificar una
conexión peer to peer única.
El uso del campo "from" como activador de
intercambio puede así ser necesario. En el caso en el que los
campos "from" sean también limitados por el servidor (3) proxy
SIP debido a las limitaciones de sus capacidades se pueden prever
esquemas basados en el uso del campo TO.
En el marco del uso del campo FROM, la solicitud
es codificada en éste y el esquema mostrado con el
Call-ID se mantiene idéntico (véase anexos
1-2). En el marco del campo TO, el terminal
receptor (T2) utilizado por Bob realiza una solicitud hacia el
terminal (T1) de Alice pero teniendo como objetivo un alias (seudo)
específico de Alice para pedirle que vuelva a llamar para que pueda
pasar la solicitud. Por lo tanto Alice llama de nuevo y de retorno
el terminal (T2) de Bob transporta su solicitud en uno de los
campos contextuales ofrecidos: la respuesta volverá al nivel del
acuse de recibo ACK o, si este método no está disponible en la red,
se puede establecer al nivel del rechazo de la solicitud que,
mediante un identificador de solicitud, Bob llame de nuevo a Alice
para transmitirle su identificador de solicitud y que ésta le
conteste en el momento del rechazo.
Varios métodos son por lo tanto posibles para
aprovechar de manera ingeniosa cierta fuerza del protocolo SIP,
pero es necesario concretar cual de estos métodos se desea utilizar
y en particular detectar cual puede ser utilizado en una red (N)
SIP y esto de manera automática. El principio de funcionamiento del
scan (escrutación) se apoya en un uso de un conjunto de métodos, de
forma secuencial, hasta que se detecte un método operacional sobre
esta infraestructura.
Durante la fase de descubrimiento de los canales
paralelos disponibles, el agente/el cliente embarcado emite una
solicitud INVITE hacia el destinatario informando los campos
disponibles sucesivamente y puede así establecer una cartografía de
los medios de comunicación paralela disponible para alcanzar al
interlocutor. Por extensión, el agente puede establecer una
cartografía de los medios de comunicaciones paralelos disponibles
para alcanzar N interlocutores o servidores, por extensión también
se pueden controlar nociones de grupos de destinatarios siempre con
respecto a los medios de comunicación paralelos cartografiados.
La descripción de las pruebas necesarias para el
descubrimiento de los medios de comunicaciones paralelas puede ser
precodificada secuencialmente. Una gramática puede describir la
lista de los campos del protocolo de señalización que la aplicación
(A1, A2) o agente podrá utilizar y evaluar. Una vez realizada la
cartografía, se puede evaluar la banda de paso disponible para cada
uno de los canales paralelos por una sucesión de pruebas recurrentes
de disponibilidad de los canales paralelos cartografiados.
Varias opciones son posibles, el cliente (A1,
A2) se mantiene en el primer método operacional. Prueba todos los
métodos conocidos y elige él de su elección en base a criterios
aleatorios, ordinales, o dependientes de la naturaleza de las
informaciones que desea intercambiar con su interlocutor. El cliente
(A1, A2) utiliza varios métodos en paralelo, si la infraestructura
SIP autoriza varios de estos métodos y puede dedicar/particularizar
cada método a unos subtipos de servicios muy precisos.
Por supuesto se entiende que los clientes (A1,
A2) en el marco de servicio de peer to peer entre 2 o N usuarios, o
el servidor (3) y el cliente (A1, A2) en el primer caso han
concretado previamente una convención protocolaria y de estructura
de las informaciones que son intercambiadas de manera que queden
inteligibles. La ventaja obtenida es utilizar la infraestructura SIP
de manera óptima para establecer un intercambio de datos multimedia
por RTP. No se deja de utilizar la infraestructura SIP y se consigue
además modificar la naturaleza o la calidad o incluso el servicio
intercambiado a través del enlace de dato RTP ya establecido, sin
querer interrumpirlo para restablecer otro. Por lo tanto se puede
obligar a tener una reducción de calidad en la entrega del
contenido si el cliente y los servidores o los clientes de los
usuarios en peer to peer detectan una alteración de la banda de
paso disponible al nivel de su control (monitoring) de las
transferencias/intercambios. Este tipo de modificación es
actualmente muy difícil de poner en práctica y requiere la mayoría
del tiempo la interrupción de la sesión establecida para reconstruir
otra.
Con el fin de reducir el consumo de banda de
paso, el terminal (T2) receptor puede por ejemplo iconificar o
reducir el tamaño de visualización del video reduciendo en la misma
medida la banda de paso necesaria (por lo tanto reducción del flujo
streaming de TV/Video). En el ejemplo de la figura 5, una ventana
reducida (I) es así utilizada para la visualización del contenido
multimedia (imágenes/video) recibido. Esta ventana (1) tiene un
formato muy inferior al de la pantalla (E) del terminal (T2)
receptor y el contenido puede ser visualizado con una definición
menor, lo que permite ahorrar la banda de paso. Como ejemplo, el
consumo de banda de paso puede ser reducido voluntariamente durante
ciertas fases de difusión de un avance, durante los créditos por
ejemplo. Las condiciones de utilización durante la recep-
ción del contenido multimedia pueden ser consideradas para ajustar automáticamente el consumo de banda de paso.
ción del contenido multimedia pueden ser consideradas para ajustar automáticamente el consumo de banda de paso.
Una de las ventajas de la invención es permitir
un dominio de nuevos protocolos utilizados particularmente en la
gestión de los servicios multimedia tales como la visiofonía, la
voz en IP, el intercambio de ficheros, el correo electrónico, etc.
En particular, el procedimiento según la invención puede permitir
controlar el uso de los canales paralelos en los protocolos de voces
en IP y disponer canales de comunicación en tiempo real ofreciendo
la posibilidad a los usuarios de modificar la calidad del servicio
consumido, el nivel del servicio y el tipo de servicio por una
disposición de una señalización flexible, independiente del soporte
(bearer) de acceso. Además, un nivel aplicativo de servicio puede
estar previsto ventajosamente para ofrecer a las aplicaciones
medios de comunicaciones con los centros servidores
independientemente de las políticas de filtrado y de las
capacidades funcionales de los servidores de señalización
subyacentes.
El procedimiento según la invención es aplicable
a varios servicios, como por ejemplo los servicios de depósito de
correo electrónico, los servicios de interactividad en el consumo
de nuevos medios (por ejemplo, la televisión interactiva, o los
intercambios de tipo Peer to Peer en las comunidades), los
servicios de negociación en tiempo real de la calidad de
servicio.
Debe ser evidente para las personas expertas en
el estado de la técnica que la presente invención permite modos de
realización en varias otras formas específicas sin alejarse del
ámbito de aplicación de la invención como se reivindica. En
consecuencia, los presentes modos de realización deben ser
considerados como una ilustración, aunque pueden ser modificados en
el campo definido por el alcance de las reivindicaciones anexas y
la invención no debe ser limitada a los detalles proporcionados más
arriba.
Anexo
1
Anexo
2
\global\parskip1.000000\baselineskip
\newpage
Anexo
3
Anexo
4
Los atributos indicados en cursiva son
facultativos. Las informaciones descritas por SDP serán diferentes
según el tipo de trama SAP (service advertising protocol). En estos
campos facultativos, algunos no son descritos sintáxicamente y por
lo tanto pueden ser utilizados según la buena disposición de los
servicios desarrollados.
\vskip1.000000\baselineskip
Esta lista de referencias citada por el
solicitante ha sido recopilada exclusivamente para la información
del lector. No forma parte del documento de patente europea. La
misma ha sido confeccionada con la mayor diligencia; la OEP sin
embargo no asume responsabilidad alguna por eventuales errores u
omisiones.
- EP 1650925 A [0009]
Claims (23)
-
\global\parskip0.930000\baselineskip
1. Procedimiento de control del establecimiento de canales de intercambios para permitir una transmisión de informaciones multimedia entre al menos dos terminales de comunicación (T1, T2, 4) conectados entre sí por una red (N) de telecomunicaciones, comprendiendo una etapa (51) de establecimiento de una comunicación entre un primer terminal de comunicación (T1) y un segundo terminal de comunicación (T2) mediante la utilización de aplicaciones respectivas para el control de un protocolo de señalización determinado permitiendo iniciar sesiones, el primer terminal (T1) efectuando una etapa (52) de selección de al menos un canal de intercambio de datos entre los dos terminales (T1, T2), la etapa (52) de selección se efectúa a un nivel aplicativo y la etapa (51) de establecimiento de una comunicación comprende las etapas siguientes:- -
- una etapa (53) de emisión de al menos una solicitud por el primer terminal (T1), con destino al segundo terminal (T2), abriendo una sesión según el protocolo de señalización determinado; el procedimiento caracterizado por
- -
- una etapa (54) de envío por el segundo terminal (T2) de una respuesta representativa de una indisponibilidad para cerrar la sesión según el protocolo de señalización determinado;
el procedimiento comprendiendo durante las etapas (53, 54) de emisión y de envío una etapa (55) de transmisión de informaciones adicionales además de dicho protocolo de señalización, por utilización de dicho canal de intercambio de datos seleccionado, este canal de intercambio de datos siendo accesible a través de un campo esencialmente descriptivo/explicativo de características de una sesión, dichas informaciones adicionales correspondiendo a informaciones aplicativas no necesarias a la gestión de sesiones multimedia. - 2. Procedimiento según la reivindicación 1, comprendiendo una etapa (50) de identificación por el primer terminal (T1) de al menos un canal de intercambio de datos susceptible de ser utilizado para la etapa (55) de transmisión de informaciones adicionales, la identificación resultando de una etapa (500) de búsqueda de canales de intercambios, en la que el primer terminal (T1) analiza al menos una respuesta del segundo terminal (T2) a una solicitud en la que uno de los campos esencialmente descriptivos ha recibido informaciones adicionales además de dicho protocolo de señalización.
- 3. Procedimiento según la reivindicación 2, en el que la etapa (500) de búsqueda de canales de intercambios comprende una etapa (510) de envío por el segundo terminal (T2) de un conjunto de mensajes de respuesta a solicitudes del primer terminal (T1).
- 4. Procedimiento según una de las reivindicaciones 1 a 3, en el que el canal de intercambios de datos seleccionado es utilizado para difundir de principio a fin informaciones multimedia.
- 5. Procedimiento según una de las reivindicaciones 1 a 4, en el que la etapa (52) de selección comprende una selección de varios canales de intercambio de datos para utilizar varios métodos de transmisión de informaciones adicionales en paralelo.
- 6. Procedimiento según una de las reivindicaciones 1 a 5, comprendiendo una etapa de negociación de medios de comunicación en tiempo real entre un cliente (A1) del primer terminal (T1) y un servidor (3) a través de una infraestructura de comunicación teniendo una capacidad para encaminar datos aplicativos a través de informaciones y de mensajes de señalización de principio a fin.
- 7. Procedimiento según una de las reivindicaciones 1 a 6, en el que al menos uno de los siguientes campos es utilizado para la etapa (55) de transmisión de informaciones adicionales además del protocolo SIP:
- -
- Encabezamiento de los paquetes SIP donde se mencionan características de sesión;
- -
- Descriptivo del código de respuesta;
- -
- Call_ID;
- -
- Branch;
- -
- TAG.
- 8. Procedimiento según una de las reivindicaciones 1 a 7, en el que al menos un campo asociado al método MESSAGE del protocolo SIP es utilizado para la etapa (55) de transmisión de informaciones adicionales además del protocolo SIP.
- 9. Procedimiento según una de las reivindicaciones 1 a 8, en el que al menos un campo asociado a la información SDP de carga útil de SIP es utilizado para la etapa (55) de transmisión de informaciones adicionales además del protocolo SIP, cuyo campo SDP en la carga útil de SIP está definido como opcional por el protocolo SIP o con una estructura y una sintaxis no fijadas por el protocolo SIP.
\global\parskip1.000000\baselineskip
- 10. Procedimiento según una de las reivindicaciones 1 a 9, en el que un campo Call_ID del protocolo SIP es utilizado para la etapa (55) de transmisión de informaciones adicionales además del protocolo SIP.
- 11. Procedimiento según una de las reivindicaciones 1 a 10, en el que las condiciones de consumo/uso del contenido multimedia transmitido durante dicha etapa (55) de transmisión son modificadas por una aplicación multimedia consumidora del contenido multimedia sobre la recepción y la consideración de las informaciones adicionales transportadas a través del protocolo SIP.
- 12. Procedimiento según la reivindicación 11, en el que dichas condiciones de consumo/uso del contenido multimedia transmitido durante dicha etapa (55) de transmisión son modificadas según la evolución del entorno de redes de transporte disponibles para el segundo terminal (T2).
- 13. Procedimiento según la reivindicación 11 ó 12, en el que dichas condiciones de consumo/uso del contenido multimedia transmitido durante dicha etapa (55) de transmisión son modificadas según la evolución de las condiciones de localización geográfica del segundo terminal (T2).
- 14. Procedimiento según una de las reivindicaciones 11 a 13, en el que dichas condiciones de consumo/uso del contenido multimedia transmitido durante dicha etapa (55) de transmisión son modificadas según la evolución de las condiciones de ejecución intrínseca del segundo terminal (T2).
- 15. Procedimiento según una de las reivindicaciones 11 a 14, en el que dichas condiciones de consumo/uso del contenido multimedia transmitido durante dicha etapa (55) de transmisión son modificadas según la evolución de las condiciones de entrega de un servicio recibido por el segundo terminal (T2).
- 16. Procedimiento según una de las reivindicaciones 1 a 15, en el que las condiciones de consumo/uso de un flujo de transmisión establecido entre los dos terminales de comunicación (1, 2) son modificados por aplicaciones multimedia consumidoras y emisoras del contenido multimedia de cada terminal sobre la emisión, la recepción y la consideración de las informaciones adicionales transportadas a través del protocolo SIP.
- 17. Procedimiento según una de las reivindicaciones 1 a 16, comprendiendo una etapa de evaluación de una banda de paso disponible para al menos uno de los canales de intercambios fuera sesión identificados.
- 18. Procedimiento según una de las reivindicaciones 1 a 17, comprendiendo una etapa de renegociación en tiempo real de un servicio cuando se modifican las condiciones de uso al nivel del segundo terminal (T2), donde la etapa de renegociación es realizada para disminuir un consumo de banda de paso, modificando el tamaño de una ventana de video visible en la pantalla.
- 19. Procedimiento según una de las reivindicaciones 1 a 18, comprendiendo una etapa de memorización en una memoria de cada uno de los dos terminales (T1, T2) de una lista de canales de intercambio identificados y que pueden ser utilizados fuera de sesión para transmitir informaciones multimedia.
- 20. Procedimiento según una de las reivindicaciones 1 a 19, en el que el protocolo de señalización es el protocolo SIP y la etapa (55) de transmisión de informaciones adicionales además de dicho protocolo comprende:
- -
- una etapa de escritura por el primer terminal (T1) de una solicitud en un formato texto;
- -
- una etapa de codificación de la solicitud:
- -
- una etapa de envío de un mensaje INVITE pasando por la solicitud codificada en el campo Call-ID.
- 21. Procedimiento según la reivindicación 20, en el que la etapa (55) de transmisión de informaciones adicionales además de dicho protocolo comprende también:
- -
- una etapa de envío de un mensaje de respuesta conteniendo una indicación de indisponibilidad temporal y en el que una respuesta a la solicitud es colocada por el segundo terminal (T2) en un campo esencialmente descriptivo o explicativo;
- -
- una etapa de confirmación de cierre de una sesión SIP, en la que el primer terminal (T1) envía al segundo terminal (T2) un mensaje de acuse de recibo ACK con el mismo campo Call-ID para indicar una buena recepción de la respuesta a la solicitud.
- 22. Procedimiento según la reivindicación 21, en el que dicho campo esencialmente descriptivo o explicativo es el campo "Reason".
- 23. Programa de un módulo de tratamiento cargable directamente en la memoria de un terminal (T1, T2, 4) de comunicación con una red (N) para dirigir las etapas de la reivindicación 1, 2, 3, 4 ó 5 cuando dicho programa es ejecutado en el terminal (T1, T2, 4).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0610629A FR2909822B1 (fr) | 2006-12-06 | 2006-12-06 | Procede et systeme de controle de l'etablissement de canaux de communication pour permettre une transmission d'informations multimedia. |
| FR0610629 | 2006-12-06 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2327969T3 true ES2327969T3 (es) | 2009-11-05 |
Family
ID=38202529
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07291241T Active ES2327969T3 (es) | 2006-12-06 | 2007-10-11 | Procedimiento de control del establecimiento de canales de comunicacion multimedia. |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7953123B2 (es) |
| EP (1) | EP1931104B1 (es) |
| JP (1) | JP2008148313A (es) |
| AT (1) | ATE434331T1 (es) |
| DE (1) | DE602007001332D1 (es) |
| DK (1) | DK1931104T3 (es) |
| ES (1) | ES2327969T3 (es) |
| FR (1) | FR2909822B1 (es) |
| PT (1) | PT1931104E (es) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20100205628A1 (en) | 2009-02-12 | 2010-08-12 | Davis Bruce L | Media processing methods and arrangements |
| CN102064994B (zh) * | 2009-11-18 | 2013-12-18 | 中兴通讯股份有限公司 | 基于媒体网关控制协议识别网络电话流量的方法和装置 |
| FR2995164A1 (fr) * | 2012-08-29 | 2014-03-07 | France Telecom | Procedes, dispositifs et systeme de journalisation d'appels pour terminaux |
| US9106673B2 (en) * | 2012-12-28 | 2015-08-11 | Vonage Network, Llc | Systems and methods for connecting telephony communications |
| US20150111557A1 (en) * | 2013-10-23 | 2015-04-23 | Acer Incorporated | Method of managing contact information for mobile devices according to network messages |
| ES2870577T3 (es) * | 2014-05-30 | 2021-10-27 | Huawei Tech Co Ltd | Procedimiento de edición de paquetes y dispositivo relacionado |
| WO2016068342A1 (en) * | 2014-10-30 | 2016-05-06 | Sharp Kabushiki Kaisha | Media playback communication |
| CN115695382A (zh) * | 2021-07-31 | 2023-02-03 | 华为技术有限公司 | 一种通信方法及装置 |
| CN116155868A (zh) * | 2021-11-19 | 2023-05-23 | 中兴通讯股份有限公司 | 电信通讯方法、电子设备及存储介质 |
| US11775245B1 (en) * | 2022-05-09 | 2023-10-03 | International Business Machines Corporation | Consistent representative screen sharing |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6738349B1 (en) * | 2000-03-01 | 2004-05-18 | Tektronix, Inc. | Non-intrusive measurement of end-to-end network properties |
| US7024461B1 (en) * | 2000-04-28 | 2006-04-04 | Nortel Networks Limited | Session initiation protocol enabled set-top device |
| EP1248431B1 (en) * | 2001-03-27 | 2007-10-31 | Sony Deutschland GmbH | Method for achieving end-to-end quality of service negotiation for distributed multimedia applications |
| US8126127B2 (en) * | 2002-01-16 | 2012-02-28 | Qualcomm Incorporated | Method and apparatus for provision of broadcast service information |
| EP1331785B1 (en) * | 2002-01-23 | 2005-04-20 | Sony International (Europe) GmbH | A method for enabling the negotiation of end-to-end QoS by using the end-to-end negotiation protocol (E2ENP) |
| US20050071459A1 (en) * | 2003-09-26 | 2005-03-31 | Jose Costa-Requena | System, apparatus, and method for providing media session descriptors |
| US8396973B2 (en) * | 2004-10-22 | 2013-03-12 | Microsoft Corporation | Distributed speech service |
| FI20041634A0 (fi) * | 2004-12-20 | 2004-12-20 | Nokia Corp | Tarjontaistunnon muodostaminen kommunikaatiojärjestelmässä |
| DE202005021930U1 (de) * | 2005-08-01 | 2011-08-08 | Corning Cable Systems Llc | Faseroptische Auskoppelkabel und vorverbundene Baugruppen mit Toning-Teilen |
| US20080089324A1 (en) * | 2006-10-13 | 2008-04-17 | Cisco Technology, Inc | Indicating or remarking of a dscp for rtp of a flow (call) to and from a server |
-
2006
- 2006-12-06 FR FR0610629A patent/FR2909822B1/fr not_active Expired - Fee Related
-
2007
- 2007-10-11 EP EP07291241A patent/EP1931104B1/fr not_active Not-in-force
- 2007-10-11 ES ES07291241T patent/ES2327969T3/es active Active
- 2007-10-11 AT AT07291241T patent/ATE434331T1/de active
- 2007-10-11 DE DE602007001332T patent/DE602007001332D1/de active Active
- 2007-10-11 PT PT07291241T patent/PT1931104E/pt unknown
- 2007-10-11 DK DK07291241T patent/DK1931104T3/da active
- 2007-11-21 US US11/943,897 patent/US7953123B2/en active Active
- 2007-12-06 JP JP2007316185A patent/JP2008148313A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| US7953123B2 (en) | 2011-05-31 |
| DE602007001332D1 (de) | 2009-07-30 |
| PT1931104E (pt) | 2009-08-14 |
| EP1931104A1 (fr) | 2008-06-11 |
| ATE434331T1 (de) | 2009-07-15 |
| FR2909822A1 (fr) | 2008-06-13 |
| FR2909822B1 (fr) | 2010-04-30 |
| DK1931104T3 (da) | 2009-10-19 |
| US20080137598A1 (en) | 2008-06-12 |
| JP2008148313A (ja) | 2008-06-26 |
| EP1931104B1 (fr) | 2009-06-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2327969T3 (es) | Procedimiento de control del establecimiento de canales de comunicacion multimedia. | |
| ES2223856T3 (es) | Aparato y metodo de proxy. | |
| CN101606352B (zh) | 下一代网络中用于非sip讲述者的服务网关代理 | |
| ES2364793B2 (es) | Fijación de la ruta de flujos portadores de ip en una red de próxima generación. | |
| CN101395483B (zh) | 由网络触发的服务质量（QoS）预留 | |
| ES2320731T3 (es) | Sistema y procedimiento para proporcionar servicios de comunicacion en grupo. | |
| ES2414874T3 (es) | Un procedimiento y una disposición para el establecimiento de una sesión de comunicaciones para multimedia | |
| ES2542965T3 (es) | Un método, un dispositivo y un sistema para la puesta en convergencia de una mensajería en IP | |
| ES2236370T3 (es) | Metodo para permitir la negociacion de la calidad de servicio extremo a extremo por utilizacion del protocolo de negociacion extremo a extremo (e2enp). | |
| KR101441567B1 (ko) | Ｉｍｓ 망을 통한 ｍ２ｍ 데이터 전달 방법 및 이를 위한 ｍ２ｍ 서비스 플랫폼 | |
| US8780794B2 (en) | Method for advertising in IP multimedia subsystem and server and terminal thereof | |
| US20070223462A1 (en) | Enhanced service delivery platform that provides a common framework for use by IMS and Web applications in delivering services | |
| US20080069086A1 (en) | Mobile Communication System Based On Ip And Session Initiation Method Thereof | |
| ES2317341T3 (es) | Gestion de mensajes en un subsistema multimedia ip. | |
| CN102090038B (zh) | 固定移动融合(fmc)架构 | |
| US8325707B2 (en) | Session initiation from application servers in an IP multimedia subsystem | |
| CN104396217B (zh) | 地理消息收发注册器和相关方法 | |
| ES2385524T3 (es) | Método y aparato para cambiar el estado del dominio de conmutación de paquetes | |
| US9008056B2 (en) | Remote network access via a visited network | |
| CN102365850A (zh) | 用于提供相关服务级别的方法和装置 | |
| US20100274908A1 (en) | Location tagging method for packet based signalling | |
| CN102144380A (zh) | 端对端地址转移 | |
| ES2276570B2 (es) | Metodo y disposicion para comunicacion multimedia. | |
| ES2289586T3 (es) | Metodo y dispositivo para servicio pulsar para hablar. | |
| JP2010516131A (ja) | 電話ベースのウェブサーバを発見する方法及び、当該方法に関連する電子機器とコンピュータプログラム |