ES2759748T3 - Procedimiento de intercambio de datos entre dos navegadores de Internet, equipo de enrutado, terminal, programa informático y soporte de informaciones correspondientes - Google Patents

Abstract

Procedimiento de intercambio de datos entre un primer navegador de Internet y un segundo navegador de Internet de una red de comunicación, caracterizado por que comprende una fase de inicialización, que implementa las siguientes etapas, a nivel de un equipo de enrutado de dicha red colocado en un camino de comunicación por omisión entre dichos primer y segundo navegadores: - recepción (24) de un mensaje de verificación de conectividad entre dichos navegadores, llevando dicho mensaje un atributo específico de autorización de intercambio de datos entre dichos navegadores; - verificación (25) de una autorización de intercambio de datos entre dichos navegadores, a partir de dicho atributo específico; - en caso de verificación positiva, modificación (26) de al menos una tabla de enrutado de los datos entre dicho primer navegador y dicho segundo navegador, de manera que se defina un camino de comunicación de sustitución entre dichos navegadores, que pasa por dicho equipo de enrutado.

Description

DESCRIPCIÓN

Procedimiento de intercambio de datos entre dos navegadores de Internet, equipo de enrutado, terminal, programa informático y soporte de informaciones correspondientes

1. Campo de la invención

El campo de la invención es el de las comunicaciones en el seno de una red de comunicaciones y, más particularmente, en el intercambio de datos entre dos navegadores de Internet.

Más precisamente, la invención ofrece una solución para el intercambio de datos entre dos navegadores de Internet que permita prescindir de la presencia de medios de repetición, de tipo servidor TURN (en inglés "Traversai Using Relays around NAT"). Se recuerda que dichos medios de repetición se utilizan clásicamente para redirigir los paquetes de datos de tipo "medios" recibidos de un primer navegador de Internet hacia un segundo navegador de Internet y viceversa.

La invención encuentra principalmente aplicaciones para el intercambio de datos según la tecnología WebRTC (en inglés "Web Real-Time Communication"), que permite el establecimiento de comunicaciones directamente entre pares (en inglés "peer to peer" o P2P) entre dos navegadores de Internet, instalados por ejemplo en dos terminales de usuario.

2. Técnica anterior

La tecnología WebRTC permite principalmente comunicaciones en videoconferencia con intercambio de datos de tipo medios en P2P, la compartición de archivos en P2P o también la voz sobre IP (en inglés "Voice over Internet Protocol").

Para hacer esto, se establece clásicamente una comunicación WebRTC por medio de un intercambio de mensajes de señalización entre dos terminales, utilizando el servidor web de un suministrador de servicios.

Por "suministrador de servicios", se entiende en este caso, y en todo lo que sigue del documento, cualquier entidad adecuada para suministrar cualquier tipo de servicio que implique intercambio de flujos de datos, el concreto sobre la red de telecomunicaciones móvil. El flujo de datos puede transportarse sobre la red entre un terminal de usuario y un servidor dedicado del suministrador de servicios o puede transportarse entre dos terminales de usuario.

En particular, en el marco de una comunicación WebRTC, el suministrador de servicios permite el enlace de dos usuarios que intercambian a continuación directamente datos en P2P.

Las comunicaciones producen unos flujos de datos P2P, que utilizan principalmente el protocolo de transporte UDP (en inglés "User Datagram Protocol"), o a veces el protocolo de transporte TCP (en inglés "Transmission Control Protocol"), para intercambiar datos entre los terminales.

Idealmente, según la tecnología WebRTC, los flujos de datos P2P se intercambian directamente entre los terminales.

Sin embargo, el intercambio de datos en P2P no es siempre posible, según la configuración de la red. En particular, el intercambio de datos en P2P puede prohibirse en el caso de redes de acceso que hayan puesto fuera de servicio el tráfico P2P o hacerse difícil en el caso de ciertas arquitecturas que implementan dispositivos de traducción de la dirección de red (en inglés "Network Address Translation" o NAT) o cortafuegos (en inglés "firewall"), por ejemplo en las redes de empresas.

Para establecer la comunicación en dichos casos, la tecnología WebRTC propone utilizar un protocolo de establecimiento de conectividad interactivo (en inglés "Interactive Connectivity Establishment" o ICE), que permita aumentar las oportunidades de atravesar los NAT o los cortafuegos descubriendo y utilizando los medios IP de sustitución gracias a tres mecanismos complementarios:

- la utilización del protocolo de transporte TCP en lugar del protocolo de transporte UDP;

- la utilización de servidores STUN (en inglés "Session Traversai Utilities for NAT", tales como los descritos en concreto en el documento "Session Traversai Utilities for NAT (STUN)" - RFC 5389) por los terminales para descubrir sus direcciones públicas cuando se colocan detrás de un NAT; y

- la utilización de servidores TURN (en inglés "Traversai Using Relays around NAT" tal como se ha descrito en concreto en el documento "Traversai Using Relays around NAT (TURN): Relay Extensions to Session Traversai Utilities for NAT (STUN) - RFC 5766), situados del lado público de un NAT (es decir generalmente sobre la Internet pública).

El protocolo ICE tal como es conocido por el documento "Interactive Connectivity Establishment: a Protocol for Network Address Translator (NAT) Traversai for Offer/Answer Protocols" (RFC 5245) permite a los terminales descubrir unas direcciones posibles, también llamadas direcciones candidatas, que pueden utilizarse para recibir datos, por ejemplo de tipo medios. Una vez descubiertas por un terminal, estas direcciones candidatas se envían al terminal distante a través del canal de señalización. Cada terminal ejecuta entonces un procedimiento de verificación de conectividad en todos los pares de direcciones candidatas.

Para esta verificación de conectividad, se utilizan mensajes STUN, comprendiendo cada mensaje un encabezado seguido eventualmente de uno o varios atributos. Se observa que las direcciones IP y los números de puerto utilizados para intercambiar los mensajes STUN de verificación de conectividad son los mismos que los utilizados para los intercambios de datos de tipo medios.

Si se considera que existe una pluralidad de pares de direcciones candidatas que permiten a los terminales conectarse entre sí, entonces se elige uno de estos pares según criterios de prioridad predeterminados.

Con el fin de asegurar el intercambio de datos en P2P y de controlar el acceso al servidor TURN utilizado por un suministrador de servicios WebRTC, se ha propuesto en concreto utilizar el protocolo "OAuth", tal como se presenta en el proyecto TRAM de la IETF titulado "Extensión TURN para la autorización de terceros" (en inglés "TURN Extension for Third Party Authorization").

Para hacer esto, como se ilustra en la figura 1, se implementan unos intercambios de claves (1112) entre un servidor de autorización 11, que puede ser el servidor WebRTC, y el servidor TURN 12, que permite implementar a nivel del servidor TURN 12 una clave simétrica.

Para el establecimiento de una comunicación WebRTC, un cliente 13 envía al servidor de autorización 11 una solicitud de ficha de acceso (1311). Este le responde enviando al cliente 13 una ficha de acceso y una clave de sesión (1113). El cliente 13 obtiene así una ficha transitoria independiente.

El cliente 13 envía a continuación al servidor TURN 12 una solicitud TURN y la ficha de acceso (1312). El servidor TURN 12 valida la ficha de acceso con su clave simétrica, lo que permite al cliente 13 tener acceso a los servicios del servidor TURN (1213). Esta implementación permite producir unas fichas independientes que el servidor TURN 12 puede verificar sin ayuda del servidor de autorización 11.

Se observa que la clave simétrica implementada a nivel del servidor TURN 12 no debe ser demasiado larga porque la ficha cifrada debería integrarse en un único mensaje STUN.

Gracias a este protocolo "OAuth", se puede verificar que el cliente que se dirige a un servidor TURN (cuya dirección IP es pública) está correctamente abonado ante un suministrador de servicios WebRTC teniendo el derecho de utilizar este servidor TURN.

Esta solución permite identificar y tratar unos flujos de manera diferenciada. El servidor TURN sirve de repetidor de medios, porque se conoce su dirección IP fija. Los proveedores de servicios de red (en inglés "Network Service Provider" o NSP), por ejemplo los suministradores de acceso a Internet (en inglés "Internet Service Provider" o ISP), pueden utilizar estas informaciones para tratar estos flujos (es decir los flujos que tienen la dirección IP del servidor TURN como dirección de origen o como dirección de destino) de una manera deseada, por ejemplo para la gestión del enrutado o la priorización de QoS (en inglés "Quality of Service").

Se observa que, en las comunicaciones de tipo WebRTC, los enrutadores utilizan clásicamente unas tablas IP estáticas para gestionar los caminos de los flujos. La utilización de repetidores de medios, como los servidores TURN, es un medio de influir en el enrutado de los flujos WebRTC y redirigirlos. Por tanto cuando un suministrador de servicios WebRTC desea hacer pasar unos flujos de medios por otro camino distinto al camino P2P, utiliza habitualmente un servidor TURN. Pero un servidor así es costoso, puesto que no solamente trata los flujos de datos de tipo medios de la comunicación, sino que además ejecuta unos tratamientos como el enrutado, el control o el marcado de los datos.

3. Exposición de la invención

La invención propone una solución novedosa para el intercambio de datos entre dos navegadores de Internet, permitiendo en concreto prescindir de la utilización de un servidor TURN.

Más precisamente, la invención propone un procedimiento de intercambio de datos entre un primer navegador de Internet y un segundo navegador de Internet de una red de comunicación, que comprende una fase de inicialización que implementa, a nivel de un equipo de enrutado de la red colocado en un camino de comunicación por omisión entre los primeros y segundos navegadores:

- una etapa de recepción de un mensaje de verificación de conectividad entre los navegadores, llevando dicho mensaje un atributo específico de autorización de intercambio de datos entre los navegadores;

- una etapa de verificación de una autorización de intercambio de datos entre los navegadores, a partir del atributo específico;

- en caso de verificación positiva, una etapa de modificación de al menos una tabla de enrutado de los datos entre el primer navegador y el segundo navegador, de manera que se defina un camino de comunicación de sustitución entre los navegadores, que pasa por el equipo de enrutado.

La invención se basa así en la utilización de un equipo de enrutado, colocado en un camino de comunicación entre el primer y segundo navegadores, al que se han asignado unas funcionalidades particulares.

En particular, un equipo de enrutado de ese tipo permite gestionar las decisiones de enrutado entre el primer navegador de Internet y el segundo navegador de Internet, de manera que fuerce la comunicación entre los dos navegadores a través de un camino particular, llamado camino de comunicación de sustitución, que pasa a su vez por el equipo de enrutado, por ejemplo para evitar problemas de congestión en el camino por omisión, para forzar el paso a través de un equipo intermedio predeterminado (equipo de contaje, de recogida), etc.

Un equipo de enrutado de ese tipo puede gestionarse en concreto mediante un proveedor de servicios de red (NSP). En particular, la utilización de un equipo de enrutado de ese tipo permite prescindir de la utilización de un servidor TURN para intercambiar datos entre dos navegadores de Internet, en concreto en el marco de una comunicación WebRTC.

Se observará que, según la invención, no hay en todos los casos necesidad más que de un único mensaje para verificar la conectividad entre los dos terminales. Este mensaje utiliza generalmente las direcciones IP del modo P2P. Según un modo de realización particular de la invención, el mensaje de verificación de conectividad entre los navegadores es de tipo STUN.

En otros términos, el equipo de enrutado recibe el mensaje STUN particular, que lleva un atributo específico de autorización de intercambio de datos entre los navegadores, procedente del primer navegador de Internet.

Por ejemplo, un atributo específico de ese tipo es una ficha de acceso, que puede generarse por un servidor de autorización (que puede ser el servidor WebRTC).

El equipo de enrutado puede entonces verificar si el intercambio de datos entre los navegadores está permitido, por ejemplo implementando una función de tipo "verificación STUN".

Una funcionalidad de ese tipo puede descargarse en concreto y almacenarse en el equipo de enrutado o implementarse llamando a una interfaz de programación (en inglés "Application Programming Interface" o API) que proporciona dicha funcionalidad.

Según un primer ejemplo, la etapa de verificación de una autorización de intercambio de datos implementa una clave conocida por el equipo de enrutado, para verificar la validez de la ficha de acceso.

Una clave de ese tipo se suministra por ejemplo por un proveedor de servicios de red y es simétrica con una clave utilizada para obtener la ficha de acceso.

Según un segundo ejemplo, la etapa de verificación de una autorización de intercambio de datos implementa un intercambio de informaciones con un servidor de autorización para verificar la validez de la ficha de acceso.

En caso de verificación positiva, el equipo de enrutado puede entonces modificar al menos una tabla de enrutado de los datos entre el primer navegador y el segundo navegador, por ejemplo una tabla que almacena las direcciones IP de origen y destino de los datos. Se consideran por tanto según la invención unas tablas de enrutado dinámicas. Según un modo de realización particular de la invención, el procedimiento de intercambio de datos comprende igualmente una fase de intercambio de datos que implementa, a nivel del equipo de enrutado:

- una etapa de recepción de un flujo de datos (de tipo medios) procedente del primer navegador;

- una etapa de transmisión del flujo de datos (de tipo medios) al segundo navegador, a través de un equipo intermedio de red predeterminado situado en el camino de comunicación de sustitución.

Según este modo de realización, el equipo de enrutado fuerza por tanto el intercambio de datos entre dos navegadores a través de un equipo intermedio predeterminado, permitiendo por ejemplo asegurar un contaje del tráfico o una recogida de informaciones de tráfico.

En otro modo de realización, la invención se refiere a un equipo de enrutado de una red de comunicación, destinado a situarse sobre un camino de comunicación por omisión entre un primer navegador de Internet y un segundo navegador de Internet de dicha red, que comprende:

- un módulo de recepción de un mensaje de verificación de conectividad entre los navegadores, llevando dicho mensaje un atributo específico de autorización de intercambio de datos entre los navegadores;

- un módulo de verificación de una autorización de intercambio de datos entre los navegadores, a partir de dicho atributo específico;

- un módulo de modificación de al menos una tabla de enrutado de los datos entre el primer navegador y el segundo navegador, activado en caso de verificación positiva, de manera que se defina un camino de comunicación de sustitución entre los navegadores, que pasa por el equipo de enrutado.

Un equipo de enrutado de ese tipo está adaptado principalmente para implementar el procedimiento de intercambio de datos anteriormente descrito.

Este equipo de enrutado podrá incluir por supuesto las diferentes características relativas al procedimiento de intercambio de datos según la invención, que pueden combinarse o tomarse aisladamente. De este modo, las características y ventajas de este tipo de enrutado son las mismas que las del procedimiento de intercambio de datos. Por consiguiente, no se detallan más ampliamente.

La invención se refiere igualmente a un procedimiento de transmisión de datos de un primer navegador de Internet con destino en un segundo navegador de Internet de una red de comunicación, que comprende una etapa en el curso de la que dicho primer navegador emite un mensaje de señalización solicitando una comunicación (por ejemplo de tipo WebRTC) con dicho segundo navegador. Dicho procedimiento comprende además las siguientes etapas:

- recepción, por el primer navegador, de un atributo específico de autorización de intercambio de datos entre los navegadores, suministrado por un servidor de autorización;

- generación de un mensaje de verificación de conectividad entre los navegadores, llevando dicho mensaje dicho atributo específico; y

- transmisión del mensaje al segundo navegador a través de un equipo de enrutado de la red colocado en un camino de comunicación por omisión entre los primeros y segundos navegadores.

Dicho procedimiento permite por tanto generar un mensaje de verificación de conectividad entre los navegadores, que lleva un atributo específico. Dicho mensaje se transmite desde el primer navegador de Internet con destino en un segundo navegador de Internet, a través del equipo de enrutado. Por tanto puede ser leído y tratado al menos parcialmente por el equipo de enrutado.

Por ejemplo, dicho mensaje es de tipo STUN y lleva un atributo específico que corresponde a una ficha de acceso. Una ficha de acceso de ese tipo puede generarse por un servidor de autorización.

Dicho procedimiento se implementa en concreto mediante un terminal que utiliza un primer navegador de Internet, para que este primer navegador de Internet pueda comunicar en P2P con un segundo navegador de Internet, según la tecnología WebRTC, sin necesitar la utilización de un servidor TURN.

En otro modo de realización, la invención se refiere a un terminal de una red de comunicación, equipado con un primer navegador de Internet destinado a transmitir unos datos con destino en un segundo navegador de Internet contenido en un terminal distante de dicha red y que comprende un módulo de emisión de un mensaje de señalización solicitando una comunicación (por ejemplo de tipo WebRTC) con dicho segundo navegador. Dicho terminal comprende además:

- un módulo de recepción de un atributo específico de autorización de intercambio de datos entre los navegadores, suministrado por un servidor de autorización;

- un módulo de generación de un mensaje de verificación de conectividad entre los navegadores, llevando dicho mensaje dicho atributo específico;

- un módulo de transmisión del mensaje al segundo navegador a través de un equipo de enrutado de la red colocado en un camino de comunicación por omisión entre los primeros y segundos navegadores.

Un terminal de ese tipo está adaptado principalmente para implementar el procedimiento de transmisión de datos anteriormente descrito.

Este terminal podrá incluir por supuesto las diferentes características relativas al procedimiento de transmisión de datos según la invención, que pueden combinarse o tomarse aisladamente. De este modo, las características y ventajas de este terminal son las mismas que las del procedimiento de transmisión de datos. Por consiguiente, no se detallan más ampliamente.

En particular, un terminal de ese tipo puede ser de tipo teléfono, tableta, ordenador, etc., equipado con un navegador de Internet. Según un modo de realización particular, un navegador de Internet de ese tipo es compatible con la tecnología WebRTC.

En otro modo de realización, la invención se refiere a uno o varios programas informáticos que incluyen instrucciones para la implementación del procedimiento de intercambio de datos o del procedimiento de transmisión de datos tal como se han descrito anteriormente, cuando este o estos programas se ejecutan por un procesador.

En todavía otra realización, la invención se refiere a uno o varios soportes de informaciones, fijos o parcial o totalmente extraíbles, legibles por un ordenador y que incluyen instrucciones de uno o varios programas informáticos para la ejecución de las etapas del procedimiento de intercambio de datos o del procedimiento de transmisión de datos tal como se han descrito anteriormente.

4. Lista de las figuras

Aparecerán más claramente otras características y ventajas de la invención con la lectura de la descripción siguiente de un modo de realización particular, dado a título de simple ejemplo ilustrativo y no limitativo y de los dibujos adjuntos, entre los que:

- la figura 1, presentada en relación con la técnica anterior, recuerda el principio general del mecanismo de autentificación "OAuth";

- las figuras 2A y 2B presentan respectivamente las principales etapas implementadas mediante un procedimiento de transmisión de datos y un procedimiento de intercambio de datos según un modo de realización de la invención; - la figura 3 ilustra un ejemplo de red que utiliza la invención;

- las figuras 4 y 5 son unos organigramas que representan las operaciones implementadas por los diferentes equipos de la red de la figura 3 según un modo de realización de la invención;

- las figuras 6 y 7 representan respectivamente la estructura simplificada de un terminal y de un equipo de enrutado según un modo de realización particular de la invención.

5. Descripción de un modo de realización de la invención

5.1 Principio general

El principio general de la invención reposa en la utilización de un equipo de enrutado particular entre dos navegadores de Internet, que permite dirigir las comunicaciones en un camino de comunicación particular para los intercambios de datos entre los dos navegadores.

Más precisamente, la invención permite a un tráfico autorizado, es decir a un flujo de datos provisto de un atributo específico de autorización de intercambio de datos entre los navegadores, ser encaminado por un camino de la red específico modificando unas tablas de enrutado. Se redirige así este tráfico para que pase por ejemplo por un equipo utilizado para contar el tráfico o recoger informaciones de tráfico. El atributo específico se suministra por el suministrador de servicios WebRTC y el tratamiento asociado puede efectuarse por un proveedor de servicios de red (NSP).

Se presentan, en relación con la figura 2A, las principales etapas implementadas por un primer cliente equipado con un primer navegador de Internet, para transmitir unos datos a un segundo cliente equipado con un segundo navegador de Internet en el seno de una red de comunicación. Se observa que las mismas operaciones pueden implementarse para la transmisión de datos del segundo cliente hacia el primer cliente, puesto que la comunicación es simétrica.

En el curso de una primera etapa 20, el primer navegador emite un mensaje de señalización solicitando una comunicación con el segundo navegador.

En el curso de una segunda etapa 21, el primer cliente recibe un atributo específico de autorización de intercambio de datos entre los navegadores, por ejemplo una ficha de acceso T, suministrada por un servidor de autorización (por ejemplo servidor WebRTC).

El primer cliente genera a continuación, en el curso de una tercera etapa 22, un mensaje de verificación de conectividad entre los navegadores. Un mensaje M de ese tipo lleva el atributo específico T.

Este mensaje de verificación de conectividad se transmite a continuación al segundo navegador en el curso de una cuarta etapa 23, a través de un equipo de enrutado de la red colocado en un camino de comunicación por omisión entre los primeros y segundos navegadores.

El mensaje de verificación de conectividad puede analizarse y tratarse así por el equipo de enrutado de la red.

Se presentan a continuación, en relación con la figura 2B, las principales etapas implementadas por el equipo de enrutado de la red situado en un camino de comunicación por omisión entre el primer y segundo navegadores, para intercambiar datos entre los dos navegadores.

Dicho equipo de enrutado implementa, en el curso de una fase de inicialización, una primera etapa 24 de recepción de un mensaje de verificación de conectividad entre los navegadores. Dicho mensaje lleva un atributo específico de autorización de intercambio de datos entre los navegadores. En particular, dicho mensaje es el mensaje M generado por el primer cliente, que lleva el atributo específico T.

En el curso de una segunda etapa 25, el equipo de enrutado implementa una verificación de una autorización de intercambio de datos entre el primer y segundo navegadores. En el curso de esta segunda etapa, el equipo de enrutado valida que el primer navegador de Internet y el segundo navegador de Internet puedan intercambiar datos directamente, en P2P.

En caso de verificación positiva, el equipo de enrutado modifica, en el curso de una tercera etapa 26, al menos una tabla de enrutado de los datos entre el primer y el segundo navegadores de Internet.

Esta modificación de la o de las tablas de enrutado permite en concreto definir un camino de comunicación de sustitución entre los dos navegadores de Internet pasándola también por el equipo de enrutado, por ejemplo para evitar problemas de congestión en el mejor camino de comunicación entre los navegadores de Internet y el servidor de Internet para el intercambio de datos de tipo medios (también llamado camino por omisión o camino principal), para forzar el paso de los datos a través de un equipo intermedio predeterminado de la red, etc.

Según un modo de realización particular, en el curso de una fase de intercambio de datos, el equipo de enrutado implementa unas etapas suplementarias de recepción de un flujo de datos procedente del primer navegador, por ejemplo un flujo de datos de tipo medios y de transmisión del flujo de datos al segundo navegador a través de un equipo intermedio predeterminado de red situado en el camino de comunicación de sustitución.

Según este modo de realización particular, se redirigen de ese modo los flujos de datos intercambiados entre dos navegadores de Internet para forzarles a pasar por un equipo intermedio predeterminado de la red, por ejemplo un equipo de contaje o de recogida de informaciones.

Se entiende en este caso por "flujo de datos" a un conjunto de paquetes de datos transmitidos de manera unidireccional entre dos entidades de la red. Clásicamente, un flujo de datos se caracteriza por una dirección IP de origen (la del emisor del flujo), un número de puerto de origen, una dirección IP de destino (la del destinatario), un número de puerto de destino y un protocolo de transporte.

La invención encuentra aplicaciones en concreto para intercambio de datos entre navegadores de Internet según la tecnología WebRTC, utilizando un servidor STUN.

Se recuerda a este efecto que el servidor STUN no está presente en el camino de comunicación de los datos en WebRTC. Se utiliza por los navegadores de Internet / terminales en ciertos momentos durante las comunicaciones, en concreto para descubrir la red.

En este contexto, la invención propone por tanto utilizar un equipo de enrutado de la red capaz de leer los mensajes STUN para asegurar una gestión de enrutado especializada.

Para hacer esto, la invención se basa en la utilización, en este contexto, de fichas de acceso y de un mecanismo de autenticación de tipo "OAuth" para identificar los flujos de datos de tipo medios que tienen la autorización de ser redirigidos, de conformidad con los acuerdos pasados entre suministradores de servicios de comunicaciones WebRTC y los proveedores de servicios de red por ejemplo. Además, la invención propone según un modo de realización particular que el tráfico redirigido pase por un equipo intermedio predeterminado, que sirve por ejemplo para contar el tráfico o para recoger informaciones de tráfico.

En este contexto, la invención enriquece por tanto el proyecto TRAM del IETF titulado "Extensión TURN para la autorización de terceros" antes mencionado, proponiendo una solución de redirección del flujo de datos de tipo medios incluso cuando no existe ningún repetidor de medios en el camino de comunicación.

Esta solución es ventajosamente ligera por comparación con el suministro de funcionalidades por una GGSN (se recuerda que una "Gateway GPRS Support Node", o GGSN, es una pasarela de interconexión entre una red de paquetes móviles y unas redes IP externas).

5.2 Ejemplo detallado de implementación

Se presenta a continuación un ejemplo detallado de implementación de la invención, para el intercambio de datos de tipo medios entre dos clientes según la tecnología WebRTC.

Se considera para hacer esto una red de comunicación ilustrada en la figura 3, que comprende dos terminales cliente 31 y 32, equipado cada uno con un navegador de Internet que soporta la tecnología WebRTC, un servidor de autorización 33, un equipo de enrutado 34 y un equipo intermedio predeterminado 35.

El equipo de enrutado 34 se coloca en el camino principal de comunicación WebRTC y es gestionado por un proveedor de servicios de red.

Se describen a continuación en el presente documento, en relación con las figuras 4 y 5, las operaciones implementadas para la transmisión de datos del navegador de Internet del primer cliente A 31 hacia el navegador de Internet el segundo cliente B 32. De nuevo, se observa que las mismas operaciones pueden implementarse para la transmisión de datos del navegador de Internet del segundo cliente B 32 hacia el navegador de Internet del primer cliente A 31.

Se considera, como se ilustra en la figura 3, que los clientes A 31 y B 32 son los puntos del extremo de la red que establecen una comunicación WebRTC.

Según este ejemplo, el primer cliente A 31 desea iniciar (41) una sesión de intercambio de datos en P2P con el segundo cliente B 32, según la tecnología WebRTC.

Para hacer esto, el cliente A 31 debe obtener (42) inicialmente una ficha de acceso T por parte del servidor de autorización 33. Dicho servidor de autorización puede preverse por un suministrador de servicios WebRTC. Este servidor puede ser el mismo que el utilizado para el establecimiento de la conexión WebRTC.

Más precisamente, cuando el primer cliente A 31 llama al segundo cliente B 32, se produce un inicio de establecimiento de comunicación WebRTC. La señalización puede asegurarse por el servidor web del suministrador de servicios WebRTC. El suministrador de servicios WebRTC decide si una comunicación dada debe redirigirse preferentemente (cambio de tabla de enrutado y, eventualmente, paso por un equipo intermedio predeterminado). Si es sí, suministra una ficha de acceso al primer cliente A 31 y/o al segundo cliente B 32, puesto que la comunicación es simétrica.

Si el primer cliente A 31 no tiene ficha de acceso T por parte del servidor de autorización (421), se inicia una sesión WebRTC "clásica", sin cambio en las tablas de enrutado y sin modificación del camino principal de comunicación entre el primer cliente A 31 y el segundo cliente B 32 (43).

Si se obtiene una ficha de acceso T por parte del servidor de autorización (422), el cliente A 31 genera (44) un mensaje de verificación de conectividad entre el navegador de Internet del primer cliente A 31 y el navegador de Internet del segundo cliente B 32. Dicho mensaje lleva un atributo específico de autorización de intercambio de datos entre los navegadores, es decir una ficha de acceso T. Por ejemplo, dicho mensaje es de tipo STUN.

Según este modo de realización, un mensaje STUN utilizado para el establecimiento de una conexión en las comunicaciones WebRTC incluye por tanto un atributo STUN suplementario, es decir la "ficha de acceso" T.

El mensaje STUN que lleva la ficha de acceso se transmite por el primer cliente A 31 al segundo cliente B 32 a través del equipo de enrutado 34, que implementa las operaciones clásicas de verificación de conectividad para todos los candidatos ICE. El segundo cliente B 32 envía una respuesta STUN (51) al primer cliente A 31.

El equipo de enrutado 34 es capaz de analizar los mensajes STUN (que no están cifrados) para detectar si un mensaje STUN lleva un atributo de tipo ficha de acceso (45).

A continuación del análisis del mensaje STUN, si el equipo de enrutado no identifica un atributo suplementario de tipo ficha de acceso en el mensaje STUN (451), se inicia una sesión WebRTC "clásica", sin cambio en las tablas de enrutado y sin modificación del camino principal de comunicación entre el primer cliente A 31 y el segundo cliente B 32 (43).

Si el equipo de enrutado identifica un atributo suplementario de tipo ficha de acceso en el mensaje STUN (452), verifica (46) la validez de la ficha de acceso. La verificación de la ficha se implementa por tanto mediante un equipo de red dado, el equipo de enrutado 34.

El equipo de enrutado 34 efectúa por tanto las operaciones de verificación de conectividad y de verificación de la validez de la ficha. Para hacer esto, el equipo de enrutado implementa una función de verificación de mensajes STUN, adquirida por ejemplo descargando una funcionalidad de "verificación STUN", en el marco de su microprograma o llamando a una interfaz de programación que suministre la funcionalidad de "verificación STUN". La función de verificación de mensajes STUN efectúa también la verificación de la ficha. En particular, se observa que el equipo de enrutado 34 puede leer los mensajes STUN utilizados durante las verificaciones de conectividad ICE, porque se supone que estos mensajes no están cifrados.

Esta verificación de la validez de la ficha puede efectuarse por ejemplo según las siguientes variantes:

- para una ficha de acceso independiente, los suministradores de servicios de red pueden establecer una clave simétrica; el equipo de enrutado puede utilizar a continuación esta clave simétrica para verificar la ficha de acceso, sin tener necesidad de llamar al servidor de autorización 33 cada vez que desea verificar la ficha de acceso; - para una ficha de acceso clásica, el equipo de enrutado debe llamar al servidor de autorización 33 cada vez que desea verificar la ficha de acceso.

Una verificación de ese tipo implementa por ejemplo un mecanismo de autentificación de tipo "OAuth" (o sus diferentes versiones), tal como se describe en relación con la figura 1, sin la utilización de servidores TURN.

En caso de verificación negativa (461), se inicia una sesión WebRTC "clásica", sin cambio en las tablas de enrutado y sin modificación del camino principal de comunicación entre el primer cliente A 31 y el segundo cliente B 32 (43).

En caso de verificación positiva (462), el equipo de enrutado modifica (47) dinámicamente la o las tablas de enrutado de los datos entre el primer cliente A 31 y el segundo cliente B 32, de manera que se defina un camino de comunicación de sustitución entre los dos clientes.

La comunicación WebRTC puede redirigirse de ese modo sobre este nuevo camino de comunicación de sustitución entre los dos clientes. El primer cliente A 31 y el segundo cliente B 32 pueden comunicar entonces en P2P intercambiando datos de tipo medios (52).

Por ejemplo, como se ilustra en la figura 3, el camino principal de comunicación entre el primer cliente A 31 y el segundo cliente B 32, según una comunicación WebRTC "clásica", es el ilustrado en línea de puntos, referenciado como 3432. El camino de comunicación de sustitución entre el primer cliente A 31 y el segundo cliente B 32, en este modo de realización de la invención, es el que pasa por el equipo intermediario predeterminado 35, referenciado 3435 y 3532.

Según este ejemplo, a continuación de las verificaciones de conectividad, el equipo de enrutado puede redirigir los flujos de datos que tienen unas fichas válidas con el fin de que pasen por un equipo suplementario, el equipo intermediario predeterminado 35. Un equipo intermediario 35 de ese tipo puede utilizarse para contar el tráfico, recoger informaciones de tráfico, etc. Estas informaciones pueden utilizarse por los suministradores de servicios para obtener estadísticas, controlar un acceso, facturar a los usuarios de servicios de comunicaciones, etc.

De este modo, analizando unos mensajes STUN y verificando la validez de al menos una ficha de acceso, el equipo de enrutado 34 puede gestionar por tanto las decisiones de enrutado modificando las tablas de enrutado (tabla de direcciones IP por ejemplo).

Se observa que la solución propuesta impone que el equipo de enrutado 34 se coloque entre dos puntos del extremo o clientes WebRTC. Esta solución es por tanto particularmente interesante para suministradores de acceso a Internet.

La tabla que sigue presenta una versión simplificada de las tablas de enrutado gestionadas por el equipo de enrutado 34 de la figura 3, antes y después de la implementación de la invención según un modo de realización particular.

En el marco de una comunicación WebRTC "clásica", la tabla de enrutado define un camino principal de comunicación para el intercambio de datos entre el primer cliente A 31 y el segundo cliente B 32, también llamado camino por omisión. La interfaz de salida del equipo de enrutado 34 es la interfaz 1.

En el marco de una comunicación WebRTC según un modo de realización de la invención, el equipo de enrutado añade una nueva entrada correspondiente a la dirección IP del segundo cliente B 32 en una segunda interfaz del equipo de enrutado en la tabla de enrutado. La tabla de enrutado define por tanto otro camino de comunicación para el intercambio de datos entre el primer cliente A 31 y el segundo cliente B 32, también llamado camino de comunicación de sustitución, diferente del camino de comunicación por omisión. La interfaz de salida del equipo de enrutado 34 es entonces la interfaz 2. La máscara de red utilizada (255.255.255.255) significa que la utilización de este camino de sustitución está reservada a un destino preciso (la dirección del segundo cliente B 32).

Se observa que está gestión del enrutado es posible porque las direcciones IP y los números de puerto utilizados para intercambiar unos mensajes STUN para el descubrimiento de la red/las verificaciones de conectividad son las mismas que las utilizadas para la transmisión de los flujos de datos de tipo medios. En otros términos, un flujo de datos de tipo medios utiliza las mismas direcciones IP y los mismos números de puerto que el mensaje STUN asociado.

Además, si el mensaje STUN es un mensaje "clásico", no comprendiendo atributo suplementario de tipo ficha de acceso o si la validez de la ficha de acceso no está verificada, el flujo de datos de tipo medios se envía en el camino por omisión.

La solución propuesta es por tanto transparente para los usuarios.

5.3 Estructuras simplificadas

Se presenta finalmente, en relación con las figuras 6 y 7, la estructura simplificada de un terminal y la estructura simplificada de un equipo de enrutado que implementan respectivamente un procedimiento de transmisión de datos y un procedimiento de intercambio de datos según uno de los modos de realización descritos anteriormente.

Como se ilustra en la figura 6, un terminal según un modo de realización de la invención comprende una memoria 61 que comprende una memoria tampón, una unidad de procesamiento 62, equipada por ejemplo con un microprocesador |jP, y controlada por el programa informático 63, que implementa el procedimiento de transmisión de datos desde un primer navegador de Internet hacia un segundo navegador de Internet descrito anteriormente.

En la inicialización, las instrucciones del código del programa informático 63 se cargan por ejemplo en una memoria RAM antes de ejecutarse por el procesador de la unidad de procesamiento 62. El microprocesador de la unidad de procesamiento 62 implementa las etapas del procedimiento de transmisión de datos descritas anteriormente, según las instrucciones del programa informático 63, para emitir un mensaje de señalización solicitando una comunicación con dicho segundo navegador, recibir un atributo específico de autorización de intercambio de datos entre los navegadores, generar un mensaje de verificación de conectividad entre los navegadores y transmitir este mensaje a un equipo de enrutado de la red. Para ello, el terminal comprende, además de la memoria tampón 61, un módulo de emisión 64 de un mensaje de señalización solicitando una comunicación con el segundo navegador, un módulo de recepción 65 de un atributo específico de autorización de intercambio de datos entre los navegadores, un módulo de generación 66 de un mensaje de verificación de conectividad entre los navegadores, un módulo de transmisión 67 del mensaje al segundo navegador, a través de un equipo de enrutado de la red.

Estos medios están controlados por el microprocesador de la unidad de procesamiento 62.

Como se ilustra en la figura 7, un equipo de enrutado según un modo de realización de la invención comprende una memoria 71 que comprende una memoria tampón, una unidad de procesamiento 72, equipada por ejemplo con un microprocesador jP , y controlada por el programa informático 73, que implementa el procedimiento de intercambio de datos entre un primer navegador de Internet y un segundo navegador de Internet descrito anteriormente.

En la inicialización, las instrucciones del código del programa informático 73 se cargan por ejemplo en una memoria RAM antes de ejecutarse por el procesador de la unidad de procesamiento 72. La unidad de tratamiento 72 recibe en la entrada un mensaje de verificación de conectividad entre los navegadores. El microprocesador de la unidad de procesamiento 72 implementa las etapas del procedimiento de intercambio de datos descritas anteriormente, según las instrucciones del programa informático 73, para extraer un atributo específico de autorización de intercambio de datos entre los navegadores del mensaje de verificación de conectividad, verificar una autorización de intercambio de datos entre los navegadores y modificar al menos una tabla de enrutado de los datos entre los navegadores. Para ello, el equipo de enrutado comprende, además de la memoria tampón 71, un módulo de recepción 74 de un mensaje de verificación de conectividad entre los navegadores, un módulo de verificación 75 de una autorización de intercambio de datos entre los navegadores y un módulo de modificación 76 de al menos una tabla de enrutado de los datos entre los navegadores.

Estos medios están controlados por el microprocesador de la unidad de procesamiento 72.

Claims (12)

REIVINDICACIONES

1. Procedimiento de intercambio de datos entre un primer navegador de Internet y un segundo navegador de Internet de una red de comunicación,

caracterizado por que comprende una fase de inicialización, que implementa las siguientes etapas, a nivel de un equipo de enrutado de dicha red colocado en un camino de comunicación por omisión entre dichos primer y segundo navegadores:

- recepción (24) de un mensaje de verificación de conectividad entre dichos navegadores, llevando dicho mensaje un atributo específico de autorización de intercambio de datos entre dichos navegadores;

- verificación (25) de una autorización de intercambio de datos entre dichos navegadores, a partir de dicho atributo específico;

- en caso de verificación positiva, modificación (26) de al menos una tabla de enrutado de los datos entre dicho primer navegador y dicho segundo navegador, de manera que se defina un camino de comunicación de sustitución entre dichos navegadores, que pasa por dicho equipo de enrutado.

2. Procedimiento de intercambio de datos según la reivindicación 1, caracterizado por que comprende una fase de intercambio de datos, que implementa las siguientes etapas, a nivel de dicho equipo de enrutado:

- recepción de un flujo de datos procedente de dicho primer navegador;

- transmisión de dicho flujo de datos a dicho segundo navegador, a través de un equipo intermedio de red predeterminado situado en dicho camino de comunicación de sustitución.

3. Procedimiento de intercambio de datos según una cualquiera de las reivindicaciones 1 y 2, caracterizado por que dicho mensaje de verificación de conectividad entre dichos navegadores es de tipo STUN.

4. Procedimiento de intercambio de datos según la reivindicación 3, caracterizado por que dicha etapa de verificación de una autorización de intercambio de datos entre dichos navegadores implementa una función de tipo "verificación STUN".

5. Procedimiento de intercambio de datos según una cualquiera de las reivindicaciones 1 a 4, caracterizado por que dicho atributo específico es una ficha de acceso.

6. Procedimiento de intercambio de datos según la reivindicación 5, caracterizado por que dicha etapa de verificación de una autorización de intercambio de datos implementa una clave, conocida por dicho equipo de enrutado, para verificar la validez de dicha ficha de acceso.

7. Procedimiento de intercambio de datos según la reivindicación 5, caracterizado por que dicha etapa de verificación de una autorización de intercambio de datos implementa un intercambio de informaciones con un servidor de autorización para verificar la validez de dicha ficha de acceso.

8. Equipo de enrutado de una red de comunicación, destinado a situarse sobre un camino de comunicación por omisión entre un primer navegador de Internet y un segundo navegador de Internet de dicha red, caracterizado por que comprende:

- un módulo de recepción (74) de un mensaje de verificación de conectividad entre dichos navegadores, llevando dicho mensaje un atributo específico de autorización de intercambio de datos entre dichos navegadores;

- un módulo de verificación (75) de una autorización de intercambio de datos entre dichos navegadores, a partir de dicho atributo específico;

- un módulo de modificación (76) de al menos una tabla de enrutado de los datos entre dicho primer navegador y dicho segundo navegador, activado en caso de verificación positiva, de manera que se defina un camino de comunicación de sustitución entre dichos navegadores.

9. Procedimiento de transmisión de datos de un primer navegador de Internet con destino en un segundo navegador de Internet de una red de comunicación, que comprende una etapa (20) en el curso de la que dicho primer navegador emite un mensaje de señalización solicitando una comunicación con dicho segundo navegador, caracterizado por que comprende además las siguientes etapas:

- recepción (21), por dicho primer navegador, de un atributo específico de autorización de intercambio de datos entre dichos navegadores, suministrado por un servidor de autorización;

- generación (22) de un mensaje de verificación de conectividad entre dichos navegadores, llevando dicho mensaje dicho atributo específico; y

- transmisión (23) de dicho mensaje a dicho segundo navegador a través de un equipo de enrutado de dicha red, de acuerdo con la reivindicación 8, colocado en un camino de comunicación por omisión entre dichos primer y segundo navegadores.

10. Terminal de una red de comunicación, equipado con un primer navegador de Internet destinado a transmitir unos datos con destino en un segundo navegador de Internet contenido en un terminal distante de dicha red y que comprende un módulo de emisión (64) de un mensaje de señalización solicitando una comunicación con dicho segundo navegador, caracterizado por que además comprende:

- un módulo de recepción (65) de un atributo específico de autorización de intercambio de datos entre dichos navegadores, suministrado por un servidor de autorización;

- un módulo de generación (66) de un mensaje de verificación de conectividad entre dichos navegadores, llevando dicho mensaje dicho atributo específico;

- un módulo de transmisión (67) de dicho mensaje al segundo navegador a través de un equipo de enrutado de dicha red, de acuerdo con la reivindicación 8, colocado en un camino de comunicación por omisión entre dichos primer y segundo navegadores.

11. Programa informático que incluye unas instrucciones para la implementación de un procedimiento según una cualquiera de las reivindicaciones 1 a 7, 9 cuando este programa se ejecuta por un procesador.

12. Soporte de informaciones, fijo o parcialmente o totalmente extraíble, legible por un ordenador y que incluye instrucciones de programa informático para la ejecución de las etapas de un procedimiento según una cualquiera de las reivindicaciones 1 a 7, 9.