ES2904675T3

ES2904675T3 - Procedimiento y sistema de transmisión de datos entre nodos conectados a distintos entornos IP mediante la asignación de direcciones ficticias

Info

Publication number: ES2904675T3
Application number: ES20185343T
Authority: ES
Inventors: Mohamed Boucadair; Yoann Noisette
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2006-02-28
Filing date: 2007-02-15
Publication date: 2022-04-05
Anticipated expiration: 2027-02-15
Also published as: EP1989858A2; JP2009528741A; US9197480B2; US20090304025A1; EP1989858B1; ES2904469T3; EP3813332A1; CN101395884B; EP3745674A1; ES2930278T3; PL3745674T3; PL3813332T3; WO2007099247A2; EP3745673A1; ES2876223T3; JP5051728B2; PL3745673T3; EP3745674B1; WO2007099247A3; EP3813332B1

Abstract

Procedimiento de transmisión de datos entre al menos dos nodos de una red, estando cada uno de dichos nodos conectado a al menos un entorno IP, denominado entorno de origen de dicho nodo, que comprende: - una etapa de asignación, a al menos un agente usuario incluido en uno (NA) de dichos nodos, de una dirección ficticia en un entorno IP diferente del entorno de origen de este nodo (NA), siendo uno de dichos entornos IP un entorno IPv6 y el otro un entorno IPv4, y - una etapa de presentación de al menos dicha dirección ficticia y de una dirección de origen de dicho agente usuario en dicho entorno de origen cuando se establece una comunicación con al menos un nodo remoto (NB), caracterizado por que dicha etapa de presentación es ejecutada por dicho agente usuario, en al menos un mensaje de invitación a entrar en comunicación con dicho nodo remoto (NB) y/o en al menos un mensaje de respuesta a un mensaje de invitación a entrar en comunicación enviado por dicho nodo remoto (NB).

Description

DESCRIPCIÓN

Procedimiento y sistema de transmisión de datos entre nodos conectados a distintos entornos IP mediante la asignación de direcciones ficticias

La invención se enmarca en el campo de las telecomunicaciones y, de manera más particular, en el de la telefonía sobre IP.

Las redes que se ajustan al denominado protocolo de comunicación IP (abreviatura bien conocida por los expertos en la materia para la expresión inglesa "Internet Protocol") se utilizan cada vez más como medios universales para una multitud de servicios y aplicaciones. Este protocolo IP ha desempeñado un papel unificador ante múltiples operadores que han elegido este protocolo para poner en común ofertas de servicios hasta ahora dispares.

IPv4 es una versión del protocolo de comunicación IP que se ha utilizado desde hace años.

Para cumplir con las limitaciones impuestas por tales servicios de comunicación y, más en particular, para satisfacer las crecientes necesidades en términos de direcciones, los operadores y los fabricantes de equipos de redes se han unido para especificar un protocolo de comunicación de nueva generación, comúnmente conocido como IPv6, definido por especificaciones así como documentos de análisis que se encuentran en una etapa de desarrollo suficientemente avanzada como para poder considerar actualmente un despliegue operativo en las redes de los operadores.

No obstante, la introducción de esta nueva generación de protocolo plantea importantes problemas ligados a la necesidad de garantizar la interoperabilidad y el interfuncionamiento del protocolo IPv6 y el protocolo IPv4 que ya está desplegado en las redes IP. En el estado actual de la técnica se han identificado soluciones a estos problemas, pero tienen la desventaja de no intervenir exclusivamente a nivel de "servicio" (en particular, la capa de aplicación) sino también a nivel de "transporte" (capa IP). En la capa de transporte, se han propuesto mecanismos, o incluso estandarizado en el IETF (abreviatura bien conocida por los expertos en la materia para la expresión en inglés "Internet Engineering Task Force") tales como una técnica conocida como NAT-PT (de la abreviatura en inglés "Network Address Translation-Protocol Translation" de "traducción de direcciones de red - traducción de protocolos") y diversas técnicas conocidas por el término inglés "tunneling" (tunelización) y que consisten en encapsular datos IPv6 en datagramas IPv4 o viceversa.

Además, las actualizaciones y adaptaciones de arquitecturas y plataformas de servicios son necesarias para permitir el interfuncionamiento entre clientes ubicados en entornos IP de diferente naturaleza (IPv4 o IPv6), y esto de la manera más transparente posible para el cliente final.

Entre otras actividades multimedia, el IETF ha estandarizado un protocolo llamado SIP (abreviatura bien conocida por los expertos en la técnica de la expresión inglesa "Session Initiation Protocol", Protocolo de inicio de sesión) que ofrece como principales funciones, el inicio, la modificación y la terminación de sesiones multimedia. Este protocolo SIP constituye un interesante ejemplo de aplicación de la presente invención. El protocolo SIP se basa en un protocolo SDP (abreviatura bien conocida por los expertos en la técnica de la expresión inglesa "Sesión Description Protocol") para producir una descripción de los parámetros relacionados con la sesión en cuestión. Después de una negociación exitosa entre dos partes en una llamada, estas últimas pueden intercambiar flujos de medios gracias a la activación de un protocolo RTP (abreviatura bien conocida por los expertos en la materia de la expresión inglesa "Real time Transport Protocol"). Los parámetros de las sesiones RTP se prenegocian mediante unos mensajes de señalización SIP, concretamente en la parte SDP. Estos parámetros son principalmente direcciones de terminación y números de puerto que se utilizarán a ambos lados del enlace de comunicación que se va a establecer.

Dado que una primera versión del protocolo SIP se describió en un documento de referencia RFC 2543 (RFC significa "solicitud de comentarios" o "Request For Comment" en inglés), este último es compatible con el protocolo IPv6. En principio, una implementación del protocolo SIP debería poder descodificar fácilmente direcciones IPv4 e IPv6. Estas direcciones IP se pueden introducir en un campo específico tal como una cabecera "CONTACT" o en las cabeceras de la parte SDP. Sin embargo, la presencia de tales direcciones puede impedir el establecimiento de llamadas SIP en caso de que no se pueda acceder a los dos terminales en un mismo entorno IP, es decir, si uno dispone de una dirección IPv4 y el otro de una dirección IPv6. Por lo tanto, cuando un agente usuario A de tipo IPv4 inicia una sesión SIP a un agente usuario de tipo IPv6 que se ha registrado en un servidor de ubicación (indicado con la letra R en lo sucesivo) de tipo IPv4, el intercambio de mensajes SIP producido se describe en la figura 1a, donde un primer agente usuario A que desea entrar en contacto con un segundo agente usuario B envía un mensaje "INVITE" a un servidor de proximidad llamado servidor proxy (denominado PS en lo sucesivo) utilizando una dirección IPv4 específica de este último. El servidor proxy PS es aquí un servidor conectado a un entorno IPv4 exclusivamente. Una vez que el servidor proxy PS ha recibido el mensaje, este último realiza una solicitud a un servidor de ubicación también denominado servidor de registro y recupera así la dirección del segundo agente usuario B. Dado que esta dirección es hipotéticamente una dirección IPv6, el servidor proxy PS no conoce una ruta a este destino ya que este servidor proxy PS es exclusivamente de tipo IPv4. A continuación, se envía un mensaje de error al agente usuario A que concluye que es imposible establecer una sesión SIP entre el primer y el segundo agente usuario A y B. Este mensaje de error está indicado con la referencia (2) 404 "No Route" en la figura 1a.

No obstante, si ahora se asume que el servidor proxy PS puede comunicarse con la dirección de ubicación del primer agente usuario A, así como la del segundo agente usuario B, se observa otro intercambio de mensajes SIP, cuando el segundo agente usuario B intenta llamar al primer agente usuario A, como se ha representado en la figura 1b.

En el caso concreto de esta figura, el servidor proxy PS enruta un mensaje "INVITE" recibido del segundo agente usuario B a la dirección de ubicación del primer agente usuario A. Este mensaje "INVITE" contiene una oferta SDP que describe, además de las capacidades ofrecidas por el primer agente usuario B en términos de CODEC (para "codificador/descodificador"), un número de puerto rTp y una dirección que el segundo agente usuario B utilizará para enviar/recibir flujos RTP. En el caso de la figura 1b, esta dirección es de tipo IPv6. Así, cuando el agente usuario A recibe este mensaje "INVITE", solo puede rechazar la apertura de la sesión porque este agente usuario es un cliente IPv4. En el mejor de los casos podrá, según las implementaciones, devolver un mensaje de error que indica que no admite conexiones de red a la dirección IP del agente usuario B. En los dos ejemplos anteriores, descritos con relación a las figuras 1a y 1b, no se pueden establecer sesiones SIP de este modo.

Una coexistencia de direcciones IP de diferentes tipos puede afectar a llamadas distintas de las que han sido objeto de la representación gráfica descrita anteriormente. Así, las llamadas destinadas a clientes de DS (abreviatura bien conocida por los expertos en la materia de la expresión en inglés "Dual Stack", doble pila), también podrían no dar lugar a intercambios de flujo de medios, siendo los agentes usuarios de tipo DS capaces de procesar los dos tipos de direcciones IPv4 y IPv6. Esto se debe a que el protocolo SIP, en su versión básica, solo le permite introducir una única dirección IP para enviar o recibir flujos de medios. Para paliar este problema, un documento de referencia RFC 4092 introduce una nueva semántica que consiste, entre otras cosas, en definir un indicador denominado "sdp-anat". Esta nueva semántica permite a un agente usuario, anunciar y/o descubrir uno o más tipos de direcciones. Así, los agentes usuarios de tipo DS pueden indicar sus dos direcciones IPv4 e IPv6 en su oferta SDP. Gracias a esta técnica, todas las llamadas desde/hacia un agente usuario de tipo DS hacia/desde clientes de versión única (es decir, solo compatibles con el protocolo IPv4 o solo con el protocolo IPv6) pueden resultar en sesiones SIP exitosas. Sin embargo, esta semántica está reservada exclusivamente para agentes usuarios de tipo DS, y por lo tanto no ofrece una solución para el establecimiento exitoso de sesiones entre clientes de versión única.

En este caso particular, en el que dos nodos que forman los extremos de un enlace de comunicación destinado a transportar una llamada determinada son de versión única, el operador del servicio de telefonía SIP en cuestión puede emplear aplicaciones ALG (abreviatura bien conocida por los expertos en la materia de la expresión en inglés "Application Level Gateway"), para modificar las ofertas SDP para asegurar la coherencia entre el tipo de dirección admitida y el contenido en los mensajes SIP recibidos. Para ello, los servidores SIP utilizan información relacionada con la capa de transporte, y no específica del protocolo SIP, para enrutar llamadas o para determinar el empleo de aplicaciones ALG para alterar el contenido de las ofertas SDP. Este comportamiento de los servidores SIP no se describe en la norma.

En general, el problema vinculado a las interconexiones de dos agentes usuarios heterogéneos (es decir, de distintos tipos de IP) no ha sido estudiado con detalle por la comunidad de las telecomunicaciones. Excepto por una propuesta de ANAT descrita (en RFC 4091, RFC 4092) que resuelve parte del problema, en particular, no existe ningún documento del IETF que describa el comportamiento de los servidores SIP para enrutar llamadas que conectan dos agentes usuarios que pertenecen a dos entornos IP diferentes.

Además, las técnicas existentes tienen los siguientes inconvenientes:

- el empleo de aplicaciones ALG y de funciones de adaptación adicionales no está documentado. El servidor proxy PS no dispone de los medios proporcionados por la RFC 3261 para facilitar esta tarea. Además, este empleo de aplicaciones ALG y de funciones de adaptación adicionales aumenta la carga de tareas completadas en la red; - el servidor proxy P^sdebe recurrir a la información de la capa de red (también denominada en este documento capa de transporte) para tomar decisiones relativas a la capa de servicio. Por lo tanto, se deben tener en cuenta otras consideraciones como la dirección de origen de los mensajes, la dirección utilizada para contactar con el servidor proxy o examinar la parte SDP. Esto puede afectar negativamente al rendimiento del proxy que, en principio, está configurado para procesar solo información de nivel de servicio;

- la solución no es genérica: la filosofía del enrutamiento de llamadas y la intervención del servidor proxy PS depende de la solución de interconexión desplegada a nivel de transporte;

- el enrutamiento de llamadas se basa en la discriminación de los clientes: de hecho, para enrutar llamadas entre nodos heterogéneos, el servidor proxy necesita saber el tipo de los nodos llamado y llamador (IPv4, IPv6 o DS). Ahora bien, la complejidad de recuperar esta información puede afectar negativamente al desempeño de la llamada.

La solicitud US 2004/0246991 divulga un traductor de direcciones IP que comprende: una unidad de procesamiento de mensajes SIP-ALG para atribuir una dirección IP virtual en un proceso de establecimiento de una sesión entre un aparato Ipv4 y un aparato IPv6 a través de un servidor SIP; una tabla de traducción de direcciones para almacenar una relación entre una dirección IPv4 y una dirección virtual IPv6, una relación entre una dirección IPv6 y una dirección IPv4 virtual, y la información de filtrado en asociación con cada una de las direcciones virtuales; y un procesador para realizar la traducción de direcciones en los paquetes IPv4 e IPv6 de acuerdo con la tabla de traducción de direcciones. La información contenida en las cabeceras de los paquetes recibidos se verifica en base a la información de filtrado antes de la traducción de la dirección, para descartar un paquete no conforme a la información de filtrado.

La solicitud EP 0840482 divulga un aparato que comprende: una unidad de emisión y recepción de IP capaz de transmitir y recibir un paquete IPv4 y un paquete IPv6; una unidad de conversión de cabecera de IP capaz de realizar una conversión mutua del paquete IPv4 y del paquete IPv6 por medio de conversión de cabecera de IP; una unidad de sustitución de DNS capaz de recibir una solicitud para obtener información de dominio enviada por un terminal IPv4 o un terminal IPv6 y reemplazarla; una unidad de obtención de direcciones IPv4 capaz de obtener una dirección IPv4 de un servidor DHCP; y una unidad de almacenamiento de información de conversión de dirección IP capaz de almacenar una dirección IPv6 del terminal IPv6 y la dirección IPv4 obtenida por la unidad de obtención de direcciones IPv4 correspondiéndose la una con respecto a la otra.

El trabajo realizado por los inventores les llevó a concluir que, a pesar de una necesidad que surge del estudio anterior, en el estado de la técnica no existe ninguna disposición que permita a un servidor proxy enrutar con éxito una llamada a un nodo remoto sin haber determinado previamente el tipo de este nodo llamado, explicando tal carencia por qué la mayoría de las técnicas de gestión de comunicaciones entre nodos heterogéneos actualmente en estudio son insuficientes y no satisfacen las necesidades de servicio que consisten en permitir comunicaciones heterogéneas.

La presente invención ofrece una solución que no presenta estos inconvenientes al proponer un procedimiento de transmisión que permite a un agente usuario, incluso si es de versión única, anunciar y/o descubrir varios tipos de direcciones, correspondientes a diferentes entornos IP.

En efecto, la invención propone un procedimiento de transmisión de datos entre al menos dos nodos de una red, estando un nodo conectado al menos a un entorno IP, denominado entorno de origen.

Según la invención, un procedimiento de ese tipo comprende:

- una etapa de asignación, a al menos un agente usuario incluido en uno de dichos nodos, de una dirección ficticia en un entorno IP diferente de dicho entorno de origen, siendo uno de dichos entornos IP un entorno IPv6 y el otro un entorno IPv4, y

- una etapa de presentación de al menos dicha dirección ficticia y de una dirección de origen de dicho agente usuario en dicho entorno de origen cuando se establece una comunicación con al menos un nodo remoto, caracterizado por que dicha etapa de presentación es ejecutada por dicho agente usuario, en al menos un mensaje de invitación a entrar en comunicación con dicho nodo remoto (NB) y/o en al menos un mensaje de respuesta a un mensaje de invitación a entrar en comunicación enviado por dicho nodo remoto (NB).

Así, la invención se basa en un enfoque completamente nuevo e inventivo de la transmisión de datos entre nodos, eventualmente heterogéneos (es decir, conectados a diferentes entornos IP, tal como IPv4 e IPv6), de una red de comunicaciones.

En efecto, la invención propone asignar una dirección ficticia a los agentes usuarios y anunciar, tanto esta dirección ficticia, como la dirección de origen de los agentes, durante el establecimiento de una sesión de comunicación con un agente usuario de otro nodo de red. Tomando como ejemplo particular el de una red de comunicaciones que comprende ciertos nodos ubicados en un entorno IPv4 y ciertos nodos ubicados en un entorno IPv6, por tanto, la técnica de la invención permite asignar a un nodo de versión única, por ejemplo, un nodo exclusivamente IPv4, una dirección ficticia en el entorno IPv6.

De conformidad con el sentido corriente del término ficticio, una dirección ficticia (que también podría designarse en inglés con la expresión "fake address") en el presente documento designa una dirección que solo existe en apariencia, en el sentido de que solo constituye una dirección de representación del agente usuario, y no puede usarse a nivel de las capas de transporte del nodo, para enrutar flujos de datos.

En el caso particular de intercambios que se ajustan al protocolo SIP, la técnica de la invención permite, por lo tanto, en una variante de realización particular, generalizar el uso del atributo ANAT, hasta ahora reservado exclusivamente para nodos de tipo Dual Stack, a todos los nodos y equipos del servicio, por lo tanto, en particular para nodos y equipos de versión única, que solo están conectados a un único entorno de IP (solo IPv4 o solo IPv6). En efecto, como se verá con más detalle en el resto del presente documento, los agentes usuarios de versión única pueden usar así el atributo ANAT para mencionar su dirección de origen y la dirección ficticia que les asignó el operador de red.

Por supuesto, la invención también podría aplicarse en el caso de tres entornos IP distintos y permitiría asignar una tercera dirección (ficticia) a clientes que ya son del tipo DS, o dos direcciones ficticias a clientes de versión única. Se observará que esta asignación puede adoptar diferentes formas. En efecto, la dirección ficticia se puede configurar definitivamente tras la entrega de un dispositivo o nodo de red. También puede ser atribuida por el operador al conectar este equipo a la red. Por último, el operador puede adjudicarla dinámicamente y, por ejemplo, modificarse con mayor o menor frecuencia por razones de seguridad.

Gracias a la presentación de las direcciones, ficticia y de origen, de los agentes usuarios propuesta por la invención, ya no es necesario, para un servidor proxy, por ejemplo, emprender medidas para determinar el tipo de agente usuario llamador o llamado, teniendo en cuenta la información de la capa de transporte. En el ejemplo particular de una red que comprende entornos IPv4 e IPv6, el servidor proxy ya no necesita determinar si un agente usuario es de tipo IPv4, IPv6 o DS para realizar el enrutamiento de llamadas entre nodos.

Según un primer aspecto de la invención, dicho procedimiento de transmisión también comprende una etapa de envío por parte de dicho agente usuario de un mensaje de registro a un servidor de ubicación, dicho mensaje de registro comprende al menos dichas direcciones, ficticia y de origen, de dicho agente usuario, y dicho mensaje de registro también comprende al menos un primer indicador de nivel de prioridad de una de dichas direcciones.

Así, durante la fase de registro preliminar en el servidor de ubicación (que también se puede denominar servidor de registro o "registrar"), el agente usuario comunica sus dos direcciones, ficticia y de origen, e indica cuál de estas dos direcciones se debe usar prioritariamente.

En el ejemplo particular del protocolo SIP, el agente usuario envía un mensaje de tipo REGISTER, en el que inserta dos cabeceras CONTACT para cada una de las dos direcciones o una sola cabecera "CONTACT" que contiene las dos direcciones. Como se verá a continuación, la prioridad se puede indicar usando un parámetro "q" especificado en el documento de referencia RFC3261.

Además, en ese caso, tal procedimiento también comprende una etapa de memorizar al menos dichas direcciones, ficticia y de origen, y dicho nivel de prioridad asociado, con referencia a un identificador de dicho agente usuario. El servidor de ubicación mantiene así una base de datos que agrupa las direcciones, ficticia y de origen, de cada uno de los agentes usuarios que se han registrado en el mismo, así como eventualmente otra información útil. De este modo puede, previa petición, transmitir esta información a los equipos que la necesiten, como un servidor proxy o un nodo intermedio de la red ubicado en el límite de dos entornos IP distintos y responsable de llevar a cabo la traducción de direcciones, como se verá con más detalle en lo sucesivo.

Según una característica ventajosa, dicho primer indicador de nivel de prioridad asigna un nivel de prioridad más alto a dicha dirección ficticia o de origen de dicho agente usuario correspondiente al entorno IP al que se conecta un servidor proxy que interviene durante dicho establecimiento de una comunicación con dicho nodo remoto.

La dirección del agente usuario que está marcada como prioritaria es, por lo tanto, del mismo tipo de IP que la del servidor proxy, asegurándose así de que el servidor proxy la comprende. Esta dirección prioritaria se utiliza a continuación para el enrutamiento de llamadas. Esto evita que el servidor proxy no comprenda la dirección utilizada para el enrutamiento de llamadas, lo que haría que la llamada fracasara.

Dicha etapa de presentación es ejecutada por dicho agente usuario en al menos un mensaje de invitación a entrar en comunicación con dicho nodo remoto y/o en al menos un mensaje de respuesta a un mensaje de invitación a entrar en comunicación enviado por dicho nodo remoto.

Así, se reducen las tareas realizadas en el núcleo de la red y, en particular, por el servidor proxy, trasladando parte del procesamiento a los nodos y terminales: son los agentes usuarios los que se encargan de introducir sus dos direcciones, ficticia y de origen, en los mensajes que envían. El servidor proxy ya no necesita, entonces, determinar el tipo de agente usuario llamador o llamado.

Además, el comportamiento de todos los nodos terminales queda así homogeneizado desde el punto de vista de la plataforma de servicios. En efecto, en el ejemplo particular del protocolo SIP y desde el punto de vista de un servidor proxy, todos los nodos, ya sean de versión única o de múltiples versiones, utilizan entonces el servicio de la misma manera.

Por último, la ejecución de esta presentación de direcciones por parte del agente usuario resulta particularmente flexible. En efecto, en el caso de que un agente usuario disponga de varias direcciones de origen del mismo tipo (por ejemplo, varias direcciones IPv6), entonces puede elegir por sí mismo, al iniciar una llamada, presentar solo una de estas direcciones de origen, además de la dirección ficticia que se le ha asignado.

En un ejemplo ilustrativo no reivindicado, dicha etapa de presentación es ejecutada por un servidor proxy que interviene durante dicho establecimiento de una comunicación entre dicho agente usuario y dicho nodo remoto, en al menos un mensaje de invitación a entrar en comunicación con dicho nodo remoto enviado por dicho agente usuario, y/o en al menos un mensaje de respuesta a un mensaje de invitación a entrar en comunicación enviado por dicho nodo remoto.

Esta variante puede ser complementaria al modo de realización anterior y constituir un proceso de control realizado a nivel del servidor proxy, en caso de fallo o mal funcionamiento de uno de los nodos. Así, si el servidor proxy constata que un mensaje que ha recibido no contiene las direcciones, ficticia y de origen, de un agente usuario, las inserta él mismo, ya sea porque sabe determinar por sí mismo estas direcciones, o después de solicitar estas direcciones al servidor de ubicación en el que se ha registrado el agente usuario.

También se podría prever que esta variante de realización sustituya al modo de realización anterior y que sea el servidor proxy y no el agente usuario el que realiza sistemáticamente la presentación. Sin embargo, no es este enfoque el que se presentará en relación con las figuras en el resto del presente documento.

Ventajosamente, dichos mensajes de invitación y respuesta también comprenden al menos un segundo indicador de nivel de prioridad de una de dichas direcciones, permitiendo asignar un nivel de prioridad más alto a dicha dirección de origen de dicho agente usuario.

De hecho, es esta dirección de origen la que debe utilizarse realmente al nivel de las capas de transporte para los flujos de medios.

El procedimiento de la invención también comprende una etapa de transformación de al menos una dirección de destino de un mensaje enviado por dicho agente usuario a dicho nodo remoto, estando destinada dicha etapa de transformación a ejecutarse cuando dicha dirección de destino es una dirección ficticia y permitiendo transformar dicha dirección ficticia en una dirección de origen asociada.

Tal transformación se puede realizar en un nodo intermedio de la red, ubicado en el límite de dos entornos IP y que actúa como retransmisor entre estos dos entornos. En el caso de dos "burbujas" IPv4 e IPv6, por ejemplo, este nodo intermedio luego realiza la conversión de paquetes IPv6 en paquetes IPv4 y viceversa. Esta transformación es especialmente útil en el caso de que los dos nodos que entran en comunicación estén conectados a dos entornos IP distintos (también se dice que son heterogéneos): la simple transformación de direcciones permite realizar el enrutamiento del tráfico, sin tener que recurrir a una aplicación de tipo ALG.

La invención también se refiere a una señal de transmisión de un mensaje intercambiado entre al menos dos nodos de una red, estando un nodo conectado al menos a un entorno IP, denominado entorno de origen. Según la invención, tal señal comprende al menos:

- un campo que contiene al menos una dirección de origen en dicho entorno de origen asociada con un agente usuario incluido en uno de dichos nodos;

- un campo que contiene al menos una dirección ficticia asignada a dicho agente usuario en un entorno IP diferente de dicho entorno de origen.

La invención también se refiere a un sistema de transmisión de datos entre al menos dos nodos de una red, estando un nodo conectado al menos a un entorno IP, denominado entorno de origen. Según la invención, un sistema de este tipo comprende:

- medios de asignación, a al menos un agente usuario incluido en uno de dichos nodos, de una dirección ficticia en un entorno IP diferente de dicho entorno de origen;

- medios de presentación de al menos dicha dirección ficticia y una dirección de origen de dicho agente usuario en dicho entorno de origen cuando se establece una comunicación con al menos un nodo remoto.

La invención también se refiere a varios programas informáticos que comprenden instrucciones de código para implementar las etapas del procedimiento de transmisión de datos como se ha descrito anteriormente, cuando estos programas son ejecutados por un procesador. Cada uno de estos programas se refiere respectivamente a las etapas del procedimiento ejecutadas en un agente usuario, en un servidor proxy o en elementos de recursos intermedios distribuidos en la red o incluidos en un nodo intermedio IN ubicado en el límite de dos entornos IP distintos.

La invención finalmente se refiere a un nodo de una red de transmisión de datos, conectado a un entorno IP, denominado entorno de origen, y que comprende al menos un agente usuario, que es destacable por que comprende:

- medios de memorización de una dirección ficticia asignada a dicho agente usuario en un entorno IP diferente de dicho entorno de origen;

- medios de presentación de al menos dicha dirección ficticia y una dirección de origen de dicho agente usuario en dicho entorno de origen cuando se establece una comunicación con al menos un nodo remoto de dicha red. La señal, el sistema, el nodo y el programa informático de acuerdo con la invención tienen las mismas ventajas que el procedimiento descrito anteriormente.

Otras ventajas y características de la invención se apreciarán con más claridad tras la lectura de la siguiente descripción de un modo de realización particular de la invención, aportado a título de simple ejemplo ilustrativo y no limitativo, y de los dibujos adjuntos, entre los cuales:

- las figuras 1a y 1b, ya comentadas en relación con la técnica anterior, ilustran dos ejemplos de fallos en el establecimiento de una sesión de comunicación entre dos agentes usuarios A y B conectados a redes IP de diferentes naturalezas;

- la figura 2a ilustra las diferentes configuraciones de red en las que se puede aplicar el procedimiento de la invención; - la figura 2b ilustra en forma de organigrama las principales etapas del procedimiento de la invención;

- la figura 2c presenta con más detalle las etapas de registro del organigrama de la figura 2a;

- la figura 3 describe un ejemplo de una red en la que se aplica la invención, que comprende una red IPv4 a la que está conectado un agente usuario NA y una red IPv6 a la que está conectado un agente usuario NB;

- la figura 4 ilustra en forma de cuadro sinóptico un nodo según la invención.

El principio general de la invención se basa, en el marco de una red de comunicaciones que comprende al menos dos entornos IP distintos, en la asignación de una dirección ficticia a un agente usuario en un entorno IP distinto del entorno IP al que está conectado. A continuación, se presenta esta dirección ficticia, junto con la dirección de origen del agente usuario, en los mensajes intercambiados durante el establecimiento de una comunicación con otro nodo de la red.

En un ejemplo particular de realización, al que se hará referencia a lo largo del resto del documento, correspondiente al establecimiento de sesiones de comunicación según el protocolo SIP entre nodos heterogéneos de tipo IPv4, IPv6 o DS, el principio de la invención consiste, por tanto, en generalizar el uso del atributo ANAT con los clientes de versión única, es decir, IPv4 puro o IPv6 puro.

Primero se presentan, en relación con la figura 2a, diferentes configuraciones de red (del caso 1 al caso 6) en las que se puede aplicar la técnica de la invención. En esta figura, se consideran dos entornos IPv4 e IPv6 interconectados por un nodo intermedio denominado IN (de la abreviatura inglesa "Intermediate Node"). Las notaciones utilizadas en esta figura 2a son las siguientes:

- R (de la abreviatura en inglés "Registrar") designa un servidor de ubicación;

- PS (de la abreviatura en inglés "Proxy Server") designa un servidor proxy;

- el número 4 indica que el equipo considerado está conectado a la red IPv4;

- el número 6 indica que el equipo considerado está conectado a la red IPv6;

- las letras DS indican que el equipo considerado es de tipo Dual Stack.

Así, R4 designa, por ejemplo, un servidor de ubicación de tipo IPv4 y PSDS designa un servidor proxy de tipo Dual Stack, que, por lo tanto, se ha representado conectado simultáneamente a los entornos IPv4 e IPv6.

En particular:

- el caso 1 corresponde al caso en el que cada entorno IP, de tipo IPv4 y de tipo IPv6, incluye un servidor de ubicación R4 respectivamente R6 y un servidor proxy PS4 respectivamente PS6;

- el caso 2 corresponde a un caso en el que el entorno IP del tipo IPv6 no incluye un servidor de ubicación ni un servidor proxy, sino que incluye un servidor de ubicación de doble pila RDS y un servidor proxy de doble pila PSDS;

- en el caso 3, cada entorno IPv4 e IPv6 comprende un servidor de ubicación R4, R6 y un servidor proxy PS4, PS6. Además, se proporciona un servidor de ubicación de doble pila RDS y un servidor proxy de doble pila PSDS;

- en el caso 4, solo la red IPv4 comprende un servidor de ubicación R4 y un servidor proxy PS4.

- el caso 5 corresponde a un caso dual del caso 4;

- el caso 6 corresponde a un caso dual del caso 2.

A lo largo del resto del presente documento, nos situamos en el contexto particular del caso 4 anterior, donde todos los elementos que constituyen la plataforma de servicio (es decir, el servidor de ubicación y el servidor proxy) están conectados a la red IPv4.

Esta configuración corresponde, de hecho, al caso más común a nivel operativo en los servicios desplegados en las redes actuales. Los expertos en la materia comprenderán fácilmente que la invención, sin embargo, no se limita a esta configuración particular y que se aplica a todos los demás casos (casos 1 a 3 y 5 a 6) de la figura 2a.

Esta configuración se ilustra con más detalle en la figura 3, en la que un nodo SIP NA, un servidor proxy PS y un servidor de ubicación R están conectados a una red IPv4, interconectada mediante un nodo intermedio IN a una red IPv6 a la que se une un nodo SIP NB.

Según el procedimiento de la invención, se realizan las siguientes modificaciones en los elementos existentes: - se atribuye una dirección IPv6 ficticia a cada uno de los elementos que constituyen la plataforma de servicios SIP, es decir, el servidor proxy PS y el servidor de ubicación R. Cada una de estas direcciones sirve para representar el elemento de servicio correspondiente en el entorno IPv6. En este caso concreto, estos elementos son puramente IPv4 y, por lo tanto, no admiten direcciones IPv6 en el nivel de transporte. Sin embargo, pueden descodificar/comprender direcciones IPv6 a nivel de aplicación, es decir, a nivel de la pila SIP.

- a cada nodo SIP IPv4 (en este caso NA) se le atribuye una dirección IPv6 ficticia, y a cada nodo SIP IPv6 (en este caso NB) se le atribuye una dirección IPv4 ficticia. No obstante, esto no convierte por ello a los nodos SIP NA y NB en clientes de doble pila. Estas direcciones ficticias son utilizadas, como parte del procedimiento objeto de la invención, únicamente por el servicio SIP. Por lo tanto, no son utilizadas por las capas de transporte del cliente correspondiente.

La asignación de direcciones está restringida para que haya una función f() y una función g(), tales como @v4=f(@v6) y @v6=g(@v4), donde @v4 y @v6 son direcciones IPv4 e IPv6 respectivamente. La definición de estas funciones se deja a la libre iniciativa del operador, al implementar el servicio. A título de ejemplo, se pueden citar las direcciones IPv4 mapeadas o las direcciones IPv4 compatibles, estando estos dos formatos descritos por los estándares IPv6.

Las direcciones IPv4 mapeadas son direcciones IPv6 representadas como ::FFFF:a.b.c.d donde a.b.c.d es una dirección IPv4. Las direcciones IPv4 compatibles son direcciones IPv6 representadas como ::a.b.c.d donde a.b.c.d es una dirección IPv4.

Simplemente se indica que la elección de las funciones f y g debe ser prudente para limitar el impacto en las funciones de enrutamiento.

En efecto, otra limitación del procedimiento objeto de la invención resulta de la necesidad de anunciar en el plan de enrutamiento las direcciones previamente identificadas: las direcciones IPv4 ficticias asignadas a los nodos SIP IPv6 deben ser anunciadas en el entorno IP IPv4 y viceversa. Por lo demás, las direcciones ficticias IPv6 asignadas a elementos del servicio, como el servidor de ubicación y el servidor proxy, deben anunciarse en el entorno IPv6.

Para facilitar la representación y comprensión de la siguiente descripción, se supone, a continuación, que todos los elementos necesarios funcionalmente para la implementación de la presente invención se encuentran integrados en el nodo intermedio IN, representado en el límite de los entornos IPv4 e IPv6. Sin embargo, se observará que se trata de una simplificación de la representación, y que todas las funciones/procesamientos/operaciones prestadas por el nodo intermedio IN también pueden distribuirse en la red de acuerdo con la implementación del servicio establecido por el operador de este último.

Normalmente, el nodo intermedio IN actúa como retransmisor entre los entornos IPv4 e IPv6. Por ejemplo, el nodo intermedio IN recibe todo el tráfico procedente de los clientes IPv6 con destino a las direcciones IPv6 del servidor de registro y del servidor proxy. Luego, el nodo intermedio IN realiza la conversión de los paquetes IPv6 en paquetes IPv4 empleando las funciones f() y g() mencionadas anteriormente. Esta conversión puede ser realizada por el propio nodo intermedio IN si conoce directamente estas funciones; el nodo intermedio IN también puede enviar una solicitud destinada al servidor de ubicación R, que tiene conocimiento de estas funciones o de la resultante de estas funciones.

Como se habrá notado al leer lo anterior, el procedimiento objeto de la invención permite, por tanto, poner en comunicación los nodos SIP NA y NB pertenecientes, cada uno, a un entorno IP de origen de un primer tipo de IP, como, por ejemplo, el tipo IPv4, respectivamente de un segundo tipo de IP, como el tipo IPv6, siendo los entornos de IP de origen antes mencionados ajenos entre sí.

El nodo NA dispone de una dirección IP en el primer entorno IP, de tipo IPv4, por ejemplo, que se indica como A@v4, perteneciendo el nodo NB al segundo tipo de entorno IP, de tipo IPv6, por ejemplo, que a su vez dispone de una dirección IP de origen, indicada como B@v6, de tipo ajeno al de la dirección de origen A@v4 del nodo SIP NA.

A continuación, se describen, en relación con la figura 2c, la fase de registro de un nodo SIP NA en un servidor de ubicación, previo a cualquier establecimiento de una sesión de comunicación con un nodo NB remoto.

Durante esta fase de registro, cualquier terminal SIP IPv4 respectivamente IPv6 que implemente el procedimiento objeto de la invención debe presentar sus dos direcciones: su dirección de origen IPv4 respectivamente IPv6 efectiva y su dirección ficticia IPv6 respectivamente IPv4 atribuida por el servicio para su propio uso. Para ello, el cliente utiliza, por ejemplo, el método REGISTER, en el que inserta dos cabeceras "CONTACT", una para cada dirección, o una sola cabecera "CONTACT" con las dos direcciones IPv4 e IPv6.

Para el caso actualmente descrito, el caso 4, se ha asumido que los elementos del servicio SIP residían en el entorno IPv4. Por consiguiente, ventajosamente, las direcciones IPv4 están marcadas como prioritarias, normalmente durante los mensajes de registro, independientemente de la naturaleza del cliente IPv4 o IPv6. Este marcado se realiza en el campo "CONTACT" de las solicitudes SIP, gracias al parámetro "q", representado a continuación en la tabla T1 en la descripción ABNF del campo "CONTACT" como se describe en el documento de referencia RFC3162:

Tabla T1

Contact = ("Contact" / "m" ) HCOLON

( STAR / (contact-param *(COMMA contact-param)))

contact-param ^{= (name-addr / addr-spec) *(SEMI contact-} _params)

name-addr = [ display-name ] LAQUOT addr-spec RAQUOT

addr-spec = SIP-URI / SIPS-URI / absoluteURI

display-name = *(token LWS)/ quoted-string

contact-params = c-p-q / c-p-expires

/ contact-extension

c-p-q = “q” EQUAL qvalue

c-p-expires = "expires" EQUAL delta-seconds

contact-_extension= generic-param

delta-seconds = 1*DIGIT

Ejemplo de registro de un agente usuario UA IPv4 (caso de la figura 2c):

Suponiendo que el nodo SIP NA sea un agente usuario UA IPv4 cuya dirección de origen A@v4 = 171.5.25.2 y que la dirección de registro IPv6 adjudicada por el procedimiento objeto de la invención sea A@v6 = ipv6A, durante la fase de registro, se observa el siguiente intercambio de mensajes SIP:

Durante una etapa de referencia 20, el nodo NA envía un mensaje de registro REGISTER a la dirección R@v4 del servidor de registro R de acuerdo con la tabla T2:

T l T2

Durante una etapa de referencia 21, el servidor de registro R responde con un mensaje "200 OK" a la dirección A@v4 del nodo N^asegún la tabla T3:

T l T

continuación

Ejemplo de registro de un agente usuario UA IPv6

Suponiendo que el nodo NB SIP sea un agente usuario UA IPv6 cuya dirección de origen es B@v6 = 200l:688:1ffb:ff80::2 y que la dirección IPv4 ficticia asignada por el operador del servicio SIP sea B@v4 = ipv4B se observa, durante la fase de registro, el siguiente intercambio de mensajes SIP:

(1) el nodo NB envía un mensaje de registro REGISTER al servidor de registro R de acuerdo con la tabla T4:

T l T4

(2) El servidor de registro R responde con un mensaje "200 OK" al nodo NB de acuerdo con la tabla T5:

T l T

Se observa que, en el caso de un nodo SIP IPv6, para el mensaje de registro REGISTER, el nodo intermedio se ve como un simple retransmisor IPv4-IPv6. Por lo tanto, se excluye cualquier procesamiento vinculado con el servicio de transmisión en la red. Para aligerar el trabajo del nodo intermedio IN, es preferible que el nodo SIP IPv6 no utilice la dirección IPv6 del servidor de ubicación R no modificable, sino más bien su nombre de dominio completo FQDN para Fully Qualified Domain Name, en inglés.

Con referencia a la figura 2b, las diversas etapas implementadas se describen a continuación, según el procedimiento de la invención, para establecer una comunicación entre dos nodos SIP heterogéneos, es decir, conectados a redes IP de diferentes tipos.

Así, según el procedimiento objeto de la invención, durante una etapa A, se adjudica a cada nodo y a cada elemento, nodo NA, nodo NB, por ejemplo, una dirección IP ficticia en el entorno IP ajeno al entorno IP de origen al que pertenece el nodo o elemento SIP en cuestión. Así, la dirección ficticia es del tipo de IP ajeno al entorno de IP de origen del nodo o elemento considerado. Esta etapa A de asignación de dirección ficticia se lleva a cabo por iniciativa del operador. Se puede realizar durante la construcción de un nodo o elemento, durante su conexión a la red, o incluso llevarse a cabo de forma dinámica (por ejemplo, mediante un cambio más o menos frecuente de las funciones f y g, por razones de seguridad).

Como se ha representado en la etapa A de la figura 2b, por lo tanto, se dispone:

- para el nodo NA de la dirección de origen de este último A@v4 y de la dirección ficticia A@v6 adjudicada a este último,

- para el nodo NB de la dirección de origen B@v6 y de la dirección ficticia B@v4 adjudicada a este último.

La etapa A mencionada anteriormente viene seguida de una etapa B que consiste en lanzar, a partir de uno de los nodos NA o NB, el nodo NA a modo de ejemplo en relación con la figura 2b, denominado nodo llamador, a otro nodo SIP, en este caso, el nodo NB, un procedimiento de llamada para la transmisión de un mensaje de invitación a entrar en comunicación que contiene al menos la dirección de origen y la dirección ficticia del nodo llamador NA al nodo llamado NB.

Se entiende, por supuesto, que la transmisión de este mensaje de invitación, también denominado mensaje de llamada, se realiza a través del nodo IN, como se describirá más adelante en la descripción.

Cuando el nodo llamado NB recibe el mensaje de llamada, el procedimiento objeto de la invención consiste en transmitir desde el nodo llamado NB al nodo llamador NA un mensaje de aceptación de llamada que contiene al menos la dirección de origen B@v6 y la dirección ficticia B@v4 del nodo llamado NB.

En la etapa B de la figura 2b, el mensaje de llamada se denota como sigue:

M(B, A@v4, A@v6), para indicar que está destinado al nodo llamado NB, y que contiene las dos direcciones, ficticia y de origen, del nodo llamador NA.

Asimismo, en la etapa C, el mensaje de aceptación de llamada se denota arbitrariamente:

OK(A, B@v6, B@v4) para indicar que está destinado al nodo llamador NA y que contiene las dos direcciones, ficticia y de origen, del nodo llamado NB.

A continuación, a la etapa C le sigue la etapa D que consiste en establecer la conexión de llamada entre el nodo llamador NA y el nodo llamado NB. Esta conexión de llamada se ejecuta al nivel del nodo intermedio IN mediante la puesta en correspondencia transitiva de las direcciones de origen y las direcciones ficticias, con el fin de asegurar la traducción de las direcciones en uno y otro de los entornos IP de origen del primero, respectivamente, del segundo tipo de IP.

Por esta razón, en la etapa D de la figura 2a, el procedimiento de conexión se denota:

A@v4(A@v6: B@v6)B@v4.

Por tanto, se entiende que la conexión de la llamada se realiza, de hecho, de acuerdo con el protocolo IP del entorno IP de origen del nodo llamador, que solo tiene en cuenta la dirección de representación B@v4 del nodo SIP llamado, mientras que el nodo llamado n B para la transmisión de su mensaje de aceptación de llamada en definitiva solo usa la dirección de representación A@v6 del nodo llamador NA en el entorno IP del segundo tipo, IPv6.

En un modo de realización particular de la invención que se basa en la generalización del uso del atributo ANAT en todos los nodos SIP de una red, cualquier nodo SIP IPv4 respectivamente Ipv6 debe, por tanto, para hacer una llamada con un nodo remoto, utilizar el atributo ANAT de los mensajes SIP para presentar sus dos direcciones: su dirección de origen Ipv4 respectivamente IPv6 efectiva y su dirección ficticia IPv6 respectivamente Ipv4 adjudicada por el servicio de transmisión para su propio uso.

Durante una llamada, el nodo SIP debe utilizar el método "INVITE", en el que utiliza el atributo ANAT en la parte SDP. Para especificar la prioridad dada a las direcciones anunciadas en el campo ANAT, la presente invención utiliza el campo "mid". Este parámetro sirve para indicar la preferencia de las direcciones enumeradas en el mensaje SDP. Este parámetro se codifica, preferentemente, en orden ascendente de direcciones. Normalmente, un nodo SIP IPv4 respectivamente IPv6 que dispone de su dirección de origen IPv4 respectivamente IPv6, de origen, y la dirección ficticia IPv6 respectivamente IPv4 proporcionada por el servicio de transmisión SIP, establece el campo "mid" en 1 para la dirección de origen IPv4 respectivamente IPv6 y en 2 para la dirección de representación IPv6 respectivamente IPv4. Este campo "mid" se utiliza en el caso de intercambios con los nodos SIP de doble pila DS. Esto se ilustra, por ejemplo, para el nodo SIP NA, para el que solo se ha representado la parte SDP en la tabla T6:

T l T

Cuando el nodo SIP llamado NB recibe este mensaje "INVITE" y acepta la llamada, devuelve un mensaje de respuesta "200 OK". Cualquier cliente que implemente el procedimiento objeto de la invención debe, en su mensaje de respuesta "200 OK", insertar también dos atributos ANAT cumplimentados con sus dos direcciones y su codificación en el campo "mid". Por ejemplo, el nodo SIP NB responde al mensaje "INVITE" anterior con el mensaje que se muestra en la tabla T7, estando solo representada la parte SDP de este último:

T l T7

Debido a esto, cada uno de los dos nodos SIP NA y NB tiene las dos direcciones IPv4 e IPv6 de su interlocutor. Para establecer la llamada, es decir, permitir la transmisión de flujos RTP, cada nodo SIP utiliza únicamente la versión del protocolo IP correspondiente al entorno IP en el que se encuentra. Esto se garantiza en la medida en que los clientes sean de tipo IPv4 puro o de tipo IPv6 puro. Concretamente, cualquier cliente considerado utiliza sistemáticamente su dirección de origen y la dirección del cliente remoto, cuyo tipo corresponde al tipo de dirección para la cual el cliente considerado ha valorado el campo "mid" con el valor más bajo, lo que garantiza la coherencia del servicio.

Así, el nodo SIP IPv4 respectivamente IPv6 transmite el tráfico RTP a la dirección ficticia IPv4 respectivamente IPv6 de su interlocutor. Este procedimiento permite optimizar todo el procesamiento de la llamada porque, en la hipótesis de que dos nodos SIP del mismo entorno IP intercambien tráfico, el enrutamiento y transmisión de datos se realiza directamente. El procedimiento objeto de la invención no distorsiona el modelo básico de transmisión de datos y no impone intermediarios cuando esto no es necesario.

En caso de que los dos nodos SIP sean efectivamente heterogéneos, un terminal IPv4 puro y un terminal SIP IPv6 puro, el tráfico RTP simplemente se enruta al nodo intermedio IN, que sirve como un simple retransmisor IPv4-IPv6. Entonces no es necesaria ninguna aplicación ALG y el servicio de interfuncionamiento es transparente para el servidor proxy.

Se indica que el nodo intermedio IN (o los recursos correspondientes eventualmente distribuidos por la red y que llevan a cabo las funciones de la invención) implementa y conoce las funciones f y g y también conoce la correspondencia entre un prefijo de red dado y la función a utilizar si la función se despliega para cubrir varios dominios de operadores SIP y, por lo tanto, varias funciones f/g. Por otra parte, las inyecciones en el plan de enrutamiento se realizan a nivel del nodo intermedio IN IPv4 y del nodo intermedio IN IPv6.

Caso de clientes de Doble Pila DS:

El procedimiento de la invención permite generalizar el uso del atributo ANAT para los nodos SIP IPv4 e IPv6 con el fin de mejorar el interfuncionamiento entre clientes heterogéneos. No obstante, dado que el objeto, para el procedimiento antes mencionado, es permitir el interfuncionamiento entre todos los tipos de nodos SIP, resulta ventajoso, naturalmente, integrar nodos SIP de doble pila en el proceso.

Para garantizar un interfuncionamiento totalmente transparente, hay que verificar que:

- los nodos SIP de doble pila implementan y hacen uso del atributo ANAT como se describe en los documentos de referencia RFC4091 y RFC4092, a lo que se suma el uso obligatorio del campo "mid";

- hipotéticamente (caso 4 de la figura 2a), los elementos del servicio SIP (servidor de ubicación y servidor proxy) se han colocado en el entorno IPv4. Por consiguiente, se debe exigir a los nodos SIP de doble pila que utilicen exclusivamente su dirección IPv4 y el transporte IPv4 para contactar con el servidor de registro y/o servidor proxy. En la hipótesis inversa de un servicio en un entorno IPv6, se exige a los nodos DS que utilicen su dirección IPv6;

- al no tener en principio los nodos SIP de doble pila preferencia entre las direcciones a su disposición, utilizan el atributo "mid" en el campo ANAT de la siguiente manera:

• un nodo SIP de doble pila que origina la llamada puede no valorar el atributo "mid" en el mensaje "INVITE" o establecerlo en valores iguales para sus direcciones IPv4 e IPv6.

• un nodo SIP de doble pila que acepta una llamada entrante envía un mensaje de respuesta "200 OK" con el campo "mid" valorado de la siguiente manera:

o si el campo "mid" se valoró con diferentes valores en el mensaje "INVITE" recibido, el llamador es, por lo tanto, un nodo SIP IPv4 puro o IPv6 puro, el nodo SIP de doble pila se ajusta a esta valoración para formatear su mensaje de respuesta "200 OK" de acuerdo con la misma prioridad;

o si el campo "mid" no fue valorado o fue valorado con valores idénticos en el mensaje "INVITE" recibido, el nodo SIP de doble pila llamado toma una decisión para valorar el campo "mid" en el mensaje de respuesta "200 OK" que envía de vuelta. La forma en la que se toma esta decisión no forma parte del objeto de la presente invención y, por lo tanto, se deja libre para su implementación.

• un nodo SIP de doble pila que recibe un mensaje de respuesta "200 OK" a cambio de un mensaje "INVITE" que ha enviado cumple sistemáticamente con la valoración del campo "mid" recibido en el mensaje de respuesta "200 OK".

Proceso de control

Puede resultar, en algunos casos, que algunos nodos SIP no respeten las reglas indicadas anteriormente. Este podría ser el caso, por ejemplo, en caso de sustitución temporal de un terminal defectuoso.

En este caso, la codificación del atributo ANAT no será realizada por el agente usuario del nodo SIP correspondiente. Para remediar cualquier mal funcionamiento en este caso, se puede introducir una optimización para controlar y prevenir este tipo de error.

Ventajosamente, la optimización puede consistir en realizar una comprobación a nivel del servidor proxy:

- cuando el campo ANAT está presente, el servidor proxy no lo modifica;

- en caso contrario, el servidor proxy agrega una declaración sdp-anat valorando los campos correspondientes con las direcciones de origen IPv4 e IPv6 de representación correspondientes al nodo SIP llamador. El servidor proxy puede recuperar estas direcciones solicitándoselo al servidor de registro o disponer de ellas directamente si tiene conocimiento de las funciones f() y g().

- el servidor proxy también debe codificar el campo "mid" de acuerdo con la versión del protocolo IP del nodo SIP.

Para un nodo SIP IPv4 respectivamente IPv6, el servidor proxy dará prioridad a la dirección de origen IPv4 respectivamente IPv6.

Finalmente se presenta, en relación con la figura 4, un cuadro sinóptico de un nodo SIP de acuerdo con la invención. Dicho nodo SIP comprende, además de los medios conocidos en el estado de la técnica, una unidad central P, equipada, por ejemplo, con un microprocesador, una memoria M, por ejemplo, de tipo RAM ("Read Access Memory", memoria de lectura) y un módulo de software Pg. En la inicialización, las instrucciones del software Pg se cargan por ejemplo desde la memoria M para ser ejecutadas por el microprocesador de la unidad central P.

Dicho nodo SIP contiene uno o más agentes usuarios UA, cada uno de los cuales tiene una dirección de origen en el entorno IP al que está conectado el nodo, por ejemplo, IPv4. Esta dirección de origen se guarda en la memoria M. El operador de red también asigna una dirección ficticia 30 a los agentes usuarios, en el entorno IPv6. Esta dirección ficticia también se guarda en la memoria M.

Siguiendo las instrucciones del módulo de software Pg, la unidad central P realiza la presentación 31 de las direcciones ficticia y de origen del agente usuario en cuestión, por ejemplo, al enviar un mensaje de registro en un servidor de ubicación, o al enviar mensajes intercambiados como parte del establecimiento de una comunicación con un nodo remoto de la red. La unidad central también coloca los indicadores de prioridad correspondientes en estos mensajes.

Claims

REIVINDICACIONES

1. Procedimiento de transmisión de datos entre al menos dos nodos de una red, estando cada uno de dichos nodos conectado a al menos un entorno IP, denominado entorno de origen de dicho nodo, que comprende:

- una etapa de asignación, a al menos un agente usuario incluido en uno (NA) de dichos nodos, de una dirección ficticia en un entorno IP diferente del entorno de origen de este nodo (NA), siendo uno de dichos entornos IP un entorno IPv6 y el otro un entorno IPv4, y

- una etapa de presentación de al menos dicha dirección ficticia y de una dirección de origen de dicho agente usuario en dicho entorno de origen cuando se establece una comunicación con al menos un nodo remoto (NB),

caracterizado por que dicha etapa de presentación es ejecutada por dicho agente usuario, en al menos un mensaje de invitación a entrar en comunicación con dicho nodo remoto (NB) y/o en al menos un mensaje de respuesta a un mensaje de invitación a entrar en comunicación enviado por dicho nodo remoto (NB).

2. Procedimiento de transmisión de datos según la reivindicación 1, que también comprende una etapa de envío por parte de dicho agente usuario de un mensaje de registro a un servidor de ubicación (R),

caracterizado por que dicho mensaje de registro comprende al menos dichas direcciones, ficticia y de origen, de dicho agente usuario, y por que dicho mensaje de registro también comprende al menos un primer indicador de nivel de prioridad de una de dichas direcciones.

3. Procedimiento de transmisión según la reivindicación 2, caracterizado por que también comprende una etapa de memorización por parte de dicho servidor de ubicación (R) de al menos dichas direcciones, ficticia y de origen, y de dicho nivel de prioridad asociado, con referencia a un identificador de dicho agente usuario.

4. Procedimiento de transmisión según una cualquiera de las reivindicaciones 2 y 3, caracterizado por que dicho primer indicador de nivel de prioridad asigna un nivel de prioridad más alto a dicha dirección ficticia o de origen de dicho agente usuario correspondiente al entorno IP al que está conectado un servidor proxy (PS) que interviene durante dicho establecimiento de una comunicación con dicho nodo remoto (NB).

5. Procedimiento de transmisión según una cualquiera de las reivindicaciones 1 a 4, caracterizado por que dichos mensajes de invitación y respuesta también comprenden al menos un segundo indicador de nivel de prioridad de una de dichas direcciones, permitiendo asignar un nivel de prioridad más alto a dicha dirección de origen de dicho agente usuario.

6. Procedimiento de transmisión según una cualquiera de las reivindicaciones 1 a 5, caracterizado por que también comprende una etapa de transformación, por parte de un nodo intermedio (IN) ubicado en el límite de dos entornos IP distintos y que sirve como retransmisor entre estos dos entornos, de al menos una dirección de destino de un mensaje enviado por dicho agente usuario a dicho nodo remoto (NB), estando destinada dicha etapa de transformación a ejecutarse cuando dicha dirección de destino es una dirección ficticia y permitiendo transformar dicha dirección ficticia en una dirección de origen asociada.

7. Nodo (NA) de una red de transmisión de datos, que puede conectarse a un entorno IP, denominado entorno de origen, y que comprende al menos un agente usuario que comprende:

- medios de memorización de una dirección ficticia de dicho agente usuario en un entorno IP diferente de dicho entorno de origen, siendo uno de dichos entornos IP un entorno IPv6 y el otro un entorno IPv4, y

- medios de presentación de al menos dicha dirección ficticia y de una dirección de origen de dicho agente usuario en dicho entorno de origen cuando se establece una comunicación con al menos un nodo remoto (NB) de dicha red,

caracterizado porque dichos medios de presentación son implementados por dicho agente usuario en al menos un mensaje de invitación a entrar en comunicación con dicho nodo remoto (NB) y/o en al menos un mensaje de respuesta a un mensaje de invitación a entrar en comunicación enviado por dicho nodo remoto (NB).

8. Sistema de transmisión de datos que comprende al menos un nodo (NA) según la reivindicación 7, conectado a al menos un entorno IP denominado entorno de origen de dicho nodo, comprendiendo además dicho sistema medios de asignación, a dicho al menos un agente usuario incluido en dicho nodo, de dicha dirección ficticia en dicho entorno IP diferente del entorno de origen de este nodo (NA), siendo uno de dichos entornos IP un entorno IPv6 y el otro un entorno IPv4.

9. Programa informático que comprende instrucciones de código para la implementación de las etapas del procedimiento de transmisión de datos de al menos una de las reivindicaciones 1 a 6, cuando dicho programa es ejecutado por un procesador.