ES2376487T3 - Elemento de proceso sip multi-tipo. - Google Patents

Abstract

Un proxy (1) para un protocolo de señalización, que comprende un componente de un modo de señalización de proxy con contexto completo (5) y un componente de un modo de señalización de proxy sin contexto (4), incluyendo el componente de un modo de señalización de proxy con contexto completo (5) una máquina de estado en el proxy y manteniendo un estado o contexto de sesión completo para una sesión, no manteniendo el componente para un modo de señalización de proxy sin contexto (4) un estado de sesión o contexto de sesión, comprendiendo, además, el proxy un medio de control (7) para cambiar entre el modo de operación sin contexto y el modo de operación con contexto completo y un medio de evaluación de protocolo (6) para evaluar las solicitudes de protocolo recibidas, en el que el medio de evaluación de protocolo (6) está configurado para detectar la recepción de una solicitud de cambio de modo de proxy y para señalizar al medio de control (7) para cambiar el modo de proxy en función de la solicitud de cambio de modo de proxy recibida, habilitando o deshabilitando el medio de control (7) a los componentes (5, 4) para el modo de señalización de proxy con contexto completo o sin contexto, dependiendo de la solicitud de cambio de modo de proxy recibida, en el que la solicitud de cambio de modo es recibida después de que una sesión entre dos elementos de la red se haya establecido y la solicitud de cambio de modo relacionada con el cambio de modo de operación del proxy para la sesión abierta, y en el que se inicializa un contexto de sesión y la máquina de estado en el proxy se establece cuando se cambia al modo de operación con contexto completo.

Description

Elemento de proceso SIP multi – tipo.

La presente invención se refiere a un proxy para un protocolo de señalización y, más en particular, a un proxy SIP.

El Protocolo de Inicialización de Sesión (SIP) proporciona una funcionalidad de señalización y de establecimiento de llamada a las comunicaciones basadas en el Protocolo de Internet. El SIP ha sido diseñado para permitir la construcción de tales características en los elementos de red que se conocen como Servidores Proxy y Agentes de Usuario. Estas son características que permiten operaciones similares a las operaciones familiares de teléfono: marcar un número, hacer que un teléfono suene, escuchar los tonos de llamada o una señal de ocupado. El SIP es un protocolo entre entidades pares. Como tal, sólo requiere una red de núcleo muy simple (y por lo tanto altamente escalable) con inteligencia distribuida al borde de la red, integrada en puntos extremos (dispositivos de terminación construidos ya sea en hardware o en software). Las características de SIP son implementadas en los puntos extremos de comunicación, es decir, en el borde de la red.

El SIP es un protocolo de aplicación cliente / servidor, en el que las aplicaciones de cliente envían mensajes de solicitud SIP para crear, modificar o destruir una sesión multimedia. Las aplicaciones de servidor responden con una

o más respuestas a cada solicitud SIP. El documento RFC 3261 describe un elemento intermedio llamado proxy SIP. Los proxy ayudan a procesar y encaminar los mensajes SIP desde / a los puntos extremos SIP. Los puntos extremos en una ruta de señalización SIP se llaman Agentes de Usuario (UA). Un punto extremo puede desempeñar el papel de un Cliente de Agente de Usuario (UAC) cuando origina las solicitudes, o de un Servidor de Agente de Usuario (SAU) cuando es el destino de la solicitud. Los proxy SIP son elementos de encaminamiento que deciden el

o los siguiente (s) salto (s) del mensaje sobre la base de información proveniente de los servidores DNS, tráfico de red, etc. Los proxy SIP encaminan los mensajes SIP a uno o más Agentes Usuario de terminación.

El SIP trabaja en conjunto con varios otros protocolos y está implicado en la porción de señalización de una sesión de comunicación. El SIP actúa como un portador del Protocolo de Descripción de Sesión (SDP). En el uso típico, las "sesiones" SIP son flujos de paquetes del Protocolo de Transporte en Tiempo Real (RTP). El RTP es el portador de la voz real o del mismo contenido de vídeo. El SIP es similar al protocolo de transferencia de hipertexto (HTTP) y comparte algunos de sus principios de diseño: Se basa en texto y está estructurado en solicitud -respuesta. El SIP comparte muchos de los códigos de estado HTTP, tales como el familiar “404 no encontrado". El SIP es un protocolo sin estado, por lo cual hace posible implementar fácilmente la conmutación automática y otras que son difíciles en los protocolos con estado, tales como H.323. El SIP y el H.323 no se limitan a la comunicación de voz, sino que puede mediar en cualquier tipo de sesión de comunicación de voz a video o en las futuras aplicaciones multimedia.

Aunque dos puntos extremos SIP se pueden comunicar sin que intervenga ningún tipo de infraestructura SIP, que es la razón por la que el protocolo se describe como de entidades pares, este enfoque es básicamente impráctico para un servicio público. Por lo tanto, la mayoría de las implementaciones SIP requieren proxy y elementos de red registradores en un servicio práctico. La distinción entre los tipos de servidores SIP es lógica y no física. Un servidor en un entorno de telefonía IP basada en SIP, normalmente es requerido en los escenarios a gran escala con numerosos números de teléfono o cuando el Internet es el transporte de larga distancia. Un proxy SIP envía solicitudes SIP aguas abajo a los centros principales, a los que el usuario tiene la intención de enviarlas. Las respuestas se envían aguas arriba al solicitante. El proxy SIP puede tomar el control de llamadas de los terminales y sirve como un repositorio central para el traslado de direcciones.

Los servidores proxy ayudan a encaminar las solicitudes a la localización actual del usuario, autenticar y autorizar a los usuarios de los servicios, implementar las políticas de encaminamiento de llamadas del proveedor, y proporcionar recursos a los usuarios. El SIP también proporciona una función de registro que permite a los usuarios cargar sus localizaciones actuales para su uso por los servidores proxy. A un Servidor de Agente de Usuario que maneja un registro se le da el nombre especial de registrador.

El SIP soporta un proxy que está operando en un modo sin estado o en un modo con estado. Un proxy sin estado establece la llamada y cortésmente se retira. El proxy sin estado puede ser parte de la ruta de señalización, pero no registra información de estado. Sólo envía los mensajes. Un proxy con estado permanece en la ruta de señalización y registra la información de estado de un diálogo SIP. Puede enviar solicitudes a más de un centro principal y decide qué hacer con las respuestas. El proxy con estado almacena los eventos de señalización durante la duración de la llamada. Por ejemplo, algunos elementos SIP almacenan información de estado para manejar las retransmisiones de mensajes con elementos adyacentes. Algunos servidores proxy SIP depositan cookies en el teléfono / terminal IP como un procedimiento para proporcionar información de estado.

Un Agente de Usuario de Reverso a Reverso (B2BUA) actúa como un agente de usuario en ambos extremos de una llamada SIP. El B2BUA es responsable de manejar toda la señalización SIP entre ambos extremos de la llamada, desde el establecimiento de llamada a la terminación. Cada llamada es seguida de principio a fin, lo que permite a los operadores del B2BUA ofrecer características de valor añadido la llamada. Para los clientes SIP, el B2BUA actúa como un Servidor de Agente de Usuario (UAS), por un lado, y como un Cliente de Agente de Usuario (UAC) en el otro lado (reverso a reverso). Un B2BUA funciona como un proxy, pero finaliza los tramos de llamada en ambos lados y conecta los dos tramos por medio de la funcionalidad interna. El B2BUA puede finalizar una llamada en un lado y originar una nueva llamada en el otro lado, mientras que un proxy sólo modifica y reenvía los mensajes SIP. La implementación básica de un B2BUA se define en el documento RFC 3261. El B2BUA pueden proporcionar funcionalidades tales como la gestión de llamadas, por ejemplo, facturación, desconexión automática de llamadas, transferencia de llamadas, etc., trabajo interno de la red, por ejemplo, la adaptación de protocolos, ocultación de los componentes internos de la red, por ejemplo, ocultación de las direcciones privadas ocultación de la topología de red, etc., o la traslación codec entre dos tramos de llamada. Debido a que un B2BUA mantiene el estado de llamada para todas las llamadas SIP que maneja, el fallo del B2BUA afectará a todas estas llamadas. A menudo, los B2BUA también finalizan y puentean las corrientes de medios para tener un control completo sobre toda la sesión. Un uso común para un B2BUA es un Controlador de Borde de Sesión (SBC), que se sitúa en el borde de una red y controla la señalización de entrada y el tráfico de medios.

Por tanto, hay principalmente tres tipos conocidos de servidores proxy de señalización: proxy sin estado que hacen pasar mensajes de señalización; proxy con estado que mantienen un estado de sesión o un contexto de sesión por medio de mensajes de análisis sintáctico, y proxy de Terminación, tales como los B2BUA que terminan el protocolo de señalización y mantienen asociaciones entre las terminaciones. Cuando se inicializa una sesión utilizando la señalización inicial, en primer lugar el cliente tiene que invocar normalmente un proxy. Un problema es que es difícil para el cliente decidir qué proxy debe ser invocado de entre los tipos que se han mencionado más arriba. En muchos escenarios de flujo de llamadas, no está claro en el principio si un proxy sin estado es suficiente o si es necesariounB2BUA.

El proyecto de Internet del IETF de Marshall et al., "Extensión SIP para soportar el Estado de Llamada Distribuido", número 2, agosto de 2001, propone un nuevo campo de encabezamiento con estado general que puede ser utilizado por el proxy para distribuir información de estado a los UAS. Por medio de esto, la información de estado es almacenada por los UA y los servidores proxy pueden ser mantenidos en un modo sin estado.

En el documento de Mauricio et al, "Hacia un Núcleo Sin Estado: Mejorar la Escalabilidad de Proxy SIP", IEEE Globecom, noviembre de 2006, propone un algoritmo que permite a un servidor proxy decidir en base a cada solicitud si una solicitud determinada debería ser manejada en un modo sin estado o en un modo con estado. El cambio del tipo proxy se realiza sobre la base de las condiciones de carga de la red.

El borrador de Internet de IETF Veltri et al. "Extensiones SIP para soporte QoS", octubre de 2002, propone dos variantes, una variante sin estado y una variante con estado, del denominado protocolo Q -SIP. De manera similar a RFC3261, no se refiere al problema de cambio de los estados proxy.

El documento de Singh et al. "Conmutación automática, carga compartida y arquitectura del servidor en la telefonía SIP", Computer Communications, Elsevier, Amsterdam, Países Bajos, vol. 30, número 5, 20.02.2007, páginas 927 942, se centra en la descripción de las técnicas de conmutación automática y de carga compartida para servidores proxy SIP. Los servidores proxy están configurados de tal manera que en primer lugar tratan de procesar una solicitud en un modo sin estado y, si una solicitud no puede ser realizada con el proxy sin estado, vuelve a un modo con estado.

La presente invención proporciona un proxy con la capacidad de alterar su tipo y utilizar preferiblemente el tipo proxy más eficiente. Estos y otros objetivos de la invención se consiguen por medio de las características de las reivindicaciones independientes adjuntas.

El problema anterior es superado por un proxy para un protocolo de señalización, comprendiendo el proxy un componente de un modo de señalización de proxy con contexto completo y un componente de una señalización de modo de señalización de proxy sin contexto. El proxy comprende, además, un medio de control para cambiar entre el modo de operación sin contexto y el modo de operación con contexto completo, y viceversa. Además, se proporciona un protocolo de evaluación de medios para evaluar las solicitudes de protocolo recibidas. El medio de evaluación de protocolo está configurado para detectar la recepción de una solicitud de cambio de modo de proxy y para señalizar al medio de control para que cambie el modo de proxy en función de la solicitud de cambio de modo de proxy recibida.

La presente invención permite utilizar inicialmente un proxy SIP sin estado, ya que es más eficiente en el procesamiento de las peticiones SIP posteriores. La invención proporciona una funcionalidad que conduce a la utilización óptima de los recursos (proxy sin estado) mientras que al mismo tiempo tiene una elevada flexibilidad (B2BUA) al poder conmutar entre ambas bajo demanda.

Preferiblemente, el protocolo de señalización es el Protocolo de Inicialización de Sesión (SIP). Sin embargo, la invención no está limitada a este protocolo y se puede emplear con otros protocolos en los que los proxy pueden operar en un modo de operación con contexto completo y en un modo de operación sin contexto. Un modo de operación sin contexto de un proxy de señalización no mantiene un estado de sesión o contexto de sesión, mientras que un modo con contexto completo mantiene un estado de sesión o un contexto de sesión. La terminación del protocolo de señalización para ambas conexiones a los AU y el mantenimiento de las asociaciones entre las terminaciones (como lo realiza el B2BUA) puede ser considerado como un caso especial de un modo de señalización con contexto completo.

Cuando se cambia a un estado con contexto completo, el proxy inicializa un contexto de sesión y establece su máquina de estado interno a un estado apropiado para la sesión. El contexto puede ser establecido mediante la aplicación de la información recibida con un mensaje de protocolo. Por ejemplo, la solicitud inicial SIP Invitar puede estar incluida en la solicitud de de cambio de proxy o transmitida por separado. En algunos casos, puede ser necesario incluir información de más mensajes en la solicitud de cambio con el fin de reconstruir correctamente el estado de sesión en el proxy. Alternativamente, el estado de sesión se sigue o se reconstruye en el UA que solicita el cambio de modo y los datos que definen el estado adecuado de la máquina de estado en el proxy se envían al servidor proxy. Por ejemplo, un mensaje que incluye una descripción del contexto de la sesión se compila en un formato en el UA y se transfiere al proxy. Se pretende que, después de inicializar el contexto de sesión, el proxy se comporte como si hubiese seguido la sesión desde el principio y correspondientemente mantiene su máquina de estado. En un caso simple, el proxy está en el mismo estado como si hubiese recibido y procesado la solicitud inicial de Invitación.

Un proxy de este tipo puede ser realizado por un dispositivo de red o implementado como un producto de software. Sirve a un dispositivo de red que comprende un medio de señalización para solicitar una transición entre los modos del proxy.

El problema anterior se resuelve, entre otras cosas, por medio de una red de telecomunicaciones que comprende tales proxy de señalización.

Y el problema anterior se resuelve por medio de un procedimiento para cambiar los modos de operación de un proxy para un protocolo de señalización entre un modo de señalización con contexto completo y un modo de señalización sin contexto. El procedimiento comprende el paso de recibir una solicitud de cambio de modo de un cliente que ordena al proxy alterar su modo de funcionamiento. En respuesta, el proxy establece un contexto basado en la solicitud recibida y altera el modo de operación de un modo a otro, dependiendo de la solicitud de cambio de modo de proxy recibida.

En otras palabras, la invención se refiere a un proxy que realiza todos los modos de operación que se han mencionado más arriba con transiciones entre los tipos de proxy de señalización y una mejora de protocolo que permite habilitar una transición. La ventaja de tener una funcionalidad para cambiar entre un proxy sin estado y un B2BUA es hacer uso de los beneficios de ambas entidades. Mientras que el proxy sin estado es menor consumidor de recursos que un B2BUA, sólo puede realizar un conjunto limitado de funciones. Sin embargo, un servidor proxy sin estado puede manejar más sesiones en paralelo a un servidor B2BUA similares, ya que no tiene que realizar el análisis SIP y el control de la máquina de estado en el mismo nivel de profundidad. Pero en muchos casos, no se puede evitar usar un B2BUA para llevar a cabo determinados servicios. Por lo tanto, la presente invención proporciona un mecanismo que permite el uso de la entidad necesaria actualmente por el cambio bajo demanda de uno a otro.

La invención se describe a continuación con referencia a realizaciones ejemplares que se ilustran esquemáticamente en las figuras que se acompañan, en las que los objetos y las características de la invención serán evidentes a partir de la descripción de las realizaciones preferidas, en las cuales

la figura 1 muestra esquemáticamente un proxy de señalización de acuerdo con una realización de la invención;

la figura 2 muestra un flujo de señalización para establecer una llamada por medio de un proxy, y

la figura 3 muestra un flujo de señalización de un ejemplo en el que un proxy sin estado se cambia a un B2BUA.

Un aspecto de la invención es una combinación de un proxy SIP sin estado y un B2BUA en el que el modo de señalización del proxy puede ser cambiado dentro de una sesión con la solicitud de un UA. Otros aspectos de la invención se refieren a las diferentes transiciones entre los proxy sin estado y con estado y los B2BUA. En general, la transición es iniciada por la recepción de un evento externo, tal como un mensaje de protocolo o solicitud, por ejemplo, una solicitud SIP.

La figura 1 ilustra esquemáticamente un proxy de señalización 1 de acuerdo con una realización de la presente invención. El proxy 1 está configurado como un proxy de señalización para SIP. El proxy de señalización 1 comprende una primera interfaz de red 2 conectada a la red de comunicación 10 y una segunda interfaz de red 3 conectada a la red de comunicación 11. Un primer elemento de red 20 está conectado a la red de comunicación 10 y puede actuar como Cliente de Agente de Usuario (UAC). Un segundo elemento de red 21 está conectado a la red de comunicación 11 y puede actuar como Servidor de Agente de Usuario (UAS). Por supuesto, más UA y redes se pueden conectar al proxy 1 que puede realizar muchas conexiones proxy entre los UA.

El proxy 1 comprende, además, un primer componente de señalización 4 para la operación en un modo de señalización proxy sin contexto, y un segundo componente de señalización 5 para la operación en un modo de señalización proxy con contexto completo. En el modo de señalización de proxy sin contexto, el proxy 1 funciona como un proxy SIP sin estado. En el modo de señalización proxy con contexto completo, el proxy funciona como un proxy SIP con estado o un B2BUA. De acuerdo con otra realización de la invención, se proporciona un tercer componente de señalización (no mostrado) que maneja la señalización como un B2BUA mientras que el segundo componente de señalización 5 opera como un proxy SIP con estado que mantiene un estado de sesión pero no finaliza el protocolo de señalización.

El proxy de señalización 1 comprende, además, una unidad de control 7 para cambiar entre el modo de operación sin contexto y el modo de operación con contexto completo y una unidad de evaluación de protocolo 6 para evaluar las solicitudes de protocolo recibidas a través de los UA por medio de las interfaces de red 2, 3. La unidad de evaluación de protocolo 6 analiza, por ejemplo, las solicitudes SIP para detectar la recepción de una solicitud de cambio de modo de proxy que ha sido enviada por un UA. Con la detección de una solicitud de cambio de modo de proxy, la unidad de evaluación de protocolo 6 señaliza a la unidad de control 7 para que cambie el modo de proxy. Dependiendo de la solicitud de cambio de modo de proxy recibida, la unidad de control 7 habilita o deshabilita los componentes de señalización primero y segundo 4, 5, respectivamente. Por ejemplo, cuando el proxy 1 se encuentra en un modo de operación sin contexto y recibe una solicitud SIP que pide un cambio a una operación con contexto completo (es decir, un proxy SIP con estado o un B2BUA), la unidad de control 7 establece un contexto de sesión, habilita el segundo componente de señalización 5, y deshabilita el primer componente de señalización 4.

La presente invención se ilustra a continuación haciendo referencia a un primer escenario en el que el proxy es iniciado al principio como un proxy sin estado en el que el proxy no registra el estado de la transacción y envía un mensaje a su destino. Después del envío, el proxy no tiene conocimiento del diálogo ni de su estado.

Si una de las partes participantes quiere ocultar información o dirigir la llamada a otro destino, le pide al proxy sin estado que cambie a un B2BUA. Para ello se establece una nueva sesión y envía un mensaje SIP al proxy.

El mensaje puede ser una solicitud estándar SIP con el procedimiento de "MENSAJE". El tipo de contenido es text / *. El contenido es el destino al que redireccionar la llamada y la solicitud inicial SIP Invitar, la cual fue enviada por el proxy sin estado.

Alternativamente, el mensaje también podría ser una nueva solicitud SIP con un mensaje no estándar. Este mensaje puede contener el nuevo destino en el encabezado de contacto SIP. Este mensaje también puede contener los mensajes anteriores en el diálogo (por ejemplo, el mensaje SIP inicial Invita) que son obligatorios para (re) construir el estado requerido del B2BUA, por ejemplo, en el contenido del mensaje como una cadena de texto.

El proxy recibe el mensaje y, dependiendo del procedimiento y del contenido del procedimiento, cambia a un B2BUA. Para ello necesita la información de sesión y el estado actual de la conexión (es decir, el contexto de la sesión), que se puede tomar del contenido del mensaje de las solicitudes anteriores, tales como la solicitud inicial de Invita. Este contenido es analizado por el Agente de Usuario que solicita el cambio de modo de funcionamiento del proxy. Un mensaje SIP puede ser creado a partir de los mensajes anteriores que han sido intercambiados entre las partes para definir el contexto de la sesión. En general, todos los mensajes que son necesarios para construir el estado requerido del proxy se deben considerar cuando se genera el mensaje SIP. En algunos casos, sin embargo, es suficiente considerar sólo el mensaje de configuración de la llamada inicial. Entonces, este nuevo mensaje corresponde a la solicitud de Invita del proxy, una vez haya sido enviado. La información de contexto es enviada preferiblemente (aunque no necesariamente) al proxy con la solicitud de cambiar el modo de operación. Cuando recibe la solicitud de cambio, el proxy sin estado anterior tiene ahora el conocimiento de la solicitud inicial y del estado de sesión. En respuesta a la recepción de la solicitud de cambio, el proxy puede actuar como que ha recibido la secuencia original de las solicitudes, tal como la solicitud de Invita. En la mayoría de los casos el mensaje inicial de Invita es suficiente para construir el estado de proxy solicitado. Actuando ahora como un B2BUA, el proxy puede crear ahora una nueva solicitud con el destino del encabezamiento de contacto de los mensajes recibidos o del contenido del mensaje recibido. Esto permite finalizar la llamada en el lado en el que se inició la solicitud de establecimiento de llamada original, e iniciar un nuevo diálogo SIP con un nuevo terminal en el lado de destino. El B2BUA conecta internamente los dos lados. En cuanto al SIP, los cambios en el lado de destino no son visibles para el emisor original de UA que todavía tiene la impresión de hablar con la parte original.

La figura. 2 muestra un flujo de señales de un escenario típico SIP en el que el elemento de red está actuando como un proxy sin estado. Las llamadas SIP solamente son transmitidas por el proxy sin estado y la sesión del medio se establece entre los puntos extremos.

En la figura 3, el proxy envía también la primera solicitud de Invita. Pero el segundo elemento envía una solicitud de "SWITCHPROXYMODE" (“CAMBIARMODODEPROXY”) para redirigir la llamada al elemento de red 3. Se debe hacer notar que esta solicitud podrá ser enviada por cualquier UA en cualquier momento después de que se haya establecido un contacto inicial entre las partes, por ejemplo, después de que la solicitud de Invita inicial se haya enviado.

La solicitud SWITCHPROXYMODE podría ser similar a:

SWITCHPROXYMOSIP: user2@providerB.SIP/2.0

CSeq: 10000 SWITCHTOB2BUA

A:

<sip: sip@serviceA.de> Max-Forwards: 69 Content-Type: text / * Via: SIP/2.0/UDP serviceA. de, branch = z9hG4bK00e0816084eb-186973221155021495638 de: "user2" <sip: user2@providerB.de>; tag = 300e0816084eb-1869732254815 ID de llamada: BE2F3645-2270-486B-B241-1F1DA19383BC @ Contact user2@providerB.de: <sip:

user2@providerC.de;transport=UDP> Content-Length: 984 INVITE sip: user2@providerB.SIP/2.0 CSeq: 29360 INVITA

A:

<sip:user2@providerB.de> Max-Forwards: 69 Content-Type: application / SDP Via: SIP/2.0/UDP serviceA.de; branch = z9hG4bK00e0816084eb-11489789339205-19591155021495888 Via: SIP/2.0/UDP providerA.de; branch = z9hG4bK00e0816084eb-186973221155021495638 Record-Route: <sip: serviceA.de;lr;oai=00e0816084eb-11489789339205> De: "user1" <sip:user1@providerA.de>; tag = 300e0816084eb-1869732254815 ID de llamada: BE2F3645 – 2270 -486B -B241 -1F1DA19383BC@149.204.84.10 User-Agent: X-PRO built 1081 Contact: <sip:149.204.84.10:5060;transport=UDP> Content-Length: 316 V= 0

o = user 3928625 3928625 IN IP4 149.204.84.10 s = X-PRO c = IN IP4 149.204.84.10 t = 0 m = audio 8000 RTP / AVP 0 8 3 4 98 97 101 a= rtpmap : 0 pcmu/8000 a= rtpmap: 8 pcma/8000 a= rtpmap : 3 gsm/8000 a= rtpmap : 4 G723/8000 a= rtpmap : 98 iLBC/8000 a = rtpmap : 97 speex/8000 a = rtpmap: 101 telephone-event/8000

a = fmtp : 101 0-15

El encabezamiento de contacto en el mensaje proporciona el destino al que enviar la nueva llamada establecida. El contenido del mensaje es la solicitud inicial, que proporciona los parámetros de sesión y el contexto de sesión.

Después de cambiar a B2BUA, el proxy puede crear una nueva llamada. Si el B2BUA recibe una respuesta a la nueva llamada, la mapea a la solicitud inicial y envía el código de respuesta.

Como se ha mencionado, un enfoque alternativo es que el procedimiento también puede ser un "mensaje" estándar y el comando de que el proxy tiene que cambiar a un B2BUA, podría estar en el contenido del mensaje.

El segundo escenario, en el que el proxy puede cambiar su modo de operación es a la inversa. Puede ser útil pasar de B2BUA a un proxy sin estado con el fin de poder realizar más llamadas en paralelo. Esto se puede conseguir más fácilmente que al revés, debido a que el B2BUA "sólo" tiene que borrar la misma sesión con toda la información de sesión almacenada. A continuación, puede actuar como un proxy sin estado.

La presente invención es particularmente útil cuando se utiliza con un Sistema de Protocolo Multimedia de Internet (IMS). Los servidores SIP y los proxy en IMS tienen varias funciones y se les llama Función de Control de Sesión de Llamada y procesan los paquetes de señalización SIP en el IMS. Un P-CSCF (Proxy-CSCF) es un proxy SIP que es el primer punto de contacto para el terminal IMS. Puede estar localizado ya sea la red visitada o en la red doméstica. Algunas redes pueden utilizar un Controlador de Borde de Sesión para esta función. El terminal descubrirá su P-CSCF. El P-CSCF está asignado a un terminal IMS durante el registro, y no cambia durante la duración del registro. Se encuentra en el trayecto de todos los mensajes de señalización, y puede inspeccionar cada mensaje. Autentica al usuario y establece una asociación de seguridad con el terminal IMS. Esto evita los ataques de suplantación y los ataques de repetición y protege la privacidad del usuario. Otros nodos confían en el P-CSCF, y no tienen que autenticar al usuario de nuevo. También puede comprimir y descomprimir los mensajes SIP, lo cual reduce el desplazamiento de ida y vuelta sobre un enlace de radio lento. El P-CSCF puede incluir una Función de Decisión de Política, que autoriza recursos de plano medio, por ejemplo, calidad de servicio (QoS) sobre el plano medio. Se utiliza para el control de política, gestión de ancho de banda, etc. También genera registros de cargos. Un S-CSCF (Servidor-CSCF) es el nodo central del plano de señalización. Es un servidor SIP, pero también realiza el control de la sesión. Siempre se encuentra localizado en la red doméstica. Maneja el registro SIP, lo cual le permite unir la localización del usuario y la dirección SIP. El S-CSCF se encuentra en el trayecto de todos los mensajes de señalización, y puede inspeccionar cada mensaje. Decide a qué servidor o servidores de aplicaciones se enviarán el mensaje SIP, con el fin de proporcionar sus servicios. Ofrece servicios de encaminamiento, impone la política del operador de red. Puede haber múltiples S-CSCF en la red para la distribución de la carga y por motivos de alta disponibilidad. Un I-CSCF (Interrogando-CSCF) es otra función SIP situada en el borde de un dominio administrativo. Se publica de manera que los servidores remotos lo puedan encontrar, y utilizarlo como punto de envío. El I-CSCF recupera la localización del usuario, y a continuación encamina la solicitud SIP a su S-CSCF asignado.

Otra aplicación útil de la invención se refiere a la movilidad de soporte de un P-CSCF que es responsable de localizar al S-CSCF o I-CSCF responsable cuando recibe un mensaje de registro. En esta función, el P-CSCF normalmente es operado como un proxy sin estado. Si un usuario registra ahora un segundo dispositivo de usuario en el P-CSCF, es ventajoso cambiar el P-CSCF de este usuario a un modo de operación con estado. Esto proporciona una funcionalidad del terminal sin problemas, que permite al usuario cambiar entre ambos terminales en una llamada en curso sin que sea reconocible por la otra parte. En este ejemplo, la solicitud de cambio puede ser originada por el S-CSCF.

La presente invención tiene muchas aplicaciones útiles adicionales. Los ejemplos anteriores se presentan sólo como ilustración y no limitarán el alcance de la invención como se define en las reivindicaciones adjuntas.

Claims (9)

1. REIVINDICACIONES

   1.

   Un proxy (1) para un protocolo de señalización, que comprende un componente de un modo de señalización de proxy con contexto completo (5) y un componente de un modo de señalización de proxy sin contexto (4), incluyendo el componente de un modo de señalización de proxy con contexto completo (5) una máquina de estado en el proxy y manteniendo un estado o contexto de sesión completo para una sesión, no manteniendo el componente para un modo de señalización de proxy sin contexto (4) un estado de sesión o contexto de sesión, comprendiendo, además, el proxy un medio de control (7) para cambiar entre el modo de operación sin contexto y el modo de operación con contexto completo y un medio de evaluación de protocolo (6) para evaluar las solicitudes de protocolo recibidas, en el que el medio de evaluación de protocolo (6) está configurado para detectar la recepción de una solicitud de cambio de modo de proxy y para señalizar al medio de control (7) para cambiar el modo de proxy en función de la solicitud de cambio de modo de proxy recibida, habilitando o deshabilitando el medio de control (7) a los componentes (5, 4) para el modo de señalización de proxy con contexto completo o sin contexto, dependiendo de la solicitud de cambio de modo de proxy recibida, en el que la solicitud de cambio de modo es recibida después de que una sesión entre dos elementos de la red se haya establecido y la solicitud de cambio de modo relacionada con el cambio de modo de operación del proxy para la sesión abierta, y en el que se inicializa un contexto de sesión y la máquina de estado en el proxy se establece cuando se cambia al modo de operación con contexto completo.

2. 2.

   El proxy de acuerdo con la reivindicación 1, que se caracteriza porque el protocolo es el protocolo de inicio de sesión, SIP.

3. 3.

   El proxy de acuerdo con la reivindicación 2, que se caracteriza porque el componente de un modo de señalización de proxy con contexto completo implementa un agente de usuario de reverso a reverso.

4. 4.

   El proxy de acuerdo con la reivindicación 1, que se caracteriza porque comprende un medio la inicialización para definir un contexto de sesión cuando se cambia del modo sin contexto al modo con contexto completo mediante la aplicación de los valores por defecto, o mediante el uso de la información recibida con un mensaje de protocolo.

5. 5.

   El proxy de acuerdo con la reivindicación 4, en el que el medio de inicialización define el contexto de sesión como si el proxy hubiese recibido la secuencia original de las solicitudes, incluyendo la solicitud inicial SIP de Invitar.

6. 6.

   Un sistema que comprende:

   un proxy de acuerdo con la reivindicación 1, y un dispositivo de red;

   el citado dispositivo de red se caracteriza porque comprende un medio de señalización para enviar una solicitud de cambio de modo de proxy para el proxy que solicita una transición entre los modos de proxy de acuerdo con la reivindicación 1.
7. 7. Un procedimiento para cambiar los modos de operación de un proxy entre un modo de señalización sin contexto y un modo de señalización con contexto completo, incluyendo el proxy una máquina de estado y manteniendo un estado o contexto de sesión completo para una sesión cuando se opera en el modo de señalización con contexto completo, no manteniendo el proxy un estado de sesión o contexto de sesión cuando opera en el modo de señalización de proxy sin contexto, que comprende las etapas de:

   recibir una solicitud de cambio de modo de proxy de un cliente;

   establecer un contexto de sesión en base a la citada solicitud solicitud, y

   alterar el modo de funcionamiento del proxy desde un modo de señalización a otro por el proxy dependiendo de la solicitud de cambio de modo de proxy recibida,

   en el que la solicitud de cambio de modo de proxy se recibe después de que una sesión entre dos elementos de la red se haya establecido y la solicitud de cambio de modo de proxy se relaciona con el cambio de modo de operación en el proxy para la sesión abierta, y en el que la máquina de estado en el proxy se establece cuando cambia al modo de señalización con contexto completo.
8. 8. El procedimiento de la reivindicación 7, que comprende los siguientes pasos antes del paso de recepción:

   recibir una solicitud para establecer una conexión con un elemento de red, y

   enviar la solicitud al elemento de red.
9. 9. Un producto de software informático que incluye un código legible por ordenador para hacer que un proxy lleve a cabo el procedimiento de la reivindicación 7 cuando se ejecuta en el proxy.