ES2381904T3 - Método para responder a una petición en un entorno de red que incluye IMS y aparato para el mismo - Google Patents

Abstract

Un método para responder a una petición en un entorno de red (100), de tal manera que dicho método comprende: recibir, en un destinatario, un mensaje (552) de INVITACIÓN de SIP procedente de un remitente, de tal manera que dicho mensaje (552) de INVITACIÓN de SIP incluye un encabezamiento de Aceptación que carece de una indicación de aceptación de un cuerpo de un primer tipo de contenido, por parte de dicho remitente, y de tal modo que dicho mensaje (552) de INVITACIÓN de SIP es una petición de una sesión de llamada a Servicios de Emergencia, ES; y proporcionar un mensaje (554) de respuesta de SIP que incluye al menos un cuerpo de dicho primer tipo de contenido, de tal manera que dicho mensaje (554) de respuesta de CIP se proporciona como respuesta a dicho mensaje (552) de INVITACIÓN de SIP.

Description

Método para responder a una petición en un entorno de red que incluye IMS y aparato para el mismo.

PRIORIDAD BAJO 35 U.S.C. § 119(e) & 37 C.F.R. § 1.78.

Esta Solicitud de Patente no provisional reivindica la prioridad basada en la(s) siguiente(s) Solicitud(es) de Patenteprovisional(es) norteamericana(s): (i) “SISTEMA Y MÉTODOS PARA MANEJAR CUERPOS DE XML DE SIP VERSIONADOS”, Solicitud Nº 60/976.419, depositada el 29 de septiembre de 2007, a nombre de Jan John-LucBakker, Andrew Allen y Adrian Buckley; y (ii) “SISTEMA Y MÉTODOS PARA MANEJAR CUERPOS DE SML DE SIP QUE INCLUYEN TIPOS DE MIME”, Solicitud Nº 60/978.976, depositada el 10 de octubre de 2007, a nombre de Jan John-Luc Bakker, Andrew Allen y Adrian Buckley.

CAMPO DE LA INVENCIÓN

La presente invención de patente se refiere generalmente al procesamiento o tratamiento de mensajes en redes de comunicación. Más particularmente, y no a modo de limitación, la presente invención de patente está encaminada a un sistema y un método para responder mensajes de petición en un entorno de red que incluye una red de Subsistema Multimedia de Protocolo de Internet (IP –“Internet Protocol”) (IMS –“IP Multimedia System”).

ANTECEDENTES

Los lenguajes de anexión abreviada de texto se vienen utilizando para describir información relativa a mensajes implementados en protocolos de comunicación. En un entorno de red en el que diferentes entidades se comunican entre sí utilizando cuerpos de mensaje, en lenguajes de anexión abreviada de texto, que son extensibles, cobra importancia el hecho de que los lenguajes, así como cualesquiera metaestructuras que se empleen para la comprensión del lenguaje, sean compatibles en todo el entorno. En caso contrario, pueden surgir problemas significativos de interoperabilidad que conduzcan, por ejemplo, a un fallo en la comunicación, a un comportamiento impredecible, etc.

El documento US 2006223510 aparece concernido con el aporte de un método para implementar un servicio de conferencia entre múltiples participantes mediante el uso de un servicio de radiodifusión / difusión múltiple (BCMCS –“broadcast / multicast service”) perteneciente a un sistema de comunicaciones inalámbricas. D1 divulga un mecanismo de transacción de mensajes de SIP que implica mensajes de SUSCRIBIR y de NOTIFICAR entre dos participantes o partes. Tanto los mensajes de SUSCRIBIR como los de NOTIFICAR son tratados como mensajes de “petición” en el SIP. Este mecanismo de transacción hace posible que el mensaje de NOTIFICAR requiera un cuerpo de mensaje que describe información de estado de un mensaje de SUSCRIBIR de conformidad con la RFC (Petición de Comentarios –“Request For Comments”) 3265. Es decir, la especificación de un cuerpo de mensaje de NOTIFICAR debe seguir a la especificación para el encabezamiento de Aceptación del mensaje de SUSCRIBIR. Se adopta una especificación por defecto cuando esta especificación no se ha definida. En particular, todas las partes que notifican, abonados / terminales móviles, controladores de BCMCS, así como servidores de proveedor de contenidos de UA de SIP, son necesarios para dar soporte a la especificación de datos “aplicación / MCMSSC+xml”como la especificación de cuerpo de mensaje por defecto.

Rosenberg et al. divulgan la publicación ‘SIP: Session Initiation Protocol’ (‘SIP: Protocolo de Inicio de Sesión’) en la RFC 3261, que describía el Protocolo de Inicio de Sesión (SIP –“Session Initiation Protocol”), un protocolo de control de capa de aplicación (intercambio de señales) para crear, modificar y poner fin a sesiones con uno o más participantes. Estas sesiones incluyen llamadas de teléfono por Internet, distribución multimedia y conferencias multimedia. Unas invitaciones de SIP que se utilizan para crear sesiones portan descripciones de sesión que permiten a los participantes ponerse de acuerdo en un conjunto de tipos de medios compatibles. El SIP hace uso de elementos denominados servidores de representante para ayudar a encaminar las peticiones a la ubicación del usuario en ese momento, autentificar y autorizar usuarios de cara a los servicios, implementar políticas o estrategias de encaminamiento de llamadas del proveedor, y proporcionar características a los usuarios. El SIP también hace posible una función de registro que permite a los usuarios cargar sus posiciones en ese momento o que hagan uso de ellas los servidores de representante.

El documento WO 03/094563 A1 proporciona un método y un sistema para tratar un procedimiento de establecimiento de sesión iniciado por un equipo de usuario, para establecer una sesión de un tipo específico para una entidad llamada. Una petición de establecimiento de sesión enviada a una entidad de red para el establecimiento de la sesión solicitada incluye información de posición así como un identificador para identificar la entidad a la que se llama. Utilizando esta información de posición, la entidad de red accede a una base de datos que almacena una lista de información de posición e identificadores asociados. Cuando se detecta que el identificador representa una sesión del tipo específico dentro de un área representada por la información de posición, el establecimiento de sesión se prosigue de una manera apropiada para una sesión del tipo específico.

SUMARIO La presente invención se define por la materia objeto de las reivindicaciones independientes 1 y 8.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

Puede tenerse una comprensión más completa de las realizaciones de la presente invención de patente haciendo referencia a la siguiente Descripción detallada, al considerarla en combinación con los dibujos que se acompañan, en los cuales:

La Figura 1 representa un entorno de red distribuido, proporcionado a modo de ejemplo, en el que pueden ponerse en práctica una o más realizaciones de la presente invención de patente;

La Figura 2 representa un diagrama de bloques de un dispositivo de Equipo de Usuario (UE –“User Equipment”) de acuerdo con una realización;

La Figura 3 representa un diagrama de bloques de un nodo de red de acuerdo con una realización;

La Figura 4 ilustra una realización de una arquitectura o estructura de software que se emplea en una entidad para procesar o tratar mensajes de protocolo de comunicación en un entorno de red distribuido proporcionado a modo de ejemplo, en el cual los mensajes de protocolo de comunicación pueden incluir cuerpos de mensaje

o documentos en múltiples versiones;

La Figura 5A representa la estructura de un mensaje de protocolo de comunicación proporcionado a modo de ejemplo (por ejemplo, un mensaje de Protocolo de Inicio de Sesión (SIP –“Session Initiation Protocol”)) que tiene una sola línea inicial, o uno o más campos de encabezamiento, y un cuerpo de mensaje, de tal manera que el cuerpo de mensaje incluye, posiblemente, múltiples partes de cuerpo;

Las Figuras 5B y 5C representan flujos de mensajes proporcionados a modo de ejemplo, entre dos entidades de un entorno de red distribuido en el que se transmiten mensajes de protocolo de comunicación que tienen cuerpos de mensaje;

La Figura 5D representa un conjunto, proporcionado a modo de ejemplo, de diferentes esquemas para la validación de documentos en Lenguaje de Anexión Abreviada de Texto Extensible (XML –“Extensible Markup Language”), proporcionados como cuerpos de mensaje en mensajes de protocolo de comunicación;

La Figura 6A ilustra una realización de un método para negociar información de versión de esquema y documento relativa a cuerpos de mensaje de un protocolo de comunicación;

La Figura 6B representa otra realización de un método para negociar información de versión de esquema y documento relativa a cuerpos de mensaje de un protocolo de comunicación;

La Figura 6C representa otra realización de un método para negociar información de versión de esquema y documento relativa a cuerpos de mensaje de un protocolo de comunicación;

La Figura 6D representa otra realización de un método para negociar información de versión de esquema y documento relativa a cuerpos de mensaje de un protocolo de comunicación;

La Figura 7 representa una realización de un método de tratamiento de mensajes que implica la validación de cuerpos de mensaje versionados (o partes de cuerpo).

La Figura 8 ilustra un diagrama de flujo de mensajes proporcionado a modo de ejemplo, que implica múltiples entidades, de tal manera que un nodo intermedio es susceptible de hacerse funcionar para negociar información de esquema con respecto a entidades de flujo ascendente y de flujo descendente, de acuerdo con una realización de la presente invención;

La Figura 9 representa una implementación proporcionada a modo de ejemplo de un servicio de telecomunicaciones (Servicios de Emergencia) de acuerdo con una realización de la presente invención; y

La Figura 10 es un diagrama de bloques que ilustra detalles adicionales de una realización de un dispositivo de comunicaciones susceptible de hacerse funcionar para los propósitos de la presente invención de patente.

DESCRIPCIÓN DETALLADA DE LOS DIBUJOS

La presente invención de patente está dirigida, en sentido amplio, a un sistema y a un método para facilitar la respuesta a mensajes de petición en un entorno de red. En el contexto de la presente Solicitud de Patente, un “mensaje” o “cuerpo de mensaje” puede hacer referencia a uno o más cuerpos de mensaje, que, a su vez, pueden ser equivalentes a una o más partes de cuerpo, y viceversa. Adicionalmente, la expresión “información de esquema” puede incluir versión de esquema, versión de instancia de documento, ámbito de las extensiones o cualquier combinación de los mismos, en relación con uno o más cuerpos de mensaje (o parte(s) de cuerpo) de un mensaje de protocolo de comunicación. En un aspecto, una realización está orientada a un método para responder a una petición en un entorno de red. La realización reivindicada comprende recibir, en un destinatario, un mensaje de INVITAR de SIP, desde un remitente, de tal manera que el mensaje de INVITAR de SIP, que incluye un encabezamiento de Aceptación, carece de una indicación de aceptación de un cuerpo de un primer tipo de contenido por parte de dicho remitente, y de tal modo que dicho mensaje de INVITAR de SIP es una petición de una sesión de llamada a Servicios de Emergencia (ES –“Emergency Services”); y proporcionar un primer mensaje de respuesta de SIP, que incluye al menos un cuerpo de dicho primer tipo de contenido, de tal manera que el mensaje de respuesta de SIP se proporciona en respuesta al mensaje de INVITAR de SIP.

En ciertos otros aspectos, la presente invención también se refiere a un esquema para llevar a cabo una llamada a ES en un entorno de red que incluye una red de IMS. Una de las realizaciones referentes a este aspecto comprende, y no está necesariamente limitada a, uno o más de los siguientes pasos: recibir una petición de servicio desde un dispositivo de UE dispuesto en el entorno de red, para establecer una llamada a ES por la red de IMS; y generar un mensaje de respuesta hacia el dispositivo de UE, de tal manera que el mensaje de respuesta incluye una indicación de que la llamada de ES se va a establecer por una red alternativa. Según otra realización, se divulga en la presente memoria un dispositivo de UE susceptible de hacerse funcionar para efectuar una llamada de ES en un entorno de red que incluye una red de IMS. El dispositivo de UE reivindicado comprende, y no está necesariamente limitado a, uno o más de los siguientes elementos: un componente configurado para generar una petición de servicio dirigida a un nodo de red dispuesto en el entorno de red, a fin de establecer una llamada a ES a través de la red de IMS; y un componente configurado para procesar o tratar un mensaje de respuesta recibido desde el nodo de red, de tal manera que el mensaje de respuesta incluye una indicación de que la llamada a ES se va a establecer por una red alternativa. En aún otra realización adicional, se describe un nodo de red destinado a efectuar una llamada a ES dentro de un entorno de red que incluye una red de IMS. El nodo de red reivindicado comprende, y no está necesariamente limitado a, uno o más de los siguientes elementos: un componente configurado para generar un mensaje de repuesta dirigido al dispositivo de UE, de tal manera que el mensaje de respuesta incluye una indicación de que la llamada de ES se va a establecer a través de una red alternativa.

El término “documento”, en la presente invención de patente, puede tener, dependiendo de su contexto, uno de los siguientes significados: un documento puede ser el cuerpo de un mensaje de SIP (que puede ser una petición o una respuesta), o puede ser una parte del cuerpo de un mensaje de SIP (petición o respuesta) (en el caso de que el cuerpo contenga múltiples partes), o bien puede ser un documento de esquema en XML [Lenguaje de Anexión Abreviada de Texto Extensible –“Extensible Markup Language”], o puede tratarse de un documento de instancia en XML (típicamente, una instancia de uno o más documentos de esquema en XML). La expresión “indicador de versión de esquema” puede indicar lo siguiente: (i) ninguno, o uno o más conjuntos de documentos a los que da soporte un destinatario, o ninguno, o uno o más conjuntos de documentos dentro de los cuales constituye un elemento el documento transmitido; o (ii) ninguno, o uno o más esquemas a los que da soporte un destinatario, o ninguno, o uno o más esquemas en virtud de los cuales puede ser validado el documento transmitido; o (iii) una combinación de las posibilidades anteriores.

Se describirán a continuación un sistema y un método de la presente invención de patente con referencia a diversos ejemplos del modo como mejor pueden realizarse y utilizarse las realizaciones. Se utilizan los mismos números de referencia a lo largo de toda la descripción y las diversas vistas de los dibujos para indicar partes análogas o correspondientes, y en ellas los diversos elementos no se han dibujado necesariamente a escala. Haciendo referencia, a continuación, a los dibujos y, más particularmente, a la Figura 1, se ilustra en ella un entorno distribuido 100 a modo de ejemplo, en el cual pueden ponerse en práctica una o más realizaciones de la presente invención de patente con el fin de gestionar la negociación de versión de esquema con respecto a los cuerpos de mensaje. Para empezar, se constatará que, si bien el entorno distribuido 100 se ha ejemplificado como una red de telecomunicaciones, las realizaciones de la presente invención de patente no están necesariamente limitadas a ello y pueden ponerse en práctica uno o más aspectos de las realizaciones en otros entornos de múltiples nodos distribuidos en los que las entidades o nodos se comunican unos con otros en protocolos de comunicación adecuados que tienen cuerpos de mensaje y tipos de cuerpo de mensaje versionados.

Como se muestra, el entorno 100 de red incluye múltiples entidades o nodos, es decir, puntos finales así como entidades intermedias situadas entre ellos, para los propósitos de llevar a cabo diversos servicios de telecomunicaciones. Ejemplos de puntos finales comprenden dispositivos de Equipo de Usuario (UE –“User Equipment”) 102, 104, que están conectados a una infraestructura de red de núcleo 112 por medio de redes de acceso adecuadas 108, 110, respectivamente. Las redes de acceso 108, 110 pueden ser consideradas, en su conjunto, como un espacio de acceso compuesto por una diversidad de tecnologías de acceso disponibles para los dispositivos de UE 102, 104. Para los propósitos de la presente invención, un dispositivo de UE puede ser cualquier dispositivo de comunicaciones ligado o no ligado, y puede incluir cualquier computadora personal (por ejemplo, computadoras de sobremesa, computadoras portátiles, miniordenadores, o dispositivos de computación de mano) equipada con un módem, o modulador-desmodulador, inalámbrico adecuado o con un dispositivo de comunicaciones móviles (por ejemplo, teléfonos celulares o dispositivos de mano con capacidad para datos, capaces de recibir y enviar mensajes, de exploración de web, etc.), o bien cualquier dispositivo PDA [asistente digital personal “Personal Digital Assistant”] o aparato de información integrada con capacidad para correo electrónico, mensajes de vídeo, acceso a la Internet, acceso a datos corporativos o de empresa, mensajería, gestión de calendario y organización o programación temporal, gestión de la información y funciones similares. En una realización, un dispositivo de UE puede ser capaz de funcionar en múltiples modos por cuanto que puede conectarse tanto en comunicaciones conmutadas en circuitos (CS –“Circuit-Switched”) como en comunicaciones conmutadas en paquetes(PS –“Packet Switched”), y puede pasar de un modo de comunicaciones a otro modo de comunicaciones sin pérdida de continuidad. Por otra parte, los expertos en la técnica constatarán que un dispositivo de UE inalámbrico puede, en ocasiones, ser tratado como una combinación de un dispositivo de equipo móvil (ME – “mobile equipment”) independiente y un módulo de memoria extraíble asociado. De acuerdo con ello, para los propósitos de la presente invención, las expresiones “dispositivo inalámbrico” y “dispositivo de UE”, que son sinónimos en un sentido amplio, se tratan, cada una de ellas, como representativa tanto de dispositivos de ME solos como de combinaciones de dispositivos de ME con módulos de memoria extraíbles, según sea aplicable.

El espacio de acceso que comprende las redes de acceso 108, 110 puede incluir redes CS, redes PS o ambas, las cuales pueden involucrar tecnologías inalámbricas, tecnologías de líneas de cable, tecnologías de acceso de banda ancha, etc. Por ejemplo, las tecnologías inalámbricas pueden incluir redes del Sistema Global para Comunicaciones Móviles (GSM –“Global System for Mobile Communications”) y redes de Acceso Múltiple por División en Código (CDMA –“Code Division Multiple Access”), así como cualquier red celular de conformidad con el Proyecto de Sociedad de 3ª Generación (3GPP –“3rd Generation Partnership Project”) (por ejemplo, 3GPP o 3GPP2). Las redes de acceso de banda ancha pueden incluir redes de área local inalámbricas o WLANs (“wireless local area networks”), redes Wi-MAX así como redes fijas tales como de Línea de Abonado Digital (DSL –“Digital Subscriber Line”), banda ancha por cable, etc. De esta forma, para los propósitos de la presente invención, las tecnologías de acceso pueden comprender tecnologías de acceso por radio seleccionadas de entre la tecnología según la norma del IEEE [Instituto de Ingeniería Eléctrica y Electrónica –“Institute of Electrical and Electronics Engineering”] 802.11a, tecnología según la IEEE 802.11b, tecnología según la IEEE 802.11g, tecnología según la IEEE 802.11n, tecnología de Red de Acceso por Radio de GSM / EDGE (GERAN –“GSM / EDGE Radio Access Network”), tanto en los dominios CS como PS), y tecnología del Sistema de Telecomunicaciones Móviles Universal (UMTS –“Universal Mobile Telecommunications System”), así como tecnología Optimizada en Datos de Evolución (EVDO –“Evolution-Data Optimized”), y sus sucesoras, tales como la Evolución a Largo Plazo (LTE –“Long Term Evolution”), y así sucesivamente. De manera adicional, las redes de acceso 108, 110 pueden incluir también la infraestructura de PSTN [Red de Telefonía Pública Conmutada –“Public Switched Telephone Network”] de línea de cable convencional, en algunas implementaciones.

La infraestructura de red 112 puede comprender una capa de núcleo de Subsistema Multimedia de IP (IMS –“IP Multimedia Subsystem”), así como una capa de servicios / aplicaciones. Como es bien conocido, el núcleo de IMS se define por las normas establecidas por el cuerpo de 3GPP que se han diseñado para permitir a los proveedores de servicios gestionar una variedad de servicios que se han de suministrar mediante IP por cualquier tipo de red, de tal manera que se utiliza el IP para transportar tanto el tráfico portador como el tráfico de intercambio de señales basado en el Protocolo de Inicio de Sesión (SIP –“Session Initiation Protocol”). En sentido amplio, el IMS es un marco para gestionar las aplicaciones (esto es, servicios) y redes (esto es, acceso), que es capaz de proporcionar servicios multimedia. El IMS define un “servidor de aplicación” como un elemento de red que suministra servicios que utilizan los abonados, por ejemplo, servicio de continuidad de llamada de voz (VCC –“voice call continuity”), de Empujar para Hablar (PTT “Push-To-Talk”), de PTT sobre Celular (PoC –“PTT over Cellular”) u otros Servicios Centralizados de IMS (ICS –“IMS Centralized Services”), etc. El IMS gestiona las aplicaciones definiendo componentes de control comunes que cada servidor de aplicación (AS –“application server”), por ejemplo, del AS-1 120-1 al AS-N 120-N, necesita tener, por ejemplo, perfiles de abonado, movilidad de IMS, acceso de red, autentificación, autorización de servicio, cargo y facturación, funciones entre operadores, e interacción o funcionamiento mutuo con la red telefónica heredada.

Debe comprenderse que, mientras que el IMS se define por el cuerpo normativo de 3GPP que se ocupa fundamentalmente de redes de GSM, se implica otro grupo, el 3GPP2, a la hora de definir una arquitectura o estructura estrechamente análoga a la que se hace referencia como Dominio Multimedia (MMD). El MMD es, básicamente, un IMS para redes de CDMA y, puesto que el MMD y el IMS son, a grandes rasgos, equivalentes, el término “IMS” puede ser utilizado en la presente invención de patente para referirse de forma colectiva tanto al IMS como al MMD cuando sea de aplicación. Además de ello, también se están desarrollando normas de redes fijas para NGN (Redes de Próxima Generación –“Next Generation Networks”) que están basadas en, y/o reutilizan, el IMS, por parte de cuerpos tales como el TISPAN de ETSI, Cablelabs y el ITU-T. NGN e IMS son, a grandes rasgos, equivalentes y, de acuerdo con el término “IMS, pueden también ser utilizados en la presente patente de invención par referirse colectivamente tanto al IMS como a la NGN, cuando sea de aplicación.

Continuando con la referencia a la Figura 1, el número de referencia 106 se refiere a uno o más nodos de red que comprenden la infraestructura de núcleo. A modo de ilustración, el nodo de red 106 puede ejemplificar nodos de Función de Control de Sesión de Llamada de Representante (P-CSCF –“Proxy-Call Session Control Function”), nodos de CSCF de Servidor, o de S-CSCF, nodos de CSCF de Interrogación, o de I-CSCF, nodos de Función de Control de Pasarela de Irrupción (BGCF –“Breakout Gateway Control Function”), nodos de Función de Control de Frontera de Interconexión (IBCF –“Interconnection Border Control Function”), nodos de Función de Control de Pasarela de Medios (MGCF –“Media Gateway Control Function”), nodos de Servidor de Abonado Doméstico (HSS – “Home Subscriber Server”), y similares. Como ya se ha aludido previamente, estos nodos, así como los dispositivos de UE de punto final, emplean el SIP como protocolo de comunicación para el control de la sesión, es decir, para el establecimiento y la interrupción de sesiones de comunicación. De acuerdo con ello, puede hacerse referencia a los nodos de red y a los dispositivos de UE, en su conjunto, como “entidades de SIP” o, más generalmente, “entidades de protocolo de comunicación” que se ocupan de enviar y recibir mensajes de protocolo de comunicación adecuados (por ejemplo, mensajes de SIP) para efectuar diversos servicios, por ejemplo, VCC, PTT, PoC, Servicios de Emergencia, etc.

Cada entidad de SIP está provista, típicamente, de un Agente de Usuario (UA –“User Agent”) que puede funcionar de dos maneras: (i) como Cliente de Agente de Usuario (UAC –“User Agent Client”) que genera mensajes de petición hacia los servidores; y (ii) como Servidor de Agente de Usuario (UAS –“User Agent Server”) que recibe mensajes de petición, los procesa o trata y genera respuestas adecuadas. En algunos contextos de aplicación, un único UA puede funcionar como tanto en una entidad de SIP, por ejemplo, un dispositivo de UE, como en un nodo de red. En la forma más básica, el SIP utiliza seis tipos (métodos) de petición:

•

INVITAR: Indica que un usuario o un dispositivo está siendo invitado a participar en una nueva sesión de llamada.

•

CONFIRMACIÓN (“ACK”): Confirma que el cliente ha recibido una respuesta final a una petición de INVITAR.

•

ADIÓS: Pone fin a una llamada / sesión y puede ser enviado tanto por el llamante como por el llamado.

•

CANCELAR: Cancela cualesquiera búsquedas pendientes pero no pone fin a una llamada / sesión que esté en curso en ese momento.

•

OPCIONES: Indaga en las capacidades de los servidores.

•

REGISTRAR: Registra la dirección listada en el campo de encabezamiento A: con un servidor de SIP.

Como el SIP puede continuar evolucionando, un destinatario puede recibir un método de petición que no reconozca. Tal método de petición se maneja como el método de petición DESCONOCIDO. En respuesta a las peticiones, el SIP hace uso de las siguientes categorías de respuestas:

•

1xx Mensajes informativos

•

2xx Respuestas satisfactorias

•

3xx Respuestas de redireccionamiento

•

4xx Respuestas de fallo de petición

•

5xx Respuestas de fallo de servidor

•

6xx Respuestas de fallo general

Los mensajes de SIP están dotados, típicamente, de una estructura de mensaje normalizada. La Figura 5A ilustra la estructura de un mensaje de protocolo de comunicación proporcionado a modo de ejemplo (por ejemplo, un mensaje de Protocolo de Inicio de Sesión (SIP)), que tiene una única línea inicial, uno o más campos de encabezamiento y un cuerpo de mensaje, de tal manera que el cuerpo de mensaje incluye, posiblemente, múltiples partes del cuerpo. Una porción de línea de orden 502 identifica la línea inicial (por ejemplo, una línea de petición en las peticiones y una línea de estado en las respuestas). Una porción de encabezamiento 504 identifica uno o más campos de encabezamiento 508-1 a 508-N que transportan diversas piezas o fragmentos de información. Uno o más cuerpos de mensaje 510-1 a 510-M pueden haberse proporcionado en una porción de cuerpo de mensaje 506. Como es bien conocido, un cuerpo de mensaje es susceptible de utilizarse para albergar cualquier contenido, tal como un texto sencillo, imágenes codificadas o cualquier información que pueda ser entregada, por ejemplo, en Lenguaje de Anexión Abreviada de Texto, tal como el XML, el HTML, etc. Cada cuerpo de mensaje (o parte del cuerpo) se describe utilizando campos de encabezamiento tales como de Contenido-Disposición, de Contenido-Codificación y de Contenido-Tipo, etc., aunque sin estar limitado por ellos, los cuales proporcionan información sobre su contenido. Típicamente, el valor de un campo de encabezamiento de Contenido-Tipo es de un tipo de Extensiones de Correo por Internet de Propósito Múltiple (MIME –“Multi-purpose Internet Mail Extensions”). Por otra parte, en el caso de que se utilice un Lenguaje de Anexión Abreviada de Texto para describir el contenido de los mensajes, puede hacerse referencia también a dicho cuerpo de mensaje como un documento. Dicho documento se adecua a un documento de esquema. Cada esquema puede producir una o más instancias de documento, o documentos, o instancias. Debido a la extensibilidad del Lenguaje de Anexión Abreviada de Texto, si el documento de esquema evoluciona, es posible que el esquema pueda producir instancias de documento adicionales, o, incluso, un conjunto diferente de ellas. Los conjuntos con documentos de instancia producidos por los diversos documentos de esquema (evolucionados), pueden identificarse por símbolos. En una realización, el conjunto con documentos de instancia puede ser identificado con el mismo símbolo que el símbolo que identifica el documento de esquema evolucionado.

En otra realización, este símbolo puede ser un dígito, un decimal, un espacio de nombre de URN [Nombre de Recurso Uniforme –“Uniform Resource Name”], o una cadena de caracteres. En aún otra realización, el conjunto con documentos de esquema puede ser identificado por un símbolo. En aún otra realización adicional, el conjunto con documentos de instancia pueden ser identificados por un símbolo.

Las aplicaciones basadas en SIP, incluyendo las aplicaciones de control de sesión para servicios de comunicaciones implementados en una red de comunicaciones tal como la red 100 que se muestra en la Figura 1, se basan cada vez más en documentos de XML para intercambiar datos y/u otra información. En general, diversas entidades de SIP pueden comunicarse unas con otras utilizando documentos de XML como lenguaje de intercambio de datos común, para llevar a efecto sesiones de comunicación, aplicaciones de Empresa a Empresa (B2B –“Business-to-Business”) y de Empresa a Consumidor (B2C –“Business-to-Consumer”), etc. Adicionalmente, tecnologías tales como servidores de web, servlets o programas ejecutados en un servidor, aplicaciones de web, servicios de web y tecnologías similares, se basan también generalmente, de alguna manera, en datos organizados de acuerdo con la Especificación de XML.

El XML es un subconjunto de una familia de Lenguajes de Anexión Abreviada de Texto Generales Normalizados (SCML –“Standardized General Markup Languages”), y se ha normalizado por el Consorcio W3. Así, pues, el XML es un conjunto jerárquico de entidades en el que una entidad puede contener uno o más elementos. Cada elemento comprende una etiqueta o marcador de apertura, texto y una etiqueta o marcador de cierre. Típicamente, los elementos también contienen uno o más atributos que funcionan para modificar información contenida en los elementos. Como lenguaje descriptivo destinado describir información o datos que se hacen pasar entre nodos, el XML está provisto de ciertas reglas de sintaxis tales como, por ejemplo: (i) los documentos de XML deben tener un elemento de raíz; (ii) los elementos de XML han de tener un marcador de cierre; (iii) los marcadores de XML son sensibles al caso; (iv) los elementos de XML deben estar adecuadamente encajados y/u ordenados; (v) los valores de atributo de XML deben ser entrecomillados, y así sucesivamente. Un archivo de XML con sintaxis correcta se denomina archivo de XML “bien formado”. Debido a su extensibilidad (que permite a cualquier autor definir sus propios elementos específicos de aplicación, atributos, etc.), un documento de XML puede existir en múltiples variantes, y, con todo, un destinatario puede aún haberse configurado únicamente para utilizar un subconjunto de elemento y atributos presentes en las diversas variantes posibles. Para facilitar la compatibilidad de los documentos entre múltiples nodos, se implementa en los nodos de transacción cierta estructura de metanivel o “esquema” que es relevante para un tipo de documento concreto. Pueden indicarse las diversas estructuras de metanivel o “esquemas” que definen los conjuntos de documentos posibles de instancia de XML. Este indicador puede ser utilizado por el nodo remitente de los nodos de transacción para identificar los conjuntos de los que es miembro el documento de instancia de XML. Un nodo de recepción de los nodos de transacción puede utilizar el indicador para identificar otro componente (por ejemplo, una capa específica de parte de cuerpo de mensaje (o de parte de cuerpo) que es capaz de manejar semántica y/o sintácticamente el elemento recibido del conjunto de documentos de MXML que se sabe que maneja.

Puede, por lo tanto, pensarse en un esquema de XML como una definición de la estructura, organización y tipos de datos que son aceptables en documentos de XML correspondientes. El esquema de XML define, de manera adicional, un conjunto de elementos de XML, atributos de XML y la organización entre los elementos de XML que se desee, gracias a lo cual el esquema de XML sirve como un vocabulario para los elementos. Por otra parte, puesto que los propios esquemas están basados en XML, estos pueden también ser extendidos y pueden existir en múltiples versiones. Debido a la extensibilidad (que permite a cualquier autor definir sus propios elementos específicos de aplicación, atributos, etc.), un documento de esquema de XML identificado utilizando el mismo identificador o tipo de medio, puede existir en múltiples variantes. A fin de facilitar la compatibilidad de documentos entre múltiples nodos, se implementa en los nodos de transacción una cierta / común estructura de metanivel o “esquema” que es relevante para un tipo de documento particular. En algunas implementaciones de XML, puede proporcionarse una Definición de Tipo de Documento (DTD –“Document Type Definition”), Esquema de XML, NGRelax, o una Definición de Contenido de Documento (DCD –“Document Content Definition”) u otro esquema de XML, para definir un conjunto de reglas con respecto a la metaestructura de un archivo de XML. Otra implementación consiste en proporcionar una alternativa basada en XML (esto es, un esquema de XML) a DTDs, por ejemplo, un Esquema de XML, NGRelax, u otra. Se hace referencia también, en ocasiones, al lenguaje de Esquema de XML como Definición de Esquema de XML (XSD –“XML Schema Definition”). Un componente que aplica un esquema de XML lo utiliza, típicamente, para validar un documento de XML. De acuerdo con ello, un documento “válido” es un documento “bien formado” que también se adecua a las reglas de un (unos) esquema(s) de XML al (a los) que se da soporte por parte de los nodos de transacción.

Con respecto a los mensajes de SIP en un entorno de red de IMS, las reglas aplicables (por ejemplo, la TS [Especificación Técnica –“Technical Specification”] de 3GGP 24.229, “Protocolo de control de llamadas multimedia de IP basado en el Protocolo de Inicio de Sesión (SIP) y en el Protocolo de Descripción de Sesión (SDP)”; Etapa 3 (Entrega 8)) establecen que el tipo de MIME asociado con un cuerpo de mensaje de XML sea “aplicación/3ggpims+xml” (“application/3gpp-ims+xml”). La norma también dispone que un UA de SIP o un representante puede insertar o extraer el cuerpo de mensaje de XML o partes del mismo según sea necesario en cualquier mensaje de SIP. De acuerdo con ello, pueden existir cuerpos o documentos de XML contenidos en los mensajes de SIP, de conformidad con esquemas de SML con diferentes versiones. Típicamente, el esquema de XML utilizado (o versión compatible) para generar el cuerpo o la parte de cuerpo se necesita también por el destinatario para validar el cuerpo o parte de cuerpo. En caso contrario, como se ha indicado en la sección de Antecedentes de la presente divulgación de patente, un documento de XML no válido puede dar lugar a un comportamiento impredecible o a resultados erróneos con respecto al servicio de telecomunicaciones solicitado. Por otra parte, si los cuerpos de mensaje de XML de un remitente no son aceptables por un dispositivo de validación del destinatario debido a la falta de compatibilidad (en sentido de avance o de retroceso), pueden surgir problemas de interoperatividad significativos en el entorno de comunicaciones.

Haciendo referencia, a continuación, a la Figura 2, se ilustra en ella un diagrama de bloques de un dispositivo de UE 200 de acuerdo con una realización, que es susceptible de hacerse funcionar como entidad de SIP capaz de transacciones de cuerpos de mensaje de SML. Se han proporcionado una o más entidades de tratamiento 202 para el control global de los diversos procedimientos ejecutables en el dispositivo. Un Agente 204 de Usuario es susceptible de hacerse funcionar, bien como un UAS o bien como un UAC con respecto a un procedimiento de protocolo de comunicación tal como un procedimiento de SIP. El número de referencia 206 se refiere a un módulo de procedimiento de protocolo proporcionado a modo de ejemplo. Un dispositivo de validación 208 es susceptible de hacerse funcionar para validar documentos de XML, por ejemplo, que se reciben en un cuerpo de mensaje de SIP. El dispositivo de validación 208 puede utilizarse también para generar documentos de XML en una versión particular y, posiblemente, incluir una versión del documento en el documento. Una aplicación 210 es susceptible de hacerse funcionar para ejecutar o invocar programación o software adecuado basándose en el contenido de los documentos de mensaje de XML. Puede proporcionarse también un diccionario y reconocedor de sintaxis 212 por lo que respecta a la comprobación de la sintaxis del mensaje. Se ha incluido un generador 214 de mensajes, susceptible de hacerse funcionar en combinación con los procedimientos de protocolo aplicables, que es también capaz de proporcionar un indicador tal como, por ejemplo, un indicador de versión de esquema, en mensajes de protocolo de comunicación generados hacia otra entidad de SIP, tal y como se explica más adelante.

La Figura 3 representa un diagrama de bloques de un nodo 300 de red de acuerdo con una realización que es susceptible de hacerse funcionar como una entidad de SIP capaz de realizar transacciones de cuerpos de mensaje de XML. A modo de ilustración, la realización del nodo 300 de red es un ejemplo de cualquier entidad de infraestructura a la que se ha hecho referencia antes en la presente memoria. Se proporcionan una o más entidades de tratamiento 304 para el control global de los diversos procedimientos llevados a cabo por el nodo 306 de red, con independencia de su arquitectura o capacidad funcional de representante. Un bloque de transmisión / recepción (Tx/Rx) 302 adecuado es susceptible de hacerse funcionar para enviar o recibir diversos mensajes de protocolo de comunicación que tienen documentos de XML en los cuerpos de los mensajes. Un Agente de Usuario de Atrás a Atrás (B2BUA –“Back-to-Back User Agent”) 310 es susceptible de hacerse funcionar como un UAS o un UAC con respecto a un procedimiento de protocolo de comunicación 312 tal como un procedimiento de SIP. Un dispositivo de validación 314 es susceptible de hacerse funcionar para validar los documentos de XML, por ejemplo, que se reciben en un cuerpo de mensaje de SIP procedentes de un remitente, o es capaz de generar documentos de XML en una o más versiones y, posiblemente, incluir una versión del documento en el documento. Una aplicación 320 es susceptible de hacerse funcionar para ejecutar o invocar software adecuado basándose en el contenido de los documentos de mensaje de XML. Puede haberse proporcionado también un diccionario y reconocedor de sintaxis 316 por lo que respecta a la comprobación de la sintaxis de los mensajes. Se ha incluido un generador 318 de mensajes susceptible de hacerse funcionar en combinación con procedimientos de software aplicables, que es también capaz de proporcionar un indicador (por ejemplo, un indicador de versión de esquema) en mensajes de protocolo de comunicación generados hacia otra entidad de SIP, tal y como se explica más adelante. Se han proporcionado dispositivos físicos o hardware 306 y almacenamiento local 308 adicionales con el fin de facilitar otras funciones relativas a la gestión y la negociación de información de versión de esquema / documento en flujos de mensajes, potencialmente tanto en el sentido de aguas arriba como en el de aguas abajo de un camino o recorrido de comunicación.

La Figura 4 representa una realización de una arquitectura de software 400 empleada en una entidad (por ejemplo, el dispositivo 200 de UE o el nodo 300 de red) para el tratamiento de los mensajes de protocolo de comunicación en un entorno de red distribuido proporcionado a modo de ejemplo, en el que los mensajes de protocolo de comunicación pueden incluir documentos de mensaje en múltiples versiones. Al recibir un mensaje de protocolo de comunicación desde un remitente, una capa 402 de protocolo de comunicación adecuado controla el tratamiento del mensaje recibido. Una vez que se ha determinado que el mensaje recibido es un mensaje adecuado, de acuerdo con la arquitectura de protocolo de comunicación (por ejemplo, la validez de la línea de orden, los campos de encabezamiento, etc.), se ejecuta una capa específica 404 de cuerpo de mensaje (o de parte de cuerpo) (por ejemplo, basada en el valor del campo de Disposición de Contenido, en el valor por defecto de Disposición de Contenido para el Tipo de Contenido, en el valor por defecto de Disposición de Contenido para el Tipo de Contenido cuando este se recibe en la entidad particular). Por ejemplo, si la capa específica del cuerpo del mensaje (o de la parte del cuerpo) es una capa de XML que considera la formación correcta, puede llevarse a cabo la validación. Si existe un error en esta etapa, el procedimiento puede abandonarse de forma elegante, con o sin una alarma, o bien puede adoptar un curso(s) alternativo(s) de acciones dependiendo de cualesquiera indicaciones que se hayan proporcionado en el propio mensaje o en la configuración previa. Tras ello, se lleva a cabo una capa 406 específica de aplicación.

Las Figuras 5B y 5C representan flujos de mensajes proporcionados a modo de ejemplo entre dos entidades de un entorno de red distribuido en el que pueden transmitirse mensajes de protocolo de comunicación que tienen cuerpo de mensaje versionados (y/o de acuerdo con esquemas versionados). En particular, la referencia numérica 500B se refiere a un flujo de mensajes entre dos nodos de red tales como un nodo 522 de CSCF en Servicio y un nodo 524 de AS, con respecto a un servicio particular. Una petición del método 526 de SIP se ha ejemplificado mediante un mensaje de REGISTRO de SIP que incluye un cuerpo de mensaje que puede contener un documento de XML versionado de acuerdo con el tipo de MIME “aplicación/3gpp-ims+xml”, donde el tipo de MIME (que representa un documento de XML) puede tener un parámetro que transporta los esquemas de XML utilizables para validar el documento de XML. La referencia numérica 500C de la Figura 5C se refiere a un flujo de mensajes entre un punto final (por ejemplo, un dispositivo de UE) 550 y un nodo de red tal como un nodo 556 de CSCF de Representante. Para los propósitos de la presente invención de patente, un “mensaje de SIP” puede significar un mensaje de petición o un mensaje de respuesta, dependiendo del contexto. Adicionalmente, en ciertas variantes, la expresión “mensaje entrante” puede referirse a una “petición” o a un “mensaje de petición”. De la misma manera, la expresión “mensaje saliente” puede hacer referencia a una “respuesta” o a un “mensaje de respuesta”. Un mensaje de peticiónde INVITACIÓN de SIP constituye un ejemplo de una petición 552 que incluye un Identificador de Servicios de Emergencia para indicar que el dispositivo de UE 550 trata de iniciar una llamada a un servicio de emergencia a través de la red de IMS. Una respuesta 554 de SIP desde la P-CSCF 556 puede comprender una respuesta de SIP 380 (Servicio Alternativo) que incluye un cuerpo de mensaje. Como puede apreciarse por un experto de la técnica, en ambos contextos de flujo de mensajes, si el destinatario de un mensaje recibe una parte de documento de cuerpo de mensaje perteneciente a un conjunto de cuerpos de mensaje de conformidad con un esquema que es incompatible con el conjunto de cuerpos de mensaje a los que da soporte el destinatario, o que no puede ser validada por el dispositivo de validación del destinatario (por ejemplo, debido a la ausencia del esquema requerido), el comportamiento del servicio se verá comprometido, lo que llevará a resultados inesperados o erróneos.

La Figura 5D representa diferentes esquemas para la validación de documentos. Las referencias numéricas 572-1 a 572-3 son ejemplos de tres documentos, de tal manera que cada documento es un esquema independiente del mismo tipo, por ejemplo, MIME o tipo de contenido: el documento 572-1 contiene un esquema de la versión X; el documento 572-2 contiene un esquema de la versión Y; y el documento 572-3 contiene un esquema de la versión Z. Documentos de instancia, instancias (por ejemplo, documentos de XML) de los documentos que contienen un esquema (por ejemplo, documentos de esquema de XML), pueden indicar también la versión del documento de esquema de acuerdo con el tipo de MIME único que lo generó: X, Y o Z. Cada documento de instancia forma parte de un conjunto con uno o más documentos de instancia generados por un documento de un único esquema de una versión particular. Los documentos de instancia, instancias (por ejemplo, documentos de XML) de los documentos que contienen un esquema (por ejemplo, documentos de esquema de XML), pueden también indicar la versión del documento de esquema de acuerdo con el tipo de MIME único que lo ha generado: X, Y o Z. Cada documento de instancia forma parte de un conjunto con uno o más documentos de instancia generados por un único documento de esquema de una versión particular. Los documentos de instancia que incluyen un indicador de versión “X”, es decir, las instancias de documento de XML 574-1 a 574-N, pueden ser mínimamente validados de forma adecuada por el documento de esquema 572-1. De la misma manera, las instancias de documentos en la versión Y, es decir, las instancias de documento 576-1 a 576-M, pueden ser apropiadamente validadas por el documento de esquema 572

2. El documento de la versión Z se ha proporcionado como ejemplo de una instancia única 578 que puede ser validada por el documento de esquema 572-3. Un documento de instancia que incluye un indicador de versión “Y” puede también ser aceptado y validado por otros documentos de esquema según se han ejemplificado por el documento de instancia 576-M y el documento de esquema 572-1.

La Figura 6A representa una realización 600A de un método para negociar información de versión de esquema relativa a cuerpos de mensaje de un protocolo de comunicación. Un remitente genera un mensaje de protocolo de comunicación (por ejemplo, una petición de SIP o una respuesta de SIP) dirigido a un destinatario (bloque 602). En una variante, el mensaje de protocolo de comunicación puede incluir un cuerpo de mensaje adecuado (o parte(s) de cuerpo). El mensaje de protocolo de comunicación incluye, adicionalmente, un indicador de versión de esquema (por ejemplo, en el encabezamiento o campo de encabezamiento de Aceptación) o, en caso contrario, incluye la información suficiente para indicar (i) qué conjunto de cuerpos / partes de cuerpo de mensaje de un tipo de contenido particular, o (ii) qué documentos de un tipo de contenido particular, puede validar y aceptar el remitente para su tratamiento (bloque 604).

En una variante, la ausencia del indicador de versión de esquema puede ser interpretada por el destinatario de modo que indique que el remitente puede validar y aceptar un conjunto por defecto de contenidos de cuerpo (parte)de mensaje o documentos de un tipo de contenido particular. Al generar una petición de INVITACIÓN inicial, el dispositivo de UE es susceptible de hacerse funcionar para indicar el soporte que proporciona al cuerpo de XML de IMS según 3GPP dentro del campo de encabezamiento de Aceptación, al incluir su tipo de MIME según se ha definido en la subcláusula 7.6.1 de la TS de 3GPP 24.229. Opcionalmente, puede añadirse un parámetro de versión denominado ‘sv’ o ‘versión de esquema’ (‘schemaversion’), que indica las versiones del esquema de XML para el cuerpo de XML de subsistema de IM CN a las que se da soporte. La sintaxis para el parámetro de versión de esquema puede encontrarse en otro lugar del presente documento. En el caso de que el parámetro ‘sv’ o ‘versión de esquema’ no esté presente, debe suponerse que el UE da soporte a la versión 1 del Esquema de XML para el cuerpo de XML del subsistema de IM CN. En el caso de que no se haya indicado el soporte para el cuerpo de XML de IMS según 3GPP, contenido en el campo de encabezamiento de Aceptación, debe suponerse que el UE da soporte a la versión 1 del Esquema de XML para el cuerpo de SML del subsistema de IM CN.

La Figura 6B representa otra realización 600B de un método de negociación de información de versión de esquema con respecto a cuerpos de mensaje de un protocolo de comunicación. Un destinatario recibe un mensaje de protocolo de comunicación (por ejemplo, una petición de SIP o un mensaje de respuesta de SIP) desde un remitente (bloque 610). En una variante, el mensaje de protocolo de comunicación puede incluir un cuerpo de mensaje adecuado (o parte(s) de cuerpo). En respuesta al mensaje de protocolo de comunicación recibido, el destinatario genera un mensaje de respuesta dirigido al remitente, de tal manera que el mensajes de respuesta incluye un indicador de documento / versión de esquema, uno o más cuerpos de mensaje (o parte(s) de cuerpo), un tipo asociado con la parte de cuerpo, para indicar (i) de qué conjuntos de contenidos de cuerpo de mensaje / parte de cuerpo de un tipo particular es miembro el cuerpo o la parte, o (ii) las versiones de documentos de esquema de XML de un tipo particular que pueden ser utilizadas para validar el cuerpo de mensaje (o parte de cuerpo) (bloque 612). Por otra parte, el indicador puede ser utilizado por el remitente para identificar una componente de capa de aplicación que puede emplearse para tratar la información.

En la Figura 6C se expone otra realización 600C de un método para indicar información de versión de esquema relativa a un cuerpo de mensaje (o parte(s) de cuerpo) de un mensaje de protocolo de comunicación. Un remitente genera un mensaje de protocolo de comunicación (por ejemplo, una petición de SIP o una respuesta de SIP) dirigido a un destinatario (bloque 620). El mensaje de protocolo de comunicación incluye, de manera adicional, uno o más cuerpos de mensaje (parte(s)), un tipo asociado con el cuerpo de mensaje, indicador de versión de esquema (por ejemplo, en el campo de encabezamiento de Tipo de Contenido), para indicar (i) de qué conjuntos de contenidos de cuerpo (parte) de mensaje de un tipo particular es miembro el cuerpo (parte), o (ii) qué versiones de los documentos de esquema de XML de un tipo particular pueden ser utilizadas para validar el cuerpo (parte) del mensaje (bloque 622). Por otra parte, el indicador puede ser utilizado por el destinatario para identificar una componente de capa de aplicación que puede ser utilizada para el tratamiento de la información.

Los expertos de la técnica constatarán que ciertos aspectos de las realizaciones anteriormente expuestas pueden ser mezclados e implementados en una o más combinaciones. Por otra parte, ha de constatarse que las metodologías de negociación anteriormente establecidas se llevan a cabo dinámicamente, en el sentido de que el proceso de negociación tiene lugar entre las entidades al tiempo que se está invocando o llamando a un servicio. Como otra alternativa, la Figura 6D representa una realización 600D de un método para negociar información de versión de esquema con respecto a cuerpos de mensajes de un protocolo de comunicación en el que puede emplearse un esquema de consulta. Una base de datos se puebla con capacidades de documento / versión de esquema de diferentes elementos de un entorno de comunicaciones, potencialmente dentro de un proceso de descubrimiento inicial con respecto a un protocolo de comunicación (bloque 652). La base de datos puede estar distribuida, reproducida de forma especular, localizada en los puntos finales, o situada centralmente dentro de una porción de núcleo del entorno de comunicaciones. Un destinatario recibe un mensaje de protocolo de comunicación (por ejemplo, un mensaje de SIP) desde un remitente (bloque 654), que puede incluir un cuerpo de mensaje (o parte de cuerpo) adecuado. En respuesta al mensaje de protocolo de comunicación recibido, el destinatario interroga a la base de datos para determinar las versiones de documento de un tipo particular que el remitente puede aceptar o validar (bloque 656). De manera adicional o alternativa, el destinatario puede ser capaz de determinar, basándose en la interrogación, lo referente a la versión de esquema que utiliza el remitente. Puede también preguntarse sobre la capacidad del remitente de convertir documentos de una versión particular en otra versión que sea compatible con uno o más nodos situados aguas abajo. En aún otra variante, en remitente puede interrogar la base de datos antes de una transacción y determinar las capacidades de esquema y/o de documento de un destinatario. De acuerdo con ello, el remitente puede determinar la inclusión únicamente de los documentos de versiones compatibles con respecto al destinatario. Como se constatará por un experto de la técnica, los remitentes y destinatarios descritos aquí y en otras partes de esta divulgación de patente pueden ser Agentes de Usuario que operan como UASs o como UACs, según sea apropiado, que se ejecutan en puntos finales, nodos de red, o en ambos.

La Figura 7 representa una realización 700 de un método de tratamiento de mensajes que implica la validación de cuerpos de mensaje versionados. Al implicarse en una metodología de negociación según se ha expuesto anteriormente con respecto a un intercambio de mensajes de protocolo de comunicación (bloque 702), un destinatario recibe un mensaje de protocolo de comunicación desde un remitente (bloque 704). Un procesador de protocolo (que incluye, por ejemplo, un reconocedor de sintaxis) puede procesar o tratar las líneas de órdenes y los campos de encabezamiento (bloque 706), con lo que se determinan los tipos de contenido (que incluyen opcionalmente un indicador que señala a las una o más versiones de esquema que pueden utilizarse para validar el cuerpo (parte) o conjuntos de documentos en los que el cuerpo (parte) es un elemento), de los diversos documentos recibidos en el mensaje de protocolo como cuerpo o cuerpos (bloque 708). A continuación, los documentos de cada tipo pueden ser validados por un procesador / dispositivo de validación de esquema apropiado puesto en marcha en el destinatario, o bien el destinatario puede determinar de otro modo si el documento recibido se puede manejar. En el caso de que se reciba un documento no válido o un documento que no pueda ser manejado, puede implementarse también un curso de acciones alternativo adecuado (por ejemplo, una salida elegante), en lugar de tener resultados indeseables tales como, por ejemplo, la congelación del nodo destinatario. Estas acciones se consolidan como el bloque 710.

En lo que sigue se exponen con detalle diversos aspectos de implementación con respecto a las anteriores realizaciones, en especial con particular referencia al intercambio de mensajes basado en SIP en entornos de red de IMS de conformidad con 3GPP. Como se ha mencionado anteriormente, las normas de 3GPP aplicables hacen posible un tipo de MIME, “aplicación/3gpp-ims+xml”, que puede estar asociado con uno o más conjuntos de documentos de instancia de XML o esquema de XML correspondiente. Como los cuerpos de mensaje de XML pueden ser extendidos de manera que incluyan nuevos elementos y/o atributos, o pueden ser modificados de manera que se redefinan elementos y/o atributos, las diversas entidades de UA de SIP que interactúan dentro de un entorno de IMS pueden no ser compatibles unas con otras. Además, las entidades de UA pueden desear indicar su soporte para diferentes cuerpos o documentos de XML de IMS de conformidad con 3GPP. En un contexto, en el caso de que un cuerpo de XML existente se extienda para incluir nuevos elementos / atributos, un destinatario sigue aún siendo capaz de tratar algo del XML, saltándose quizá los elementos y/o atributos desconocidos (como ejemplo de compatibilidad en sentido de avance). El mismo tratamiento puede también aplicarse en el caso de que un cuerpo de XML ya existente sea modificado de manera tal, que los elementos / atributos se redefinan. En este contexto, los elementos y/o atributos redefinidos pueden ser simplemente ignorados durante la validación. Alternativa o adicionalmente, el destinatario puede estar dotado de la capacidad para señalizar de vuelta al remitente que el destinatario no comprende el (los) documento(s) de XML recibido(s) (por ejemplo, por medio de un mensaje de SIP 415 (Tipo de Contenido Inaceptable) con los tipos de MIME que están habilitados y, opcionalmente, sus indicadores de versión de esquema listados en el campo de encabezamiento de Aceptación de SIP). Los expertos de la técnica constatarán que existen diversas elecciones de implementación con respecto al modo como un UA o representante de SIP que recibe dicha señal de respuesta debe tratarla, si debe ser la señal de respuesta almacenada y, en caso afirmativo, dónde y por cuanto tiempo, etc.

La compatibilidad en sentido de avance entre las diversas versiones puede conseguirse estableciendo cierto código

o instrucciones que tienen el efecto de permitir la posibilidad de elementos o atributos adicionales, o ambos, sin provocar que el dispositivo de validación de XML del destinatario declare no válida la instancia de documento de XML. En una realización, puede ser insertada la siguiente porción de código:

<xs:any namespace=”##any” (<xs: cualquier espacionombre=”##cualquiera”)

processContents=”lax” (Contenidoproceso=”lax”)

minOccurs=”0” (Ocurrenciasmin=”0”)

maxOccurs=”unbonded”/> (Ocurrenciasmax=”no limitada”/>)

Sin embargo, no todos los procesadores o dispositivos de validación de XML pueden dar soporte al emplazamiento aleatorio de la línea “xs:any” anteriormente mencionada. A fin de incrementar la compatibilidad con dispositivos de validación de XML, una realización proporcionada a modo de ejemplo hace posible que la línea “xs:any” se emplace como última línea de la definición de cualquier Tipo complejo, grupo, etc. De acuerdo con ello, cualesquiera nuevos elementos del esquema de XML actualizado son insertados justo por encima de la porción de código anteriormente mencionada. La compatibilidad en sentido de avance puede conseguirse también estableciendo “<xs:anyAttribute/>” (“<xs:cualquierAtributo/>”) o líneas similares que tienen el efecto de hacer posibles atributos adicionales sin provocar que el dispositivo de validación de XML declare no válida la instancia de documento de XML.

Una construcción proporcionada a modo de ejemplo y que es consistente con respecto a diversos problemas de compatibilidad de versión de esquema aplicable, se expone a continuación, en la Tabla 1.

Tabla 1

<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema” (xs:esquema xmlns:xs=”http://www.w3.org/2001/XMLSchema”) elementFormDefault=”qualified” attributeFormDefault=”unqualified” version=”1”> (FormaelementoporDefecto=”cualificado” FormaatributoporDefecto=”no cualificado” versión=”1”>)

<xs:complexType name=”tIMS3GPP”> (<xs:nombre Tipocomplejo=”tIMS3GPP”>)

[..] <xs:element name=”ims-3gpp” type=”tIMS3GPP”> (<xs:nombre elemento=”ims-3gpp” tipo=”tIMS3GPP”>)

<xs:attribute name=”version” type=”allowedVersionValues”

(<xs:nombre atributo=”versión” tipo=”ValoresVersiónpermitidos”) use=”required”/> (uso=”requerido”/>)

</xs:element> (</xs:elemento>) <xs:simpleType name=’allowedVersionValues’> (<xs:nombre Tiposimple=’ValoresVersiónpermitidos’>)

<xs:restriction base=’xs:decimal’>

(<xs:base restricción=’xs:decimal’>) <xs:pattern value=’111\.[0-9] 11\.[1-9][0-9]’/> (<xs:valor configuración=’111\.[0-9] 11\.[1-9][0-9]’/>)

</xs:restriction>

(</xs:restricción) </xs:simpleType> (</xs:Tiposimple>)

</xs:shema> (</xs:esquema>)

Otra posible realización de una construcción de esquema de XML se expone a continuación en las Tablas 2A y 2B.

Tabla 2A <?xml version=”1.0” encoding =”UTF-8”?> (<?versión xml=”1.0” codificación =”UTF-8”?> <xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema” (<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema”) elementFormDefault=”qualified” attributeFormDefault=”unqualified” version=”1”> (FormaelementoporDefecto=”cualificado” FormaatributoporDefecto=”no cualificado” versión=”1”>)

<xs:complexType name=”tIMS3GPP”>

(<xs:nombre Tipocomplejo=”tIMS3GPP”>) <xs:sequence> (<xs:secuencia>)

<xs:choice>

(<xs:elección>) <xs:element name=”alternative-service” (<xs:elemento nombre=”servicio-alternativo”)

type=”tAlternativeService”/> (tipo=”tServicioAlternativo”/>)

<xs:element name=”service-info” type=”xs:string”/>

(<xs:nombre elemento=”info-servicio” tipo=”xs:cadena”/>) <xs:choice> (<xs:elección>) <xs:any namespace=”##any” processContents=”lax” minOccurs=”0”

(<xs:cualquier espacionombre=”##cualquiera” Contenidoproceso=”lax” Ocurrenciasmin=”0”) maxOccurs=”unbonded”/> (Ocurrenciasmax=”no limitada”/>)

</xs:sequence> (</xs:secuencia>) <xs:attribute name=”version” type=allowedVersionValues” (<xs:atributo nombre=”versión” tipo=ValoresVersiónpermitidos”)

use=”required”/>

(uso=”requerido”/>) <xs:anyAttribute/> (<xs:cualquierAtributo/>)

</xs:complexType> (</xs:Tipocomplejo>) <xs:simpleType name=’allowedVersionValues’> (<xs:nombre Tiposimple=’ValoresVersiónpermitidos’>)

<xs:restriction base=’xs:decimal’>

(<xs:base restricción=’xs:decimal’>) <xs:pattern value=’111\.[0-9] 11\.[1-9][0-9]’/> (<xs:valor configuración=’111\.[0-9] 11\.[1-9][0-9]’/>)

</xs:restriction> (</xs:restricción>)

Tabla 2B

</xs:simpleType>

(</xs:Tiposimple>)

</xs:choice>

(</xs:elección>)

</xs:complexType>

(</xs:Tipocomplejo>)

<xs:complexType name=’tAlternativeService’>

(<xs:nombre Tipocomplejo=’tServicioAlternativo’>) <xs:sequence> (<xs:secuencia>)

<xs:element name=”type” type=”tType”/> (<xs:nombre elemento=”tipo” tipo=”tTipo”/>) <xs:element name=”reason” type=”xs:string”/>

(<xs:nombre elemento=”razón” tipo=”xs:cadena”/>) <xs:any namespace=”##any” processContents=”lax” minOccurs=”0”

(<xs:cualquier espacionombre=”##cualquiera” Contenidoproceso=”lax” Ocurrenciasmin=”0”) maxOccurs=”unbonded”/> (Ocurrenciasmax=”no limitada”/>)

</xs:sequence> (</xs:secuencia>) <xs:anyAttribute/> (<xs:cualquierAtributo/>)

</xs:complexType> (</xs:Tipocomplejo>) <xs:complexType name=”tType”> (<xs:nombre Tipocomplejo=”tTipo”>)

<xs:sequence>

(<xs:secuencia>) <xs:element name=”emergency” minOccurs=”0” maxOccurs=”1”> (<xs:nombre elemento=”emergencia” Ocurrenciasmin=”0” Ocurrenciasmax=”1”>)

<xs:complexType/>

(<xs:Tipocomplejo/>) </xs:element> (</xs:elemento>) <xs:any namespace=”##any” processContents=”lax” minOccurs=”0”

(<xs:cualquier espacionombre=”##cualquiera” Contenidoproceso=”lax” Ocurrenciasmin=”0”) maxOccurs=”unbonded”/> (Ocurrenciasmax=”no limitada”/>)

</xs:sequence> (</xs:secuencia>) <xs:anyAttribute/> (<xs:cualquierAtributo/>)

</xs:complexType>

(</xs:Tipocomplejo>) <xs:element name=”ims-3gpp” type=”tIMS3GPP”/> (<xs:nombre elemento=”ims-3gpp” tipo=”tIMS3GPP”/>)

</xs:schema> (</xs:esquema>)

El elemento de raíz del esquema de XML de IMS según 3GPP, tal y como se incorpora en las Tablas 2A y 2B, se describe como sigue:

<ims-3gpp>: Este es el elemento de raíz del cuerpo de XML de IMS según 3GPP. Siempre estará presente. La versión de Esquema de XML que se describe en el presente documento es 1. Los documentos de instancia de XML de versiones futuras del Esquema de XML que se define en las Tablas 2A y 2B, en el caso de que la parte de atributo de la versión de Esquema de XML, perteneciente al elemento xs:esquema, sea menor que 2 y mayor o igual que 1, serán válidos frente al Esquema de XML que se define en las Tablas 2A y 2B de este documento. Los documentos de instancia de XML del Esquema de XML que se define en las Tablas 2A y 2B del presente documento, tendrán un valor de atributo de versión, parte del elemento de ims3gpp, que es igual al valor de la versión de Esquema descrita en el presente documento.

En otra representación, un atributo o parámetro de versión de esquema de XML puede ser opcional, y puede asignarse para este un valor por defecto apropiado. En los dos casos, es decir, en el caso de que el atributo de versión del esquema se ajuste por defecto, y en el caso de que el atributo de versión del esquema se ajuste en un valor predefinido que puede ser codificado de diversas maneras, puede proporcionarse el Valoresquema de un documento de instancia de XML de manera que coincida con el atributo de versión del esquema de XML a partir del cual se ha obtenido la instancia de documento.

Como ya se ha mencionado anteriormente, se permite la adición de cualquier UA y la modificación de los documentos. De acuerdo con ello, resulta ventajoso que las entidades de UA conozcan esquemas de XML aceptables y sus versiones. De conformidad con una realización, pueden proporcionarse ciertas indicaciones para indicar números de versión o un cierto intervalo de números de versión, tecnología descriptora (tal como XML) y nombre de elemento de raíz. El tipo de MIME puede extenderse, por ejemplo, de manera que incluya dicha información: “aplicación/3gpp-ims+xml; sv=1-1.99”, donde “sv” es la versión de esquema y el guión denota un intervalo de los valores de versión. Además, puede proporcionarse un único valor para indicar soporte para una versión de esquema única, y puede proporcionarse una lista separada por comas para indicar versiones de esquema específicas, según son enumeradas y separadas por comas. Dicha cadena puede ser emplazada en un encabezamiento de mensaje de SIP adecuado, incluyendo el campo de encabezamiento de Aceptación, el campo de encabezamiento de Registro-Ruta, etc., aunque sin estar limitado por estos. Pueden definirse también otros nuevos campos de encabezamiento (por ejemplo, encabezamiento P), gracias a los cuales cada entidad de UA puede insertar sus capacidades y/o compatibilidades de manejo de documentos de XML. Adicionalmente, en el caso de que múltiples entidades de UA puedan estar implicadas en un recorrido de señalización, cada entidad puede dar soporte a diferentes esquemas de XML. En semejante contexto de múltiples nodos, puede proporcionarse también un nombre de elemento de función (fe –“function element”) para identificar el nodo (por ejemplo, P-CSCF, S-CSCF, UE, AS y así sucesivamente) en múltiples encabezamientos de Aceptación, según se expone en el siguiente ejemplo:

“aplicación/3gpp-ims+xml; sv=1-1.99; fe=ue,as,s-cscf”.

Una sintaxis general para la señalización de capacidades de manejo de documento de XML en un contexto de múltiples nodos es como sigue:

Funciones = <fe nombre1 símbolo>, <fe nombre2 símbolo>... <fe nombreN símbolo>

Pueden proporcionarse también reglas adicionales dependiendo de la implementación. Por ejemplo, la ausencia de un símbolo de elemento funcional de IMS (ife –“IMS functional element”) puede significar que la información de versión de esquema de XML y de instancia de documento, proporcionada en el encabezamiento, es aplicable a cualquier nodo de aguas abajo. De la misma manera, la ausencia del parámetro sv puede significar que cualquier versión de esquema es de aplicación o aceptable. Alternativamente, la ausencia del parámetro sv puede significar que se aplica, o es aceptable, una versión por defecto, por ejemplo, la versión “1”. Debe resultar evidente que pueden utilizarse también nombres simbólicos distintos de “sv” o “ife”, siempre y cuando todos los nodos, por ejemplo, los originarios o remitentes, los destinatarios o finales, y los nodos intermedios, estén al tanto de la nomenclatura, capacidad funcional, sintaxis, así como de las reglas asociadas con ellas. Se expone un ejemplo de un símbolo sv que tiene números discretos así como intervalos para indicar la capacidad de soporte o habilitación para diversas versiones de esquema:

Sv = 1-2, 10-12, 14, 16

El ejemplo anterior indica que se da soporte a las versiones de esquema 1 y 2 (inclusive), 10 a 12 (inclusive), así como a las versiones 14 y 16. Puesto que puede haberse incluido también un documento de cuerpo de XML aguas arriba, puede suceder que un UA de recepción (en una configuración de Agente de Usuario a Atrás a Atrás, o

5 B2BUA –“Back-to-Back User Agent”) o representante desee utilizar un mensaje de SIP no provisional para indicar su soporte o habilitación para ciertos esquemas de XML. Alternativamente, en caso de que no se dé soporte al número de versión requerido, el UA de recepción puede desear indicar dicha información en un mensaje de error de SIP. Si el remitente recibe una respuesta de SIP no provisional, puede responder con una petición de SIP tal como una petición de CANCELAR, que opcionalmente incluye la razón de semejante acción.

10 Un ejemplo adicional de un símbolo sv dentro de un encabezamiento de aceptación es como sigue:

Aceptación: aplicación/3gpp-ims+xml; sv=”1, 1.1”; ife=”ue, p-cscf, as,...”

El anterior ejemplo permitirá a las diferentes entidades de UA de SIP, en caso necesario, poblar el encabezamiento de Aceptación (por ejemplo, en un mensaje de INVITAR) con todas sus versiones de esquema para el tipo de MIME “aplicación/3gpp-ims+xml”. En lo que sigue se exponen ejemplos de formatos de encabezamiento de Aceptación de

15 acuerdo con normas conocidas (por ejemplo, la RFC [Petición de Comentarios –“Request For Comments”] 2616 y la RFC 3261), que pueden ser utilizados para codificar adecuadamente los símbolos de sv e ife.

Tabla 3

Aceptación = “Aceptación” “:” #(intervalo-medios [parámetros-aceptación])

intervalo-medios = (“*/*” 1(tipo “/” “*”) 1(tipo “/” subtipo) ) *(“;” parámetro)

parámetros-aceptación = “;” “q” “=” qvalor * (extensiónaceptación) extensión-aceptación = “;” símbolo [“=” (símbolo 1cadenaentrecomillada)]

Tabla 4

Aceptación = “Aceptación” HCOLON

[intervalo-aceptación *(COMA intervalo-aceptación)] intervalo-aceptación = intervalo-medios *(SEMI parámetro-aceptación) intervalo-medios = ( “*/*”

/ (tipo-m BARRA “*”)

/ (tipo-m BARRA subtipo-m)

) *(SEMI parámetro-m) parámetro-aceptación = (“q” IGUAL valorq) / parámetro-genérico valorq = ( “0” [ “.” 0*3DÍGITO ] )

/ ( “1” [“.” 0*3(“0”) ] )

parámetro-genérico = símbolo [ IGUAL valor-gen ] valor-gen = símbolo / anfitrión / cadena-entrecomillada parámetro-m = atributo-m IGUAL valor-m atributo-m = símbolo valor-m = símbolo / cadena entrecomillada

En lo que sigue se expone aún otra posible realización de una construcción de esquema de XML, en la Tabla 5. El tipo de MIME de aplicación/3gpp-ims+xml, utilizado en el campo de encabezamiento de Aceptación de acuerdo con la subcláusula 5.1.3.1 de la 3GPP TS 24.229, se extiende de manera que incluya información de versión específica necesaria para el establecimiento de entidad funcional de subsistema de IM CN. Si el parámetro no está presente, se supondrá que el UA que da origen al método de SIP con el encabezamiento de Aceptación, da soporte a la versión 1 del Esquema de XML para el cuerpo de XML de subsistema de IM CN. El parámetro sv o de versión de esquema (“schemaversion”) tiene la sintaxis que se describe en la Tabla 5. El componente de intervalo de medios ha sido copiado de la RFC de IETF [Grupo de Trabajo de Ingeniería de Internet –“Internet Engineering Task Force”] 3261 por conveniencia. El parámetro sv o de versión de esquema constituye un caso de parámetro-m obtenido del componente de intervalo-medios vigente en ese momento del encabezamiento de Aceptación, donde el tipo-m es aplicación y el subtipo-m es 3gpp-ims-xml. Si el parámetro sv o de versión de esquema se ajuste en “ninguno”, el UA que da origen al método de SIP indica que no encuentra el tipo de MIME de “aplicación/3gpp-ims+xml” aceptable. La Tabla 5 muestra una posible Sintaxis del parámetro “sv” o de “versión de esquema” para el tipo de MIME de “aplicación/3gpp-ims+xml”:

Tabla 5

intervalo-medios = ( “*/*” / ( tipo-m BARRA “*” ) / ( tipo-m BARRA subtipo-m ) ) *(SEMI parámetro-m )

Versión de esquema = (“versión de esquema” / “sv”) “=” “ninguno” / [versiones de esquema *(COMA versiones de esquema)] versiones de esquema = símbolo / ( DÍGITO [“.” 0*2DÍGITO] [“-“ ( DÍGITO [ “.” 0*2DÍGITO ] ) ] )

Como se ha expuesto en los anteriores ejemplos, el símbolo o parámetro sv puede dotarse de valores numéricos discretos que están separados por comas, así como con intervalos de números o dígitos que tienen la ventaja de ser secuenciales a la hora de especificar una versión de esquema. Además, el símbolo sv puede tomar valores proporcionados en forma de cadenas de texto, caracteres, secuencias alfanuméricas y similares, aunque no está limitado por estos. Puede proporcionarse también información adicional en los campos de encabezamiento de mensaje de SIP para indicar directivas adicionales que pueden ser ejecutadas en el nivel de una capa de tratamiento de protocolo de comunicación. A modo de ilustración, un UA de recepción puede concluir, mediante la inspección del encabezamiento de Aceptación, que papeles de UA o incluso UAs o elementos funcionales dan soporte a qué tipos de contenido. En una implementación, cualquier UA de recepción que inserta o incorpora instancia(s) de documento de tipo de contenido de XML, puede ser capaz de insertar una directriz para dirigir un elemento situado aguas abajo para que procese uno o más documentos de tipo de contenido de XML. Directrices adicionales pueden incluir las siguientes: “eliminar tras tratar”, “evitar si no se comprende”, “debe comprenderse” o “conformidad para eliminar”, y directrices similares, aunque no están limitadas por ellas. Las directrices pueden ser codificadas como cadenas de texto o valores binarios, tal y como se ejemplifica en lo que sigue:

Eliminar tras tratar 00 Evitar si no se comprende 01

Debe comprenderse 10 Conformidad para eliminar 11

Ha de constatarse que lo anterior es tan solo un ejemplo ilustrativo y el ordenamiento de las directrices puede ser cualquiera y puede ser codificado con cualquier número de bits.

Un elemento de información adecuado que incluya tal información puede ser un parámetro de URI [Identificador de Recurso Uniforme –“Uniform Resource Identifier”] o de MIME, preferiblemente en una representación de cadena de texto. En otra alternativa, dichas directrices pueden ser también codificadas dentro del cuerpo de mensaje o dentro de una parte de cuerpo de mensaje. En otra alternativa, la información puede ser representada como una parte de cuerpo adicional si se da soporte a múltiples partes de cuerpo, codificarse en alguna parte de cuerpo, con directrices que hagan referencia a otras partes de cuerpo. Por ejemplo, las representaciones pueden ser codificadas en XML y para cada esquema de XML que exista por cada nodo de recepción. En aún otra realización alternativa adicional, las directrices para cada nodo de recepción pueden establecerse por cada cuerpo (o parte de cuerpo) existente en el campo de encabezamiento de Tipo de Contenido que se utiliza en los mensajes de SIP devueltos para identificar el contenido. A continuación se proporciona una estructura de alto nivel para dicha representación:

<<Comenzar mensaje de SIP y campos de encabezamiento

-

incluyendo campo de encabezamiento de Tipo de Contenido + parámetros opcionales que incluyen cero o más de entre directrices, versiones de esquema u otros parámetros

-

en caso de que se dé soporte a cuerpos de MIME de múltiples partes/* y estén incluidas múltiples partes de cuerpo, parámetros que incluyen cero o más de entre directrices, versiones de esquema u otros parámetros

Final de mensaje de SIP>>

Puede proporcionarse también otra codificación alternativa para valores de sv utilizando espacios de nombre. A modo de ilustración, se expone en el siguiente ejemplo la generación de una versión de esquema de XML en un servicio de PoC, a fin de mostrar el uso de espacios de nombre para señalizar o indicar la información de sv.

Accept:application/poc-settings+xml; sv=”urn:oma:params:xml:ns:poc:poc-settings, urn:oma:xml:poc:poc2.0-settings”

(Aceptación:aplicación/poc-ajustes+xml; sv=”urn:oma:parámetros:xml:ns:poc:ajustes-poc, urn:oma:xml:poc:ajustespoc2.0”). Básicamente, el nombre de símbolo “sv” del ejemplo anterior puede ser reemplazado por un símbolo denominado “ns” con el fin de indicar que una lista de uno o más identificadores de espacio de nombre de XML está seguida por comillas y separada por comas. Por otra parte, una solución similar puede utilizarse también para otras entidades de UA específicas del servicio, por ejemplo, UAs con respecto a la Continuidad de Llamada de Voz (VCC –“Voice Call Continuity”), Servicios Centralizados de IMS (ICS –“IMS Centralized Services”), Continuidad de Sesión de IMS (ISC –“IMS Session Continuity”), etc.

Además de transportar directrices de mensaje de nivel de SIP, pueden transmitirse también diversos atributos que definen una capacidad de manejo con respecto a los documentos de XML, según un criterio nodo por nodo. Es decir, la información de atributo puede ser utilizada para indicar un comportamiento permisible para cada UA de SIP o elemento de representante identificado, a modo de mecanismo de gestión de política o estrategia que se ejecuta o lleva a efecto en asociación con un dispositivo de validación de XML. Las siguientes estrategias son ilustrativas: (i) conformidad para ignorar, continuar con el tratamiento del documento de mensaje, cancelar el elemento; (ii) obligatorio comprender, rechazar el documento de mensaje si no se comprende; (iii) obligatorio declinar, se requiere no tratar si no se comprende; y así sucesivamente. Las estrategias de comportamiento pueden extenderse a la indicación del comportamiento específico de nodo para cada nodo de recepción, por ejemplo, (i) requisitos de UE; (ii) requisitos de P-CSCF; (iii) requisitos de S-CSCF; (iv) requisitos de Servicio (por ejemplo, Información de Identificador de ICS, o ICSI –“ICS Identifier”), y así sucesivamente.

Como se expuesto anteriormente en relación con la realización mostrada en la Figura 6C, un mecanismo alternativo para indicar la información de versión de esquema y de versión de conjunto de documentos, puede implicar el acceso a una base de datos configurada con las capacidades de soporte de versión, según un criterio nodo por nodo. La base de datos puede ser accesible para cualquier nodo de la red de IMS. Por otra parte, la ubicación de la base de datos puede ser proporcionada a los nodos por medio de cualquier mecanismo apropiado (por ejemplo, un mecanismo basado en la RFC 4483). Puede proporcionarse un Localizador de Recursos Uniformes (URL –“Uniform Resource Locator”), que identifica la ubicación de la base de datos, en un mensaje que ese nodo puede utilizar para acceder a la base de datos. También, la base de datos puede encontrarse en único nodo, o estar repartida a lo largo y ancho de múltiples nodos, en una arquitectura de base de datos distribuida.

A continuación se aporta una estructura de sintaxis proporcionada a modo de ejemplo del parámetro sv o de versión

de esquema, en la Tabla 6.

Tabla 6

m-parameter /= (“sv” / “schemaversion”) EQUAL LDQUOT

(parámetro-m /= (“sv” / “versión de esquema”) IGUAL COMILLAS DOBLES IZQUIERDAS) [ sv-value-list ] RDQUOT ([ lista-valores-sv ] COMILLAS DOBLES DERECHAS)

sv-value-list = sv-value-range *( “,” sv-value ) (lista-valores-sv = intervalo-valores-sv *(“,” valor-sv)) sv-value-range = sv-value [ “-“ sv-value] (intervalo-valores-sv = valor-sv [ “-“ valor-sv]) sv-value = number / token (valor-sv = número / símbolo number = 1*DIGIT [ “.” 1*DIGIT ] (número = 1*DÍGITO [ “.” 1*DÍGITO ])

La sintaxis de sv mostrada anteriormente (en Formato de Backus-Naur, o forma BNF (“Backus-Naur Format”)) puede utilizarse para transportar diversos tipos de valores (dígitos, cadenas, etc.) con el fin de indicar: (i) las versiones del esquema de XML de IMS según 3GPP que pueden utilizarse para validar los cuerpos de XML de IMS según 3GPP, en el caso de que el tipo y el parámetro de MIME estén presentes en el encabezamiento de Tipo de Contenido, y (ii) las versiones aceptadas de los cuerpos de XML de IMS según 3GPP, si el tipo y el parámetro de MIME están presentes en el encabezamiento de Aceptación. Como se ha mencionado anteriormente, pueden aplicarse reglas por defecto donde el parámetro sv o de versión de esquema, o cuando el parámetro sv o de versión de esquema, esté ausente. En una realización, si el parámetro sv o de versión de esquema está ausente, debe entenderse que se da soporte a una cierta versión o conjunto de versiones, por ejemplo, la versión 1. En otra realización, si el tipo de MIME (por ejemplo, “aplicación/3gpp-ims+xml”) está ausente y el parámetro sv o de versión de esquema correspondiente está ausente, ha de entenderse que cierta versión o conjunto de versiones del tipo de MIME (por ejemplo, “aplicación/3gpp-ims+xml”) es, en cualquier caso, aceptable, por ejemplo, la versión 1. En aún otra realización, si el valor del parámetro sv o de versión esquemática está ausente, debe comprenderse que no se da soporte a ninguna versión ni conjunto de versiones del tipo de MIME. Esta última propiedad puede ser ventajosa en los casos en que esté ausente incluso el tipo de MIME correspondiente (por ejemplo, aplicación /3gpp-ims+xml”), en los que el destinatario ha de entender que, con todo, el tipo de MIME y un valor por defecto para el parámetro de versión. En este caso, un remitente puede utilizar un campo de encabezamiento de SIP (por ejemplo, el campo de encabezamiento de Aceptación) para indicar de forma explícita que un tipo de MIME y cualesquiera de sus versiones son aceptables.

Como constatará un experto de la técnica, el tipo de MIME y sus parámetros pueden necesitar ser registrados con una autoridad de registro adecuada (esto es, un secretario), tal como, por ejemplo, la Autoridad de Números Asignados por Internet, o IANA (Internet Assigned Numbers Authority”). En lo que sigue se expone una plantilla proporcionada a modo de ejemplo que puede ser utilizada para propósitos de registro:

Nombre de tipo de medios MIME:	aplicación
Nombre de subtipo de MIME:	3gpp-ims+xml
Parámetros requeridos:	ninguno

Parámetros opcionales: “sv” o “versión de esquema”

La anterior entrada de registro puede incluir la sintaxis de sv mostrada anteriormente en la Tabla 5, en la forma BNF Aumentada (ABNF –“Augmented BNF”).

Haciendo referencia, a continuación, a la Figura 8, se muestra en ella un diagrama de flujo 800 de mensaje proporcionado a modo de ejemplo, que implica múltiples entidades de SIP en las que un nodo intermedio es susceptible de hacerse funcionar para negociar información de versión de esquema y de documento con respecto a entidades situadas aguas arriba y aguas abajo, de acuerdo con una realización de la presente divulgación. El UA1 802 es un dispositivo originario o remitente de una petición dirigida, en última instancia a la UA2, que opera como destinatario. Un B2BUA 804 (por ejemplo, un nodo de pasarela de frontera tal como una BGCF o una IBCF) essusceptible de hacerse funcionar como nodo intermedio. El UA1 802 genera una petición de INVITACIÓN de SIP 808 con su encabezamiento de Aceptación establecido como:

aplicación/3gpp-ims+xml; sv=”1,1.1”; ife=”ua1”

El nodo intermediario 804 intercepta la INVITACIÓN 808 y modifica el encabezamiento de Aceptación, y genera unanueva petición de INVITACIÓN 810 dirigida al UA2 806. El encabezamiento de Aceptación modificado incluye ahora lo siguiente:

aplicación/3gpp-ims+xml; sv=1,1.1,2.5”; ife=”ua1”,

aplicación/3gpp-ims+xml; sv=”2.5”; ife=b2bua”

En esencia, al modificar la información de encabezamiento de Aceptación según se ha expuesto en lo anterior, el nodo intermediario 804 traslada el hecho de que es susceptible de hacerse funcionar para convertir o transportar de otra manera el contenido de aplicación/3gpp-ims+xml de conformidad con la versión de esquema 2.5 que está destinada al UA1 (en el recorrido de aguas arriba), en el contenido de XML que es compatible con la versión de esquema 1 o 1.1 a la que da soporte el UA1 802 (en la medida de lo posible; por otro lado, cuando no sea posible, la información no convertible puede ser señalada de otra manera). Además, el nodo intermediario 804 también señaliza que es susceptible de hacerse funcionar para aceptar el contenido de aplicación/3gpp-ims+xml, de acuerdo con la versión de esquema 2.5 que está destinada al B2BUA. Mensajes de respuesta adecuados son el 812 y el 814, los cuales son propagados de vuelta por el recorrido de retorno, mensajes que pueden o no incluir cualesquiera documentos tales como los que tienen un tipo de contenido de “aplicación/3gpp-ims+xml” como cuerpo de SIP o como parte(s) de cuerpo.

Ha de constatarse que, en el caso de que algunas de las versiones vigentes de la norma de 3GPP (es decir, la Entrega 5, la Entrega 6, la Entrega 7 y la Entrega 8 de la 3GPP TS 24.229) no adopten la medida de que los UAs incluya explícitamente el tipo de MIME de “aplicación/3gpp-ims+xml” en el encabezamiento de Aceptación, puede ser necesario implementar variaciones adicionales. A fin de evitar la modificación de los UAs desplegados de conformidad con las Entregas 5/6/7/8 y que requieren la inserción de “*/*” o “aplicación/*”, o de “aplicación/3gpp-imsxml”, realizaciones adicionales de la presente invención hacen posible que un indicador de versión especial (por ejemplo, ausencia de una versión en esquema de versión, o valor del parámetro sv: aplicación/3gpp-ims+xml; sv=””)

o símbolo (por ejemplo, “ninguno”) pueda reservarse para indicar que el contenido del tipo de MIME antes mencionado no es aceptable por el UA que origina el método de SIP. El símbolo de versión especial puede ser también utilizado para significar que la ausencia de “*/*”, “aplicación/*” o “aplicación/3gpp-ims+xml”, o la ausencia del parámetro “sv” o de “versión de esquema”, mientras el tipo de MIME de “aplicación/3gpp-ims+xml” está presente, indica la susceptibilidad de soporte y la aplicación de una versión por defecto (por ejemplo, la versión de esquema 1 relativa al tipo de MIME anteriormente mencionado).

La Figura 9 representa una implementación proporcionada a modo de ejemplo de un servicio de telecomunicaciones tal como, por ejemplo, una llamada a Servicios de Emergencia (ES –“Emergency Services”), por una red de IMS con mensajería de SIP. Como puede apreciarse por un experto de la técnica, cuando un dispositivo de UE desea hacer una llamada a ES por la red de IMS, el nodo de P-CSCF (típicamente el primer nodo de IMS con el que interactúa el dispositivo de UE) puede no permitir la llamada a ES por diversas razones. Por ejemplo, la realización de una llamada a ES por una red de IP puede estar prohibida por las autoridades regulativas en una región o país en el que únicamente las llamadas a ES por una red CS convencional son obligatorias. En algunos casos, las llamadas a ES basadas en IP pueden ser muy caras y, además, pueden no tener fiabilidad en calidad de portadores con respecto a tales llamadas. En aún otros contextos adicionales, incluso en el caso de que se permita una llamada a ES basada en IP, la red de IMS puede desear encaminar la llamada por una red de IP diferente, en lugar de encargarse ella misma de ella. Con independencia de las razones, cuando se utilizan versiones diferentes de cuerpos de mensaje de XML y/o de esquemas de XML por parte de las diversas entidades, es decir, el dispositivo de UE, la P-CSCF, etc, con respecto al establecimiento de la llamada a ES, existe la posibilidad de que dichos cuerpos de mensaje o esquemas no sean compatibles, lo que tiene como resultado un comportamiento impredecible. No solo puede no completarse la llamada a ES deseada, sino que el dispositivo de UE que lo solicita puede no recibir ninguna alarma ni indicación acerca de ningún posible curso o cursos alternativos de acciones.

En el esquema 900 proporcionado a modo de ejemplo y que se muestra en la Figura 9, las entidades de SIP están dotadas de la capacidad de negociar la información de versión y de señalar cursos alternativos de acciones cuando sea necesario. De acuerdo con ello, cuando el dispositivo de UE realiza una petición de servicio a un nodo de IMS (es decir, el nodo de P-CSCF) con el fin de efectuar una llamada a ES a través de la red de IP (bloque 902), el nodo de IMS está configurado para tratar la llamada entrante y ejecutar la lógica de servicio apropiada al objeto de generar un mensaje de respuesta advirtiendo de que la llamada a ES a través de red solicitada puede no ser establecida (bloque 904). El nodo de IMS está también configurado para proporcionar una indicación al dispositivo de UE (por ejemplo, a través del mensaje de respuesta) para que efectúe la llamada a ES por una red alternativa (por ejemplo, una red de IP diferente), y puede incluir información de encaminamiento aplicable (bloque 906). En otra alternativa, el nodo de IMS puede haberse configurado para proporcionar una indicación al dispositivo de UE de que la llamada a ES se va a efectuar a través de una red CS convencional, la cual puede de nuevo incluir información de encaminamiento apropiada (bloque 908. Alternativa o adicionalmente, el nodo de IMS puede también proporcionar al dispositivo de UE una alarma y/o indicación de que la llamada a ES no puede ser completada, con lo que puede facilitarse una salida elegante, incluyendo, por ejemplo, un código de causa o una razón en texto como parte del mensaje de respuesta con respecto a si se sugiere por parte de la red un servicio alternativo o por qué (bloque 910). Por otra parte, en respuesta a las indicaciones incluidas en el mensaje de respuesta o como consecuencia del procedimiento local por defecto, el dispositivo de UE puede también interrogar una base de datos (de nuevo, aportada localmente dentro del dispositivo de UE o facilitada remotamente o a distancia en el entorno de red) para obtener información de ID y/o de encaminamiento apropiada con respecto al establecimiento de la llamada a ES por una red alternativa.

Basándose en lo anterior, puede observarse que las presentes realizaciones proporcionan un método para responder a una petición en un entorno de red que incluye una porción de IMS. Como ya se ha mencionado anteriormente, un destinatario es susceptible de hacerse funcionar para recibir un mensaje de petición desde un remitente, de tal manera que el mensaje de petición puede carecer sustancialmente de una indicación de aceptación por parte del remitente de un cuerpo de un tipo de contenido particular. El destinatario incluye capacidad funcional para proporcionar un mensaje de respuesta que incluye al menos un cuerpo del tipo de contenido particular. En una realización, el mensaje de respuesta puede consistir en una petición de una sesión de llamada a Servicios de Emergencia (ES) y el tipo de contenido particular es aplicación/3gpp-ims+xml. Como se ha especificado en detalle anteriormente, el mensaje de respuesta puede incluir un campo de encabezamiento de Aceptación o puede estar desprovisto de un campo de encabezamiento de Aceptación.

La Figura 10 representa un diagrama de bloques de una realización de un dispositivo de comunicaciones susceptible de hacerse funcionar como un dispositivo de UE compatible con SIP, por ejemplo, el UE 102, para los propósitos de la presente invención de patente. Se constatará por los expertos de la técnica, al hacer referencia a la presente memoria, que, si bien una realización del UE 102 puede comprender una disposición similar a la que se muestra en la Figura 10, puede haber diversas variaciones y modificaciones, en dispositivos físicos o hardware, en programación o software, o en programas incorporados de forma permanente en hardware, o firmware, por lo que respecta a los diversos módulos representados. De acuerdo con ello, la disposición de la Figura 10 ha de tomarse como ilustrativa en lugar de como limitativa con respecto a las realizaciones de la presente invención de patente. Un microprocesador 1002 que hace posible el control global de una realización del dispositivo de UE, está conectado operativamente a un subsistema de comunicación 1004 que puede ser capaz de comunicaciones de múltiples modos (por ejemplo, en el dominio CS, en el dominio de IP, tal como IMS, etcétera). El subsistema de comunicación 1304 incluye generalmente uno o más receptores 1008 y uno o más transmisores 1014, así como componentes asociados tales como uno o más módulos 1010 de oscilador local y un módulo de procesamiento o tratamiento tal como un procesador de señal digital (DSP –“digital signal processor”) 1012. Como resultará evidente para los expertos en el campo de las comunicaciones, el diseño concreto del módulo de comunicación 1004 puede depender de las redes de comunicaciones con las que el dispositivo móvil está destinado a operar (por ejemplo, una red de CDMA, una red de GSM, una WLAN, etcétera). Con independencia del diseño particular, sin embargo, las señales recibidas por la antena 1006 a través de la infraestructura de acceso apropiada 1005 (por ejemplo, torres de estación de base celular, puntos de alta densidad de conexión a WLAN, etc.) son proporcionadas al receptor 1308, el cual puede llevar a cabo funciones comunes de un receptor tales como la amplificación de las señales, la conversión en sentido descendente de frecuencia, la filtración, la selección de canal, conversión de analógicas a digitales (A/D) y funciones similares. De igual manera, las señales que se van a transmitir son tratadas, incluyendo su modulación y codificación, por ejemplo, por el DSP 1012, y se proporcionan al transmisor 1014 para su conversión de digitales a analógicas (D/A), conversión en sentido ascendente de frecuencia, filtración, amplificación y transmisión por la interfaz de radio aérea, a través de la antena 1016.

El microprocesador 1002 puede también actuar como interfaz con subsistemas de dispositivo adicionales tales como una entrada / salida auxiliar (E/S –“I/O (input / output)”) 1018, un acceso o puerta en serie 1020, un dispositivo de presentación visual 1022, un teclado / cuadro de teclas 1024, un altavoz 1026, un micrófono 1028, una memoria de acceso aleatorio (RAM –“random access memory”) 1030, un subsistema de comunicaciones de corto alcance 1032, y cualesquiera otros subsistemas de dispositivo, por ejemplo, mecanismos temporizadores, designados generalmente por el número de referencia 1033. Para el control del acceso, puede haberse proporcionado también una interfaz 1034 en comunicación con el microprocesador 1002, con respecto a un módulo de almacenamiento extraíble (Módulo de Identidad de Abonado / Universal (U/SIM –“Universal / Subscriber Identity Module”) o un Módulo de Identidad de Usuario Extraíble (RUIM –“Removable User Identity Module”). En una implementación, la interfaz 1034 de U/SIM o de RUIM puede ser susceptible de hacerse funcionar con una tarjeta de U/SIM o de RUIM que tiene diversas configuraciones de clave 1044 y otra información 1046 tal como perfiles de disposición de contenido por defecto, gestores de estrategias, información sobre redes alternativas, así como datos de identificación y relativos al abonado que pueden complementar la información basada en el almacenamiento local.

Es posible incorporar software de sistema operativo y software de lógica de servicio aplicable en un módulo de almacenamiento permanente (es decir, un almacenamiento no volátil), tal como una memoria de refrescamiento por impulsos o de tipo Flash 1035. En una implementación, la memoria de tipo Flash 1035 puede ser dividida o separada en diferentes áreas, por ejemplo, un área de almacenamiento para programas informáticos 1036 (por ejemplo, lógica de procesamiento de servicio), así como regiones de almacenamiento de datos tales como el estado del dispositivo, 1037, un libro de direcciones 1039, otros datos 1041 de gestor de información personal (PIM – “personal information manager”), y otras áreas de almacenamiento de datos designadas generalmente por el número de referencia 1043. Puede haberse proporcionado un apilamiento o pila de transporte 1045 para llevar a cabo uno o más protocolos de transporte de radio en paquetes apropiados. Se ha proporcionado, además, un módulo lógico de validación de esquema de XML y/o de negociación / indicación de versión, a fin de facilitar una o más realizaciones según se ha establecido en detalle anteriormente en la presente memoria.

Debe apreciarse que las diversas operaciones, componentes y procedimientos expuestos en la presente invención de patente, ya sean susceptibles de hacerse funcionar en el dispositivo de UE, en el nodo de red de IMS o en otras posiciones de la red, pueden llevarse a la práctica a través de diversos medios, incluyendo software (por ejemplo, código de programa o secuencia de instrucciones), firmware, hardware, o en cualquier combinación, habitualmente en asociación con un sistema de tratamiento, como componentes configurados para llevar a cabo funciones específicas. En el caso de que los procedimientos se hayan incorporado en software, dicho software puede comprender instrucciones de programa que forman un producto de programa informático, instrucciones en medios accesibles por computadora, software de aplicación de servicio susceptible de ser cargado, o software descargable desde una estación remota, y similares. Por otra parte, en el caso de que los procedimientos, estructuras de datos, o ambos, estén almacenados en un dispositivo de almacenamiento accesible por computadora, dicho dispositivo de almacenamiento puede incluir memoria de semiconductor, medios de almacenamiento informáticos internos y externos, y abarca medios de almacenamiento de información no volátiles, medios de almacenamiento de información volátiles, así como medios de transmisión, aunque sin estar limitado por estos. Los medios de almacenamiento de información no volátiles pueden incluir CD-ROMs [memorias de solo lectura de disco compacto –“compact disc-read only memories”], cintas magnéticas, PROMs [memorias de solo lectura programables – “programmable read only memories”], memoria de tipo Flash o medios de almacenamiento ópticos. Los medios de almacenamiento de información volátiles pueden incluir memoria dinámica, memorias caché, RAMs [memorias de acceso aleatorio –“random access memories”], etc. Los medios de transmisión pueden incluir ondas portadoras u otros medios de transporte de señales. Tal y como se utiliza aquí, la expresión “medio accesible por computadora” abarca un “medio legible por computara” así como un “medio ejecutable por computadora”.

Por otra parte, si bien las realizaciones que se han expuesto en la presente memoria han sido descritas en detalle con respecto al intercambio de mensajes basado en SIP en redes de conformidad con el 3GPP, se constatará que las enseñanzas de la presente invención de patente pueden ser aplicadas a otros entornos distribuidos que implican protocolos diferentes (por ejemplo, HTTP). De la misma manera, las enseñanzas de esta memoria pueden ser también aplicadas por lo que respecta a otros lenguajes de anexión abreviada de texto en los que son posibles cuerpos versionados y se usa alguna clase de metaestructura para la validación de dichos cuerpos.

Se cree que el funcionamiento y la construcción de las realizaciones de la presente solicitud de patente resultarán evidentes de la Descripción Detallada anteriormente expuesta. Si bien las realizaciones proporcionadas a modo de ejemplo que se han mostrado y descrito, pueden haber sido caracterizadas como las preferidas, debe comprenderse fácilmente que es posible realizar en ellas diversos cambios y modificaciones sin apartarse del ámbito de la presente divulgación, tal y como se establece en las siguientes reivindicaciones.

Claims (8)

1. REIVINDICACIONES

   1.-Un método para responder a una petición en un entorno de red (100), de tal manera que dicho método comprende:

   recibir, en un destinatario, un mensaje (552) de INVITACIÓN de SIP procedente de un remitente, de talmanera que dicho mensaje (552) de INVITACIÓN de SIP incluye un encabezamiento de Aceptación que carece de una indicación de aceptación de un cuerpo de un primer tipo de contenido, por parte de dichoremitente, y de tal modo que dicho mensaje (552) de INVITACIÓN de SIP es una petición de una sesión de llamada a Servicios de Emergencia, ES; y

   proporcionar un mensaje (554) de respuesta de SIP que incluye al menos un cuerpo de dicho primer tipo de contenido, de tal manera que dicho mensaje (554) de respuesta de CIP se proporciona como respuesta adicho mensaje (552) de INVITACIÓN de SIP.
2. 2.-El método para responder a una petición de acuerdo con la reivindicación 1, en el cual dicho primer tipo de contenido es aplicación/3gpp-ims+xml.
3. 3.-El método para responder a una petición de acuerdo con cualquiera de las reivindicaciones 1 a 2, en el cual dicho remitente es un dispositivo (200) de Equipo de usuario, UE, dispuesto en dicho entorno de red (100).
4. 4.-El método para responder a una petición de acuerdo con cualquiera de las reivindicaciones 1 a 3, en el cual dicho remitente es un nodo (300) de red dispuesto en dicho entorno de red (100).
5. 5.-El método para responder a una petición de acuerdo con cualquiera de las reivindicaciones 1 a 4, en el cual dicho destinatario es un nodo (300) de red dispuesto en dicho entorno de red (100).
6. 6.-El método para responder a una petición de acuerdo con cualquiera de las reivindicaciones 1 a 4, en el cual dicho destinatario es un dispositivo de UE (200), dispuesto en dicho entorno de red (100).
7. 7.-El método para responder a una petición de acuerdo con cualquiera de las reivindicaciones 1 a 6, en el cual almenos uno de dicho mensaje (552) de INVITACIÓN de SIP y dicho mensaje (554) de respuesta de SIP, contiene un cuerpo que comprende al menos un documento de XML.
8. 8.-Un aparato dispuesto para llevar a cabo un método según se ha establecido en cualquiera de las reivindicaciones 1 a 7.