ES2352164T3 - Procedimiento de transcodificación de sesiones de tipo sip. - Google Patents
Procedimiento de transcodificación de sesiones de tipo sip. Download PDFInfo
- Publication number
- ES2352164T3 ES2352164T3 ES08103823T ES08103823T ES2352164T3 ES 2352164 T3 ES2352164 T3 ES 2352164T3 ES 08103823 T ES08103823 T ES 08103823T ES 08103823 T ES08103823 T ES 08103823T ES 2352164 T3 ES2352164 T3 ES 2352164T3
- Authority
- ES
- Spain
- Prior art keywords
- transcoding
- sip
- authentication
- client device
- server
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 230000004044 response Effects 0.000 claims description 27
- 230000009471 action Effects 0.000 claims description 19
- 230000004913 activation Effects 0.000 claims description 6
- 238000011282 treatment Methods 0.000 claims description 6
- 230000002093 peripheral effect Effects 0.000 claims description 4
- 238000012545 processing Methods 0.000 claims description 4
- 238000004519 manufacturing process Methods 0.000 claims description 3
- 238000006243 chemical reaction Methods 0.000 claims description 2
- 230000006978 adaptation Effects 0.000 claims 1
- 230000000977 initiatory effect Effects 0.000 abstract description 3
- 230000002085 persistent effect Effects 0.000 description 7
- 238000004891 communication Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 235000014510 cooky Nutrition 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000009792 diffusion process Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- 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
-
- 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]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Multimedia (AREA)
- General Business, Economics & Management (AREA)
- Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Telephonic Communication Services (AREA)
- Use Of Switch Circuits For Exchanges And Methods Of Control Of Multiplex Exchanges (AREA)
- Exchange Systems With Centralized Control (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Procedimiento de transcodificacion de al menos una sesion caracterizado porque la sesion transcodificada es una sesion del tipo SIP y porque dicho procedimiento incluye las siguientes etapas: -una etapa (201), iniciada por un dispositivo cliente, de interrogacion de un dispositivo de transcodificacion, dicha interrogacion se realiza a traves de al menos una solicitud de interrogacion que incluye unos datos de identificacion que permiten una primera autentificacion del dispositivo cliente por el dispositivo de transcodificacion de sesiones del tipo SIP, -si (203, 204) se consigue la primera autentificacion entonces: -una etapa (205), iniciada por el dispositivo de transcodificacion, de segunda autentificacion del dispositivo de transcodificacion de sesiones del tipo SIP sobre un servidor del tipo SIP, unos datos de identificacion de la segunda autentificacion que dependen de al menos uno de los primeros datos de identificacion, -si se logra la segunda autentificacion entonces: -una etapa (205) de establecimiento de una conexion del tipo SIP entre el dispositivo de transcodificacion y el servidor del tipo SIP, -una etapa (208), ejecutada por el dispositivo de transcodificacion, respuesta a la pregunta iniciada por el dispositivo cliente en la que el dispositivo de transcodificacion produce un mensaje de interfaz que depende al menos del resultado de la segunda autentificacion, -una etapa (209) ejecutada por el dispositivo cliente, de interpretacion del mensaje de interfaz, actualizando dicha interpretacion el estado de un periferico de salida del dispositivo cliente, -mientras que, cuando se desea una autentificacion robusta, entre la etapa de autentificacion del cliente con el dispositivo de transcodificacion y la etapa de autentificacion del dispositivo de transcodificacion de sesiones del tipo SIP con el servidor SIP, incluye ademas la etapa siguiente durante la que un dispositivo pasarela entre el dispositivo cliente y la red, que incluye una tarjeta SIM integrada, establece un tunel IP para acceder a la infraestructura de acceso IMS del operador utilizando dicha tarjeta SIM para autentificarse con el operador.
Description
El invento tiene como objeto un procedimiento de transcodificación de sesiones del tipo SIP.
El dominio del invento es el de las telecomunicaciones y más concretamente el de el acceso a servicios a través de una red de telecomunicaciones.
En el estado de la técnica se conoce la arquitectura IMS (IP Multimedia Subsystem, subsistema multimedia sobre IP), arquitectura que garantiza la interoperabilidad de diferentes bloques de una red de un operador y la interoperabilidad entre las redes de operadores de telecomunicaciones.
La arquitectura IMS está construida bajo las normas y recomendaciones publicadas por el 3GPP para el 3rd Generation Partnership Project o asociación para un proyecto de tercera generación. Se trata de un grupo de trabajo del ETSI, que ha definido la 3G (tercera generación de redes móviles) y sus evoluciones.
La arquitectura IMS se basa, entre otros en el protocolo SIP. SIP como Session Initiation Protocol o protocolo de iniciación de sesiones, definido por el grupo de normalización IEFT, SIP es un nuevo lenguaje de señalización adaptado a las sesiones multimedia y adaptado al establecimiento y a la gestión de conexiones de terceros o de terceros a servidores.
Esta arquitectura se basa también en uno, o varios servidores CSCF (Call Session Control Function como Función de control de sesión de llamada) para gestionar las solicitudes SIP entre los terminales y los servidores de aplicaciones, esta función incluye tres grandes módulos: P-CSFC (proxy, servidor mandatario), S-CSCF (serving, servidor) e I-CSCF( interrogating, servidor de interrogación).
Un servidor CSCF está a su vez conectado a un servidor HSS Home Subscriber Server (servidor de gestión de abonados), base de datos que contiene los perfiles de los abonados. Interviene en su autentificación y autorización de acceso a los servicios. Depende de un servidor HLR en una red móvil pre-R5 3GPP.
Esta arquitectura se ha vuelto independiente de la red de acceso es decir del soporte físico que permite el acceso. En la práctica cualquier dispositivo compatible con una versión del protocolo IP puede conectarse e interactuar con una arquitectura IMS.
En dicha arquitectura se encuentran también servidores de aplicaciones. Albergan las aplicaciones tratadas mediante IMS, como los servicios ligados a la voz, la videoconferencia o la gestión de presencia.
El documento US 2005/0044188A1 divulga un dispositivo de conversión HTTP-SIP.
Uno de los problemas del estado de la técnica es que una arquitectura IMS está basada en el protocolo SIP tal y como se prevé en el 3GPP (es decir tal y como se prevé por la ETSI) mientras que los aparatos compatibles con el protocolo SIP lo son también con el protocolo SIP IETF.
Otro problema del estado de la técnica es que una aplicación SIP está instalada en un dispositivo con su propio controlador SIP. Por tanto dos aplicaciones del tipo “Smartphone” (teléfono inteligente) instaladas en el mismo dispositivo van a entrar en conflicto. Si no entran en conflicto serán incapaces de todas formas de interactuar una con la otra en el ámbito de la misma sesión SIP.
Por ejemplo en el caso de una llamada entrante habrá un conflicto entre las dos aplicaciones Smartphone para determinar la que va a gestionar la llamada entrante.
Igualmente, por ejemplo en el caso en el que una primera aplicación Smartphone gestione ya una primera comunicación y que una segunda comunicación entre, entonces la segunda aplicación Smartphone va a gestionar la segunda comunicación emitiendo un timbre sin indicar al llamante que el llamado ya está en comunicación (ocupado). Aquí se trata de una explotación no funcional.
En el invento se resuelve este problema gracias a un dispositivo intermedio entre la arquitectura IMS y el dispositivo cliente. Este dispositivo intermedio lleva a cabo un procedimiento de transcodificación de sesión SIP. Este procedimiento cumple al menos tres funciones:
-paliar las diferencias entre los protocolos SIP IETF y SIP 3GPP,
-asegurar la convergencia de las diferentes sesiones con el destino y/o que provengan de los dispositivos cliente conectados al dispositivo intermedio en una única sesión SIP,
-asegurar la compatibilidad de un dispositivo cliente con los flujos de los medios conectados a las sesiones en destino y/o que provengan de los dispositivos cliente conectados al dispositivo intermedio.
Para ello el procedimiento de transcodificación necesita y propone dos interfases:
-una interfaz HTTP atacada por el dispositivo cliente que ya no necesita ser SIP sino únicamente ser capaz de devolver/jugar e interactuar con los flujos de los medios recibidos,
-una interfaz SIP a través de la cual el dispositivo intermedio comunica con la arquitectura IMS.
El procedimiento según el invento se comporta pues desde el punto de vista de la red como un cliente SIP, y desde el punto de vista cliente como un servidor Web. Un servidor Web es un servidor que basa sus comunicaciones principalmente en el protocolo HTTP. Esto simplifica en gran medida el acceso de los dispositivos cliente a las arquitecturas IMS.
El invento tiene pues como objeto un procedimiento de transcodificación de al menos una sesión caracterizado porque la sesión transcodificada es una sesión del tipo SIP y porque dicho procedimiento incluye las siguientes etapas:
-una etapa, iniciada por un dispositivo cliente, de interrogación de un dispositivo de transcodificación, dicha interrogación se hace al menos a través de una solicitud de interrogación que incluye datos de identificación que permiten una primera autentificación del dispositivo cliente por el dispositivo de transcodificación de sesiones del tipo SIP,
-si la primera autentificación es positiva entonces:
-una etapa, iniciada por el dispositivo de transcodificación, de segunda autentificación del dispositivo de transcodificación de sesión del tipo SIP sobre un servidor del tipo SIP (tipo CSCF), unos datos de identificación de la segunda autentificación que dependen de al menos uno de los primeros datos de identificación,
-si la segunda autentificación es positiva entonces:
-Una etapa de establecimiento de una conexión del tipo SIP entre el dispositivo de transcodificación y el servidor del tipo SIP,
-una etapa, de ejecución por el dispositivo de transcodificación, en respuesta a la pregunta iniciada por el dispositivo cliente en la que el dispositivo de transcodificación produce un mensaje de interfaz dependiendo al menos del resultado de la segunda autentificación,
-una etapa, de ejecución por el dispositivo cliente, de interpretación del mensaje de interfaz, actualizando dicha interpretación el estado de un periférico de salida del dispositivo cliente.
En una variante, el procedimiento según el invento se caracteriza también porque, cuando se desea una autentificación muy fuerte, entre la etapa de autentificación del cliente sobre el dispositivo de transcodificación y la etapa de autentificación del dispositivo de transcodificación de las sesiones del tipo SIP con un servidor SIP, incluye además la etapa siguiente durante la que se establece un túnel IP entre un dispositivo pasarela y entre el dispositivo cliente y la red, que incluye en este caso una tarjeta SIM integrada, para acceder a la infraestructura de acceso IMS del operador utilizando dicha tarjeta SIM integrada para autentificarse con el operador.
En una variante, el procedimiento según el invento se caracteriza también porque incluye también las siguientes etapas:
-Una etapa, realizada por el dispositivo cliente, de pregunta de actualización efectuada regularmente hacia el dispositivo de transcodificación,
-una etapa, realizada por el dispositivo de transcodificación como respuesta a la recepción de la pregunta de actualización, de producción y emisión de un mensaje de interfaz,
-una etapa, realizada por el dispositivo cliente, de interpretación del mensaje de interfaz, actualizando dicha interpretación el estado de un periférico de salida del dispositivo cliente.
En una variante, el procedimiento según el invento está también caracterizado porque el contenido de un mensaje de interfaz depende de los datos recibidos por el dispositivo de transcodificación vía la conexión del tipo SIP, los datos recibidos a través de esta conexión se almacenan en una memoria de estado, estando el contenido de estas memoria de estado asociado al dispositivo cliente.
En una variante, el procedimiento según el invento está también caracterizado porque un mensaje de interfaz incluye códigos con instrucciones que corresponden a la descripción de una opción que debe ser propuesta a la selección de un usuario a través de una interfaz del dispositivo cliente, la selección de esta opción provoca la emisión de un mensaje de activación de la opción hacia el dispositivo de transcodificación.
En una variante, el procedimiento según el invento está también caracterizado porque un mensaje de activación incluye al menos un código instrucción correspondiente a una acción que debe efectuar el dispositivo de transcodificación en relación con el servidor del tipo SIP, el tratamiento de un mensaje de activación incluye las etapas siguientes realizadas por el dispositivo de transcodificación:
-Negociación de una sesión con el servidor del tipo SIP,
-conexión con al menos un servidor de aplicación conforme al resultado de la negociación,
-transcodificación de los datos recibidos del servidor de aplicación en un formato inteligible por el dispositivo cliente,
-transmisión de datos codificados hacia el dispositivo cliente.
En una variante, el procedimiento según el invento está también caracterizado porque las preguntas emitidas por el dispositivo cliente y el tratamiento de las respuestas a estas preguntas son realizadas por una aplicación del tipo navegador Internet.
En una variante, el dispositivo de transcodificación realiza una puesta a punto de los datos recibidos de los servidores de aplicación y una composición modulable de estos servicios en el seno de una página WEB única y dinámica, el dispositivo de transcodificación almacena entonces el perfil de servicio del usuario y da igualmente la posibilidad al usuario de compartir este perfil con una comunidad de usuarios.
En una variante, el procedimiento según el invento está también caracterizado porque la aplicación del tipo navegador Internet incluye de forma nativa o bajo la forma de módulos de extensión al menos un interpretador de datos apto para interpretar los datos transcodificados por el dispositivo de transcodificación.
En una variante, de igual manera que situándose el dispositivo de transcodificación entre el cliente y el servidor SIP, asegura una protección de este, este último, del mismo modo, se inmiscuye en medio de un flujo de medios sin transcodificarlo para ocultar la dirección IP del cliente y protegerlo, jugando por tanto el papel de servidor mandatario.
En una variante, el dispositivo de transcodificación marca los flujos con el fin de indicar a las redes la prioridad en términos de ”calidad de servicio” de dichos flujos.
Se comprenderá mejor el invento con la lectura de la descripción siguiente y el examen de las figuras que le acompañan. Estas son presentadas a título indicativo y no limitativo del invento. Las figuras muestran:
Figura 1: Una ilustración de los dispositivos que ejecutan el procedimiento según el invento,
Figura 2: Una ilustración de las etapas del procedimiento según el invento.
La figura 1 muestra una primera red 101 que se va a denominar aquí red local. Red local es aquí empleado en el sentido de pequeña red en oposición a una red del tipo Internet. La red 101 incluye un dispositivo 102 cliente y un dispositivo 103 pasarela.
El dispositivo 102 cliente es, por ejemplo, un teléfono móvil conectado al dispositivo 103 pasarela mediante una conexión OTA (Over The Air, a través del aire) del tipo Wi-Fi. En otro ejemplo el dispositivo 102 cliente es un ordenador individual (PC) conectado al dispositivo 103 pasarela a través de una conexión OTA como una conexión cableada del tipo Ethernet.
El dispositivo 103 es la “caja” de un operador suministrador de acceso a Internet o a cualquier otra red de comunicación que soporte los protocolos IP (Internet Protocol que existe actualmente en las versiones 4 y 6). Dicha caja asegura las interfaces eléctrica y lógica entre la red 101 y una red 104 del tipo Internet. Aquí se considera que se trata de una red Internet en sí misma. Una red del tipo Internet es una red abierta que permite acceder a un gran número de dispositivos y de servicios. Este tipo de redes es opuesto a las redes privadas de empresas o domésticas que incluyen un número limitado de dispositivos a los que únicamente el personal autorizado puede conectarse.
La figura 1 muestra que la red 104 permite acceder a una red 105, que es la mayor parte del tiempo una parte de la red 104, organizada según una arquitectura IMS.
El dispositivo 102 incluye:
-Un microprocesador 106,
-una memoria de programa 107,
-una memoria 108 de subprogramas, P1 a PN, de devolución del flujo, dicho subprograma se denomina player (jugador), un plugin (conectar con) y/o un addon (añadido, mejora, extensión). Dicho subprograma permite incrementar la funcionalidad es de otro programa formando parte de este.
-Una memoria 109 de configuración, y
-una interfaz 110 de conexión a otro dispositivo.
Los elementos 106 a 110 están interconectados mediante un bus 111.
Cuando se presta una acción a un dispositivo, esta acción es efectuada por un microprocesador del dispositivo controlado mediante códigos con instrucciones grabadas en una memoria del programa de dicho dispositivo.
Cuando se ejecuta una acción de un programa, esta acción corresponde a la ejecución de códigos de instrucciones correspondientes a la acción mediante un microprocesador de un dispositivo que incluye una memoria de programa que incluye en sí misma los códigos con instrucciones correspondientes al programa al que presta la acción.
La memoria 107 incluye al menos una zona 107a que incluye códigos con instrucciones correspondientes a un navegador Internet. Dicho navegador permite producir y emitir solicitudes hacia un servidor HTTP e interpretar la respuesta del servidor HTTP para producir una página web, es decir una imagen que incluye eventualmente uno o varios elementos activos, que se pueden mostrar en una pantalla (no representada) del dispositivo 102. Un elemento activo es, por ejemplo, código según un lenguaje conocido del navegador. Dichos lenguajes son, por ejemplo, Ecma Script, Javascript, Jscript o también Java. Una página web incluye también vínculos de “hipertexto” cuya selección mediante un dispositivo de puntero (no representado) del dispositivo 102 permite controlar la emisión de una nueva solicitud hacia un servidor HTTP. Los servidores HTTP son también conocidos bajo el nombre de servidor web o Internet.
La interfaz 110 incluye circuitos electrónicos que permiten la conexión del dispositivo 102 a una red. En modos de realización preferidos la interfaz 110 permite conectar el dispositivo 102 a la red 101 y es del tipo Wi-Fi o Ethernet según la estructura de la red 101. La interfaz 110 es una interfaz Wi-Fi si la red 101 incluye un punto de acceso Wi-Fi. La interfaz 110 es un conector Ethernet si la red 101 incluye un dispositivo del tipo conmutador Ethernet.
Como se ha precisado anteriormente, la interfaz 110 permite integrar el dispositivo 102 a la red 101. Esto permite al dispositivo 102 dialogar con los otros dispositivos de la red 101.
La memoria 109 es una memoria de configuración que incluye los parámetros que permiten al dispositivo 101 conectarse al dispositivo 103 e identificarse. El contenido de la memoria 109 permite pues reconstituir una dirección según la sintaxis siguiente o equivalente:
http://login:pass@box.local:port/action
En esta dirección se encuentra:
-http: el protocolo utilizado para conectarse al dispositivo 103, por tanto la elección de la aplicación para realizar esta conexión será un navegador Internet apto para gestionar el protocolo http,
-login: un identificador,
-pass: La palabra clave asociada al identificador,
-box.local: La dirección local del dispositivo 103 en la red 101.
-port: Un puerto según uno de los protocolos IP. En general el puerto por defecto para el protocolo http es el puerto 80.
Se utilizará una dirección IP dedicada de la red IP local,
-action: La acción que permite responder a la solicitud de conexión. El dispositivo 103 incluye:
-Un microprocesador 111,
-una memoria de programa 112, -una memoria 113 de transcodificación de autentificación,
-una memoria 114 de transcodificadores, T1 a Tn, de flujo,
-una memoria 115 de descripción de sesión,
-una interfaz 116 de conexión a la red 101,
-una interfaz 117 de conexión a la red 104.
Los elementos 111 a 117 están interconectados a través de un bus 118.
La memoria 112 incluye varias zonas en las que al menos:
-Una zona 112a que incluye códigos con instrucciones correspondientes a la ejecución de un servidor HTTP (Hyper Text Transfer Protocol para protocolo de transferencia de hipertexto). En nuestro ejemplo se considera que un servidor HTTP es un servidor HTTP dinámico, es decir apto para efectuar tratamientos que van más allá del servicio de ficheros. Estos tratamientos dinámicos corresponden a la interpretación de scripts redirigidos en un lenguaje de programación dinámico. Dichos lenguajes son, por ejemplo, ASP, PHP, Java, Perl,Python… por citar únicamente los más conocidos. El resultado de estos tratamientos es devuelto a través de un mensaje HTTP. Se habla pues siempre de servidor HTTP,
-una zona 112b que incluye códigos con instrucciones correspondientes a la ejecución del protocolo SIP,
-una zona 112c que incluye códigos con instrucciones para la transcodificación de flujo. En la práctica los códigos con instrucciones de esta zona hacen uso del transcodificador de la memoria 113 en función de los parámetros de la memoria 114 para transcodificar un flujo multimedia recibido por el dispositivo 104 después de una solicitud del dispositivo 103. El flujo transcodificado es emitido hacia el dispositivo 102 en respuesta a su solicitud.
La memoria 103 permite asociar parámetros de autentificación HTTP a parámetros de autentificación SIP. Un identificador y una palabra clave HTTP son pues transcodificados en identificador y palabra clave SIP a través de esta memoria. En una realización esta memoria es una tabla que incluye dos columnas.la primera columna incluye dos parejas [identificador, palabra clave] HTTP, que se hacen corresponder con la segunda columna con dos parejas [identificador, palabra clave] SIP.
La memoria 113 incluye transcodificadores, es decir programas de transcodificado de flujo. Un programa de transcodificación de flujo acepta como entrada datos formateados según un tipo de flujo y produce en la salida datos formateados según otro tipo de flujo. De entre los tipos de flujo conocidos se citan al menos todos los que son aceptables para el parámetro “Content-Type” (tipo de contenido) del protocolo HTTP y más particularmente los tipos y subtipos definidos en la RFC2046 y las RFC asociadas. Todos estos tipos no se tienen en cuenta para una ejecución razonable del invento. Únicamente los más utilizados son transcodificados.
La memoria 114 es una memoria de sesión en la que son almacenados los parámetros F1 a Fn, de una sesión SIP. Estos parámetros son de hecho los contenidos de respuestas y los contenidos de mensajes de advertencia recibidos de la arquitectura IMS consecutivamente con la apertura de una sesión SIP.
La figura 2 muestra una etapa de 201 realizada por el dispositivo 102 de conexión al dispositivo 103. En la etapa 201 un usuario del dispositivo 102 selecciona un comando de conexión en un menú. La selección de este comando tiene como efecto producir en el dispositivo 201 una solicitud de conexión según los parámetros grabados en la memoria 109 de configuración.
El dispositivo 102 invoca la aplicación por defecto designada para gestionar el protocolo HTTP. Esta aplicación es, mediante configuración del dispositivo 102, un navegador de Internet. En efecto el contenido de la memoria 109 es una URL (Universal Resource Locator, como localización universal de un recurso) cuyo protocolo es el protocolo HTTP. En todos los dispositivos que no se corresponden con dispositivos de tratamiento automatizado, este tipo de URL está asociado por defecto a un navegador de Internet.
El navegador de Internet invocado emite una solicitud 202 de conexión conforme al contenido de la memoria 109 de configuración. La solicitud 202 incluye al menos un campo “action” y en una variante preferida unos campos “log” y “pass”.
La solicitud 202 es encaminada por la red 101 hasta el dispositivo 103 utilizando el protocolo HTTP.
En una etapa 203, el dispositivo 103 recibe la solicitud 202. El protocolo utilizado para la solicitud permite al dispositivo 203 determinar que la solicitud debe ser tratada por la aplicación servidor HTTP. El contenido del campo ”action” permite a la aplicación servidor HTTP de terminar que acción debe emprender. En el caso de la solicitud 202 se trata de una acción de conexión a una arquitectura IMS y más concretamente a un servidor CSCF. Como la solicitud 202 incluye también un campo “log” y un campo “pass”, la aplicación servidora no necesita más información para realizar la acción.
En una variante, la solicitud 202 no incluye los campos “log” y “pass”. En este caso, la aplicación servidora HTTP pone el tratamiento de la solicitud en espera y emite una búsqueda de solicitud de elementos de autentificación. El tratamiento de la solicitud 202 se queda en espera hasta que los elementos de autentificación hayan sido asumidos.
Los elementos de autentificación, es decir el contenido de los campos “log” y “pass” permiten a la aplicación servidora HTTP efectuar una búsqueda en la tabla 112 para determinar si una línea de la tabla 112 corresponde a los elementos de autentificación HTTP sometidos a través de la solicitud 202. Si no se encuentra tal línea, entonces la aplicación servidora HTTP pasa a una etapa 204 de producción y de emisión de un mensaje de error. En caso contrario la aplicación servidora HTTP pasa a una etapa 205 de conexión SIP.
El mensaje de error producido en la etapa 204 es un mensaje 206 según el protocolo HTTP señalando que el acceso a la acción solicitada es denegado.
En una etapa 207 el dispositivo 102, y más concretamente la aplicación de navegación de Internet, recibe una respuesta a la solicitud 202. Esta respuesta es un mensaje de error que es interpretado por la aplicación navegador de Internet, se muestra un resultado de la interpretación en una pantalla del dispositivo 102. En este caso, el procedimiento termina aquí, salvo que se sometan nuevos datos a la autentificación HTTP.
En la etapa 205 la aplicación utiliza los elementos de autentificación SIP encontrados en la etapa 203 para producir y emitir una solicitud de conexión SIP. Los elementos de autentificación SIP incluyen al menos una dirección de un servidor de apertura de conexión de una arquitectura IMS, es decir un servidor CSCF, un identificador SIP y una palabra clave SIP asociada a este identificador SIP. La aplicación servidora HTTP utiliza entonces los códigos con instrucciones de la zona 112b para intentar abrir una sesión SIP. En caso de fallo de la tentativa de apertura de sesión SIP entonces la aplicación servidora HTTP pasa a la etapa 204. En caso de éxito la aplicación servidora HTTP pasa a una etapa 208 de producción y de emisión de un menú.
En una variante del invento el dispositivo 103 incluye una configuración que le permite asegurar sus intercambios con el servidor CSCF. Esta configuración incluye por ejemplo una llave de cifrado que permite el establecimiento de un túnel llamado IpSec entre el dispositivo 103 y el servidor CSCF. Esta configuración está, por ejemplo, grabada en una tarjeta SIM (tarjeta de microcircuito). Dicha tarjeta de microcircuito es entonces distribuida por el operador al que pertenece el servidor CSCF.
En la etapa 208 la aplicación servidora HTTP almacena en la memoria 114 una nueva línea que se corresponde con las informaciones recibidas en respuesta a la apertura de sesión SIP. Esta nueva línea está asociada mediante un identificador de sesión a la aplicación navegador de Internet que haya emitido la solicitud 202. Cada nueva solicitud de la aplicación navegador de Internet tendrá que incluir este identificador para permitir a la aplicación servidora HTTP asociar a la solicitud una línea en la memoria 114. Se obtiene este resultado, por ejemplo, mediante un intercambio de “cookie” entre la aplicación servidora HTTP y la aplicación navegador de Internet.
Las informaciones grabadas en la memoria 114 son también llamadas datos de sesión. En el ejemplo que sigue se considera que el identificador de sesión es S1. Se habla entonces de la sesión S1 y de datos de la sesión S1. Esta sesión S1 está también asociada a la conexión SIP.
En la etapa 208, además de emitir una “cookie” que incluye un identificador de sesión, la aplicación servidora HTTP produce unos códigos con instrucciones correspondientes a un menú según los datos de la sesión S1. Estos datos dependen de los derechos asociados a las informaciones de autentificación SIP mediante la arquitectura IMS.
En la práctica dicho menú incluye unos vínculos que permiten acceder a difusiones multimedia (texto, audio, video), a servicios de telefonía, a servicios de videoconferencia, a servicios de información en tiempo real… siendo la lista no exhaustiva.
En una variante la composición de este menú para el dispositivo 103 está también realizada en función de un perfil de usuario almacenado en una memoria de perfil del dispositivo 103. Dicho perfil permite, por ejemplo:
-especificar un orden para los elementos del menú,
-especificar qué elementos del menú deben ser particularmente resaltados,
-especificar qué elementos del menú deben estar ocultos,
-especificar estilos gráficos para los elementos del menú,
-…
Esta lista no es exhaustiva. Cada elemento de esta lista puede además estar asociado a datos de calendario que permiten hacer evolucionar el perfil en función de la fecha o del periodo del día, de la semana, del mes, del año…
En ésta variante el usuario del dispositivo 103 tiene la posibilidad de compartir el contenido de su perfil con otros usuarios, o grupos de usuarios, especificados por este. Este conjunto de usuarios es entonces llamado comunidad.
Este perfil permite pues modular la producción de la página “WEB” dinámica representando el menú. Éste perfil confiere también un carácter único a esta página “WEB”.
Una vez que se ha producido el menú se emite hace el dispositivo 102 como respuesta a la solicitud 202. En una etapa 209 la aplicación navegador de Internet recibe una respuesta a una solicitud anteriormente emitida. El contenido de esta respuesta es interpretado y devuelto/jugado según el contenido de la respuesta. Esto se traduce en la modificación de lo que se muestra en pantalla del dispositivo 101 y/o por la difusión de sonido por el dispositivo 101. Desde el punto de vista del dispositivo 102 y de la aplicación navegador de Internet que ejecuta, todo sucede como si estuviera conectado a un servidor HTTP clásico. El dispositivo 102 emite solicitudes HTTP e interpreta las respuestas a estas solicitudes.
Esta interpretación provoca al menos que se muestre un menú que incluye vínculos activables por un usuario del dispositivo 102.
En una variante del invento la solicitud 202 de conexión incluye también informaciones relativas a las aptitudes de rendimiento del navegador de Internet realizado. Esto permite a la aplicación servidora HTTP saber qué flujos multimedia pueden ser interpretados por la aplicación de navegador de Internet.
En el invento la arquitectura IMS ve el dispositivo 103 como un cliente SIP y se comporta en lo relativo a este como en lo relativo a un cliente SIP. El hecho de registrarse/conectarse a una arquitectura IMS permite, entre otros, recibir llamadas vocales y/o video. En efecto, esta conexión corresponde a una asignación de recursos permanentes mientras que dure la conexión, se habla de conexión persistente. En oposición a estas conexiones persistentes están las conexiones temporales que únicamente duran el tiempo requerido para la resolución de una transacción, es decir el tiempo requerido para el intercambio de una pregunta y de su respuesta, la emisión de la respuesta finaliza la conexión. Una conexión persistente es finalizada por la emisión provocada por un usuario de un mensaje de desconexión. Esto permite a la arquitectura IMS “empujar” los datos hacia el dispositivo a través de la conexión persistente establecida en la etapa 205. Estos datos empujados son, por ejemplo, la señal de una llamada de voz entrante, una información correspondiente a un servicio de información en tiempo real, no siendo la lista exhaustiva. Estos datos son almacenados como datos de sesión.
En el invento una respuesta de la aplicación servidora HTTP a la aplicación navegador de Internet incluye un elemento activo cuyo principio es el siguiente:
-desencadenamiento de una cuenta atrás,
-en caso de fallo de la cuenta atrás emisión de una solicitud de refresco de la pantalla actual de la aplicación del navegador de Internet.
En la etapa 209 la aplicación del navegador de Internet pasa a una etapa 210 de espera de un evento.
Los eventos posibles son al menos:
-Llegada a cero de la cuenta atrás,
-selección de un enlace por un usuario del dispositivo 102.
En la hipótesis en la que se sale de la etapa 201 como consecuencia de haber llegado a cero la cuenta atrás, entonces la aplicación navegador de Internet emite la aplicación servidora HTTP la misma solicitud que la que provocaría mostrar la pantalla actual en la pantalla del dispositivo 102. Esta solicitud es la que sería emitida si el usuario del dispositivo 102 utilizará la funcionalidad de actualización de la aplicación del navegador de Internet.
En una variante del invento esta actualización es realizada a través de las tecnologías AJAX que permiten actualizar únicamente una parte de la página Web. Esto permite un mejor rendimiento visual para el usuario impidiendo una impresión de parpadeo de la pantalla.
En todos los casos una vez realizada la actualización, la cuenta atrás se reinicia.
La solicitud de actualización es tratada como en la etapa 208 teniendo en cuenta el estado actual de los datos de sesión que han podido evolucionar a través de la conexión persistente SIP.
En la hipótesis en la que se sale de la etapa 201 después de una activación de un enlace por el usuario, la aplicación navegador de Internet emite hacia el dispositivo 103 una solicitud correspondiente a los parámetros del enlace activado. Estos parámetros incluyen al menos una información de acción.
Consideremos el caso en el que el enlace activado corresponde a una solicitud de visualización de un flujo multimedia. En este caso estos parámetros incluyen también un identificador de flujo multimedia.
En una etapa 212 la aplicación servidora HTTP recibe la solicitud 211 que incluye una información de acción relativa a la visualización de un contenido multimedia. En la etapa 212 la aplicación servidora HTTP inicia una negociación SIP sobre el contenido multimedia. Para ello transcodifica la solicitud HTTP en una solicitud SIP que es emitida hacia la infraestructura IMS a través de la conexión persistente. Después pasa a una etapa 213 en la que espera la respuesta a la solicitud SIP.
Si esta respuesta es positiva, es decir si las informaciones de autentificación SIP correspondientes a la conexión persistente están asociadas, en la arquitectura IMS, a derechos suficientes para satisfacer la solicitud, entonces la aplicación servidora HTTP pasa a una etapa 214 de recepción de los flujos multimedia correspondiente a la solicitud SIP. Estos flujos multimedia son descritos en la respuesta de la arquitectura IMS a la solicitud SIP. En este caso la respuesta SIP OK incluye una descripción de los flujos multimedia requeridos para satisfacer la solicitud
211. Si esta respuesta es negativa entonces la aplicación servidora HTTP actualizar los datos de la sesión S1 en función de esta respuesta y pasa a la etapa 208.
En la etapa 214 la aplicación servidora HTTP utiliza las informaciones contenidas en la solicitud SIP OK para conectarse a un servidor de flujo multimedia. Estas informaciones incluyen la descripción de al menos un flujo multimedia. Esta descripción incluye al menos una URL del flujo. De forma opcional estas informaciones incluyen el tipo de flujo. Si estas informaciones no incluyen el tipo de flujo entonces el hecho de emitir una solicitud utilizando la URL del flujo va a conducir a la recepción de mensajes correspondientes a este flujo, incluyendo los encabezados de estos mensajes el tipo de flujo. A partir del tipo de flujo y de los datos de sesión, en particular de los datos de sesión relativos a las capacidades de rendimiento de la aplicación navegador de Internet, la aplicación servidora HTTP determina si es útil transcodificar el flujo.
Es útil transcodificar el flujo si el tipo del flujo no aparece en las capacidades de rendimiento de la aplicación navegador de Internet. En este caso hay al menos dos posibilidades:
-ya sea que el dispositivo 103 exacto para ejecutar el programa que permite mostrar el flujo, en este caso la aplicación servidora HTTP emite un mensaje para proponer la actualización de la aplicación navegador de Internet con un programa que permita tener en cuenta este tipo de flujo,
-ya sea que el dispositivo 103 no es apto para ejecutar el programa que permite mostrar el flujo, en este caso el flujo debe ser transcodificado. Aquí hay dos razones que pueden hacer que el dispositivo 103 no sea apto: ya sea una incompatibilidad material, ya sea una parametrización que impida las actualizaciones.
En el caso en el que se requiera una transcodificación, la aplicación servidora de Internet elige un tipo de flujo equivalente al tipo de flujo a transcodificar de entre los tipos de flujo soportados por la aplicación navegador de Internet. Una vez que se ha elegido el tipo equivalente, la aplicación servidora utiliza, en una etapa 215, los códigos con instrucciones Tx de la memoria 113 correspondiente al transcodificado del flujo a transcodificar hacia el flujo equivalente para transcodificar el flujo a transcodificar. El resultado de la transcodificación mediante Tx es enviado, en una etapa 216, hacia la aplicación cliente de Internet en respuesta a la solicitud 211.
En una etapa 217 la aplicación navegador de Internet recibe una respuesta a la solicitud 211. Esta respuesta, según el protocolo HTTP incluye un encabezado que describe el tipo de datos que incluye la respuesta. Mediante configuración cada tipo de datos particular es asociado a una extensión de la aplicación. En la medida donde durante la conexión la aplicación navegador de Internet ha declarado los tipos de flujo que puede gestionar, la extensión correspondiente al flujo recibido existe a la fuerza, y es invocada para gestionar este flujo.
Con el invento se ve pues que es posible incluso para un dispositivo que no sea SIP, conectarse a una infraestructura IMS y aprovechar los servicios ofrecidos por esta arquitectura.
Además con el invento, todos los servicios y conexiones SIP son gestionados por el mismo dispositivo que no requiere la instalación de una aplicación particular. Para un usuario dado correspondiente a un par [identificador, palabra clave] HTTP, sólo hay una conexión SIP y por tanto un único gestor SIP que tiene una vista de conjunto de todos los servicios SIP a través de los datos de sesión. Es por tanto perfectamente posible hacer interactuar dos servicios SIP a través de un mismo gestor. Se recuerda que en el estado de la técnica cada servicio SIP corresponde a una aplicación, teniendo cada aplicación su propio gestor de conexión.
El invento permite además gestionar varios usuarios simultáneamente teniendo cada uno su sesión SIP y por tanto sus datos de sesión.
En el invento el dispositivo 103 actúa como un servidor mandatario(proxy) para la cuenta del usuario del dispositivo 102. Este papel le permite, proteger este usuario relativamente de todos los ataques que vienen de la red 104. Esta protección es cuánto más eficaz cuando está gestionada por el operador prestatario que suministra el dispositivo 103. Este operador tiene en efecto la posibilidad de actualizar dinámicamente, es decir aquí cada vez que se requiera, los medios de protección.
En una variante del invento el dispositivo 103 actúa sobre los flujos de datos,
5 en particular sobre los encabezados de los paquetes de datos que constituyen estos flujos, para asegurar una buena calidad de servicio en función de los tipos de flujo tratados. Los diferentes servicios correspondientes a estos diferentes flujos son pues entregados en unas condiciones óptimas.
Esta acción sobre los flujos permite también gestionar la calidad de servicio en
10 función de un tipo de contrato suscrito por el usuario del dispositivo, o de una situación de red global particular que deba gestionar el operador que haya suministrado el dispositivo 103. Este operador tiene así la posibilidad de gestionar con finura los servicios, y la interacción de estos servicios, sobre la red 104.
15
Claims (1)
1- Procedimiento de transcodificación de al menos una sesión caracterizado porque la sesión transcodificada es una sesión del tipo SIP y porque dicho procedimiento incluye las siguientes etapas:
-una etapa (201), iniciada por un dispositivo cliente, de interrogación de un dispositivo de transcodificación, dicha interrogación se realiza a través de al menos una solicitud de interrogación que incluye unos datos de identificación que permiten una primera autentificación del dispositivo cliente por el dispositivo de transcodificación de sesiones del tipo SIP, -si (203, 204) se consigue la primera autentificación entonces: -una etapa (205), iniciada por el dispositivo de transcodificación, de segunda autentificación del dispositivo de transcodificación de sesiones del tipo SIP sobre un servidor del tipo SIP, unos datos de identificación de la segunda autentificación que dependen de al menos uno de los primeros datos de identificación, -si se logra la segunda autentificación entonces: -una etapa (205) de establecimiento de una conexión del tipo SIP entre el dispositivo de transcodificación y el servidor del tipo SIP, -una etapa (208), ejecutada por el dispositivo de transcodificación, respuesta a la pregunta iniciada por el dispositivo cliente en la que el dispositivo de transcodificación produce un mensaje de interfaz que depende al menos del resultado de la segunda autentificación, -una etapa (209) ejecutada por el dispositivo cliente, de interpretación del mensaje de interfaz, actualizando dicha interpretación el estado de un periférico de salida del dispositivo cliente, -mientras que, cuando se desea una autentificación robusta, entre la etapa de autentificación del cliente con el dispositivo de transcodificación y la etapa de autentificación del dispositivo de transcodificación de sesiones del tipo SIP con el servidor SIP, incluye además la etapa siguiente durante la que un dispositivo pasarela entre el dispositivo cliente y la red, que incluye una tarjeta SIM integrada, establece un túnel IP para acceder a la infraestructura de acceso IMS del operador utilizando dicha tarjeta SIM para autentificarse con el operador.
2-Procedimiento según la reivindicación 1, caracterizado porque incluye también las siguientes etapas: -una etapa, ejecutada por el dispositivo cliente, de interrogación de actualización efectuada en un intervalo regular hacia el dispositivo de transcodificación, -una etapa, ejecutada por el dispositivo de transcodificación como reacción a la recepción de la pregunta de actualización, de producción y emisión de un mensaje de interfaz, -una etapa, ejecutada por el dispositivo cliente, de interpretación del mensaje de interfaz, dicha interpretación actualizada el estado de un periférico de salida del dispositivo cliente.
3-Procedimiento según la reivindicación 1 o 2, caracterizado porque el contenido de un mensaje de interfaz depende de los datos recibidos por el dispositivo de transcodificación a través de la conexión del tipo SIP, los datos recibidos a través de esta conexión están almacenados en una memoria de estado, estando el contenido de esta memoria asociado al dispositivo cliente.
4-Procedimiento según una de las reivindicaciones 1 a 3, caracterizado porque un mensaje de interfaz incluye códigos con instrucciones correspondientes a la descripción de una opción que se propondrá para su selección a un usuario a través de interfaz del dispositivo cliente, la selección de esta opción provoca la emisión de un mensaje de activación de la opción hacia el dispositivo de transcodificación.
5-Procedimiento según la reivindicación 4, caracterizada porque un mensaje de activación incluye al menos un código de instrucción correspondiente a una acción que debe efectuar el dispositivo de transcodificación en relación a un servidor del tipo SIP, el tratamiento de un mensaje de activación incluye las etapas siguientes ejecutadas por el dispositivo de transcodificación: -negociación de una sesión con el servidor del tipo SIP, -conexión a al menos un servidor de aplicación conforme al resultado de la negociación, -transcodificación de los datos recibidos del servidor de aplicación en un formato inteligible para el dispositivo cliente,
-transmisión de los datos transcodificados hacia el dispositivo cliente.
6-Procedimiento según una de las reivindicaciones 1 a 5, caracterizado porque las preguntas emitidas por el dispositivo cliente y el tratamiento de las respuestas a estas preguntas son realizadas por una aplicación del tipo navegador de Internet.
7-Procedimiento según una de las reivindicaciones 1 a 6, caracterizado porque el dispositivo de transcodificación realiza una adecuación de los datos recibidos de los servidores de aplicación y una composición modulable de estos servicios en el seno de una página WEB única y dinámica, el dispositivo de transcodificación almacena entonces el perfil de servicio del usuario y da igualmente la posibilidad al usuario de compartir este perfil con una comunidad de usuarios.
8-Procedimiento según una de las reivindicaciones 1 a 7, caracterizado porque la aplicación del tipo navegador de Internet incluye de forma nativa o con forma de módulos de extensión al menos un interpretador de datos apto para interpretar los datos transcodificados por el dispositivo de transcodificación.
9-Procedimiento según una de las reivindicaciones 1 a 8, caracterizado porque, del mismo modo que el dispositivo de transcodificación situándose entre el cliente y el servidor SIP, asegura una protección de este, este último, del mismo modo, se inmiscuye en medio de un flujo de medios sin transcodificarlo para ocultar la dirección IP del cliente y protegerle jugando aquí el papel de un servidor mandatario.
10-Procedimiento según una de las reivindicaciones 1 a 9, caracterizado porque, el dispositivo de transcodificación marca los flujos con el fin de indicar a la red la prioridad en términos de “calidad de servicio” de dichos flujos.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0755161 | 2007-05-21 | ||
| FR0755161A FR2916552B1 (fr) | 2007-05-21 | 2007-05-21 | Procede de transcodage de sessions de type sip. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2352164T3 true ES2352164T3 (es) | 2011-02-16 |
Family
ID=38871898
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES08103823T Active ES2352164T3 (es) | 2007-05-21 | 2008-05-05 | Procedimiento de transcodificación de sesiones de tipo sip. |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP1995930B1 (es) |
| AT (1) | ATE481810T1 (es) |
| DE (1) | DE602008002468D1 (es) |
| ES (1) | ES2352164T3 (es) |
| FR (1) | FR2916552B1 (es) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101945027B (zh) * | 2010-08-30 | 2014-03-19 | 中兴通讯股份有限公司 | 一种家庭有线物联网关获取uim卡号的方法及系统 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4277621B2 (ja) * | 2003-08-20 | 2009-06-10 | 沖電気工業株式会社 | サービス提供システムおよびその方法ならびにサービス提供プログラムおよび記録媒体 |
| US7979519B2 (en) * | 2003-10-09 | 2011-07-12 | Oki Electric Industry Co., Ltd. | System for providing information between different protocol environments cooperative with each other and a method therefor |
-
2007
- 2007-05-21 FR FR0755161A patent/FR2916552B1/fr active Active
-
2008
- 2008-05-05 AT AT08103823T patent/ATE481810T1/de active
- 2008-05-05 DE DE602008002468T patent/DE602008002468D1/de active Active
- 2008-05-05 ES ES08103823T patent/ES2352164T3/es active Active
- 2008-05-05 EP EP08103823A patent/EP1995930B1/fr active Active
Also Published As
| Publication number | Publication date |
|---|---|
| ATE481810T1 (de) | 2010-10-15 |
| EP1995930A3 (fr) | 2009-11-18 |
| FR2916552A1 (fr) | 2008-11-28 |
| DE602008002468D1 (de) | 2010-10-28 |
| EP1995930B1 (fr) | 2010-09-15 |
| EP1995930A2 (fr) | 2008-11-26 |
| FR2916552B1 (fr) | 2015-02-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| TWI295135B (en) | Communication device and method for handling user identity and privacy | |
| US9854508B2 (en) | Downloadable ISIM | |
| ES2393952T3 (es) | Proporcionar servicios de empresa en una red de abastecimiento de servicios | |
| US20080010676A1 (en) | System, apparatus, and method for accessing mobile servers | |
| EP1881434A1 (en) | A personal token having enhanced signaling abilities | |
| US10057307B2 (en) | Distributed programmable connection method to establish peer-to-peer multimedia interactions | |
| US20160119788A1 (en) | Authentication of browser-based services via operator network | |
| Bertin et al. | WebRTC, the day after: What's next for conversational services? | |
| Beltran et al. | User identity for WebRTC services: A matter of trust | |
| JP2023078229A (ja) | ユーザネットワークインターフェイスプロキシを通じたキャリア統合 | |
| PH12017000187A1 (en) | Methods and system in pairing a unique alphanumeric name/s to any callable number os sip account to generate unique and easy to remember url calling link for real time communication purposes | |
| US11490255B2 (en) | RCS authentication | |
| US20080186958A1 (en) | Dynamic configuration of voip trunks | |
| GB2547231A (en) | Apparatus, method and computer program product for use in authenticating a user | |
| GB2517765A (en) | Operating a user device | |
| ES2352164T3 (es) | Procedimiento de transcodificación de sesiones de tipo sip. | |
| ES2782527T3 (es) | Procedimiento de registro de al menos una dirección pública en una red IMS y aplicación correspondiente | |
| JP2004166226A (ja) | 端末ユーザからコンテンツ・サービスへのオンライン・アクセスを制御する方法及びシステム | |
| US10028141B2 (en) | Method and system for determining that a SIM and a SIP client are co-located in the same mobile equipment | |
| ES2342784T3 (es) | Metodo y sistema para la preparacion de servicio de un dispositivo de acceso a red residencial. | |
| JP5632429B2 (ja) | オープンな通信環境にクローズな通信環境を構築するサービス認証方法及びシステム | |
| WO2022147693A1 (zh) | 一种呼叫处理方法、相关设备以及通信系统 | |
| JP2012509005A (ja) | 通信サービスを制御するための方法及び装置 | |
| US20150050914A1 (en) | Method and apparatus for verifying a device during provisioning through caller id | |
| Hasan et al. | Implementation of WebRTC (Web based Real Time Communication) solution for On Premise Video Conferencing System |