ES2373357T3 - Técnica para realizar la conversión de señalización entre los dominios http y sip. - Google Patents

Técnica para realizar la conversión de señalización entre los dominios http y sip. Download PDF

Info

Publication number
ES2373357T3
ES2373357T3 ES08873006T ES08873006T ES2373357T3 ES 2373357 T3 ES2373357 T3 ES 2373357T3 ES 08873006 T ES08873006 T ES 08873006T ES 08873006 T ES08873006 T ES 08873006T ES 2373357 T3 ES2373357 T3 ES 2373357T3
Authority
ES
Spain
Prior art keywords
http
sip
message
request message
http request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES08873006T
Other languages
English (en)
Inventor
Ioannis Fikouras
Nikolaos Albertos Fikouras
Roman Levenshteyn
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2373357T3 publication Critical patent/ES2373357T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/142—Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Reduction Or Emphasis Of Bandwidth Of Signals (AREA)

Abstract

Un método para realizar la conversión de señalización entre una sesión de estado del Protocolo de Transferencia Hipertexto, o HTTP, y un diálogo del Protocolo de Inicio de Sesiones, o SIP, caracterizado por: - recibir desde una entidad habilitada con HTTP un primer mensaje de petición HTTP, el primer mensaje de petición HTTP que incluye la información de estado HTTP; - crear un primer mensaje SIP en respuesta a la recepción del primer mensaje de petición HTTP, el primer mensaje SIP que pertenece a un diálogo SIP; - enviar el primer mensaje SIP a una entidad habilitada con SIP; y - establecer una asignación entre la información de estado HTTP y el diálogo SIP.

Description

Tecnica para realizar la conversi6n de senalizaci6n entre los dominios HTTP y SIP
Campo tecnico
La presente invenci6n se refiere de manera general a la conversi6n de senalizaci6n entre los dominios HTTP y SIP. 5 En particular, la invenci6n se dirige a una tecnica de conversi6n que permite una comunicaci6n de estado entre los dos dominios.
Antecedentes
En la actualidad, el Protocolo de Transporte de HiperTexto (HTTP) constituye el medio principal para la entrega de contenido en la Web a nivel Mundial (WWW). El HTTP es un protocolo de capa de aplicaciones sin estado, basado
10 en texto que define un mecanismo de intercambio de mensajes basado en petici6n/respuesta entre un cliente HTTP y un servidor HTTP. En el modelo cliente-servidor HTTP, una petici6n HTTP se emite por un Cliente de Agente de Usuario HTTP, mientras que la respuesta HTTP a la petici6n llega desde un Servidor de Agente de Usuario HTTP.
La demanda creciente de servicios WWW personalizados ha llevado al desarrollo de sesiones de estado HTTP que comprenden dos o mas (nominalmente independientes) parejas de mensajes de petici6n y respuesta HTTP.
15 Actualmente, los planteamientos dominantes para la administraci6n de sesi6n HTTP son las cookies, los parametros en los Localizadores de Recursos Universales (URL) HTTP y los denominados URL gruesos.
En cuanto a las cookies, el memorando RFC2965 publicado por el Grupo de Trabajo de Ingenieria de Internet (IETF) y titulado "Mecanismo de Gesti6n de Estado HTTP" propone varias cabeceras HTTP capaces de transportar la informaci6n de estado entre los puntos finales de un intercambio de mensajes de petici6n-respuesta HTTP. Las 20 cookies se definen como Pares de Valores de Atributos (AVP) de nombres y valores arbitrarios que se pueden acompanar por una gama de parametros predefinidos como se describe en la RFC2965. En un mensaje de petici6n
o respuesta HTTP unico, se pueden incluir una o mas cookies segun se requiera.
Un ejemplo de una petici6n HTTP que contiene cookies es el siguiente:
GET URI HTTP/1.1
25 Cookie: dialog-id=ali2alice1;method=bye
Esta petici6n HTTP contiene dos cookies que identifican colectivamente el estado actual de una sesi6n. La primera cookie define el atributo 'dialog-id' como 'ali2alice1', mientras que la segunda cookie asigna al atributo 'method' el valor 'bye'.
Otra posibilidad para conservar la informaci6n de estado HTTP son los parametros HTTP y los componentes de
30 consulta. Es bien conocido que los esquemas URL basan su sintaxis URL en un formato general de nueve partes (ver RFC2396):
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
Usando este formato, es posible transportar la informaci6n de estado de sesi6n a aplicaciones de red remotas o bien como parametros o bien como componentes de consulta. Los listados de c6digo siguientes ilustran dos peticiones
35 HTTP de un cliente HTTP para entregar la informaci6n de estado de sesi6n a un servidor HTTP.
Senalando la informaci6n de estado de sesi6n como parametros HTTP:
GET path;dialog-id=ali2alice1;method=bye HTTP/1.1 host: URI
Senalando la informaci6n de estado como componentes de consulta HTTP:
GET path?dialog-id=ali2alice1&amp;method=bye HTTP/1.1 host: URI
40 En ambos casos el servidor HTTP es informado de que los valores actuales para los atributos 'dialog-id' y 'method' son 'ali2alice1' y 'bye', respectivamente.
Los URL gruesos son versiones extendidas de los URL, anadidos sufijos con informaci6n usada para identificar el estado actual de una sesi6n HTTP. La siguiente petici6n HTTP ilustra c6mo se puede incluir la informaci6n de estado en la indicaci6n del trayecto en un URL:
45 GET path/dialog-id=ali2alice1/method=bye HTTP/1.1 host: URI
En el ejemplo anterior, el cliente HTTP emite una petici6n a un servidor HTTP que es consciente de que los ultimos dos segmentos del trayecto corresponden a la informaci6n de estado de sesi6n. En este caso particular, el atributo 'dialog-id' es equivalente a 'ali2alice1' y el atributo 'method' es equivalente a 'bye'.
Mientras que HTTP constituye el medio principal para la distribuci6n de contenido en la WWW, el Protocolo de Inicio de Sesiones (SIP) es el protocolo de senalizaci6n principal en el plano de control del IMS (Subsistema Multimedia del Protocolo Internet) y otras redes de aprovisionamiento de servicios. SIP es un protocolo basado en texto usado para autorizar el acceso de usuario asi como establecer, controlar y terminar las sesiones de medios entre las aplicaciones alojadas por los puntos finales habilitados SIP.
Similar a HTTP, SIP se basa en la transmisi6n de mensajes de petici6n y respuesta. Estos mensajes se intercambian entre los Agentes de Usuario instalados en los puntos finales SIP de comunicaci6n. Un Agente de Usuario SIP puede actuar o bien como un Cliente de Agente de Usuario (cuando envia un mensaje de petici6n) o bien como un Servidor de Agente de Usuario (cuando responde al mensaje de petici6n con un mensaje de respuesta).
SIP define que solamente se puedan establecer una o mas sesiones de medios entre dos puntos finales SIP dentro del contexto de un dialogo SIP. El dialogo es una relaci6n conceptual entre los puntos finales SIP implicados que se mantiene por la Capa de Usuario de Transacci6n de las Capas de Protocolo SIP. En la practica, un dialogo se manifiesta como una colecci6n de informaci6n que refleja el estado actual del dialogo para cada punto final. Como se entiende aqui dentro, cada dialogo SIP comprende una o mas transacciones SIP, y cada transacci6n SIP implica uno o mas mensajes (tipicamente un mensaje de petici6n y uno o mas mensajes de respuesta). En este sentido, cada mensaje SIP se puede ver como parte de una transacci6n SIP.
Cada dialogo SIP se identifica por un identificador (el denominado ID de dialogo) que esta formado por una serie de atributos negociados entre los puntos finales SIP durante el inicio de una sesi6n y que permanecen validos durante el tiempo de vida del dialogo. Especificamente, el ID del dialogo de un dialogo entre un Cliente de Agente de Usuario y un Servidor de Agente de Usuario (los dos puntos finales de un dialogo SIP) se definen como:
Dialog (-ID) - call-ID, local tag (To-header tag of dialog response), remote tag (From-header tag of dialog request)
El SIP y los Identificadores de Recursos Universales (URI) de SIP siguen las pautas fijadas por la RFC2396. La forma general de un URI SIP como se define en la RFC3261 tiene la siguiente sintaxis:
sip:user:password@host:port;uri-parameters?headers
La estructura URI SIP permite la inclusi6n de varios parametros y cabeceras dentro de su forma generica.
Mientras que HTTP es el protocolo estandar para la entrega de contenido en la WWW, no existe actualmente soluci6n documentada o implementada que permitiria al equipo de usuario habilitado con HTTP iniciar, conducir y terminar sesiones con un Agente de Usuario SIP.
La EP 1093281 describe metodos para la conversi6n del Lenguaje de Marcado de Hipertexto (HTML) -SIP. En un metodo para convertir HTML a SIP, un Agente de Usuario SIP recibe un mensaje HTML, analiza sintacticamente el mensaje HTML para la clase y contenido, y analiza la clase y contenido para crear una senal SIP a partir del mensaje HTML. La senal SIP se envia a un intermediario SIP. Igualmente, se describe un metodo de conversi6n de una senal SIP en un mensaje HTML. Un Agente de Usuario SIP recibe la senal SIP desde un intermediario SIP, analiza sintacticamente la senal SIP para el tipo de mensaje y extrae el contenido, la parte que llama, y la parte llamada. Usando la informaci6n extraida, el Agente de Usuario SIP genera un mensaje HTML y envia el mensaje HTML a la parte llamada.
Resumen
Por consiguiente, hay una necesidad para permitir una conversi6n de senalizaci6n eficiente entre los dominios HTTP y SIP que preserve el concepto de sesi6n.
De acuerdo con un primer aspecto, se proporciona un metodo de realizar la conversi6n de senalizaci6n entre una sesi6n de estado HTTP y un dialogo SIP, que comprende recibir desde una entidad habilitada con HTTP un primer mensaje de petici6n HTTP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP; crear un primer mensaje SIP en respuesta a la recepci6n del primer mensaje de petici6n HTTP, el primer mensaje SIP que pertenece a un dialogo SIP; enviar el primer mensaje SIP a una entidad habilitada con SIP; y establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP, como en la reivindicaci6n 1.
La informaci6n de estado HTTP puede tener cualquier formato y contenido. En una implementaci6n, la informaci6n de estado HTTP toma la forma de una cadena de caracteres alfanumericos que es unica al menos localmente (por ejemplo, entre los componentes de red que controlan la transferencia del mensaje descrita aqui dentro).
La asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP se puede realizar en una interfaz entre un dominio HTTP que comprende una o mas entidades habilitadas HTTP y un dominio SIP que comprende una o mas entidades habilitadas SIP. Especificamente, se puede usar la asignaci6n para ligar la senalizaci6n relacionada con la sesi6n que se origina o termina en el dominio SIP con la senalizaci6n relacionada con la sesi6n que se origina o
termina en el dominio HTTP. Para este fin, la asignaci6n se puede establecer, consultar y/o actualizar cada vez que un mensaje previsto para el dominio SIP llega desde el dominio HTTP, y viceversa. Como resultado, la asignaci6n puede formar la base para que cualquier entidad habilitada con HTTP inicie, acepte, conduzca y termine una o mas sesiones con una entidad habilitada con SIP (por ejemplo una entidad habilitada IMS tal como un abonado IMS o un servidor de aplicaciones IMS), y viceversa.
Las tecnicas tratadas aqui dentro se pueden realizar en contexto con un dialogo SIP que ya se ha establecido (por ejemplo, para el cual uno o mas mensajes ya se han intercambiado entre la entidad habilitada con HTTP y la entidad habilitada con SIP). Alternativamente, las tecnicas tambien se pueden realizar en contexto con un dialogo SIP que esta a punto de ser establecido (por ejemplo, para el cual solamente la entidad habilitada con HTTP y la entidad habilitada con SIP han transmitido hasta el momento un mensaje con el prop6sito de establecer un dialogo).
Como se estableci6 anteriormente, el primer mensaje SIP se crea en respuesta a la recepci6n del primer mensaje de petici6n HTTP. Ademas en respuesta a la recepci6n del primer mensaje de petici6n HTTP, un primer mensaje de respuesta HTTP se puede enviar a la entidad habilitada con HTTP. El primer mensaje de respuesta HTTP opcionalmente puede incluir o referenciar la informaci6n de estado HTTP a traves del primer mensaje de petici6n HTTP.
El metodo ademas comprende los pasos de recibir un segundo mensaje SIP; determinar el dialogo SIP al cual pertenece el segundo mensaje SIP; determinar la informaci6n de estado HTTP asociada con el dialogo SIP; generar un segundo mensaje de petici6n HTTP que incluye o referencia la informaci6n de estado HTTP determinada de esta manera; y enviar el segundo mensaje de petici6n HTTP a la entidad habilitada con HTTP.
Adicionalmente, un segundo mensaje de respuesta HTTP en respuesta al segundo mensaje de petici6n HTTP se puede recibir desde la entidad habilitada con HTTP. El segundo mensaje de respuesta HTTP opcionalmente puede incluir o referenciar la informaci6n de estado HTTP.
En base a la informaci6n de estado HTTP, la pareja de primeros mensajes de petici6n y respuesta HTTP asi como la pareja de segundos mensajes de petici6n y respuesta HTTP se pueden agrupar en una sesi6n de estado HTTP. En otras palabras, asociando la informaci6n de estado HTTP (o la informaci6n unicamente derivada de alli o que referencia a la misma) con dos o mas parejas de mensajes de petici6n y respuesta HTTP, las parejas de mensajes se pueden clasificar como pertenecientes a una sesi6n especifica que se extiende entre el dominio HTTP y el dominio SIP.
El primero o cualquier mensaje de petici6n HTTP posterior ademas puede incluir la informaci6n de direcci6n indicativa de un Agente de Usuario SIP de la entidad habilitada con SIP. La informaci6n de direcci6n incluida en el primer mensaje de petici6n HTTP se puede usar para dirigir el primer mensaje SIP al Agente de Usuario SIP. Para este fin, la informaci6n de direcci6n se puede escribir (por ejemplo, copiar) en el primer mensaje SIP.
El primero o cualquier mensaje de petici6n HTTP posterior ademas puede incluir la informaci6n de dialogo HTTP. La informaci6n de dialogo HTTP y la informaci6n de dialogo SIP pueden cada una identificar unicamente un dialogo especifico relacionado con la sesi6n entre al menos una entidad habilitada con HTTP y al menos una entidad habilitada con SIP. En algunos casos, uno y el mismo identificador puede constituir simultaneamente la informaci6n de dialogo HTTP y la informaci6n de dialogo SIP, de manera que una asignaci6n llegaria a estar obsoleta y un simple almacenamiento de este identificador seria suficiente. Junto con la informaci6n de dialogo HTTP y/o SIP, se puede almacenar la informaci6n acerca del estado actual del dialogo especifico. Este planteamiento permite buscar el estado actual de cualquier dialogo en base a la informaci6n de dialogo HTTP y/o SIP. Tal busqueda se puede realizar en contexto con la construcci6n de uno o mas mensajes SIP para continuar, modificar o terminar el dialogo.
De acuerdo aun con una posibilidad adicional, el primero o cualquier mensaje de petici6n HTTP posterior puede incluir informaci6n de descripci6n de sesiones tal como la informaci6n de acuerdo con el estandar del Protocolo de Descripci6n de Sesiones (SDP). La informaci6n de descripci6n de sesiones se puede enviar, por ejemplo, en un contexto de ofrecimiento/contestaci6n SDP. En el caso que el primer mensaje de petici6n HTTP incluya informaci6n de descripci6n de sesiones, esta informaci6n se puede reenviar a traves del primer mensaje SIP a la entidad habilitada con SIP. En otras palabras, la informaci6n de descripci6n de sesiones recibida a traves del primer mensaje de petici6n HTTP se puede incluir (por ejemplo, copiar) en el primer mensaje SIP.
Existen varias posibilidades para insertar la informaci6n de estado HTTP en al menos uno del primer mensaje de petici6n HTTP y el segundo mensaje de petici6n HTTP. De acuerdo con una primera variante, las cookies HTTP se usan para transportar la informaci6n de estado. De acuerdo con una segunda variante, se transmite la informaci6n de estado en forma de un URL grueso. Como una variante adicional, se puede mencionar la utilizaci6n de los parametros y los componentes de consulta HTTP. Dos o mas de estas variantes se pueden combinar segun se necesite.
El primer mensaje de petici6n HTTP puede incluir una indicaci6n de mensaje SIP que permite al destinatario del primer mensaje de petici6n HTTP identificar el tipo de mensaje SIP que va a ser creado. La indicaci6n del mensaje SIP puede referirse directa o indirectamente a cualquier metodo SIP tal como INVITE, ACK, BYE, CANCEL, OPTIONS, REGISTER e INFO. De acuerdo con otra variante, la indicaci6n del mensaje SIP puede referirse directa o
indirectamente a un c6digo SIP tal como cualquiera de los siguientes (u otros) c6digos de respuesta: 1xx Informational (por ejemplo, 100 Trying, 180 Ringing), 2xx Successful (por ejemplo, 200 OK, 202 Accepted), 3xx Re-Direction, 4xx Request Failure, 5xx Server Failure, y 6xx Global Failure. De acuerdo con una variante adicional, la indicaci6n del mensaje SIP puede referirse directa o indirectamente a un c6digo de estado HTTP que se puede traducir en un c6digo SIP o metodo SIP correspondiente.
De acuerdo con un aspecto adicional, se proporciona un metodo de realizaci6n de la conversi6n de senalizaci6n entre un dialogo SIP y una sesi6n de estado HTTP, que comprende recibir desde una entidad habilitada con SIP un primer mensaje SIP, el primer mensaje SIP que pertenece a un dialogo SIP; establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP; crear un primer mensaje de petici6n HTTP indicativo de un contenido del primer mensaje SIP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP que se asigna en el dialogo SIP; y enviar el primer mensaje de petici6n HTTP a una entidad habilitada con HTTP, como en la reivindicaci6n 8.
El metodo puede comprender ademas recibir un primer mensaje de respuesta HTTP en respuesta al primer mensaje de petici6n HTTP desde la entidad habilitada con HTTP. El primer mensaje de respuesta HTTP opcionalmente puede incluir o referenciar la informaci6n de estado HTTP recibida por la entidad habilitada con HTTP a traves del primer mensaje de petici6n HTTP.
Aun ademas, el metodo puede comprender los pasos de recibir un segundo mensaje de petici6n HTTP que incluye la informaci6n de estado y, opcionalmente, que incluye una indicaci6n de mensaje SIP indicativa de un segundo mensaje SIP que va a ser creado; determinar el dialogo SIP asignado en la informaci6n de estado HTTP; crear un segundo mensaje SIP en respuesta a la recepci6n de un segundo mensaje de petici6n HTTP en base al dialogo SIP determinado (y opcionalmente en base a la indicaci6n del mensaje SIP si esta disponible); y enviar el segundo mensaje SIP a la entidad habilitada con SIP. Ademas, un segundo mensaje de respuesta HTTP se puede devolver a la entidad habilitada con HTTP en respuesta al segundo mensaje de petici6n HTTP. El segundo mensaje de respuesta HTTP opcionalmente puede incluir o referenciar la informaci6n de estado HTTP.
En base a la informaci6n de estado HTTP, la pareja de primeros mensajes de petici6n y respuesta HTTP asi como la pareja de segundos mensajes de petici6n y respuesta HTTP se pueden agrupar en la sesi6n de estado HTTP. En otras palabras, mientras que HTTP como tal es sin estado, la inclusi6n de la informaci6n de estado HTTP en al menos los mensajes de petici6n HTTP (y opcionalmente tambien en los mensajes de respuesta correspondientes) permite extender el paradigma de sesi6n de estado del dominio SIP en el dominio HTTP.
La informaci6n de estado HTTP se puede generar (por ejemplo, en respuesta a la recepci6n del primer mensaje SIP) por cualquiera de los componentes de red implicados en el intercambio del mensaje. Si, por ejemplo, la sesi6n se inicia desde el dominio HTTP (es decir, por una entidad habilitada con HTTP), la informaci6n de estado HTTP se puede generar por la entidad habilitada con HTTP y transmitir con el primer mensaje de petici6n HTTP. Si, por otra parte, la sesi6n se inicia desde el dominio SIP (es decir, por una entidad habilitada con SIP), la informaci6n de estado HTTP se puede generar por el componente de red que establece la asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP. Por supuesto, existen varias posibilidades adicionales de c6mo y d6nde se puede generar la informaci6n de estado HTTP.
La entidad habilitada con HTTP que participa en la transferencia del mensaje descrita aqui dentro puede tomar la forma de cualquier equipo de usuario, tal como un telefono m6vil, un asistente digital personal, un ordenador personal, un ordenador portatil, una tarjeta de red o datos etc. La entidad habilitada con SIP puede ser una entidad IMS tal como un servidor de aplicaciones IMS o un equipo de usuario habilitado IMS.
El dialogo SIP realizado entre la entidad habilitada con HTTP y la entidad habilitada con SIP se puede realizar en cualquier contexto de mensajeria SIP. Los posibles contextos de mensajeria SIP incluyen un contexto de registro de usuario, un contexto de inicio de sesi6n y un contexto de terminaci6n de sesi6n.
De acuerdo con otro aspecto, se proporciona un producto de programa informatico. El producto de programa informatico comprende partes de c6digo de programa para realizar uno o mas de los pasos de uno o mas de los metodos descritos aqui dentro cuando el producto de programa informatico se ejecuta en uno o mas dispositivos informaticos, como en la reivindicaci6n 14. El producto de programa informatico se puede almacenar en un medio de grabaci6n legible por ordenador tal como una memoria permanente o re escribible, un CD-ROM, o un DVD. El producto de programa informatico tambien se puede proporcionar por descarga a traves de una o mas redes informaticas tales como Internet, una red de telecomunicaciones celular o una Red de Area Local (LAN) inalambrica
o cableada.
De acuerdo aun con un aspecto adicional, se proporciona un aparato para realizar la conversi6n de senalizaci6n entre una sesi6n de estado HTTP y un dialogo SIP, como en la reivindicaci6n 16. El aparato comprende un Agente de Usuario HTTP adaptado para recibir desde una entidad habilitada con HTTP un primer mensaje de petici6n HTTP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP; un Agente de Usuario SIP adaptado para enviar un primer mensaje SIP a una entidad habilitada con SIP en respuesta a la recepci6n del primer mensaje de petici6n HTTP, el primer mensaje de petici6n SIP que pertenece a un dialogo SIP; y una l6gica de asignaci6n adaptada para establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP. El aparato se puede configurar para realizar cualquier de los aspectos del metodo tratados aqui dentro.
El Agente de Usuario SIP u otro componente del aparato se puede configurar tambien para crear el primer mensaje SIP. Ademas, el Agente de Usuario HTTP se puede adaptar para devolver un primer mensaje de respuesta HTTP a la entidad habilitada con HTTP.
Un aparato adicional para realizar la conversi6n de senalizaci6n entre un dialogo SIP y una sesi6n de estado HTTP comprende un Agente de Usuario SIP adaptado para recibir desde una entidad habilitada con SIP un primer mensaje SIP, el primer mensaje SIP que pertenece a un dialogo SIP; una l6gica de asignaci6n adaptada para establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP; y un Agente de Usuario HTTP adaptado para enviar un primer mensaje de petici6n HTTP indicativo de un contenido del primer mensaje SIP a una entidad habilitada con HTTP, el primer mensaje de petici6n HTTP que incluye o que referencia la informaci6n de estado HTTP asignada en el dialogo SIP, como en la reivindicaci6n 18. El aparato se puede configurar para realizar cualquiera de los aspectos del metodo tratados aqui dentro.
El Agente de Usuario HTTP u otro componente del aparato se puede adaptar tambien para crear el primer mensaje de petici6n HTTP. El Agente de Usuario HTTP se puede adaptar ademas para recibir un primer mensaje de respuesta HTTP en respuesta al primer mensaje de petici6n HTTP desde la entidad habilitada con HTTP.
Cualquiera de los aparatos descritos aqui dentro se pueden configurar como un nodo de red intermedio que interconecta (o que puentea) un dominio HTTP por un lado y el dominio SIP por el otro. En una posible implementaci6n, el aparato se configura como un intermediario Web.
Breve descripcion de los dibujos
A continuaci6n, la presente invenci6n se describira en mas detalle con referencia a las realizaciones ejemplares ilustradas en los dibujos, en los cuales:
La Fig. 1 ilustra esquematicamente una infraestructura de red que comprende una realizaci6n del nodo de red;
La Fig. 2 es un diagrama de bloques que ilustra los componentes internos de la realizaci6n del nodo de red;
La Fig. 3 es un diagrama de senalizaci6n esquematico que ilustra un mecanismo de senalizaci6n basico que implica la realizaci6n del nodo de red de la Fig.2;
La Fig. 4 ilustra esquematicamente la arquitectura de los componentes l6gicos de un componente de Agente de Usuario HTTP de la realizaci6n del nodo de red ilustrado en la Fig. 2;
La Fig. 5 es un diagrama de senalizaci6n esquematico que ilustra la senalizaci6n de inicio de sesi6n;
La Fig. 6 ilustra una realizaci6n de una tabla de estado de dialogo segun se mantiene por el nodo de red mostrado en la Fig. 4;
La Fig. 7 ilustra una realizaci6n de una tabla de resoluci6n de dialogo;
La Fig. 8 ilustra una realizaci6n de una tabla de recuento de transacciones;
La Fig. 9 es un diagrama de senalizaci6n esquematico que ilustra en mas detalle algunos aspectos de la senalizaci6n de inicio de sesi6n;
La Fig. 10 es un diagrama de senalizaci6n esquematico que ilustra genericamente la senalizaci6n en contexto con la aceptaci6n de una invitaci6n de sesi6n;
La Fig. 11 es un diagrama de senalizaci6n esquematico adicional que ilustra en mas detalle algunos aspectos de la aceptaci6n de una invitaci6n de sesi6n;
La Fig. 12 es un diagrama de senalizaci6n esquematico que ilustra una primera variante de la senalizaci6n de terminaci6n de sesi6n;
La Fig. 13 es un diagrama de senalizaci6n esquematico que ilustra una segunda variante de la senalizaci6n de terminaci6n de sesi6n;
La Fig. 14 es un diagrama de senalizaci6n esquematico que ilustra la senalizaci6n de registro de la Pasarela de Confianza;
La Fig. 15 ilustra una realizaci6n de una tabla de abonado;
La Fig. 16 ilustra una realizaci6n de una tabla de registro.
Descripcion detallada
En la siguiente descripci6n, para prop6sitos de explicaci6n y no de limitaci6n, se establecen en adelante detalles especificos tales como las configuraciones de red especificas y los escenarios de senalizaci6n especificos para proporcionar una comprensi6n minuciosa de las tecnicas reveladas aqui dentro. Sera evidente para un experto en la tecnica que las tecnicas se pueden practicar en otras realizaciones sin salir de estos detalles especificos. Por ejemplo, los expertos apreciaran que las tecnicas tratadas aqui dentro se pueden practicar en combinaci6n con otras configuraciones de red y distintos pasos de senalizaci6n. Ademas, mientras que las realizaciones siguientes se describiran en primer lugar en relaci6n con las entidades IMS habilitadas SIP, sera facilmente evidente que las tecnicas descritas aqui dentro tambien se pueden practicar en contexto con las entidades habilitadas SIP que no son compatibles con el estandar IMS.
Aquellos expertos en la tecnica apreciaran ademas que los metodos, pasos y funciones explicadas aqui dentro se pueden implementar usando circuiteria de componentes fisicos individual, usando componentes l6gicos que funcionan en conjunto con un microprocesador programado u ordenador de prop6sito general, usando un Circuito Integrado de Aplicaciones Especificas (ASIC) y/o usando uno o mas Procesadores de Senal Digitales (DSP). Tambien se apreciara que, mientras que las siguientes realizaciones se describiran en primer lugar en forma de metodos y aparatos, las tecnicas reveladas aqui dentro tambien se pueden integrar en un procesador informatico y una memoria acoplada al procesador, en donde la memoria se codifica con uno o mas programas que realizan los pasos tratados aqui dentro cuando se ejecutan por el procesador.
Se hace ahora referencia a la Fig. 1, la cual muestra una arquitectura de red ejemplar 100 en la cual se pueden implementar las diversas tecnicas descritas aqui dentro. La arquitectura de red 100 comprende una red IMS 102, una red de Acceso HTTP a IMS (HIAnet) 104 y varios elementos de Equipo de Usuario habilitado con HTTP (HUE)
106. En el escenario ejemplar ilustrado en la Fig. 1, los HUE 106 se configuran como telefonos m6viles.
La HIAnet 104 proporciona un nodo de red central que aloja una denominada Funci6n de Acceso HTTP a IMS (HIAF) 108. La HIAF 108 sirve a los diversos HUE 106 a traves de los enlaces de red basados en HTTP y al mismo tiempo mantiene un enlace de red basado en SIP con la red IMS 102. La HIAF 108 de esta manera interactua o interviene entre la pluralidad de los HUE 106 por una parte y la red IMS 102 por otra parte.
La red IMS 102 comprende una pluralidad de nodos de red distribuidos sobre un plano de aplicaci6n, un plano de control y un plano de transporte. El plano de control incluye una pluralidad de servidores SIP e intermediarios SIP que se llaman colectivamente Funciones de Control de Sesi6n de Llamada (CSCF) y que se usan para procesar la senalizaci6n SIP. Una CSCF Intermediaria (P-CSCF) 110 es un intermediario SIP que constituye el primer punto de contacto para las entidades habilitadas IMS externas tales como telefonos m6viles. La P-CSCF 110 se asigna a una entidad habilitada IMS durante el registro y proporciona servicios de autentificaci6n. Una CSCF de Servicio (S-CSCF) 112 es el nodo central del plano de control. Es un servidor SIP pero tambien realiza el control de sesi6n. Las tareas principales de la S-CSCF 112 incluyen el manejo de registros SIP y la selecci6n de un Servidor de Aplicaciones (AS) 114 que va a proporcionar un servicio requerido. Una CSCF de Interrogaci6n (I-CSCF) 116 es otra funci6n SIP configurada para consultar a un Servidor Local de Abonado (HSS) 118 en respuesta a la recepci6n de una petici6n SIP, y para encaminar la petici6n SIP recibida a la S-CSCF asignada 112 en base a la informaci6n recuperada desde el HSS 118.
En la capa de aplicaciones, el uno o mas AS 114 alojan y ejecutan los servicios, que incluyen servicios de voz, datos y multimedia. Los AS 114 interactuan con la S-CSCF 112 a traves de la senalizaci6n SIP. El HSS 118 es un componente de la capa de aplicaciones adicional que mantiene la informaci6n relacionada con la suscripci6n (perfiles de usuario), y que participa en los procesos de autentificaci6n y autorizaci6n. La Funci6n de Recursos de Medios (MRF) 120 es un servidor de medios que proporciona las funciones relacionadas con los medios que incluyen la manipulaci6n de los medios (por ejemplo, la mezcla de secuencias de voz).
Una Funci6n de Controlador de Pasarela de Medios (MGCF) 122 es una pasarela de la Red Publica de Telefonia Conmutada (PSTN) a cargo de la conversi6n del protocolo de control de llamada entre SIP y el protocolo de la Parte de Usuario ISDN (ISUP). Una Pasarela de Medios (MGW) 124 es una pasarela PSTN adicional que se situa en la capa de transporte e interactua con el plano de medios de la PSTN realizando la conversi6n de protocolos entre el Protocolo de Transporte en Tiempo Real (RTP) como se usa en la red IMS 102 y la Modulaci6n de C6digo de Pulsos (PCM) como se usa en las PTSN de circuitos conmutados.
La red IMS 102 ademas comprende el equipo de usuario habilitado con SIP 110', 112', 116', 122', 124' que incluye los telefonos m6viles (como se ilustran esquematicamente en la Fig. 1, por ejemplo en conexi6n con la S-CSCF 112). Basicamente, la configuraci6n y operaci6n de los componentes IMS individuales tratadas anteriormente es bien conocida por las personas expertas en la tecnica, y por esta raz6n se omitira aqui una discusi6n mas detallada de las mismas a menos que sea necesario para comprender la comunicaci6n entre la red IMS 102 y la HIAF 108 de la HIAnet 104.
Como se mencion6 anteriormente, la HIAF 108 constituye el nodo de red central de la HIAnet 104. La HIAF 108 funciona como un intermediario Web e intercepta las peticiones HTTP generadas por los HUE 106. La direcci6n de
red de la HIAF 108 se puede preconfigurar estaticamente, o se puede descubrir dinamicamente como se describira en mas detalle mas adelante.
La tarea basica de la HIAF 108 es permitir una interacci6n entre los HUE 106 por una parte y la red IMS 102 por otra. Esta interacci6n incluye el inicio, aceptaci6n y terminaci6n de las sesiones multimedia con las entidades IMS habilitadas SIP incluyendo los abonados IMS (es decir, el equipo de usuario habilitado IMS) y los AS de IMS 114. La HIAF 108 se configura para establecer, actualizar y terminar las asignaciones entre los dialogos SIP y la informaci6n de estado HTTP (es decir, las sesiones de estado HTTP). En base a estas asignaciones, la HIAF 108 realiza adicionalmente la conversi6n de senalizaci6n que permite a los HUE 106 iniciar las sesiones de medios hacia las entidades IMS, y ser el objetivo de las sesiones de medios iniciadas por las entidades IMS.
La Fig. 2 ilustra la configuraci6n interna de la HIAF 108. La HIAF 108 aloja un Cliente de Agente de Usuario HTTP (HUAC) y Servidor (HUAS) en una funci6n llamada colectivamente Agente de Usuario HTTP (HUA) 130. El HUAC emite las peticiones HTTP y recibe las respuestas HTTP, mientras que el HUAS recibe las peticiones HTTP y devuelve las respuestas HTTP. La HIAF 108 ademas comprende un Cliente de Agente de Usuario SIP y un Servidor de Agente de Usuario SIP alojado en una funci6n llamada colectivamente Agente de Usuario SIP 132. El Cliente de Agente de Usuario SIP emite las peticiones SIP y recibe las respuestas SIP, y el Servidor de Agente de Usuario SIP recibe las peticiones SIP y devuelve las respuestas SIP.
El Agente de Usuario HTTP 130 constituye un punto final de la mensajeria HTTP, mientras que el Agente de Usuario SIP 132 constituye un punto final para la mensajeria SIP. Una funci6n llamada L6gica de Asignaci6n HTTP a SIP (HSML) 134 se acopla entre el Agente de Usuario HTTP 130 y el Agente de Usuario SIP 132. La HSML 134 esta a cargo de establecer (por ejemplo, determinar, crear, actualizar o borrar) la informaci6n de estado para las sesiones HTTP y SIP y adicionalmente realiza la conversi6n de senalizaci6n entre ellas. Especificamente, en la HSML 134 cada mensaje SIP se puede asociar con y traducir en una pareja de mensaje petici6n-respuesta HTTP y viceversa. El patr6n de senalizaci6n resultante se ilustra en la Fig. 3.
La Fig. 3 ilustra el intercambio de mensajes basado en HTTP entre un HUE 106 y la HIAF 108. Tambien mostrados estan los mensajes SIP asociados enviados por la HIAF 108 hacia la red IMS 102. De una manera similar que la HIAF 108, el HUE 106 comprende un HUAC 106A y un HUAS 106B. La HIAF 108 esta limitada a un numero de puertos del Protocolo de Control de Transmisi6n (TCP) predefinido conocido por todos los HUE 106.
Como es bien conocido, HTTP es un protocolo sin estado en el cual cada pareja de mensajes de petici6n y respuesta se abre una nueva conexi6n TCP (como se muestra en el lado izquierdo de la Fig. 3). En la presente realizaci6n, la informaci6n de estado HTTP se transporta con al menos un mensaje de cada pareja de mensaje de petici6n y respuesta. Identificando la informaci6n de estado HTTP similar o interrelacionada en mensajes que pertenecen a distintas parejas de mensajes de petici6n y respuesta HTTP (es decir, a distintas conexiones TCP), las parejas de mensajes de petici6n y respuesta individuales se pueden agrupar a una sesi6n HTTP de estado unica.
La HIAF 108 establece adicionalmente (por ejemplo, genera y/o mantiene) una asignaci6n entre un dialogo SIP (que implica un mensaje de petici6n SIP y un mensaje de respuesta SIP en el escenario ejemplar mostrado en el lado derecho de la Fig. 3) y la informaci6n de estado HTTP incluida en las dos parejas de mensajes de petici6n y respuesta HTTP de la Fig. 3. De esta manera, se realiza aproximadamente una asociaci6n entre la sesi6n HTTP de estado y la sesi6n SIP a la que se refiere el dialogo SIP. Como resultado, y a pesar de la falta de estado inherente del HTTP, el HUE 106 puede iniciar las sesiones hacia las entidades IMS y tambien puede ser el objetivo de las sesiones iniciadas por las entidades IMS.
Los mensajes HTTP ilustrados en la Fig. 3 se procesan por el Agente de Usuario HTTP 130 de la HIAF 108 mostrada en la Fig. 2. La configuraci6n interna de los componentes l6gicos del Agente de Usuario HTTP 130 se ilustra esquematicamente en la Fig. 4.
Como se muestra en la Fig. 4, el Agente de Usuario HTTP 130 comprende tres capas distintas, a saber una capa de conexi6n de transacciones 140, una capa de administraci6n de transacciones 142 y una capa de administraci6n de dialogos 144. Conceptualmente, el cliente independiente y los componentes de servidor 142A, 142B dentro del Agente de Usuario HTTP 130 comparten la misma capa de conexi6n de transacciones 140 pero son entidades separadas en la capa de administraci6n de transacciones 142. La capa de administraci6n de dialogos 144 se extiende sobre ambos componentes 142A, 142B de la capa de administraci6n de transacciones 142.
La capa de conexi6n de transacciones 140 y la capa de administraci6n de transacciones 142 se configuran para realizar las operaciones de procesamiento basadas en transacci6n. Una transacci6n tipicamente comprende el intercambio de un mensaje de petici6n SIP unico y uno o mas mensajes de respuesta SIP relacionados como parte de un dialogo SIP. Cada dialogo SIP, a su vez, incluye una o mas transacciones individuales (tales como las transacciones INVITE, las transacciones non-INVITE y las peticiones de ACK, que constituyen su propia transacci6n).
Como ya se mencion6, los mensajes de petici6n y respuesta SIP individuales se asignan en parejas de mensajes de petici6n y respuesta HTTP separados en base a la informaci6n de estado HTTP. Es el prop6sito de la capa de conexi6n de transacci6n 140 explotar la asignaci6n en contexto con la utilizaci6n de la informaci6n de estado HTTP
incluida dentro de las parejas de petici6n y respuesta HTTP para hacer coincidir cada mensaje de petici6n HTTP (que contiene, por ejemplo, una petici6n de transacci6n SIP) con su mensaje de respuesta HTTP asociado. Ademas, la capa de conexi6n de transacci6n 140 maneja los tiempos de espera y las retransmisiones HTTP. Para este prop6sito, la capa de conexi6n de transacci6n 140 implementa una maquina de estado separada que depende del tipo de componente de administraci6n de transacci6n requerido (cliente 142A o servidor 142B) y el tipo de transacci6n (por ejemplo, transacci6n INVITE o non-INVITE).
La capa de administraci6n de transacci6n 142 se dispone por encima de la capa de conexi6n de transacci6n 140 y es responsable de crear (o iniciar) y cancelar las transacciones SIP que pertenecen a los dialogos SIP individuales. La capa de administraci6n de dialogos 144 mantiene la informaci6n de estado para cada dialogo SIP establecido. Ademas, la capa de administraci6n de dialogos 144 comprende la l6gica de comunicaci6n entre elementos que interviene entre los componentes del cliente y el servidor 142A, 142B de cada Agente de Usuario HTTP 130 y administra la pila completa de capas de componentes l6gicos.
A continuaci6n, la cooperaci6n de las capas de componentes l6gicos individuales 140, 142 y 144 ilustrada en la Fig. 4 se tratara ejemplarmente en contexto con el diagrama de senalizaci6n esquematico ilustrado en la Fig. 5. En el escenario de mensajeria de la Fig. 5, el HUE 106 inicia una transacci6n INVITE. Para este fin, el HUAC 106 B del HUE 106 emite un primer mensaje de petici6n HTTP como se muestra en la Fig. 5 (paso 1 en la Fig. 4). El mensaje de petici6n HTTP contiene varios elementos de informaci6n que incluyen la informaci6n de estado HTTP, una indicaci6n del mensaje SIP en forma de una petici6n (INVITE) de transacci6n y una informaci6n de descripci6n de sesi6n (en forma de un ofrecimiento SDP). La informaci6n de estado HTTP se transmite como una cookie en la cabecera del mensaje de petici6n HTTP. La indicaci6n del mensaje SIP y la informaci6n de descripci6n de sesi6n compatible con SDP, por otra parte, se transportan en el cuerpo del mensaje de petici6n HTTP.
El Protocolo de Descripci6n de Sesiones, o SDP, se describe en la RFC2327 y define una sintaxis para describir las sesiones multimedia con la informaci6n requerida para participar en esa sesi6n. Las descripciones de sesi6n se pueden enviar usando protocolos de aplicaciones existentes arbitrarios para el transporte.
El modelo de ofrecimiento/contestaci6n como se define en la RFC3264 permite a los puntos finales usar SDP para obtener una visi6n compartida de un sesi6n. Algunos parametros de sesi6n se negocian (por ejemplo, los c6dec a usar), mientras que otros simplemente se comunican desde un punto final a otro (por ejemplo, las direcciones IP). De acuerdo con el modelo de ofrecimiento/contestaci6n de SDP, un punto final de comunicaci6n (el 'oferente') genera un mensaje SDP que constituye la oferta. La oferta necesita ser transportada al otro punto final (el 'que contesta'). El que contesta genera una contestaci6n, que es un mensaje SDP que responde al ofrecimiento presentado por el oferente. La contestaci6n tiene una secuencia de medios de coincidencia para cada secuencia en el ofrecimiento, que indica si la secuencia se acepta o no. El modelo de ofrecimiento/contestaci6n SDP no define un medio de transporte especifico para entregar los mensajes SDP entre los puntos finales.
La informaci6n de estado HTTP recibida con el primer mensaje de petici6n HTTP de la Fig. 5 se transporta desde el HUAC 106B a la HIAF 108 en la forma ejemplar de una cookie. Se apreciara que otros mecanismos para transferir la informaci6n de estado HTTP (tal como los URL gruesos o los parametros URI) se podrian utilizar alternativamente o adicionalmente.
El mensaje de petici6n HTTP desde el HUAC 106B se recibe en la capa de conexi6n de transacci6n 140 del Agente de Usuario HTTP 130 de la HIAF 108. En la capa de conexi6n de transacci6n 140, se procesa el mensaje de petici6n HTTP, y un mensaje de respuesta HTTP en respuesta al mensaje de petici6n HTTP se devuelve al HUAC 106B como se muestra en la Fig. 5 (paso 2 en la Fig. 4). El mensaje de respuesta HTTP opcionalmente puede incluir la informaci6n de estado HTTP (por ejemplo, en forma de una cookie).
Entonces, la petici6n de transacci6n, el ofrecimiento SDP y la informaci6n de estado HTTP se pasan desde la capa de conexi6n de transacci6n 140 al componente de cliente 142A de la capa de administraci6n de transacci6n 142. En respuesta a la recepci6n de estos elementos, el componente de cliente 142A crea un nuevo caso de transacci6n de cliente (paso 3 en la Fig. 4). Despues de la creaci6n del nuevo caso de transacci6n de cliente, se crea un nuevo caso de dialogo SIP en la capa de administraci6n de dialogo 144 (paso 4 en la Fig. 4) y un mensaje de petici6n SIP (mensaje INVITE) que incluye el ofrecimiento SDP se envia a la red IMS (es decir, a la S-CSCF 112) como se muestra en la Fig. 5 para iniciar la sesi6n SIP requerida.
En respuesta a la recepci6n del mensaje de petici6n SIP (INVITE) que incluye el ofrecimiento SDP, la S-CSCF 112 devuelve un mensaje de respuesta SIP con el c6digo de respuesta 183 y una consulta SDP como se muestra en la Fig. 5. Tras la recepci6n del mensaje de respuesta SDP, la l6gica de comunicaci6n entre elementos dentro de la capa de administraci6n de dialogo 144 da instrucciones al componente de servidor 142B de la capa de administraci6n de transacci6n 142 para crear un nuevo caso de transacci6n de servidor (paso 5 en la Fig. 4) y entregar la contestaci6n SDP recibida desde la S-CSCF 112 junto con el c6digo de respuesta a la capa de conexi6n de transacci6n 140.
La capa de conexi6n de transacci6n 140 construye un nuevo mensaje de petici6n HTTP que transporta el c6digo de respuesta, la contestaci6n SDP asi como una cookie con la informaci6n de estado HTTP como se recibe desde el
HUE 106 con el primer mensaje de petici6n HTTP. El mensaje de petici6n HTTP recien creado entonces se envia en un siguiente paso al HUAS 106A del HUE 106 como se muestra en la Fig. 5 (paso 6 en la Fig. 4). En respuesta a la recepci6n del mensaje de petici6n HTTP, el HUAS 106A devuelve un mensaje de respuesta HTTP a la HIAF 108 como tambien se muestra en la Fig. 5.
Dado que la misma (o unicamente asociable) informaci6n de estado HTTP se incluye tanto en el primer mensaje de petici6n HTTP enviado desde el HUAC 106B a la HIAF 108 y el segundo mensaje de petici6n HTTP enviado desde la HIAF 108 al HUAS 106A, el HUE 106 y la HIAF 108 pueden agrupar las dos parejas de mensajes de petici6n y respuesta HTTP nominalmente independientes en una sesi6n HTTP correspondiente a un dialogo SIP en forma de una transacci6n INVITE. Ademas, este mecanismo de gesti6n de estado HTTP tambien se puede usar para asignar los mensajes de petici6n y respuesta HTTP en la senalizaci6n SIP de dialogo adicional tal como las peticiones y respuestas de registro.
En caso que el HUE determine en base a la contestaci6n SDP que ciertos parametros (por ejemplo, los parametros relacionados con los medios o los parametros relacionados con la capacidad del terminal) necesitan ser renegociados, el patr6n de mensajeria tratado anteriormente puede repetir en si mismo cuando el HUAC 106B envie un nuevo mensaje de petici6n HTTP a la HIAF 108 que ofrece renegociar (ver la Fig. 5). En respuesta a este nuevo mensaje de petici6n HTTP, la HIAF 108 construye un mensaje PRACK con una nueva oferta y envia este mensaje a la S-CSCF 112. La S-CSCF 112 contesta al mensaje PRACK con un mensaje 200 OK. Entonces, y aun con referencia a la Fig. 5, la S-CSCF 112 envia un mensaje 200 (INVITE) a traves de la HIAF 108 al HUE 106 y recibe un mensaje de ACK como respuesta.
Durante los diversos dialogos realizados en contexto con la senalizaci6n ilustrada en la Fig. 5, la capa de administraci6n de dialogo 144 del Agente de Usuario HTTP 130 ilustrada en la Fig. 4 hace el seguimiento de todos los dialogos activos. Para este fin, la capa de administraci6n de dialogo 144 mantiene una tabla de estado de dialogo 600 como se ilustra en la Fig. 6. La tabla de estado de dialogo 600 comprende las siguientes columnas. En la primera columna, se almacena la direcci6n local en forma del URI de SIP local usado en el dialogo particular. La segunda columna identifica el objetivo remoto (es decir, la S-CSCF 112) por su URI de SIP. La tercera columna indica la secuencia local, que es el numero de indice del ultimo mensaje de petici6n SIP enviado para el dialogo especifico. En la cuarta columna, la secuencia remota indica el numero de indice del ultimo mensaje de petici6n SIP recibido. La columna de contacto indica la direcci6n IP del punto final remoto (esta columna es importante solamente para la comunicaci6n entre HIAnet sin la intervenci6n de la HIAF 108). En la columna ID de dialogo, se da a cada dialogo SIP un identificador localmente unico.
En el escenario ilustrado en las Fig. 4 y 5, se supone que la HIAF 108 es capaz de conducir el modelo ofrecimiento/contestaci6n SDP con el punto final SIP remoto (a traves de la S-CSCF 112). Alternativamente, el modelo ofrecimiento/contestaci6n SDP tambien se podria conducir directamente entre el HUE 106 y el punto final SIP remoto. Para este fin, el mensaje SDP se puede incluir en el cuerpo del mensaje de los mensajes de petici6n y respuesta HTTP enviados y recibidos por el HUE 106.
Habiendo descrito el concepto de mensajeria general entre el HUE 106 y la S-CSCF 112 bajo el control de la HIAF 108, el mecanismo de gesti6n de estado realizado por el HSML 134 de la HIAF 108 (ver la Fig. 2) se describira ahora en mas detalle para proporcionar una mejor comprensi6n de c6mo se puede realizar la asignaci6n de los dialogos SIP en las sesiones de estado HTTP (es decir, la informaci6n de estado HTTP). Como se explico anteriormente, esta asignaci6n se explota para agrupar multiples parejas de mensajes de petici6n y respuesta HTTP en sesiones de estado HTTP que corresponden con las transacciones SIP que pertenecen a los dialogos SIP.
Los siguientes ejemplos de asignaci6n se basan ejemplarmente en el diagrama de senalizaci6n de inicio de sesi6n detallado de la Fig. 9. El diagrama de senalizaci6n detallado de la Fig. 9 basicamente corresponde a los primeros y los dos ultimos intercambios de mensajes entre el HUE 106 y la S-CSCF 112 (a traves de la HIAF 108) de la Fig. 5 (con la excepci6n de que no se transfiere ninguna contestaci6n SDP a traves del penultimo intercambio de mensaje en la Fig. 5).
Con referencia ahora a la Fig. 9, la mensajeria comienza de nuevo con el HUE 106 que envia un mensaje de petici6n HTTP a la HIAF 108. El mensaje de petici6n HTTP incluye varias cookies HTTP para transportar distintos elementos de informaci6n. Las cookies 'dialog-id' y 'transaction' constituyen (tanto individualmente como en su combinaci6n) la informaci6n de estado HTTP. Dado que en el presente caso la mensajeria se inicia por el HUE 106, la informaci6n de estado HTTP se genera igualmente por el HUE 106. La informaci6n de estado HTTP indica que el mensaje de petici6n HTTP esta asociado con el dialogo ali2alice1 y es parte del numero de transacci6n 000001. En la presente realizaci6n, las peticiones SIP y las respuestas SIP correspondientes estan a cuestas en mensajes de petici6n y respuesta HTTP separados. Como puede haber mas de una petici6n pendiente para el mismo dialogo SIP, el numero de transacci6n se usa por el HUE 106 como la informaci6n de estado encajar las respuestas HTTP con sus peticiones, y viceversa.
El id de llamada es en el caso mas simple el call-id de SIP. No obstante, el id de llamada tambien se puede asignar a otro identificador que ocurre que ser mas conveniente que el dialog-id. El contador de transacci6n es un identificador que corresponde a las sesiones de medios que existen dentro del dialogo SIP. Un ejemplo seria
multiples secuencias de video dentro de un dialogo SIP. El contador de transacciones pudiera ser usado en tal caso para distinguir entre estas diferentes secuencias de video.
El elemento de informaci6n &quot;method&quot; en el cuerpo del primer mensaje de petici6n HTTP de la Fig. 9 indica que el HUE 106 requiere el inicio de una transacci6n INVITE en relaci6n con un Agente de Usuario SIP remoto. La direcci6n SIP de este Agente de Usuario se incluye en la primera linea del estado GET (sip:alice@baba). Como se muestra en la Fig. 9, el cuerpo del mensaje de petici6n HTTP incluye un elemento de informaci6n adicional que transporta la informaci6n de descripci6n de sesi6n en forma de un ofrecimiento SDP.
En base a la informaci6n recibida a traves del mensaje de petici6n HTTP desde el HUE 106, la HIAF 108 es informada de que se requiere una transacci6n INVITE (method=invite) y que un procedimiento de ofrecimiento/contestaci6n SDP tiene que ser realizado. Ya que la sesi6n resultante se extendera entre el dominio HTTP del HUE 106 por una parte y el dominio SIP de la S-CSCF 112 por otra parte, la informaci6n de estado HTTP necesita ser almacenada por la HIAF 108 para permitir una comunicaci6n de estado con el HUE 106 en el contexto de esta sesi6n.
Para almacenar la informaci6n de estado HTTP, la HIAF llena las tablas locales en base a la informaci6n de estado HTTP recibida a traves del mensaje de petici6n HTTP desde el HUE 106 y el ID de dialogo SIP asociado generado por la capa de administraci6n de dialogo 144 como se trat6 anteriormente en contexto con la Fig. 4. Para este fin, el HSML 134 de la HIAF 108 mantiene dos tablas de asignaci6n separadas, a saber una Tabla de Resoluci6n de Dialogo (DRT) 700, como se ilustra en la Fig. 7, por una parte y una Tabla de Recuento de Transacciones (TCT) 800, como se ilustra en la Fig. 8, por otra parte. Ambas tablas se mantienen y actualizan por el HSML 134 con el prop6sito de asignar las sesiones de estado HTTP a los dialogos SIP asi como para monitorizar el progreso de las transacciones SIP y las sesiones HTTP.
Como se muestra en la Fig. 7, la DTR 700 asigna el ID de dialogo SIP como se asigna por la capa de administraci6n de dialogo 144 a un ID dialogo HIAF (ali2alice1) como se recibe en el presente caso desde el HUE 106. Usando cualquier ID de dialogo contenido en la DRT 700, es posible para el HSML 134 determinar el estado actual del dialogo y construir cualquier mensaje SIP necesario para continuar, modificar o terminar el dialogo. El estado de dialogo para cada dialogo se mantiene por el Agente de Usuario SIP 132 para cada dialogo que implica a la HIAF
108.
La TCT 800 mostrada en la Fig. 8 se usa por el HSML 134 en conjunto con la DRT 700 de la Fig. 7 para producir los mensajes de petici6n y respuesta HTTP adecuados dirigidos al HUE 106. Una entrada en la TCT 800 indica que hay una transacci6n activa entre el HUE 106 y la HIAF 108 con un numero de transacci6n dado. Los numeros de transacci6n se usaran en la senalizaci6n intercambiada entre el HUE y los puntos finales de la HIAF para completar las transacciones. Dos transacciones dentro del mismo dialogo SIP no deberian usar el mismo numero de transacci6n, independientemente de si estas transacciones se emiten por el HUE 106 o la HIAF 108. Se deberia senalar que ademas de la TCT 800 de la HIAF 108 mostrada en la Fig. 8, el HUE 106 mantendra independientemente su propia tabla de recuento de transacciones de una manera similar a la TCT 800.
En base a la DRT 700 y la TCT 800, el ID de dialogo SIP se puede buscar de esta manera cuando se conoce el ID de dialogo de la HIAF y el numero de transacci6n. Cada vez que la HIAF 108 determina que un nuevo dialogo esta a punto de ser establecido, asigna un nuevo ID de dialogo de la HIAF y actualiza la DRT 700 (nuevo ID de dialogo SIP) y la TCT 800 (nuevo numero de transacci6n) en consecuencia. Como se muestra en las Fig. 7 y 8, la DRT 700 y la TCT 800 se pueden usar para mantener otros datos de estado. Tales otros datos de estado pueden incluir los parametros del ramal SIP.
Siempre que la HIAF 108 recibe un mensaje de petici6n HTTP desde el HUAC del HUE 106, realiza las siguientes tareas en relaci6n con la DRT 700 y la TCT 800. En un primer paso, la HIAF 108 determina si el HUE 106 solicitante tiene un registro valido con un tiempo de vida pendiente. Para este fin, la HIAF 108 busca a traves de su tabla de registro local (como se trata en mas detalle mas adelante) una entrada que contenga la direcci6n IP que ha obtenido el mensaje de petici6n HTTP entrante (es decir la direcci6n IP del HUE 106). En un siguiente paso, la HIAF 108 usa la informaci6n de la tabla de registro, la DRT 700 y el mensaje de petici6n HTTP para construir el mensaje de petici6n SIP requerido. En el mismo momento, la HIAF 108 actualiza su DRT 700.
En un paso adicional, la HIAF 108 utiliza la informaci6n adquirida a partir de la DRT 700 y la TCT 800 para construir un mensaje de respuesta HTTP para el HUE 106. Como se ilustra en la Fig. 9, el mensaje de respuesta HTTP transporta el c6digo 200 OK. Se deberia senalar que el c6digo de estado contenido en el mensaje de respuesta HTTP se relaciona meramente con la capacidad de la HIAF 108 para ejecutar los contenidos de la petici6n HTTP, y no con el resultado de la ejecuci6n. En otras palabras, en el caso ilustrado en la Fig. 9 el c6digo de estado 200 OK incluido en el mensaje de respuesta HTTP solamente indica que es valido el mensaje de petici6n HTTP previo, pero no que el mensaje INVITE enviado por la HIAF 108 a la S-CSCF 112 fue exitoso. Si, por cualquier raz6n, una petici6n HTTP especifica no se puede servir por la HIAF 108, entonces se devolvera un mensaje de respuesta HTTP con un c6digo de estado non-200 (por ejemplo, un c6digo 4xx de SIP) y una frase con la raz6n adecuada al HUE
106.
Siempre que la HIAF 108 recibe un mensaje SIP de la red IMS (es decir, desde la S-CSCF 112), se realizan las siguientes tareas (ver la Fig. 9). Primero, se actualiza la DRT 700 con respecto al tipo de mensaje SIP recibido y la informaci6n contenida en el mensaje SIP. La HIAF 108 entonces usa la informaci6n de la tabla de registro, la DRT 700 y la TCT 800 para producir una petici6n HTTP que se envia al HUAS del HUE 106 (ver la Fig. 9). En un siguiente paso, la HIAF 108 recibe un mensaje de respuesta HTTP desde el HUAS del HUE 106. Como llega a ser evidente a partir de la Fig. 9, la informaci6n de estado HTTP contenida en el mensaje de respuesta HTTP es la misma que la informaci6n de estado HTTP contenida en el mensaje de respuesta HTTP enviado inicialmente por el HUE 106 a la HIAF 108 en contexto con iniciar la transacci6n INVITE requerida.
En la realizaci6n de senalizaci6n tratada anteriormente en contexto con la Fig. 9, se supone que el establecimiento de sesi6n se desencadena desde el dominio HTTP por el HUE 106. De acuerdo con unas realizaciones de senalizaci6n alternativas que seran tratadas ahora con referencia a las Fig. 10 y 11, el establecimiento de sesi6n se desencadena por una entidad habilitada con SIP tal como el AS de SIP 114 ilustrado en la Fig. 1 o un equipo de usuario habilitado con SIP.
La Fig. 10 ilustra c6mo se puede realizar un escenario de ofrecimiento/contestaci6n SDP complejo usando la HIAF 108 asignando los mensajes de petici6n SIP en los mensajes petici6n/respuesta HTTP, y viceversa. La senalizaci6n entrante desde la entidad habilitada con SIP se pasa por la S-CSCF 112 a la HIAF 108 como se ilustra por el mensaje INVITE (que incluye un ofrecimiento SDP) en la Fig. 10. En respuesta a la recepci6n del mensaje INVITE, la HIAF 108 genera la informaci6n de estado HTTP adecuada y envia la misma junto con el ofrecimiento SDP en un mensaje de petici6n HTTP al HUAS 106A del HUE 106. El HUAS 106A responde con un mensaje de respuesta HTTP que incluye de nuevo la informaci6n de estado HTTP. La mensajeria continua con el HUAC 106B del HUE 106 enviando un mensaje de petici6n HTTP con la informaci6n de estado HTTP y una contestaci6n SDP a la HIAF
108. La HIAF 108 asigna este mensaje de petici6n HTTP en una respuesta SIP (c6digo de estado 183) que incluye la contestaci6n SDP y en el mismo momento reconoce la recepci6n del mensaje de petici6n HTTP mediante un mensaje de respuesta HTTP al HUE 106.
Entonces, la HIAF 108 recibe un mensaje PRACK desde la S-CSCF 112 y asigna este mensaje a un nuevo mensaje de petici6n HTTP incluyendo de nuevo la informaci6n de estado HTTP generada previamente asi como un nuevo ofrecimiento SDP (offer2) como se recibe a traves del mensaje PRACK. El nuevo mensaje de petici6n HTTP enviado desde la HIAF 108 al HUAS 106A provoca un reconocimiento en forma de un mensaje de respuesta HTTP. El intercambio de mensajes adicional tiene similitudes con el intercambio de mensajes tratado anteriormente en contexto con la Fig. 5, pero en la direcci6n contraria. Similar a la situaci6n ilustrada en la Fig. 5, se requiere la comunicaci6n interna entre el HUAS 106A y el HUAC 106B del HUE 106 para facilite la reacci6n con los mensajes de petici6n HTTP enviados por el HUAC 106B despues de la recepci6n de los mensajes de petici6n HTTP por el HUAS 106A.
El diagrama de senalizaci6n de la Fig. 11 ilustra en mas detalle la senalizaci6n implicada con la recepci6n de un mensaje INVITE desde la S-CSCF 112 por la HIAF 108 para el escenario en que el HUE 106 es el destinatario de una petici6n de transacci6n. Los tres primeros mensajes de la Fig.11 corresponden a los tres primeros mensajes de la Fig. 10. El intercambio de mensajes adicional ilustrado en la Fig. 11 tiene similitudes con el intercambio de mensajes ilustrado en la Fig. 9, pero en la direcci6n contraria. Se cree que en base a las explicaciones dadas en contexto con la Fig. 9, el diagrama de senalizaci6n de la Fig. 11 es en gran medida auto explicativo. Por esta raz6n, se omite aqui una discusi6n mas detallada del mismo. Se senala solamente que la informaci6n de contacto negociada durante el modelo de ofrecimiento/contestaci6n SDP corresponde con las parejas direcci6n IP/puertos asignada por el HUE 106 y los puntos finales SIP a la sesi6n particular. Como tal, la sesi6n se conduce directamente entre el HUE 106 y los puntos finales SIP.
Los diagramas de senalizaci6n de las Fig. 12 y 13 ilustran la senalizaci6n de terminaci6n de sesiones iniciada por el HUE 106 por una parte (Fig. 12) y a traves de la S-CSCF 112 por otra parte (Fig. 13). La terminaci6n de sesiones en cada caso implica la transmisi6n de un mensaje BYE o bien a la S-CSCF 112 o bien a traves de la S-CSCF 112. El mensaje BYE se acompana en cada caso por dos parejas de mensajes de petici6n y respuesta HTTP. Como llega a ser evidente a partir de las Fig. 12 y 13, la misma informaci6n de estado HTTP (dialog-id=alice2ali1; transaction=000008) se incluye en cada uno de estos cuatro mensajes HTTP. En base a la informaci6n de estado HTTP, las dos parejas de mensajes de petici6n y respuesta HTTP estan limitadas de esta manera al dialogo SIP correspondiente como se ilustra en las tablas de las Fig. 7 y 8.
En las realizaciones siguientes, se explican algunos aspectos adicionales relacionados con la HIAF que se pueden implementar en combinaci6n con las realizaciones anteriores o de una manera separada. Especificamente, se tratan los aspectos tecnicos del descubrimiento de la HIAF, la transcodificaci6n de medios HIAF, la autentificaci6n HIAF y los mensajes de registro HIAF.
El descubrimiento HIAF implica la determinaci6n de la direcci6n de la HIAF 108 en la HIAnet 104 (ver la Fig. 1). Cuando el HUE 106 despliega el Servicio General de Paquetes de Radio (GPRS) como el medio de acceso de red, la direcci6n de la HIAF 108 se puede determinar durante la activaci6n del contexto del Protocolo de Datos por Paquetes (PDP) general o de senalizaci6n. Potencialmente, se puede necesitar que sea definido un nuevo Nombre de Punto de Acceso (APN) para la activaci6n del contexto PDP de Acceso IMS de HTTP.
Alternativamente, el HUE 106 puede usar el Protocolo de Configuraci6n Dinamica de Servidor (DHCP) para descubrir la HIAF 108. Si la direcci6n de la HIAF 108 se devuelve por el DHCP como un Nombre de Dominio Totalmente Cualificado (F�DN), entonces la direcci6n IP de la HIAF 108 se puede adquirir a traves del Sistema de Nombres de Dominio (DNS) como es bien conocido en la tecnica. Como una posibilidad adicional, la HIAF 108 se puede descubrir automaticamente con la ayuda de un Protocolo de Autoconfiguraci6n Intermediario (PAD) tal como el estandar del Protocolo de Autodescubrimiento Intermediario Web (WPAD) o la Autoconfiguraci6n Intermediaria (PAC).
La HIAF 108 tambien puede realizar las operaciones de transcodificaci6n de medios. Durante la negociaci6n de un formato de sesi6n de medios, la HIAF 108 puede declararse a si misma como la destinataria de la sesi6n de medios. Como resultado, la sesi6n de medios se recibe por la HIAF 108, y la HIAF 108 realiza la transcodificaci6n de medios en un formato de sesi6n que se ha negociado previamente entre (o preconfigurado en) la HIAF 108 y el HUE 106. Despues de la operaci6n de transcodificaci6n, la nueva sesi6n de medios se entrega al HUE 106. Tal transcodificaci6n de medios basada en la HIAF ayuda a reducir la carga de procesamiento y la complejidad en el lado del HUE 106.
Ahora, se trataran en mas detalle varios aspectos relacionados con la autentificaci6n y el registro que preceden una sesi6n de medios real.
El HTTP ofrece una estructura de autentificaci6n con soporte para un esquema basico (autentificaci6n basica) y un esquema basado en las generaciones de claves criptograficas (autentificaci6n de acceso de resumen) ambos que implementan un mecanismo de autentificaci6n reto-respuesta. En autentificaci6n basica, un Cliente de Agente de Usuario respondera a un reto del Servidor de Agente de Usuario emitiendo una cadena codificada base64 que contiene su nombre de usuario y contrasena. El hecho de que la autentificaci6n basica dicte la transmisi6n de las credenciales de usuario casi en texto claro hace este esquema de autentificaci6n inadecuado para ciertas aplicaciones. En autentificaci6n de acceso de resumen, el cliente de Agente de Usuario es retado con un numero aleatorio y se le pide que devuelva una cadena producida aplicando un algoritmo de resumen con un secreto compartido sobre el numero aleatorio y un conjunto de datos.
Un HUE 106 que desea ser alcanzable en un URI de SIP o disfrutar de los servicios de valor anadido de IMS tiene que realizar inicialmente el registro IMS. Para este fin, la HIAF 108 puede, por ejemplo, proporcionar el modo de autentificaci6n de la Pasarela de Confianza.
Generalmente, el registro HIAF implica un registro HTTP conducido entre el HUE 106 y la HIAF 108, y un registro SIP conducido entre la HIAF 108 y la red IMS 102. En el modo de autentificaci6n de la Pasarela de Confianza, la HIAF 108 autentifica cada HUE 106 a traves de la autentificaci6n HTTP (por ejemplo, usando autentificaci6n de acceso basica o de resumen) y confirma a la red IMS 102 la autenticidad del HUE 106. En este modo de funcionamiento, la HIAF 108 es autorizada a actuar a favor del HUE 106 y originar (o responder a) las peticiones y respuestas de registro SIP intercambiadas con la red IMS 102. Los registros HTTP y SIP en ambos lados de la HIAF 108 son independientes entre si. Esto significa que un registro HTTP con exito no significa necesariamente que el registro SIP sea igualmente un exito.
A continuaci6n, el contenido de los mensajes de registro HIAF asi como los pasos basicos del metodo de autentificaci6n de la Pasarela de Confianza se trataran en mas detalle. En este sentido se asumira que el dominio SIP esta considerando la HIAF 108 como de confianza. Consecuentemente, todas las peticiones de registro que vienen de la HIAF 108 se aceptaran automaticamente. No obstante, la HIAF 108 no confia en los HUE 106, los cuales en consecuencia tienen que ser autentificados.
Cada petici6n de registro HIAF desde un HUE 106 incluye un mensaje de petici6n HTTP que contiene informaci6n que indica que la sesi6n HTTP esta introduciendo el estado de registro. Un posible mensaje de petici6n HTTP enviado desde el HUE 106 a la HIAF 108 se muestra en el diagrama de senalizaci6n esquematico de la Fig. 14 ilustrando el registro HIAF de la Pasarela de Confianza. Como llega a ser evidente a partir del primer mensaje de petici6n HTTP en este diagrama de senalizaci6n, el HUE 106 esta usando la cookie &quot;method=register&quot; para notificar a la HIAF 108 que la sesi6n HTTP esta introduciendo el estado de registro.
La respuesta de registro de la HIAF 108 es un mensaje de respuesta HTTP. Si el c6digo de estado del mensaje de respuesta HTTP es 200 OK como se ilustra en la Fig. 14, entonces la petici6n de registro HIAF se ha procesado con exito. En tal caso, el mensaje de respuesta HTTP correspondiente tambien contendra informaci6n que indica el nuevo estado introducido por la sesi6n HTTP. En el ejemplo dado en la Fig. 14, la HIAF 108 esta emitiendo un mensaje de petici6n HTTP que incluye la cookie &quot;code=401&quot;. Esta cookie indica al HUE 106 que tiene que autentificarse a si mismo con la red IMS 102. El valor del c6digo de 401 corresponde al c6digo de estado del mensaje de respuesta SIP recibido por la HIAF 108.
Se deberia senalar que el HUE 106 y la HIAF 108 no afrontan el problema de tener que determinar una coincidencia entre los mensajes de petici6n y respuesta de registro HIAF dado que estos mensajes se transportan sobre una y la misma conexi6n TCP. Por esta raz6n, no necesita ser iniciada la sesi6n HTTP de estado.
A continuaci6n, se describira en mas detalle un ejemplo de un proceso de autentificaci6n de la Pasarela de
Confianza con referencia al diagrama de senalizaci6n de la Fig. 14 y las tablas de las Fig. 15 y 16. En una realizaci6n presente el registro HIAF con la autorizaci6n de la Pasarela de Confianza se basa en las siguientes suposiciones:
1.
La informaci6n de la autorizaci6n se ha establecido a priori entre el HUE 106 y la HIAF 108. Es decir, el HUE 106 esta en una posici6n de autentificarse a si mismo con la HIAF 108 usando o bien la autentificaci6n basica o bien la de resumen.
2.
La HIAF 108 mantiene una tabla de abonados 1500 como se muestra en la Fig. 15 que asigna los nombres de usuario de autentificaci6n del HUE a los abonados IMS. La tabla de abonados 1500 contiene todos los campos necesarios con los que se puede autentificar el HUE 106. La columna de esquema de autentificaci6n de la tabla 1500 indica el metodo especifico por el cual el usuario deberia ser autentificado. Las restantes columnas se usan para construir la cabecera de autentificaci6n (con la cual se desafia al usuario) y para verificar la validez de la respuesta del usuario.
La autentificaci6n de la Pasarela de Confianza basicamente comprende dos partes. Durante la primera parte, el HUE 106 es autentificado con la HIAF 108. El metodo de autentificaci6n HTTP especifico usado a este respecto depende del perfil del abonado segun se define en la tabla de abonados 1500. Por ejemplo, un abonado con la entrada de la tabla &quot;de resumen&quot; en la columna del esquema de autentificaci6n sera autentificado usando autentificaci6n de resumen.
Con referencia ahora al diagrama de senalizaci6n de la Fig. 14, tras la recepci6n del mensaje de petici6n HTTP inicial, el HSML 134 de la HIAF 108 (ver la Fig. 2) realiza los siguientes pasos. En un primer paso, el HSML 134 evalua la cookie en el mensaje de petici6n HTTP y determina el prop6sito del mensaje de petici6n HTTP que ha sido recibido. La cookie &quot;method=register&quot; indica que este mensaje es una petici6n de registro HIAF. En un siguiente paso, y usando el contenido de la petici6n URI en la linea de petici6n de la petici6n de registro HIAF, el HSML 134 realiza una busqueda en la tabla de abonado 1500 para adquirir el perfil de abonado. En un siguiente paso, el HSML 134 realiza la autentificaci6n de acceso con respecto al metodo de autentificaci6n definido para el abonado en la tabla de abonado 1500.
Una vez que la autentificaci6n se ha realizado con exito y antes de la transmisi6n del mensaje de respuesta HTTP (200 OK) al HUE 106, la HIAF 108 crea una entrada para el usuario en una tabla de registro HIAF 1600 como se ilustra en la Fig. 16.
La tabla de registro 1600 tiene varias columnas. La columna de Nombre de Usuario de Autentificaci6n indica el Nombre de Usuario de Autentificaci6n usado por el HUE 106 durante el registro HIAF. La columna de ID de Usuario Publico indica el ID correspondiente del abonado y se puede reservar para uso futuro. La columna de Dominio Local del HUE 106 esta rellenada con el contenido correspondiente de la cabecera de autentificaci6n en el mensaje de petici6n de registro HIAF. La columna de Direcci6n IP esta rellenada con la Direcci6n IP del HUE 106. Esta direcci6n se deriva generalmente de la Direcci6n IP fuente de los mensajes de petici6n de registro HIAF entrantes. La columna de Estado indica el Estado de los registros HIAF y la columna de Tiempo de Vida indica el Tiempo de Vida de los registros HIAF.
Despues de cada autentificaci6n con exito, se crea y se rellena una nueva entrada en la tabla de registro HIAF 1600 como sigue. Los campos de Nombre de Usuario de Autentificaci6n y Dominio Local se rellenan con los valores usados por el abonado durante la autentificaci6n. La lista de ID de Usuario Publico se mantiene vacia y se reserva para uso futuro. El campo de direcci6n IP se fija a la direcci6n usada por el HUE 106 durante el registro HIAF. El campo de Estado se fija a REGISTRADO y el tiempo de vida se deja vacio.
La HIAF 108 entonces construye un mensaje REGISTER de SIP (ver la Fig. 14) rellenando el campo individual de mensaje como sigue. Los campos De y A se rellenan con el valor dado por la Petici6n URI en la petici6n de registro HIAF. Se crea un nuevo ID de Llamada que puede contener en su fondo la direcci6n IP del HUE 106. Este ID de Llamada tiene que ser grabado en las entradas respectivas de la tabla de registro 1600. El campo de Contacto se rellena con el propio URI de SIP de la HIAF 108. Este es basicamente la direcci6n donde la HIAF 108 desea recibir las invitaciones de sesi6n futuras para este abonado. En un paso adicional, se anade una cabecera Path indicando su propio URI de SIP que conduce a la red IMS 102 a creer que la HIAF 108 esta actuando como la P-CSCF 110 para un abonado IMS (ver la Fig. 1).
Para cada mensaje de respuesta de registro SIP recibido desde la red IMS 102, el HSML 134 de la HIAF 108 realiza las siguientes acciones. En un primer paso, el HSML 134 actualiza el valor del tiempo de vida de la entrada respectiva en la tabla de registro 1600 con el valor correspondiente en el mensaje de respuesta de registro SIP. Entonces construye un mensaje de respuesta HTTP con una linea de estado 200 OK que contiene la cookie &quot;lifetime=xxxx&quot; en su cuerpo de mensaje. Esta cookie indica al HUE 106 el tiempo de vida del registro HIAF.
Como ha llegado a ser evidente a partir de las realizaciones anteriores, las tecnicas presentadas aqui dentro permiten al equipo de usuario habilitado con HTTP iniciar, conducir y terminar sesiones con un Agente de Usuario SIP en base a las asignaciones que se establecen entre los dialogos SIP y las sesiones de estado HTTP. El paradigma de sesi6n se puede extender de esta manera en el dominio HTTP, lo cual aumenta la interoperabilidad general de las redes que confian en distintos protocolos de la capa de aplicaciones. La conversi6n de senalizaci6n se puede realizar de manera eficiente en una interfaz entre los dominios HTTP y SIP.
En lo anteriormente mencionado, se han descrito los principios, las realizaciones preferentes y varios modos de implementar las tecnicas reveladas aqui dentro. No obstante, la presente invenci6n no deberia ser construida como que esta limitada a los principios, realizaciones y modos particulares tratados anteriormente. De esta manera se apreciara que se pueden hacer variaciones y modificaciones por una persona experta en la tecnica sin salir del alcance de la presente invenci6n como se define por las siguientes reivindicaciones.

Claims (16)

  1. REIVINDICACIONES
    1. Un metodo para realizar la conversi6n de senalizaci6n entre una sesi6n de estado del Protocolo de Transferencia Hipertexto, o HTTP, y un dialogo del Protocolo de Inicio de Sesiones, o SIP, caracterizado por: -recibir desde una entidad habilitada con HTTP un primer mensaje de petici6n HTTP, el primer mensaje de
    5 petici6n HTTP que incluye la informaci6n de estado HTTP; -crear un primer mensaje SIP en respuesta a la recepci6n del primer mensaje de petici6n HTTP, el primer mensaje SIP que pertenece a un dialogo SIP;
    -enviar el primer mensaje SIP a una entidad habilitada con SIP; y -establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP.
    10 2. El metodo de la reivindicaci6n 1, que ademas comprende devolver un primer mensaje de respuesta HTTP a la entidad habilitada con HTTP.
  2. 3. El metodo de la reivindicaci6n 1 o 2, que ademas comprende:
    -
    recibir un segundo mensaje SIP;
    -
    determinar el dialogo SIP al cual pertenece el segundo mensaje SIP; 15 -determinar la informaci6n de estado HTTP asociada con el dialogo SIP;
    -
    generar un segundo mensaje de petici6n HTTP que incluye o que referencia la informaci6n de estado HTTP determinada de esta manera; y -enviar el segundo mensaje de petici6n HTTP a la entidad habilitada con HTTP.
  3. 4. El metodo de la reivindicaci6n 3, que ademas comprende recibir un segundo mensaje de respuesta HTTP en 20 respuesta al segundo mensaje de respuesta HTTP desde la entidad habilitada con HTTP.
  4. 5. El metodo de cualquiera de las reivindicaciones precedentes, en el que basado en la informaci6n de estado HTTP la pareja de primeros mensajes de petici6n y respuesta HTTP asi como la pareja de segundos mensajes de petici6n y respuesta HTTP se agrupan en la sesi6n de estado HTTP y/o en el que el primer mensaje de petici6n HTTP ademas incluye informaci6n de direcci6n indicativa de un Agente de Usuario SIP de la entidad habilitada con
    25 SIP, y en el que la informaci6n de la direcci6n se usa para dirigir el primer mensaje SIP al Agente de Usuario SIP y/o en el que el primer mensaje de petici6n HTTP ademas incluye informaci6n de dialogo HTTP, y en el que la informaci6n de dialogo HTTP se asigna a la informaci6n de dialogo SIP y/o en el que el primer mensaje de petici6n HTTP ademas incluye informaci6n de descripci6n de sesi6n, y que ademas comprende insertar la informaci6n de descripci6n de sesi6n incluida en el primer mensaje de petici6n HTTP en el primer mensaje SIP.
    30 6. El metodo de la reivindicaci6n 5, en el que la informaci6n de descripci6n de sesi6n se envia en un contexto de ofrecimiento/contestaci6n del Protocolo de Descripci6n de Sesiones, o SDP.
  5. 7. El metodo de cualquiera de las reivindicaciones precedentes, en el que la informaci6n de estado se incluye en al menos uno del primer mensaje de petici6n HTTP y el segundo mensaje de petici6n HTTP en forma de al menos uno de una cookie HTTP, un Localizador de Recursos Universal grueso, o URL grueso, un parametro HTTP y una
    35 componente de consulta y/o en el que el primer mensaje de petici6n HTTP incluye una indicaci6n de mensaje SIP indicativa de al menos uno de un metodo SIP, un c6digo SIP y un c6digo de estado HTTP.
  6. 8. Un metodo para realizar la conversi6n de senalizaci6n entre un dialogo de Protocolo de Inicio de Sesiones, o SIP, y una sesi6n de estado del Protocolo de Transferencia de Hipertexto, o HTTP, caracterizado por: -recibir desde una entidad habilitada con SIP un primer mensaje SIP, el primer mensaje SIP que pertenece a un 40 dialogo SIP;
    -
    establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP; -crear un primer mensaje de petici6n HTTP indicativo de un contenido del primer mensaje SIP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP asignada en el dialogo SIP; y
    -
    enviar el primer mensaje de petici6n HTTP a una entidad habilitada con HTTP.
    45 9. El metodo de la reivindicaci6n 8, que ademas comprende recibir un primer mensaje de respuesta HTTP en respuesta al primer mensaje de respuesta HTTP desde la entidad habilitada con HTTP.
  7. 10. El metodo de la reivindicaci6n 8 o 9, que ademas comprende
    -
    recibir un segundo mensaje de petici6n HTTP, el segundo mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP y una indicaci6n opcional de un segundo mensaje SIP que va a ser creado;
    -
    determinar el dialogo SIP asignado en la informaci6n de estado HTTP;
    -
    crear un segundo mensaje SIP en respuesta a la recepci6n del segundo mensaje de petici6n HTTP en base a la indicaci6n opcional en el segundo mensaje de petici6n HTTP y el dialogo SIP determinado; y
    -
    enviar el segundo mensaje SIP a la entidad habilitada con SIP.
  8. 11.
    El metodo de la reivindicaci6n 10, que ademas comprende devolver un segundo mensaje de respuesta HTTP a la entidad habilitada con HTTP.
  9. 12.
    El metodo de las reivindicaciones 8 a 11, en el que en base a la informaci6n de estado HTTP la pareja de primeros mensajes de petici6n y respuesta HTTP asi como la pareja de segundos mensajes de petici6n y respuesta HTTP se agrupan en la sesi6n de estado HTTP y/o el metodo que ademas comprende generar la informaci6n de estado HTTP en respuesta a la recepci6n del primer mensaje SIP.
  10. 13.
    El metodo de cualquiera de las reivindicaciones precedentes, en el que la entidad habilitada con HTTP es un equipo de usuario y/o en el que la entidad habilitada con SIP es una entidad del Subsistema Multimedia de Protocolo de Internet (IMS) y/o en el que el dialogo SIP se realiza en uno de un contexto de registro de usuario, un contexto de inicio de sesi6n y un contexto de terminaci6n de sesi6n.
  11. 14.
    Un producto de programa informatico que comprende partes de c6digo de programa para realizar los paso de cualquiera de las reivindicaciones precedentes cuando el producto de programa informatico se ejecuta en un dispositivo informatico.
  12. 15.
    El producto de programa informatico de la reivindicaci6n 14, almacenado en un medio de grabaci6n legible por ordenador.
  13. 16.
    Un aparato (108) para realizar la conversi6n de senalizaci6n entre una sesi6n de estado del Protocolo de Transferencia Hipertexto, o HTTP, y un dialogo del Protocolo de Inicio de Sesiones, o SIP, caracterizado por:
    -
    un Agente de Usuario HTTP (130) adaptado para recibir desde una entidad habilitada con HTTP un primer mensaje de petici6n HTTP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP;
    -
    un Agente de Usuario SIP (132) adaptado para crear y enviar un primer mensaje SIP a una entidad habilitada con SIP en respuesta a la recepci6n del primer mensaje de petici6n HTTP, el primer mensaje SIP que pertenece a un dialogo SIP; y
    -
    una l6gica de asignaci6n (134) adaptada para establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP.
  14. 17.
    El aparato de la reivindicaci6n 16, en el que el aparato se adapta para realizar los pasos de cualquiera de las reivindicaciones 2 a 7.
  15. 18.
    Un aparato (130) para realizar la conversi6n de senalizaci6n entre un dialogo del Protocolo de Inicio de Sesiones, o SIP, y una sesi6n de estado del Protocolo de Transferencia Hipertexto, o HTTP, caracterizado por:
    -
    un Agente de Usuario SIP (132) adaptado para recibir desde una entidad habilitada con SIP un primer mensaje SIP, el primer mensaje SIP que pertenece a un dialogo SIP;
    -
    una l6gica de asignaci6n (134) adaptada para establecer una asignaci6n entre la informaci6n de estado HTTP y el dialogo SIP;
    -
    un Agente de Usuario HTTP (130) adaptado para crear y enviar un primer mensaje de petici6n HTTP indicativo de un contenido del primer mensaje SIP a una entidad habilitada con HTTP, el primer mensaje de petici6n HTTP que incluye la informaci6n de estado HTTP asignado en el dialogo SIP.
  16. 19. El aparato de la reivindicaci6n 18, en el que el aparato se adapta para realizar los pasos de cualquiera de las reivindicaciones 9 a 13.
ES08873006T 2008-02-29 2008-12-11 Técnica para realizar la conversión de señalización entre los dominios http y sip. Active ES2373357T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US3281508P 2008-02-29 2008-02-29
US32815P 2008-02-29
PCT/EP2008/010539 WO2009106117A1 (en) 2008-02-29 2008-12-11 Technique for performing signaling conversion between http and sip domains

Publications (1)

Publication Number Publication Date
ES2373357T3 true ES2373357T3 (es) 2012-02-02

Family

ID=40527545

Family Applications (1)

Application Number Title Priority Date Filing Date
ES08873006T Active ES2373357T3 (es) 2008-02-29 2008-12-11 Técnica para realizar la conversión de señalización entre los dominios http y sip.

Country Status (6)

Country Link
US (2) US9094463B2 (es)
EP (1) EP2250786B1 (es)
AT (1) ATE524008T1 (es)
ES (1) ES2373357T3 (es)
PL (1) PL2250786T3 (es)
WO (1) WO2009106117A1 (es)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090206986A1 (en) * 2005-08-31 2009-08-20 Shingo Murakami method of presenting ims public user identify to rfid applications
US8831032B2 (en) * 2008-03-05 2014-09-09 Telefonaktiebolaget L M Ericsson (Publ) SIP-HTTP application correlator
WO2009148400A1 (en) * 2008-06-05 2009-12-10 Telefonaktiebolaget L M Ericsson (Publ) System for conversion of sip messages
JP5313395B2 (ja) 2009-04-13 2013-10-09 リサーチ イン モーション リミテッド Ｓｉｐメッセージに対する信用を決定するシステムおよび方法
WO2011157928A1 (fr) * 2010-06-16 2011-12-22 France Telecom Procede et systeme d'acces securise a un serveur http
ES2387437B1 (es) 2010-11-19 2013-05-20 Telefónica, S.A. Sistema de comunicaciones y método para comunicaciones entre internet y subsistemas ngn/ims.
WO2012072099A1 (en) * 2010-11-29 2012-06-07 Nokia Siemens Networks Oy Cross-authentication arrangement
WO2012072098A1 (en) * 2010-11-29 2012-06-07 Nokia Siemens Networks Oy Cross-authentication arrangement
CN102149018B (zh) * 2010-11-30 2013-04-24 广东星海数字家庭产业技术研究院有限公司 一种应用hsml解析引擎的安全保护处理方法及系统
US8767719B2 (en) * 2011-09-23 2014-07-01 Avaya Inc. System and method for split SIP
CN102347950B (zh) * 2011-09-29 2018-02-06 中兴通讯股份有限公司 电信网络向互联网提供会话服务的方法及系统
WO2014060008A1 (en) * 2012-10-19 2014-04-24 Unify Gmbh & Co. Kg Method and system for creating a virtual sip user agent by use of a webrtc enabled web browser
US9307031B2 (en) 2013-02-04 2016-04-05 Oracle International Corporation Generic model for customizing protocol behavior through javascript
US10476915B2 (en) * 2013-02-04 2019-11-12 Oracle International Corporation Real-time communication signaling gateway
US9648049B2 (en) 2013-02-04 2017-05-09 Oracle International Corporation System and method for extending IP multimedia subsystem to HTML5 environments
US9509745B2 (en) 2013-02-04 2016-11-29 Oracle International Corporation Java API for programming web real-time communication applications
US9473581B2 (en) 2013-02-04 2016-10-18 Oracle International Corporation Integrated web-enabled session border controller
US9712593B2 (en) 2013-02-04 2017-07-18 Oracle International Corporation Javascript API for WebRTC
US9331967B2 (en) 2013-02-04 2016-05-03 Oracle International Corporation Browser/HTML friendly protocol for real-time communication signaling
US9065844B1 (en) * 2013-05-22 2015-06-23 Sprint Spectrum L.P. Method and apparatus for managing sequential processing of messages
FR3007603A1 (fr) * 2013-06-21 2014-12-26 France Telecom Etablissement de communication entre une application web et un terminal
US9231915B2 (en) 2013-10-29 2016-01-05 A 10 Networks, Incorporated Method and apparatus for optimizing hypertext transfer protocol (HTTP) uniform resource locator (URL) filtering
US9769214B2 (en) * 2013-11-05 2017-09-19 Avaya Inc. Providing reliable session initiation protocol (SIP) signaling for web real-time communications (WEBRTC) interactive flows, and related methods, systems, and computer-readable media
US10200418B2 (en) 2014-01-31 2019-02-05 Avaya Inc. Call context conveyance
US9736194B1 (en) * 2015-03-06 2017-08-15 Amazon Technologies, Inc. System for establishing communication between devices
CN112187810A (zh) * 2020-09-30 2021-01-05 武汉中科通达高新技术股份有限公司 一种前端设备控制方法及装置
CN112887497B (zh) * 2020-12-24 2022-11-01 武汉船舶通信研究所（中国船舶重工集团公司第七二二研究所） 通信方法、装置和计算机存储介质
CN114979263B (zh) * 2022-03-28 2023-09-15 慧之安信息技术股份有限公司 基于Gin框架的高并发网关SIP代理方法和装置
US12519775B2 (en) * 2022-09-02 2026-01-06 Cisco Technology, Inc. Authentication (AuthN) and authorization (AuthZ) binding for secure network access

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5655015A (en) * 1994-02-18 1997-08-05 Aurora Systems, Inc. Computer-telephone integration system
US6937699B1 (en) * 1999-09-27 2005-08-30 3Com Corporation System and method for advertising using data network telephone connections
EP1093281A3 (en) 1999-10-15 2002-11-06 Nortel Networks Limited Call redirection through portable device
KR100576935B1 (ko) * 2003-12-22 2006-05-10 한국전자통신연구원 온톨로지 기반의 애드혹 서비스 검색 시스템 및 방법
JP4160092B2 (ja) * 2004-03-09 2008-10-01 ケイティーフリーテル カンパニー リミテッド パケットデータ課金細分化方法及びそのシステム
EP1679867A1 (en) * 2005-01-06 2006-07-12 Orange SA Customisation of VoiceXML Application
JP2006333034A (ja) * 2005-05-26 2006-12-07 Sony Corp 通信方法、通信システム、通信装置、プログラム
JP4735068B2 (ja) 2005-06-15 2011-07-27 沖電気工業株式会社 通信システム、通信方法及び通信装置
US9053461B2 (en) * 2005-10-07 2015-06-09 Yahoo! Inc. Instant messaging interoperability between disparate service providers
US8396922B2 (en) * 2005-11-18 2013-03-12 Aol Inc. Promoting interoperability of presence-based systems through the use of ubiquitous online identities
US7853271B2 (en) * 2006-02-01 2010-12-14 Qualcomm Incorporated Method and apparatus for interlocking communication and tracking applications in a wireless communication device
US8380698B2 (en) * 2006-02-09 2013-02-19 Ebay Inc. Methods and systems to generate rules to identify data items
ATE507681T1 (de) * 2006-02-28 2011-05-15 Telecom Italia Spa Kommunikationsserver mit einer dienstlogikausführungsumgebung
US20070253435A1 (en) * 2006-05-01 2007-11-01 Motorola, Inc. Method for providing reliable session communication within a network
JP4921551B2 (ja) * 2006-06-02 2012-04-25 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ＨｉＧＡのＩＭＳサービスプロキシ
US20080144655A1 (en) * 2006-12-14 2008-06-19 James Frederick Beam Systems, methods, and computer program products for passively transforming internet protocol (IP) network traffic
CN101212446A (zh) * 2006-12-29 2008-07-02 朗迅科技公司 移动多媒体内容共享应用系统
CN101330498A (zh) * 2007-06-20 2008-12-24 朗迅科技公司 VoIP网络中的SIP端点配置
US8090840B2 (en) * 2007-06-22 2012-01-03 At&T Intellectual Property I, L.P. Methods and apparatus to provide a call-associated content service
US9112902B2 (en) * 2007-11-13 2015-08-18 Optis Wireless Technology, Llc Service subscription associated with real time composition of services
US9220054B2 (en) * 2009-12-22 2015-12-22 Intel Corporation Enhanced service discovery mechanism in wireless communication system
WO2011121374A1 (en) * 2010-03-30 2011-10-06 Nokia Corporation Method and apparatus for device discovery through beaconing
US9712285B2 (en) * 2011-11-18 2017-07-18 Lg Electronics Inc. Method and device for searching for service for terminal using gas protocol
US8953478B2 (en) * 2012-01-27 2015-02-10 Intel Corporation Evolved node B and method for coherent coordinated multipoint transmission with per CSI-RS feedback
US9474094B2 (en) * 2012-08-07 2016-10-18 Intel Corporation Methods and arrangements to establish peer-to-peer link

Also Published As

Publication number Publication date
US20110072144A1 (en) 2011-03-24
EP2250786A1 (en) 2010-11-17
US9544375B2 (en) 2017-01-10
US20150222714A1 (en) 2015-08-06
ATE524008T1 (de) 2011-09-15
PL2250786T3 (pl) 2012-03-30
US9094463B2 (en) 2015-07-28
EP2250786B1 (en) 2011-09-07
WO2009106117A1 (en) 2009-09-03
WO2009106117A8 (en) 2009-11-19

Similar Documents

Publication Publication Date Title
ES2373357T3 (es) Técnica para realizar la conversión de señalización entre los dominios http y sip.
TWI358930B (en) System and method for originating a sip call via a
ES2306238T3 (es) Aparato y metodo de acceso a un subsistema multimedia ip.
ES2389250T3 (es) Un método para autenticar un terminal de usuario en un subsistema multimedia IP
ES2375871T3 (es) Acceso de grupo a un servicio del subsistema multimedia ip.
JP4806400B2 (ja) Ｉｐネットワークの信頼できるドメインにおけるアイデンティティの処理
US10142341B2 (en) Apparatus, system and method for webRTC
WO2011079522A1 (zh) 一种认证方法、系统和装置
US8713634B2 (en) Systems, methods and computer program products supporting provision of web services using IMS
BRPI0520701B1 (pt) Método para fornecer acesso aos serviços de multimídia para dispositivos de comunicação conectados a uma rede privada, e, arranjo em um ponto de conexão de multimídia de uma rede privada
US20130080648A1 (en) Session initiation from application servers in an ip multimedia subsystem
WO2006099815A1 (en) A method for implementing the user registering in the ip multimedia subsystem and the system thereof
JP5718827B2 (ja) 同じパブリックユーザｉｄを共有するいくつかのユーザ機器を区別する方法および装置
CN102144380B (zh) 端对端地址转移
ES2327274T3 (es) Tratamiento o gestion de mensajes en un subsistema multimedia ip.
US20080120705A1 (en) Systems, Methods and Computer Program Products Supporting Provision of Web Services Using IMS
EP1894387B1 (en) Method and apparatus for utilizing network services in a manner substantially transparent to service endpoints
US7940748B2 (en) Systems, methods and computer program products supporting provision of web services using IMS
EP2119178B1 (en) Method and apparatuses for the provision of network services offered through a set of servers in an ims network
JP2007233803A (ja) Ｈｔｔｐ対応端末をｓｉｐ対応サーバに接続する代理接続方法、プロキシサーバ及びプログラム
KR102507608B1 (ko) Did를 통해 비식별성을 확보한 멀티미디어 커뮤니케이션의 세션 생성 시스템 및 방법
CN102082769A (zh) Ims终端在获取非ims业务时的认证系统、装置及方法
WO2009068115A1 (en) Methods for secure sip signalling to a destination ip address being a cryptographi cally generated address (cga)