ES2741448T3

ES2741448T3 - Método y aparatos para utilizar conexiones no IMS en sesiones IMS

Info

Publication number: ES2741448T3
Application number: ES11870137T
Authority: ES
Inventors: Alexander Shatsky
Original assignee: BlackBerry Ltd
Current assignee: BlackBerry Ltd
Priority date: 2011-07-22
Filing date: 2011-07-22
Publication date: 2020-02-11
Anticipated expiration: 2031-07-22
Also published as: EP2735203A1; US10609153B2; EP2735203A4; US9961148B2; WO2013013286A1; EP3541046B1; US9094438B2; EP3541046A1; EP2735203B1; US20130021998A1; US20150319648A1; US20180227371A1

Abstract

Un método para la reserva de recursos del sistema multimedia de Protocolo de Internet 'IP' 'IMS', comprendiendo el método: transmitir desde un primer dispositivo electrónico, a través de una red IP, un mensaje 'SIP' de Protocolo de Inicio de Sesión no IMS a un servidor de aplicaciones en una red IMS, en donde el mensaje SIP no-IMS comprende al menos uno de los siguientes: un mensaje `HTTP' de Protocolo de Transferencia de Hipertexto, un mensaje SIP "no IMS" tal como lo define la solicitud de comentarios del grupo de trabajo de ingeniería de Internet IETF RFC, un mensaje `REST' de Transferencia de Estado Representacional o un mensaje de protocolo 'P2P' punto a punto, y el mensaje SIP no IMS incluye una solicitud para iniciar una sesión de comunicación IMS a través de la red IMS entre el servidor de aplicaciones y un segundo dispositivo electrónico; transmitir desde el primer dispositivo electrónico, a través de la red IMS, un mensaje SIP al servidor de aplicaciones que inicia una sesión SIP INVITE entre el primer dispositivo electrónico y el servidor de aplicaciones, en donde la sesión SIP INVITE se enruta a través de la red IMS; recibir en el primer dispositivo electrónico, desde el servidor de aplicaciones, un mensaje de respuesta SIP que identifica una reserva de recursos para la sesión de comunicación IMS; y asociar el mensaje de respuesta SIP recibido a través de la red IMS con la sesión de comunicación IMS iniciada; y completar la reserva de recursos para la sesión de comunicación IMS.

Description

DESCRIPCIÓN

Método y aparatos para utilizar conexiones no IMS en sesiones IMS

Campo técnico

Esta invención se refiere a comunicaciones inalámbricas y, más particularmente, a la utilización de un protocolo de señalización SIP no IMS para una sesión IMS.

Antecedentes

En los sistemas del Proyecto de Asociación de Tercera Generación (3GPP), una red de subsistema multimedia de protocolo de Internet (IP) (IMS) puede proporcionar a los usuarios móviles servicios multimedia IP, tales como voz, vídeo y datos. Utilizando IMS, un dispositivo móvil puede transmitir y recibir comunicaciones multimedia y/o con conmutación de paquetes (PS) de voz a través de una estación base que implementa uno o más Componentes Funcionales IMS. Para implementar IMS, las redes pueden contar con el protocolo de inicio de sesión (SIP) para proporcionar una señalización basada en texto que se puede usar para comunicarse entre un UE y la Red Central (CN) IMS, entre la CN IMS y los Servidores de Aplicaciones, y entre otros diversos componentes de la Red IMS. La especificación técnica TR 29.962 v 6.1.1 de 3GPP se refiere al interfuncionamiento de señalización entre el perfil 3GPP del Protocolo de Inicio de Sesión (SIP) y el uso de SIP no 3GPP.

En una red IMS, cuando una persona que llama desea establecer una sesión de comunicación IMS con un destinatario de la llamada, el dispositivo móvil de la persona que llama puede crear una solicitud SIP INVITE y reenviarla a la red base de la persona que llama mediante una Función de Control de Sesión de Llamada Proxy (P-CSCF). La P-CSCF puede tomar una instantánea del Protocolo de Descripción de Sesión (SDP) en la solicitud INVITE y enruta la solicitud posteriormente a la SCF de Servicio (S-CSCF) de la persona que llama. Después de recibir y validar la solicitud, la S-CSCF recupera los Criterios de Filtro iniciales (iFC) de la persona que llama del Servidor de Abonado Local (HSS) y ejecuta la lógica de control de servicio. La lógica de ejecución puede incluir, por ejemplo, la invocación de los Servidores de Aplicaciones (AS) IMS ubicados en la red base. Típicamente, la S-CSCF no invoca el AS IMS por sí misma, sino que pasa el control sobre la organización de servicios a un Servidor de Aplicaciones (AS) de un mediador de servicios. En algunos casos, el AS del mediador de servicios organiza las invocaciones de AS IMS en función de las configuraciones de iFC.

Una vez que el AS IMS ha procesado la solicitud SIP INVITE, el control se devuelve a la S-CSCF. La S-CSCF puede determinar el siguiente salto para la solicitud y reenvía la solicitud a la CSCF de Interrogación (I-CSCF) del destinatario de la llamada. La I-CSCF puede localizar la S-CSCF local del destinatario de la llamada y envía la solicitud a la S-CSCF a través de varias consultas DNS y diameter. La invocación del AS IMS en la red de terminación es similar a la de origen. Además, la S-CSCF reenvía la solicitud a la P-CSCF del destinatario de la llamada y, finalmente, el dispositivo móvil del destinatario de la llamada recibe la solicitud. La respuesta generada por el destinatario de la llamada atraviesa la misma ruta de regreso a la persona que llama. Después de varios mensajes SIP hacia adelante y hacia atrás, se completa el procedimiento de establecimiento de sesión.

Descripción de los dibujos

La Figura 1 es una representación esquemática de un sistema de comunicación celular inalámbrico ejemplar.

La Figura 2 es un diagrama de carriles que ilustra un proceso ejemplar de inicio de sesión IMS basado en el uso de un protocolo no IMS.

La Figura 3 es un diagrama de carriles que ilustra un proceso ejemplar de activación de portadora en IMS basado en el uso de un protocolo no IMS.

La Figura 4 es un diagrama de carriles que ilustra un procedimiento de IMS ejemplar cuando se rechaza una solicitud SIP INVITE.

La Figura 5 es un diagrama de carriles que ilustra un procedimiento de IMS ejemplar cuando se retrasa una solicitud SIP INVITE.

La Figura 6 es una representación esquemática de un servidor y un equipo de usuario operables para algunas de las diversas implementaciones de la divulgación.

Los símbolos de referencia similares en los diversos dibujos indican elementos similares.

Descripción detallada

La presente invención se divulga en la reivindicación 1 del método independiente adjunta y en las reivindicaciones 6 y 11 del aparato. En algunos aspectos, un primer dispositivo electrónico (por ejemplo, un equipo de usuario (UE), un servidor, una centralita privada (PBX), una pasarela) puede iniciar una sesión de comunicación de protocolo de inicio de sesión (SIP) del subsistema multimedia IP (IMS) utilizando un protocolo/conexión “SIP no IMS”. En comparación con SIP IMS, que puede ser un conjunto de especificaciones 3GPP que definan el perfil SIP en redes IMS, un “SIP no IMS” puede ser un perfil SIP definido fuera de las actividades de estandarización IMS de 3GPP. Además, en algunas implementaciones, los mensajes SIP IMS pueden ser enviados por un dispositivo electrónico dentro de las redes IMS, mientras que los mensajes SIP pueden enviarse fuera de las redes IMS. Después del inicio de la sesión SIP IMS, se puede reservar un recurso de red para uno o más servicios de medios utilizados en la sesión de comunicación SIP IMS. El proceso de inicio de sesión SIP IMS puede comenzar desde el primer dispositivo electrónico que envíe un mensaje “SIP no IMS”. El mensaje SIP no IMS puede ser una indicación de una llamada/sesión/diálogo SIP iniciada o iniciado por el primer dispositivo electrónico. El mensaje “SIP no IMS” se puede transmitir al servidor de aplicaciones IMS directamente, a través de una red IP pública. En comparación, un mensaje de solicitud SIP INVITE regular para el inicio de sesión SIP IMS se puede enrutar a través de múltiples saltos, incluyendo a través de una Función de Control de Sesión de Llamada Proxy (P-CSCF) y una CSCF de Servicio (S-CSCF) de la red central IMS. El “SIP no IMS” puede ser cualquier otro protocolo que no sea un SIP IMS que pueda enviar el mensaje "SIP IMS" al AS más rápidamente que el SIP IMS. Por ejemplo, los “SIP no IMS” que son adecuados para las implementaciones de la divulgación pueden incluir el Protocolo de Transferencia de Hipertexto (HTTP), SIP "no IMS" (según lo define la solicitud de comentarios del grupo de trabajo de ingeniería de Internet (IETF RFC)), Transferencia de Estado Representacional (REST), Protocolo de Control de Transmisión (TCP), protocolos P2P, protocolos de propiedad registrada (por ejemplo protocolos de Research in Motion) u otros. El primer dispositivo electrónico también puede enviar una solicitud SIP INVITE para iniciar un diálogo/llamada/sesión SIP INVITE regular. Después de recibir el mensaje “SIP no IMS”, el AS puede iniciar un diálogo SIP con la red central IMS sin tener que esperar a la solicitud SIP INVITE.

Después de que una solicitud SIP INVITE y una respuesta provisional a la solicitud SIP INVITE hayan atravesado la red IMS entre al menos el primer dispositivo electrónico, el AS y el segundo dispositivo electrónico, se puede inicializar la sesión de comunicación SIP IMS y se puede completar una reserva de recursos para uno o más servicios multimedia IMS. El primer dispositivo electrónico puede entonces activar al menos una portadora/medios asociados con el recurso reservado. En algunos aspectos, un primer dispositivo electrónico puede iniciar un procedimiento de activación de portadora/medios para una sesión SIP IMS utilizando un protocolo/una conexión “SIP no IMS” después de que se haya completado un procedimiento de reserva de recursos descrito en la sección anterior. El procedimiento de activación de portadora puede comenzar desde un primer dispositivo electrónico transmitiendo un mensaje “SIP no IMS”, por ejemplo una solicitud HTTP UPDATE, es decir un mensaje que puede incluir un encabezamiento HTTP o un parámetro de encabezamiento con, por ejemplo, el verbo "UPDATE" (actualizar) o cualquier otro parámetro que pueda ser utilizado por el servidor de aplicaciones para identificar una acción que se haya de realizar en el tramo de llamada SIP de una llamada/diálogo/sesión sin apartarse del alcance de la presente divulgación. Debe entenderse que además del parámetro de encabezamiento "UPDATE" (y la correspondiente solicitud/transacción SIP UPDATE), los parámetros ejemplares adecuados para otras transacciones SIP para el mensaje “SIP no IMS” también pueden incluir "PRACK", "OPTIONS", "BYE", "CANCEL", "INFO" y "MESSAGE". De manera similar al proceso de inicio de sesión SIP IMS que utiliza un protocolo/una conexión “SIP no IMS”, el mensaje HTTP UPDATE puede transmitirse directamente al servidor de aplicaciones. Como tal, el tiempo para que el mensaje HTTP UPDATE llegue al servidor de aplicaciones puede ser más rápido que una solicitud SIP UPDATE regular, que puede ser retrasada por la P-CSCF y la S-CSCF antes de llegar al AS. Es posible que el primer dispositivo electrónico no transmita una solicitud SIP UPDATE por separado al AS para la activación de la portadora, ya que el recurso de red ya se ha reservado. Después de recibir la solicitud HTTP UPDATE, el AS puede enviar un mensaje/una solicitud SIP a la red central IMS para la activación de la portadora/los medios.

Los dispositivos electrónicos descritos anteriormente pueden operar en un sistema celular 100 de comunicación, tal como el sistema ejemplar mostrado en la Figura 1. El sistema celular 100 ejemplar ilustrado en la Figura 1 incluye uno o más UE 110 (se muestran dos UE), una red 120 de acceso por radio (RAN), una red central (CN) 130, IMS 140, y redes 145 de protocolo de Internet (IP) externas. La red central 130 incluye además un servidor 135 de abonado local (HSS), y el IMS incluye además un servidor IMS 150 de aplicaciones.

El UE 110 puede ser cualquier dispositivo electrónico móvil utilizado por un usuario final para comunicarse, por ejemplo, dentro del sistema celular 100. El UE 110 puede denominarse dispositivo electrónico móvil, dispositivo móvil, dispositivo de usuario, estación móvil, estación de abonado, o terminal inalámbrico. El UE 110 puede ser un teléfono celular, un asistente personal de datos (PDA), un teléfono inteligente, un ordenador portátil, una tableta, un ordenador personal (PC) u otro dispositivo de comunicaciones inalámbricas. Además, los UE 110 pueden incluir buscapersonas, ordenadores portátiles, teléfonos con Protocolo de Inicio de Sesión (SIP), uno o más procesadores dentro de dispositivos, o cualesquiera otros dispositivos de procesamiento adecuados capaces de comunicar información utilizando una tecnología de radio. El UE 110 puede comunicarse directamente con una estación base 115 incluida en una RAN 120 para recibir servicio cuando el UE 110 se opera dentro de la célula asociada con la estación base 115 correspondiente. El UE 110 también puede recibir señales de radio de más de una estación base 115 incluida en la RAN 120.

Funcionalmente, los UE 110 pueden utilizarse como una plataforma para diferentes aplicaciones de comunicaciones. Por ejemplo, los UE 110 se pueden usar para interactuar con la red celular mediante la transmisión/recepción de señales para iniciar, mantener o terminar las comunicaciones solicitadas por el usuario final. El UE 110 también puede incluir funciones de gestión de movilidad tales como traspasos e informes de la ubicación, y en éstas el UE 110 actúa según las instrucciones de la red celular. Una función ejemplar del UE 110 puede ser proporcionar la interfaz de usuario al usuario final de modo que puedan implementarse aplicaciones tales como llamada de voz, comunicación de vídeo, transmisión de datos o navegación web.

En algunas implementaciones, los UE 110 pueden transmitir en una o más bandas celulares. Uno o más UE 110 pueden estar acoplados de manera comunicativa a la RAN 120. En estos casos, los mensajes transmitidos y/o recibidos por los UE 110 pueden basarse en una tecnología de acceso múltiple. En algunas implementaciones, los UE 110 están configurados para usar tecnología de acceso múltiple por división de frecuencia ortogonal (OFDMA) o tecnología de acceso múltiple por división de frecuencia de portadora única (SC-FDMA) para comunicarse con la estación base 115. En algunas otras implementaciones, unos eNB 112 pueden también alojar los UE 110 utilizando tecnologías de acceso múltiple como el acceso múltiple por división de tiempo (TDMA), el acceso múltiple por división de frecuencia (FDMA) y el acceso múltiple por división de código (CDMA). Los UE 110 pueden transmitir voz, vídeo, multimedia, texto, contenido web y/o cualquier otro contenido específico de usuario/cliente. Algunos contenidos multimedia, por ejemplo, contenido de vídeo y web, pueden aprovechar un alto rendimiento de canal sobre la base de la tecnología de múltiple entrada, múltiple salida (MIMO). La tecnología MIMO puede permitir que el sistema configure múltiples flujos de datos en el mismo canal, lo que aumenta el rendimiento del canal. En resumen, los UE 110 generan solicitudes, respuestas o se comunican de otra manera en diferentes medios con la red central 130 y/o las redes 145 del Protocolo de Internet (IP) a través de RAN 120. Algunos componentes incluidos en el UE 110 y sus funcionalidades correspondientes se describen con más detalle en la ilustración de la Figura 6.

Una RAN 120 es parte de un sistema de telecomunicaciones que implementa una tecnología de acceso por radio, tal como el Sistema Global de Comunicaciones Móviles (GSM), CDMA, el Sistema Universal de Telecomunicaciones Móviles (UMTS) y la Evolución a Largo Plazo 3GPP (LTE). En algunas aplicaciones, la RAN 120 para un sistema 3GPP lTe se llama EUTRAN. La RAN 120 puede ubicarse entre los UE 110 y la CN 130. La RAN 120 incluye una o más estaciones base 115. Las estaciones base 115 pueden ser estaciones base 115 de radio, que pueden controlar una o más funciones relacionadas con la radio en una parte fija del sistema. La estación base 115 puede comunicarse directamente con uno o más UE 110, otras estaciones base 115 y la CN 130. La estación base 115 puede ser el punto final de los protocolos de radio hacia los UE 110 y puede transmitir señales entre la conexión de radio y la conectividad hacia la CN 130.

Una CN 130, o una red troncal, puede ser la parte central de una red de telecomunicaciones. Funcionalmente, la CN 130 se puede utilizar para proporcionar diversos servicios a clientes conectados por la RAN 120, incluyendo enrutamiento de llamadas a través de la RAN 120, redes IP y/o red telefónica pública conmutada (PSTN). En el sistema LTE, el componente principal de la CN 130 es el núcleo de paquetes evolucionado (EPC). La CN 130 puede incluir un servidor 135 de abonado local (HSS). En algunas implementaciones, el HSS también se denomina Función de Servidor de Perfiles de Usuario (UPSF). El HSS 135 es una base de datos de usuario maestra que admite las entidades de red IMS que realmente manejan las llamadas. El HSS 135 contiene la información relacionada con el abono (por ejemplo, los perfiles de abonado) y el usuario identifica, realiza la autenticación y autorización de los UE 110, y puede proporcionar información sobre la ubicación y la información de IP del UE. Se pueden asociar diversas identidades de usuario con IMS, por ejemplo Identidad Privada Multimedia IP (IMPI), Identidad Pública Multimedia IP (IMPU), URI de Agente de Usuario Enrutable Globalmente (GRUU), Identidad Pública Comodín de Usuario. En algunas implementaciones, la red central 130 puede incluir una red central IMS.

Un IMS 140 es un marco arquitectónico para prestar servicios multimedia de Protocolo de Internet (IP). Para facilitar la integración con las redes IP externas 145, el IMS 140 utiliza protocolos del Grupo de Trabajo de Ingeniería de Internet (IETF), por ejemplo SIP. El IMS 140 se puede usar para ayudar a acceder a aplicaciones de voz y multimedia desde terminales inalámbricos y alámbricos. En otras palabras, el IMS 140 puede crear una forma de convergencia fijo-móvil. Esto se hace teniendo una capa de control horizontal que aísla la RAN 120 de la capa de servicio. Desde una perspectiva de arquitectura lógica, los servicios pueden no tener sus propias funciones de control, ya que la capa de control se puede usar como una capa horizontal común. El IMS 150 está acoplado de manera comunicativa a la CN 130 y a la RAN 120 para proporcionar servicios multimedia a los UE. En algunas implementaciones, los componentes de red incluidos en CN 130 y RAN 120 se pueden usar para formar parte del IMS 140. El IMS 140 se puede comunicar con un UE 110 o las redes IP externas 145 utilizando el Protocolo de Internet para direccionamiento y enrutamiento IP. El IMS 140 puede incluir un servidor IMS 150 de aplicaciones. El servidor IMS 150 de aplicaciones puede alojar una o más aplicaciones para proporcionar servicios multimedia a los UE 110. Algunos componentes incluidos en el servidor IMS 150 y sus funcionalidades correspondientes se describen con más detalle en la ilustración de la Figura 6. En algunas implementaciones, el IMS 140 puede estar acoplado de manera comunicativa a una PSTN (no mostrada) y/o redes IP externas 145. Las redes IP externas 145 pueden incluir redes públicas (por ejemplo, Internet) y redes privadas que admitan el Protocolo de Internet.

En algunos aspectos de la operación, el UE 110 puede enviar un mensaje SIP IMS, a través de la RAN 120 y la CN 130 que incluye una CN IMS, al servidor AS IMS 150. Mientras se transmite a través de la CN IMS, una P-CSCF incluida en la CN IMS puede procesar el mensaje SIP IMS recuperando al menos una información de protocolo de descripción de sesión del mensaje SIP IMS, y una S-CSCF incluida en la CN IMS puede procesar el mensaje SIP IMS recuperando al menos un Criterio de Filtro inicial del HSS 135 y ejecutando una lógica de control de servicio. Para un mensaje “SIP no IMS” enviado por el UE 110, el mensaje puede entregarse al servidor AS IMS 150 sin ser procesado por la P-CSCF y la S-CSCF. Debe entenderse que aunque el UE 110 se usa aquí como un dispositivo electrónico ejemplar para representar en general un terminal para la comunicación IMS, pueden utilizarse también como dispositivos terminales en las diversas implementaciones de esta divulgación cualesquiera otros dispositivos electrónicos (por ejemplo, servidor, centralita privada, pasarela, etc.) que puedan transmitir y recibir mensajes SIP IMS y “SIP no IMS”.

Aunque se describe en términos de la Figura 1, la presente divulgación no se limita a dicho sistema celular. En general, los sistemas de telecomunicaciones celulares pueden describirse como redes celulares formadas por varias células de radio, o células que son atendidas cada una por una estación base u otro transceptor fijo. Las células se utilizan para cubrir diferentes áreas con el fin de proporcionar cobertura de radio en un área. Los sistemas de telecomunicaciones celulares ejemplares incluyen los protocolos del Sistema Global de Comunicaciones Móviles (GSM), el Sistema Universal de Telecomunicaciones Móviles (UMTS), la Evolución a Largo Plazo (LTE) 3GPP, y otros. Además de los sistemas de telecomunicaciones celulares, otros sistemas de comunicación inalámbrica que son adecuados para las diversas implementaciones descritas en la presente divulgación pueden incluir, pero no se limitan a, la red de área local inalámbrica IEEE 802.11, el sistema IEEE 802.15.4, el sistema Bluetooth, la red WiMAX IEEE 802.16, etc. En consecuencia, la RAN 120, la CN 130, las redes IP externas 145 pueden ser las redes RAN, CN e IP externas incluidas en cualquier sistema de comunicación inalámbrica sin apartarse del alcance de esta divulgación.

La Figura 2 es un diagrama de carriles que ilustra un proceso ejemplar 200 de inicio de sesión IMS basado en el uso de un protocolo no IMS. El proceso ejemplar 200 ilustrado se implementa mediante componentes de red que incluyen un UE 202, una P-CSCF 204, una S-Cs Cf 206, un servidor 208 de aplicaciones (AS), una CSCF 210 de servidor y/o proxy (S/P-CSCF) y un UE 212. La P-CSCF 204 y la S-CSCF 206 pueden ubicarse en la red base del UE 202, la s /p -CSCF 210 puede ubicarse en un UE 202 de red visitante o en una red base para el UE 212. En algunas implementaciones, antes de la sesión IMS, el UE 202, el UE 212 o ambos pueden haber sido autenticados y autorizados por el AS 208 para establecer un canal de comunicación seguro. El procedimiento de autenticación puede basarse en la seguridad proporcionada por un protocolo de transporte. Por ejemplo, si el protocolo “SIP no IMS” es un protocolo HTTP/TCP, entonces se puede usar la seguridad de la capa de transporte (TLS) para asegurar el canal de comunicación. El canal de comunicación también se puede asegurar mediante la Seguridad del Protocolo de Internet (IPSec) en modo de transporte o túnel, u otros protocolos de propiedad registrada. Como se describe en la ilustración de la Figura 1, aunque el UE se usa como un dispositivo terminal ejemplar para la comunicación IMS, también pueden usarse como dispositivos terminales basados en la implementación específica cualesquiera otros dispositivos electrónicos (por ejemplo, servidor, centralita privada, pasarela, etc.) que puedan transmitir y recibir mensajes SIP IMS y “SIP no IMS”.

En 220, el UE 202 transmite un mensaje “SIP no IMS” (por ejemplo, solicitud HTTP) al AS 208. El AS 208 puede ser un AS IMS 150 como se describe en la ilustración de la Figura 1. El mensaje puede ser una indicación de una llamada/sesión/diálogo SIP iniciada o iniciado por el UE 202. El “SIP no IMS” puede ser cualquier protocolo que pueda enviar el mensaje “SIP no IMS” más rápidamente que el SIP al AS 208. El “SIP no IMS” puede incluir protocolos HTTP, IETF SIP, REST, TCP, P2P y protocolos de propiedad registrada. En algunas implementaciones, el mensaje “SIP no IMS” puede enviarse al AS 208 a través de una red que sea diferente de la red IMS, por ejemplo las redes IP externas 145 como se describe en la ilustración de la Figura 1. En este ejemplo particular, una solicitud HTTP INVITE se considera como el mensaje “SIP no IMS”. La solicitud HTTP INVITE que indica que se está iniciando una llamada/sesión/diálogo SIP puede comprender un encabezamiento HTTP y/o un parámetro de encabezamiento con, por ejemplo, el verbo "INVITE". La solicitud HTTP INVITE también puede contener un parámetro que indique una dirección de destino de la próxima llamada/sesión/diálogo SIP (por ejemplo, la dirección del UEn°2212). El parámetro puede tener la forma de un Identificador Uniforme de Recursos (URI) de SIP o cualquier otra forma que pueda permitir al AS 208 generar una dirección URI SIP válida del destino. La solicitud HTTP también puede contener una oferta de Protocolo de Descripción de Sesión (SDP) que el UE 202 puede enviar en el tramo SIP 222 de la llamada/sesión/diálogo. En algunas implementaciones, cuando el UE 202 inicia múltiples sesiones en el mismo destino al mismo tiempo, la solicitud HTTP también puede contener un encabezamiento/parámetro que puede ayudar al AS 208 a correlacionar la solicitud HTTP con las próximas solicitudes SIP (por ejemplo, SIP INVITE 222). El encabezamiento/parámetro puede tener valores que incluyen el Identificador de Servicio de Comunicación IMS (ICSI)/Identificador de Referencia de Aplicación IMS (IARI), las capacidades del agente de usuario, las preferencias de la persona que llama, el encabezamiento de identificación de llamada SIP. En algunas implementaciones, el AS 208 puede consultar al UE 202 utilizando una solicitud SIP (por ejemplo, la solicitud SIP OPTIONS). Por consiguiente, el AS 208 puede recibir una oferta SDP en un mensaje que esté en la respuesta a la solicitud SIP. También se pueden usar otras implementaciones de SIP y SIP no IMS para obtener una oferta SDP para el UE 202 en el AS 208 sin apartarse del alcance de esta divulgación.

En 222, el UE 202 puede iniciar un diálogo/llamada/sesión SIP INVITE regular con el UE 212. En la especificación técnica (TS) 24.229 del estándar 3GPP IMS se puede encontrar una ilustración detallada del procedimiento de inicio de diálogo/sesión/llamada SIP INVITE regular. En resumen, la solicitud SIP INVITE se transmite primero a una P-CSCF 204. Múltiples funciones de los servidores o proxies SIP pueden denominarse colectivamente CSCF. Las funciones de los servidores SIP y los proxies son, respectivamente, la P-CSCF 206 y la S-CSCF 208. La CSCF se puede utilizar para procesar paquetes de señalización SIP en el IMS. Una P-CSCF 206 es un proxy SIP que puede ser el primer punto de contacto para el terminal IMS. Puede ubicarse bien en una red visitada, bien en una red base. Después de recibir la solicitud SIP INVITE, la P-CSCF puede tomar una instantánea del SDP en la solicitud INVITE y enrutar la solicitud SIP INVITE a la S-CSCF 206 en 224. Después de recibir y validar la solicitud SIP INVITE, la S-CSCF 206 puede recuperar un iFC del HSS, tal como un HSS 135 descrito en la ilustración de la Figura 1, y reenviar el SIP INVITE al AS 208 en 226. De acuerdo con la solicitud SIP INVITE recibida, el AS 208 puede descodificar una oferta SDP que identifique los servicios IMS solicitados por el UE 202. En comparación con la transmisión de HTTP INVITE 220, el SIP INVITE es procesado tanto por la P-Cs CF 204 como por la S-CSCF 206, lo que puede resultar en un tiempo de transmisión más largo para que la solicitud de INVITE llegue al AS 208. El mensaje “s Ip no IMS” puede no atravesar la CN IMS en el tramo 202 de llamada del UEn°1-AS. Por lo tanto, el AS 208 puede iniciar los flujos de llamada SIP INVITE en 230 basándose en la recepción del mensaje IMS SIP no IMS en lugar de la solicitud SIP iNv ITE regular, y se puede ahorrar un tiempo 228 durante el procedimiento de inicio de diálogo/sesión/llamada SIP.

Una vez que el AS 208 recibe el mensaje “SIP no IMS” transmitido por el UEn°1 202 en 220, puede realizar al menos una de las siguientes operaciones: 1) autenticar y validar el mensaje “SIP no IMS” recibido; 2) descodificar la información de la dirección de destino a partir del mensaje “SIP no IMS” (por ejemplo, URI SIP); 3) identificar si se incluye una oferta SDP en el mensaje “SIP no IMS” y, si se incluye una oferta SDP, descodificar y almacenar una oferta SDP basada en el mensaje “SlP no IMS”; 4) generar una solicitud SIP INVITE de acuerdo con las reglas definidas en 3GPP TS24.229; 5) establecer la dirección de destino en la solicitud SIP INVITE generada; 6) establecer la oferta SDP prealmacenada en la solicitud SIP INVITE; o 7) iniciar un diálogo SIP 230 con la CN IMS, como la CN 130 descrita en la ilustración de la Figura 1.

En 230, la invitación SIP se transmite al UE 212 a través de una S-CSCF y/o una P-CSCF (S/P-CSCF) 210 en función de la dirección de destino descodificada. En 234, el UE 212 reserva un recurso de red IMS. Los recursos de red IMS pueden corresponder a uno o más servicios multimedia que pueden usarse en la sesión de comunicación SIP IMS. En 232, el UE 212 envía una respuesta SIP 183 que incluye una respuesta SDP a la S/P-CSCF 212 y la respuesta SIP 183 se reenvía al AS 208 en 236.

El AS 208 espera a la respuesta SIP INVITE del UE 202 y la respuesta SIP 183 (Sesión en Curso) (o cualquier otra respuesta SlP con respuesta SDP) del UE 212. Cuando el AS 208 ha recibido tanto la solicitud SlP INVITE como la respuesta SIP 183, el AS 208 puede descodificar la respuesta SDP basándose, por ejemplo, en el SIP 183 del UE 212. La respuesta SDP puede incluirse en un SIP 183 o en cualesquiera otros mensajes de respuesta SIP. El AS 208 también puede almacenar la oferta SDP del UEn°1 202 y la respuesta SDP del UEn°2212. En 238, la respuesta SDP puede incluirse en un mensaje de respuesta SIP (por ejemplo, respuesta SIP 183) a la S-CSCF 206. El mensaje de respuesta SIP se puede reenviar posteriormente a la P-Cs Cf 204 en 240 y finalmente al UE 202 en 242.

En algunas implementaciones, el AS 208 puede detectar una falta de coincidencia de códec entre la oferta SDP SIP INVITE del UE 202 y una respuesta SDP del UE 212, es decir que los servicios multimedia asociados con la oferta SDP pueden usar diferentes códecs en comparación con la respuesta SDP. El AS 208 puede actuar como un agente de usuario adosado (B2BUA), puede invocar un Controlador de Función de Recursos de Medios (MRFC)/Procesador de Función de Recursos de Medios (MRFP) IMS, u otras funciones de transcodificación para transcodificar medios entre las sesiones asociadas con la oferta SDP y la respuesta SDP. Por ejemplo, un AS 208 puede recibir una solicitud HTTP INVITE del UE 202 e iniciar una sesión SlP con el UE 212 utilizando los códecs 1 y 2. Sin embargo, debido a una política interna, las portadoras pueden invocar una función de transcodificación de medios y reemplazan los códecs 1 y 2 por los códecs 3 y 4. El UE 212 puede responder al SIP INVITE (incluida la oferta SDP asociada con los códecs 1 y 2) del AS 208 con el códec 2. Por lo tanto, el AS 208 puede detectar una falta de coincidencia de códec (UEn°1 202 con códecs 3 y 4 y UEn°2212 con códecs 2). El AS 208 puede entonces establecer una sesión con el MFRC. El MRFC puede asignar recursos en el MRFP para la transcodificación entre los códecs 3/4 y 2. El AS 208 puede responder utilizando una respuesta SIP con los códecs 3 y 4 en respuesta al SIP INVITE del UE 202. El AS 208 también puede usar el códec 2 en cualesquiera transacciones SIP próximas (por ejemplo, SIP UPDATE) con oferta SDP en la interfaz con el UE 212. El MRFP puede luego transcodificar el flujo de medios con los códecs 3 o 4 del UE al códec 2 en la interfaz al UEn°2, y viceversa.

La Figura 3 es un diagrama de carriles que ilustra un proceso ejemplar 300 de activación de portadora en IMS basado en el uso de un protocolo no IMS. El proceso ejemplar 300 ilustrado se implementa mediante componentes de red que incluyen un UE 302, una P-CSCF 304, una S-CSCF 306, un AS 308, una S/P-CSCF 310 y un UE 312. La P-CSCF 304 y la S-CSCF 306 pueden estar ubicadas en la red base del UE 302, la S/P-CSCF 310 puede estar ubicada en la red visitante del UE 302 o la red base del UE 312. En algunas implementaciones, se supone que, antes del proceso de activación de portadora, el UE 302 y el UE 312 han inicializado y/o completado el procedimiento de reserva de recursos después de realizar el proceso ejemplar 200 ilustrado en la Figura 2, o un proceso de inicio de sesión SIP IMS regular. Además, el AS 308 puede obtener y/o almacenar una copia de la oferta SDP del UE 302.

En 320, el UE 302 envía un mensaje “SIP no IMS”, por ejemplo una solicitud HTTP UPDATE al AS 308. La solicitud HTTP UPDATE puede incluir un encabezamiento HTTP o un parámetro de encabezamiento con, por ejemplo, el verbo "UPDATE" (actualizar), o cualquier otro parámetro que el AS pueda usar para identificar una acción que se haya de realizar en el tramo de llamada SIP de la llamada/diálogo/sesión. En algunos casos, el mensaje “SIP no IMS” también puede incluir un parámetro (por ejemplo, el encabezamiento de identificación de llamada SIP) que pueda ayudar al AS 308 a correlacionar el mensaje “SlP no IMS” con un diálogo/sesión/llamada SIP existente. En algunos casos, el mensaje “SIP no IMS” puede incluir además una indicación que identifique que el UE 302 ha solicitado activar la portadora. La indicación puede incluir, por ejemplo, un parámetro SDP "a = sendrecv" o "a = sendonly". En algunos casos, el mensaje “SIP no IMS” puede incluir además una oferta SDP actualizada del UE 302.

En el diagrama mostrado en la Figura 300, una solicitud SIP UPDATE regular enviada por el UE 302 a través de la P-CSCF 304 en 344a, y la S-CSCF 306 en 344b, al AS 308 en 344c se muestra solo con fines de comparación. En el proceso ejemplar 300 para la activación de la portadora, es posible que no se envíe la solicitud SIP UPDATE regular. Dado que se supone que el SDP asociado con el UE 302 es obtenido por el AS 308 durante el proceso de inicio de sesión SIP IMS, el sistema puede utilizar la información de SDP obtenida para la activación de la portadora. De manera similar a la solicitud SIP INVITE regular, la solicitud SIP UPDATE puede llegar al AS 308 a través de múltiples saltos, lo que puede causar demoras. En la Figura 3 se muestra un ejemplo del tiempo ahorrado 346 para usar un mensaje “SIP no IMS”, aunque puede que el UE 302 no transmita ninguna solicitud SIP INVITE.

En algunas implementaciones, el UE 302 envía solo una solicitud HTTP "UPDATE", pero no se envían mensajes en el tramo SIP de la llamada/diálogo/sesión. Sin embargo, la P-CSCF a la que el UE 302 está conectado procesa los SDP tanto del UE 302 como del UE 312 para contactar con el PCC y activar la portadora. Después de recibirla solicitud HTTP UPDATE en 320, el AS 308 puede realizar al menos una de las siguientes operaciones: 1) autenticar, validar y correlacionar la solicitud HTTP UPDATE con una sesión SIP existente; 2) descodificar y almacenar una oferta SDP del “SIP no IMS” si se incluye una oferta SDP en la solicitud HTTP UPDATE; 3) generar una solicitud SIP UPDATE y, dependiendo de la implementación específica, la solicitud generada también puede ser Acuse de Recibo de Respuesta SIP Provisional (PRACK), SIP INFO, SIP Re-INVITE y/o SIP OPTIONS; 4) establecer la oferta SDP prealmacenada en la solicitud SIP UPDATE; o 5) enviar el mensaje/la solicitud SIP a la CN IMS en 322.

Un flujo de llamadas de mensajería SIP que comienza en 322 entre el AS 308 y el UE 312 puede ser un flujo de llamadas IMS estándar tal como se define en 3GPP TS24.229. La S/P-CSCF 310 del UE 312 puede realizar ajustes finales para la portadora cuando los mensajes SIP cruzan la S/P-CSCF en 324 y 326. El mensaje transmitido por el UE 312 en 326 puede ser un mensaje SIP 200 (OK). En 328, el UE 312 puede confirmar la reserva de recursos, activar la portadora y/o comenzar a llamar/alertar al usuario final para la sesión de medios entrante iniciada por el UE 302. En 330, la S/P-CSCF 310 puede reenviar el SIP 200 (OK) al As 308. Cuando el AS recibe el SIP 200 para la solicitud SIP UPDATE del UE 312, puede descodificar una respuesta SDP del SIP 200 e incluirla en una solicitud SIP UPDATE en el tramo de llamada SIP hacia el UE 302. El SDP se convierte en un SDP de oferta en el tramo de llamada SIP del UE. El AS 308 envía el mensaje SIP UPDATE a través de la S-CSCF en 332, la P-CSCF en 334, al UE 302 en 336. El UE 302 recibe, procesa y responde al mensaje con su propia respuesta SDP y envía un SIP 200 (OK) a la P-CSCF 304. La P-CSCF 304 puede hacer ajustes finales para la portadora después de recibir el SIP 200 en 338, y reenviarla a través de la S-CSc F 306 en 340 al AS 308 en 342.

La Figura 4 es un diagrama de carriles que ilustra un procedimiento IMS ejemplar 400 cuando la CN IMS rechaza una solicitud SIP INVITE debido, por ejemplo, a un tipo de medio no admitido en el cuerpo del SDP. El proceso ejemplar 400 ilustrado se implementa mediante componentes de red que incluyen un UE 402, una P-CSCF 404, una S-CSCF 406, un AS 408, una S/P-CSCF 410 y un u E 412. En el procedimiento ejemplar 400 ilustrado, en 420, el UE 402 envía al AS 408 una solicitud “SIP no IMS” INVITE, por ejemplo un HTTP INVITE, y el AS 408 envía el SIP INVITE a través de la S/P-CSCF 410 en 424 al UE 312 en 426 usando un proceso similar al descrito en la ilustración de la Figura 2. Sin embargo, la solicitud SIP INVITE enviada en 422 es rechazada por la P-CSCF 404, debido a un error de tipo de medios no admitidos en 426; se entenderá que puede haber otras razones para el rechazo. El UE 402 puede cancelar el procedimiento de establecimiento de llamada enviando, por ejemplo, un mensaje HTTP CANCEL al AS 408 en 428. El AS 408 puede además cancelar la sesión SIP con el UE 412 enviando el mensaje CANCEL (cancelar) a través de la S/P-CSCF 410 en 430 al UE 412 en 432.

La Figura 5 es un diagrama de carriles que ilustra un procedimiento IMS ejemplar 500 cuando se retrasa una solicitud SIP INVITE. El proceso ejemplar 500 ilustrado se implementa mediante componentes de red que incluyen un UE 502, una P-CSCF 504, una S-Cs Cf 506, un AS 508, una S/P-CSCF 510 y un UE 512. En el procedimiento ejemplar 500 ilustrado, en 520, el UE 502 envía un mensaje “SIP no IMS”, por ejemplo una solicitud Ht Tp INVITE, al a S 508. El AS 508 envía SIP INVITE a través de la S/P-CSCF 510 en 524 al Ue en 546. El UE 512 devuelve una respuesta 183 (Sesión en Curso) a través de la S/P-CSCF en 550 al AS en 552. La solicitud SIP INVITE enviada desde el UE 502 es recibida por la P-CSCF 504 en 522 y reenviada a la S-CSCF 506 en 548, pero aún no es recibida por la S-CSCF. El AS 508 puede cancelar la sesión SIP con el UE mediante el envío de una solicitud SIP CANCEL a través de la S/P-CSCF 510 en 556 al UE 512 en 558. El AS puede devolver un código de error o un motivo en un mensaje de respuesta “SIP no IMS”, por ejemplo un mensaje de respuesta HTTP (200 OK). El mensaje de respuesta HTTP puede contener un encabezamiento "reason" (motivo) con el valor "timeout on SIP bearer" (tiempo límite en la portadora SIP). En algunas implementaciones, antes de enviar la solicitud SIP CANCEL en 556, el AS 508 puede iniciar un temporizador mientras espera a que llegue el SIP INVITE entrante del UE 502. Si el temporizador expira, el AS 508 puede enviar la solicitud SIP CANCEL. El valor del temporizador puede ser específico de la implementación. El AS 208 puede ajustar dinámicamente el valor en función de un procedimiento de "aprendizaje" por el AS 208 de las condiciones de red/la capacidad de respuesta de las sesiones anteriores. En algunos casos, el valor del temporizador puede no exceder los 2-3 segundos para sesiones en tiempo real, tales como llamadas de voz o vídeo.

En algunas implementaciones, un AS ha iniciado una sesión SIP al UE 512 pero ha recibido una respuesta SIP de error (por ejemplo, SIP 486 Ocupado Aquí); el AS puede transmitir la respuesta al UE 502 en función del estado de la sesión SIP con el UE 502 de la siguiente manera: 1) Si el AS ha recibido una solicitud SIP del UE 502 (por ejemplo, SIP INVITE), el AS puede transmitir el código/motivo de rechazo del SIP (por ejemplo, SIP 486 Ocupado Aquí) del UEn°2 en una respuesta SIP a la solicitud SIP del UE 502; 2) Si el AS no ha recibido una solicitud SIP del UE 502, el AS puede propagar el código/motivo de rechazo del SIP en una respuesta “SIP no IMS” similar al proceso correspondiente descrito en la ilustración de la Figura 5.

En algunas implementaciones, un AS recibe un INVITE “SIP no IMS”, pero debido a un error interno/de sintaxis u otro, no puede iniciar una sesión SIP con el UE 512. El AS puede responder al INVITE “SIP no IMS” con una respuesta “SIP no IMS”. La respuesta “SIP no IMS” puede incluir un código o un motivo del fallo.

En algunas implementaciones, un AS recibe un SIP INVITE sin un INVITE “SIP no IMS” puesto previamente en cola. Entonces, el As puede seguir los procedimientos de flujos de IMS estándar descritos en 3GPP TS24.229. El AS también puede rechazar el uso de un código de error (por ejemplo, código de respuesta 481 "Call leg/transaction does not exist" (no existe el tramo de llamada/la transacción)) para los mensajes INVITE “SIP no IMS” recibidos después del SIP INVITE recibido.

La Figura 6 es una representación esquemática 600 de un servidor 610 y un UE 650 operables para algunas de las diversas implementaciones de la divulgación. El servidor 610 y el UE 650 pueden ser, respectivamente, el servidor IMS 150 de aplicaciones y el UE 110 descritos en la ilustración de la Figura 1. El servidor 610 y el UE 650 pueden estar acoplados de manera comunicativa a través de una red 640, tal como el sistema celular 100 en la Figura 1. El UE 650 puede incluir además al menos un procesador 655, una memoria 660, una circuitería DSP 665, un transceptor 670 y al menos una antena 675.

El procesador 655 puede comprender un microprocesador, una unidad central de procesamiento, una unidad de control gráfico, un procesador de red u otro procesador para llevar a cabo instrucciones almacenadas en la memoria 660. Las funciones del procesador 655 pueden incluir computación, gestión de colas, procesamiento de control, aceleración gráfica, descodificación de vídeo y ejecución de una secuencia de instrucciones almacenadas del programa guardado en el módulo 660 de memoria. En algunas implementaciones, el procesador 665 también puede ser responsable del procesamiento de señales, incluido el muestreo, la cuantificación, la codificación/descodificación y/o la modulación/demodulación de la señal. El módulo 660 de memoria puede incluir un dispositivo de estado temporal (por ejemplo, memoria de acceso aleatorio (RAM) y almacenamiento de datos. El módulo 660 de memoria se puede utilizar para almacenar datos o programas (es decir secuencias de instrucciones) de forma temporal o permanente para su uso en un UE.

El transceptor inalámbrico 670 puede incluir tanto la circuitería transmisora como la circuitería receptora. El transceptor inalámbrico 206 puede ser responsable de convertir una señal de banda base en una señal de banda de paso o viceversa. Los componentes del transceptor inalámbrico 206 pueden incluir un convertidor digital a analógico/convertidor analógico a digital, un amplificador, un filtro de frecuencia y un oscilador. Además, el transceptor inalámbrico 670 también puede incluir o estar acoplado de forma comunicativa a una circuitería 665 de procesamiento digital de señales (DSP, por sus siglas en inglés). La circuitería DSP 665 puede realizar funcionalidades que incluyen codificación/descodificación, detección, estimación, modulación y/o demodulación de señales. El transceptor 670 puede comunicarse con una o más antenas 675.

La antena 675 es un transductor que puede transmitir y/o recibir ondas electromagnéticas. La antena 675 puede convertir la radiación electromagnética en corriente eléctrica, o viceversa. La antena 675 es generalmente responsable de la transmisión y recepción de ondas de radio, y puede servir de interfaz entre el transceptor 206 y el canal inalámbrico. En algunas implementaciones, la estación inalámbrica 675 puede estar equipada con más de una antena para aprovechar la tecnología de múltiple entrada, múltiple salida (MIMO). La tecnología MIMO puede proporcionar un proceso para utilizar las múltiples rutas de señal para reducir el impacto del desvanecimiento por trayectos múltiples y/o para mejorar el rendimiento. Mediante el uso de múltiples antenas en la estación inalámbrica, la tecnología MIMO puede permitir que el sistema configure múltiples flujos de datos paralelos en el mismo canal, lo que aumenta el rendimiento del canal.

El servidor 610 puede incluir al menos un procesador 615, una memoria 620, una o más aplicaciones 625, un controlador 625 de entrada/salida y una interfaz 635. El servidor puede ser un AS SIP IMS que pueda alojar y ejecutar servicios y comunicarse mediante interfaz con la S-CSCF usando SIP. Un ejemplo de un servidor de aplicaciones que se está desarrollando en 3GPP es la Función de continuidad de llamadas de Voz (Servidor VCC). Dependiendo del servicio real, el AS 610 puede operar en modo proxy SIP, modo UA SIP o modo B2BUA SIP. Un AS 610 puede estar ubicado en una red base o en una red externa de terceros (por ejemplo, las redes IP externas 145 descritas en la ilustración de la Figura 1). Si el servidor 610 está ubicado en la red base, puede consultar e1HSS con las interfaces Diameter Sh o Si.

El procesador 615 incluido en el servidor 610 puede ejecutar una o más aplicaciones multimedia 625 para proporcionar servicios multimedia IMS. El procesador 615 puede ser una unidad central de procesamiento (CPU, por sus siglas en inglés), un blade, un circuito integrado de aplicación específica (ASIC, por sus siglas en inglés), una matriz de puertas programable in situ (FPGA, por sus siglas en inglés) u otro componente adecuado. En general, el procesador 615 ejecuta instrucciones y manipula datos para realizar las operaciones del servidor 610 y, específicamente, la o las aplicaciones 625. Independientemente de la implementación concreta, las aplicaciones 625 pueden incluir instrucciones legibles por ordenador, firmware, hardware cableado o programado, o cualquier combinación de los mismos en un medio tangible y no transitorio operable cuando se ejecuta para realizar al menos los procesos y las operaciones descritos en la presente memoria. De hecho, cada componente de software puede estar completamente o parcialmente escrito o descrito en cualquier lenguaje informático apropiado, incluyendo C, C +, Java, Visual Basic, ensamblador, Perl, cualquier versión adecuada de 4GL, así como otros. Los procesadores 615 adecuados para la ejecución de las aplicaciones 625 incluyen, a modo de ejemplo, microprocesadores tanto de uso general como especializados, y cualesquiera uno o más procesadores de cualquier tipo de ordenador digital. Generalmente, un procesador 615 recibirá instrucciones y datos de la memoria 620. Los dispositivos adecuados para almacenar aplicaciones 625 y datos incluyen todas las formas de memoria, medios y dispositivos de memoria no volátiles, incluyendo, a modo de ejemplo, dispositivos de memoria de semiconductores, por ejemplo, EPROM, EEPROM, y dispositivos de memoria flash; discos magnéticos, por ejemplo, discos duros internos o discos extraíbles; discos magnetoópticos; y discos CD ROM y DVD-ROM. El procesador 615 y la memoria 620 pueden complementarse con circuitería lógica especializada o incorporarse a la misma.

La memoria 620 incluida en el servidor 610 puede ser cualquier memoria o módulo de base de datos y puede adoptar la forma de memoria volátil o no volátil, incluyendo, sin limitación, medios magnéticos, medios ópticos, memoria de acceso aleatorio (RAM), memoria de solo lectura (ROM, por sus siglas en inglés), medios extraíbles o cualquier otro componente de memoria local o remota adecuado.

El controlador 630 de entrada/salida puede ser una circuitería o un módulo para controlar la entrada y/o la salida de la interfaz 635. El servidor 610 utiliza la interfaz 635 para comunicarse con otros componentes de la red, tales como los componentes de red descritos en la ilustración de la Figura 1. En general, la interfaz 635 incluye una lógica codificada en software y/o hardware en una combinación adecuada y operable para comunicarse con la red 640 (por ejemplo, una red IMS). Más específicamente, la interfaz 635 puede comprender un software que admita uno o más protocolos de comunicación (por ejemplo, SIP, HTTP, P2P, etc.) asociado con las comunicaciones, de modo que la red 640 o el hardware de la interfaz sea operable para comunicar señales físicas dentro y fuera de una red celular. En algunos casos, el hardware de la interfaz puede incluir transceptores inalámbricos y una antena (no se muestra).

Si bien este documento contiene muchos detalles, estos no deben interpretarse como limitaciones en el alcance de una invención que se reivindica o de lo que puede reivindicarse, sino más bien como descripciones de características específicas de realizaciones concretas. Ciertas características que se describen en este documento en el contexto de realizaciones separadas también pueden implementarse en combinación en una única realización. A la inversa, diversas características que se describen en el contexto de una única realización también pueden implementarse en múltiples realizaciones por separado o en cualquier subcombinación adecuada. Además, aunque las características pueden haberse descrito anteriormente actuando en ciertas combinaciones e incluso estar inicialmente reivindicadas como tales, una o más características de una combinación reivindicada pueden en algunos casos ser eliminadas de la combinación, y la combinación reivindicada puede dirigirse a una subcombinación o una variación de una subcombinación. De manera similar, aunque las operaciones se representen en los dibujos en un orden concreto, esto no debe entenderse como que es necesario que dichas operaciones se realicen en el orden concreto mostrado o en orden secuencial, o que se realicen todas las operaciones ilustradas, para lograr resultados deseables.

Sólo se divulgan algunos ejemplos e implementaciones. Pueden realizarse variaciones, modificaciones y mejoras de los ejemplos e implementaciones descritos y otras implementaciones sobre la base de lo divulgado.

Claims

REIVINDICACIONES

1. Un método para la reserva de recursos del sistema multimedia de Protocolo de Internet 'IP' 'IMS', comprendiendo el método:

transmitir desde un primer dispositivo electrónico, a través de una red IP, un mensaje 'SIP' de Protocolo de Inicio de Sesión no IMS a un servidor de aplicaciones en una red IMS, en donde el mensaje SIP no-IMS comprende al menos uno de los siguientes: un mensaje 'HTTP' de Protocolo de Transferencia de Hipertexto, un mensaje SIP "no IMS" tal como lo define la solicitud de comentarios del grupo de trabajo de ingeniería de Internet IETF RFC, un mensaje 'REST' de Transferencia de Estado Representacional o un mensaje de protocolo 'P2P' punto a punto, y el mensaje SIP no IMS incluye una solicitud para iniciar una sesión de comunicación IMS a través de la red IMS entre el servidor de aplicaciones y un segundo dispositivo electrónico;

transmitir desde el primer dispositivo electrónico, a través de la red IMS, un mensaje SIP al servidor de aplicaciones que inicia una sesión SIP INVITE entre el primer dispositivo electrónico y el servidor de aplicaciones, en donde la sesión SIP INVITE se enruta a través de la red IMS;

recibir en el primer dispositivo electrónico, desde el servidor de aplicaciones, un mensaje de respuesta SIP que identifica una reserva de recursos para la sesión de comunicación IMS; y

asociar el mensaje de respuesta SIP recibido a través de la red IMS con la sesión de comunicación IMS iniciada; y completar la reserva de recursos para la sesión de comunicación IMS.

2. El método de la reivindicación 1, en donde el mensaje SIP no IMS comprende un mensaje SIP que tiene un perfil SIP definido en la red IP, en donde la red IP es diferente de la red IMS.

3. El método de la reivindicación 1, en donde el mensaje SIP no IMS incluye además una indicación que indica una asociación entre el mensaje SIP no IMS y el mensaje SIP.

4. El método de la reivindicación 1, en donde el mensaje SIP no IMS incluye además información de autenticación asociada con el primer dispositivo electrónico, para validar el primer dispositivo electrónico en el servidor de aplicaciones, y una dirección de destino asociada con el segundo dispositivo electrónico.

5. El método de la reivindicación 1, en donde el mensaje SIP no IMS incluye además una oferta 'SDP' de Protocolo de Descripción de Sesión que identifica al menos un servicio de medios solicitado por el primer dispositivo electrónico.

6. Un servidor que comprende:

al menos un procesador de hardware operable para:

recibir, desde un primer dispositivo electrónico, un mensaje 'SIP' de Protocolo de Inicio de Sesión no IMS a través de una red IP, en donde el mensaje SIP no IMS comprende al menos uno de los siguientes: un mensaje 'HTTP' de Protocolo de Transferencia de Hipertexto, un mensaje SIP "no IMS" según lo definido por la solicitud de comentarios del grupo de trabajo de ingeniería de Internet IETF RFC, un mensaje 'REST' de Transferencia de Estado Representacional o un mensaje de protocolo P2P;

identificar una solicitud para iniciar una sesión de comunicación IMS a través de una red IMS con un segundo dispositivo electrónico sobre la base, al menos en parte, del mensaje SIP no IMS;

iniciar la sesión de comunicación IMS con el segundo dispositivo electrónico en respuesta a la solicitud;

recibir, desde el primer dispositivo electrónico, un primer mensaje SIP a través de la red IMS que inicia una sesión SIP INVITE entre el primer dispositivo electrónico y el servidor de aplicaciones, en donde la sesión SIP INVITE se enruta a través de la red IMS; y

asociar el primer mensaje SIP recibido a través de la red IMS con la sesión de comunicación IMS iniciada.

7. El servidor de la reivindicación 6, siendo el al menos un procesador de hardware operable además para ejecutar instrucciones para:

identificar el mensaje SIP no IMS recibido en cuanto a la información de autenticación asociada con el primer dispositivo electrónico y una dirección de destino asociada con un segundo dispositivo electrónico;

validar el dispositivo electrónico sobre la base, al menos en parte, de la información de autenticación identificada; transmitir, al segundo dispositivo electrónico, un segundo mensaje SIP que incluye la dirección de destino; e iniciar un diálogo SIP con una red central IMS durante la sesión de comunicación IMS iniciada.

8. El servidor de la reivindicación 7, siendo el al menos un procesador de hardware operable además para ejecutar instrucciones para identificar una oferta 'SDP' de Protocolo de Descripción de Sesión sobre la base, al menos en parte, del mensaje SIP no IMS recibido, almacenar la oferta SDP identificada en un memoria acoplada de forma comunicativa al al menos un procesador de hardware, y en donde el segundo mensaje SIP incluye además la oferta SDP.

9. El servidor de la reivindicación 7, siendo el al menos un procesador de hardware operable además para ejecutar instrucciones para:

identificar una oferta 'SDP' de Protocolo de Descripción de Sesión sobre la base, al menos en parte, del mensaje SIP no IMS recibido;

recibir una primera respuesta SIP del segundo dispositivo electrónico;

identificar la primera respuesta SIP para una respuesta SDP;

almacenar la oferta SDP y la respuesta SDP en una memoria acoplada de manera comunicativa al al menos un procesador de hardware; y

transmitir, al primer dispositivo electrónico, una segunda respuesta SIP que incluye información asociada con la respuesta SDP para la reserva de recursos.

10. El servidor de la reivindicación 9, siendo el al menos un procesador de hardware operable además para: determinar un primer códec sobre la base, al menos en parte, de la oferta SDP;

determinar un segundo códec sobre la base, al menos en parte, de la respuesta SDP, en donde el segundo códec es diferente del primer códec determinado;

transcodificar el primer códec al segundo códec para un mensaje SIP transmitido del primer dispositivo electrónico al segundo dispositivo electrónico; y

transcodificar el segundo códec al primer códec para un mensaje SIP transmitido del segundo dispositivo electrónico al primer dispositivo electrónico.

11. Un aparato que comprende:

al menos un procesador de hardware operable para ejecutar instrucciones para:

transmitir, a través de una red IP, un mensaje "SIP" de Protocolo de Inicio de Sesión no IMS a un servidor de aplicaciones en una red IMS, en donde el mensaje SIP no IMS comprende al menos uno de los siguientes: un mensaje 'HTTP' de Protocolo de Transferencia de Hipertexto, un mensaje SIP “no IMS” según lo definido por la solicitud de comentarios del grupo de trabajo de ingeniería de Internet IETF RFC, un mensaje 'REST' de Transferencia de Estado Representacional o un mensaje de protocolo P2P, y el mensaje SIP no IMS incluye una solicitud para iniciar una sesión de comunicación IMS a través de la red IMS entre el servidor de aplicaciones y un dispositivo electrónico diferente del aparato;

transmitir, a través de la red IMS, un mensaje SIP al servidor de aplicaciones que inicia una sesión SIP INVITE entre el aparato y el servidor de aplicaciones, en donde la sesión SIP INVITE se enruta a través de la red IMS; recibir, desde el servidor de aplicaciones, un mensaje de respuesta SIP que identifica una reserva de recursos para la sesión de comunicación IMS; y

12. El aparato de la reivindicación 11, en donde el mensaje SIP no IMS comprende un mensaje SIP que tiene un perfil SIP definido en la red IP, en donde la red IP es diferente de la red IMS.

13. El aparato de la reivindicación 11, en donde el mensaje SIP no IMS incluye además una indicación que indica una asociación entre el mensaje SIP no IMS y el mensaje SIP.

14. El aparato de la reivindicación 11, en donde el mensaje SIP no IMS incluye además información de autenticación asociada con el aparato, para validar el aparato en el servidor de aplicaciones, y una dirección de destino asociada con el dispositivo electrónico.

15. El aparato de la reivindicación 11, en donde el mensaje SIP no IMS incluye además una oferta 'SDP' de Protocolo de Descripción de Sesión que identifica al menos un servicio de medios solicitado por el aparato.