ES2413194A2 - Procedimiento de gestión mensajes de red entre operadores de telefonía móvil - Google Patents

Procedimiento de gestión mensajes de red entre operadores de telefonía móvil Download PDF

Info

Publication number
ES2413194A2
ES2413194A2 ES201130188A ES201130188A ES2413194A2 ES 2413194 A2 ES2413194 A2 ES 2413194A2 ES 201130188 A ES201130188 A ES 201130188A ES 201130188 A ES201130188 A ES 201130188A ES 2413194 A2 ES2413194 A2 ES 2413194A2
Authority
ES
Spain
Prior art keywords
enabler
message
operator
network messages
network
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.)
Granted
Application number
ES201130188A
Other languages
English (en)
Other versions
ES2413194R1 (es
ES2413194B1 (es
Inventor
Rogelio Martinez Perea
Philip Carter
Johathon MARCHANT
Oscar GALLEGO GOMEZ
Alfonso Gomez Diaz
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.)
Vodafone Espana SA
Original Assignee
Vodafone Espana SA
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 Vodafone Espana SA filed Critical Vodafone Espana SA
Priority to ES201130188A priority Critical patent/ES2413194B1/es
Publication of ES2413194A2 publication Critical patent/ES2413194A2/es
Publication of ES2413194R1 publication Critical patent/ES2413194R1/es
Application granted granted Critical
Publication of ES2413194B1 publication Critical patent/ES2413194B1/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procedimiento de gestión mensajes de red entre operadores de telefonía móvil. Se describe un procedimiento de gestión mensajes de red entre al menos dos operadores de telefonía móvil, que permite mediante la implementación de un habilitador (ENABLER) en un operador receptor a la escucha de mensajes entrantes provenientes de un operador emisor encargado de manipular dichos mensajes de red mediante manipulación de protocolo SIP para realizar una serie de transacciones dependientes del tipo respuestas y peticiones, haciendo innecesario el uso de servidores de presencia.

Description

PROCEDIMIENTO DE GESTIÓN MENSAJES DE RED ENTRE OPERADORES DE TELEFONÍA MÓVIL
CAMPO DE LA INVENCIÓN
La invención se refiere a comunicación, y más específicamente a un sistema de comunicación inalámbrica.
Más concretamente el objeto de la invención se base en un método que permite traducir mensajes de red entre operadores evitando el uso de servidores de presencia.
ANTECEDENTES
La iniciativa RCS (Rich Communication Suite (colección de herramientas de comunicación enriquecida) es una GSMA (especificación que permite diferentes tipos de comunicaciones (características) entre usuarios en su agenda de direcciones. Podemos resumir estas características, que son Presencia (usuario disponible, no disponible, en una llamada,...), Mensajería instantánea, Compartición de vídeo y Transferencia de archivos. Todas basadas en IMS (Subsistema multimedia de IP) usando SIP (Protocolo de inicio de sesión).
En la especificación RCS hay dos mecanismos para descubrir las capacidades de otros usuarios (qué características que están disponibles para compartirlas con ellos). A veces un usuario, debido a falta de ancho de banda, cámara, memoria o que está usando otro servicio, no puede compartir algunas características RCS con otros usuarios.
Mecanismo entre iguales: durante una llamada de voz CS (con circuitos conmutados) un usuario puede enviar un mensaje de OPTIONS al otro usuario de la llamada para consultar sus capacidades en tiempo real. Cuando las OPTIONS llegan al otro usuario, este responderá con un mensaje 200OK que contiene sus capacidades. Por ejemplo, ahora el usuario A sabrá si el usuario B puede soportar una sesión de vídeo y, por lo tanto, empezarla o no.
Mecanismo de Servidor de presencia: cuando se añade un nuevo contacto a su agenda de direcciones (lista de recursos) se envía un SUBSCRIBE anónima al nuevo usuario. Este SUBSCRIBE llegará al Servidor de presencia de la red del otro usuario y basándose en las reglas de presencia de este usuario (si permite este tipo de procedimiento) el Servidor de presencia responderá a este SUBSCRIBE con un NOTIFY que informa de las capacidades de la RCS del usuario al remitente del SUBSCRIBE.
El problema radica en el Servidor de presencia. La presencia es un servicio caro debido al hardware, las licencias y la infraestructura de red. Así que parece deseable ofrecer un servicio compatible con RCS basado en el estándar evitando el servicio de presencia. De esta manera, los operadores pueden evitar la necesidad de Servidores de presencia y nodos de Servidores XDM (Gestión de documentos XML) en la arquitectura del servicio.
DESCRIPCIÓN DE LA INVENCIÓN
El objeto de la invención propone una solución al problema mencionado anteriormente, , haciendo innecesario el uso de servidores de presencia, por medio de la implementación de un habilitador (ENABLER) que traduce los mensajes de red tipo SUBSCRIBE enviados por otros operadores a la RCS local en un mensajes de red tipo OPTIONS. El usuario envía una respuesta 200OK a dichos mensajes de red tipo OPTIONS que luego se transforma en mensajes de red tipo NOTIFY que se envía como respuesta a los SUBSCRIBE del usuario del otro operador.
Por lo tanto, el operador puede implementar un servicio compatible con RCS que ofrece la mayoría de las características de RCS (excepto presencia) y que necesita menos recursos y complejidad ya que no hay necesidad de un Servidor de presencia ni un Servidor XDM, ya que la presencia no es un servicio crítico para los usuarios residenciales y aumenta en gran medida la complejidad del servicio RCS.
El método objeto de la invención abarca distintas realizaciones, para poder dar cobertura a las distintas posibilidades que se pueden dar en este tipo de situaciones.
10 En un primer tipo de realización, el método permite adaptar un operador RCS, es decir que cumple los requisitos RCS, envía un mensaje de red de subscripción (SUBSCRIBE) a un operador no-RCS OPRITONS). El SUBSCRIBE llega al habilitador (ENABLER) de la siguiente manera, el usuario A (USER A) perteneciente al operador A (OPERATOR A) que es un operador
15 que cumple con los requisitos especificados en la RCS (RCS Compliant) añade como un contacto RCS un usuario B (USER B) de un operador B (OPERATOR B) que no cumple con los requisitos especificados en la RCS, no tiene servidor de presencia (Presence Server) ni XDMS pero tiene un habilitador de capacidad de descubrimiento de RCS (RCS Capability Discovery Enabler).
20 El usuario A, más concretamente el equipo (UE del inglés “User Equipment”) envía un mensaje de red tipo SUBSCRIBE anónimo al Tel-URI del Usuario B (USER B), mediante mecanismos estándar DNS el citado SUBSCRIBE llega a la red del operador B (OPERATOR B), más
25 concretamente al punto de entrada de la misma: el NNI-SBC.
La session iniciada por el SUBCRIBE llega al habilitador alojado en el (IMS Core) del operador B (OPERATOR B), dado que el habilitador se encuentra en el en el interfaz de señalización de dicho operador y a la escucha
30 de solicitudes de inicio de sesión SIP.
En este punto el operador B (OPERATOR B) opera de dos maneras
para enrutar la solicitud SUBSCRIBE del NNI-SBC hacia el hbailitador (ENABLER):
-
Directamante el NNI-SBC se encuentra configurado con una ruta por defecto que enrute todos los SUBSCRIBES anónimos procedentes del operador A al habilitador (ENABLER).
-
Basado en un iFC terminante para mensajes SUBCRIBE para todos los usuarios usando el habilitador (ENABLER). Esto implica, que el habilitador (ENABLER) se enruta en un procedimiento estándar hacia el I-CSCF del operado B (OPERATOR B) y desde aquí al S-CSCFd el usuario B (USER B). El perfil de servicios del usuario B( USER B) en el HSS tiene un capacidad de lanzar procesos terminantes (iFC) para SUBSCRIBES y enruta todas las transacciones al puerto de señalización del habilitador (ENABLER).
Tal y como se ha indicado anteriormente el habilitador (ENABLER) se encuentra realizando una escucha permanente del puerto y/o del interfaz de señalización a la espera de llegada de peticiones. Solo acepta peticiones y respuestas que provienen o vienen generadas en respuesta de mensajes de red tipo SUBSCRIBE y tipo OPTIONS, comportándose como un Back to back User Agent (B2BUA).
Cuando el habilitador (ENABLER) escucha o detecta un mensaje en el interfaz de comunicación determina si se trata de un mensaje de red tipo SUBSCRIBE; si es así el habilitador (ENABLER) chequea la sintaxis del SUBSCRIBE basada en RFC3261, si determina que no es correcta genera y envía un mensaje “400 Bad Request” en respuesta a dicho mensaje, si es correcto genera y envía un mensaje “200 OK” en respuesta y almacena todo los parámetros relacionados con la sesión.
A continuación, el habilitador (ENABLER) genera un nevo diálogo OPTIONS, en adelante OPTIONS, S-CSCF del Operador B (el dominio o rango de IPs del S-CSCF está codificador en habilitador (ENABLER) de tal forma que es capaz de saber a qué dirección enviar la solicitud/es OPTIONS).
El citado OPTIONS tiene el mismo origen y destino que el mensaje original SUBSCRIBE, esto implica que tiene la misma URI de petición, el mismo encabezamiento de destino (To header) y el mismo encabezamiento de origen (from header).
El hablitador (ENABLER) añade su puerto de dirección IP The Enabler (IP:port) en los encabezamientos del contacto (Contact) y ruta (Via), asegurando así la recepción de respuestas al OPTIONS, y envía la transacción al S-CSCF que se encuentra indicado en el encabezamiento de la ruta SIP (SIP Route header).
Entonces se procede a esperar una respuesta a dicha solicitud de OPTIONS para continuar con esta transacción..
Si la respuesta a este nuevo diálogo OPTIONS se excede del tiempo de espera o es diferente de una respuesta “480 Calling User Not Registered” o “200 OK” se procederá al borrado de los diálogos SUBSCRIBE y el OPTIONS de la memoria dado que no se hace necesaria una respuesta en este caso (el “USUARIO/USER B” de destino se considera como un usuario no-RCS “non-RCS USER”).
En el caso en el que el usuario recibe una respuesta que comprende un “480 Calling User Not Registered” o “200 OK, entonces se procede al borrado del diálogo OPTIONS de la memoria.
Si se da el caso de una respuesta “480 Calling User Not Registered”, esto implica que el usuario es un usuario RCS (“RCS USER”) del operador B, pero se encuentra inactivo en ese momento por lo que la respuesta tipo “480…” no contiene información sobre capacidades.
Si el usuario es un usuario RCS y registrado (activo) en ese momento, la respuesta debería haber sido un “200 OK” con toda la información referida a capacidades incluida a modo de etiqueta de características, estando separadas por comas “,” en la cabecera del contacto “CONTACT HEADER” a continuación
5 del URI del contacto. El hablitiador (“ENABLER”) debe entonces proceder a grabar toda la etiqueta de características.
Entonces el hablitiador (“ENABLER”) mandará al “operador A” una petición de “NOTIFY” embebida en el diálogo inicial “SUSBCRIBE”. Dicho 10 “NOTIFY” se enviará a la cabecera de Contacto (“CONTACT HEADER”) del “SUBSCRIBE” original (se incluirá en la solicitud URI del NOTIFY –“ NOTIFY’s Request-URI) y se añade su IP y Puerto (“IP:port”) en el campo CONTACT del NOTIFY. Las cabeceras de ruta se añadirán invirtiendo el orden de las cabeceras de ruta grabadas del SUBSCRIBE (B2BUA behaviour). Con dicho
15 B2BUA behaviour, el habilitador (“ENABLER”) se asegura que este NOTIFY llega a un usuario A (“USER A”) alojado en el Operador A (originador del SUBSCRIBE).
Esta información de capacidades se añadirá como estados RCS 20 estándar en la parte XML del NOTIFY.
Para la respuesta tipo “480 Calling User Not Registered” el habilitador (“ENABLER”) añadirá una parte XML embedida en hardware en la plataforma, sólo para este caso o en el caso en que no se haya llevado a cabo durane la
25 configuración del habilitador (“ENABLER”), estando entonces la parte XML vacía.
Para la respuesta “200 OK”, todas las etiquetas de características almacenadas en la cabecera CONTACT se incluirán en el NOTIFY a modo de 30 tuplas XML a continuación de las recomendaciones de presencia OMA.
Una vez el NOTIFY es enviado, el habilitador (“ENABLER”) esperará a
la respuesta “200 OK” por parte del operador A para proceder a borrar los diálogos SUBSCRIBE y NOTIFY de su memoria.
DESCRIPCIÓN DETALLADA DE UNA REALIZACIÓN PREFERIDA
Para la descripción de la implementación del Habilitador tendremos un Operador A con un Núcleo totalmente compatible con RCS (con PS y XDMS) y un Operador B con un Núcleo más sencillo no totalmente compatible con RCS pero con un Habilitador (ENABLER) de descubrimiento de capacidad RCS. Un
10 agente de usuario A pertenece al Operador A mientras que un agente de usuario B pertenece al Operador B.
En una primera realización del procedimiento de la invención se describe una búsqueda anónima del Agente de usuario B al Agente de usuario A. 15
El Agente de usuario B envía un mensaje de red tipo SUBSCRIBE, en adelante SUBSCRIBE, anónimo hacia el Agente de usuario B, debido a los iFC (criterios de filtro iniciales) de configuración de presencia en el núcleo del IMS (Subsistema multimedia IP) el SUBSCRIBE llega a un Servidor de presencia
20 del Operador A. Desde dicho Servidor de presencia debido a los mecanismos ENUM/DNS (el Enum traduce los números E164 en puntos de servicio de Internet y DNS significa Sistema de nombres de dominio) este SUBSCRIBE llega a una red del Operador B a través de una Interconexión de red a red. Del B NNI SBC del operador, este SUBSCRIBE anónimo se envia al Habilitador
25 (ENABLER).
Este es un ejemplo de señalización, obsérvese que algunos campos como operatorXdomain.com, NNISBC_X_IP se establecen de una manera genérica, y a las etiquetas Call-ID, From/To, y las cabeceras Contact se les da
30 un valor para este ejemplo.
En este caso una cabecera Expire de la suscripción se pone en 0
8
segundos pero este temporizador puede tener un valor más elevado (normalmente un valor pequeño). Sin embargo, este mecanismo sólo enviará un primer mensaje tipo NOTIFY, en adelante NOTIFY, como respuesta a la suscripción inicial sin manipular el temporizador.
SUBSCRIBE sip:[email protected] SIP/2.0 Via: IP/2.0/UDP NNISBC:5060;branch=z9hG4bK8q2qj200boj17j003S4r0.1 Call-ID: b9bbb83d968833d6718b49c30a0927d4@NNISBC_A_IP CSeq: 1 SUBSCRIBE From: <sip:[email protected]>;tag=155 To: <sip: [email protected]> Max-Forwards: 69 Contact: <sip:userA-akkif7e18ht32@NNISBC_B_IP:5060;transport=udp> Event: presence Accept: application/pidf+xml,application/rlmi+xml,multipart/related Expires: 0 Privacy: id Content-Length: 0 P-Asserted-Identity: sip:[email protected] Route: <sip:Enabler.operatorBdomain.com:5060;lr>
El Habilitador en este punto contestará con una respuesta 200 Ok al mensaje SUBSCRIBE e iniciará un mensaje OPTIONS hacia el usuario B. El habilitador asignará ambas bifurcaciones del programa (SUBSCRIBE y OPTIONS) ya que las respuestas Opciones requerirán respuestas al SUBSCRIBE.
OPTIONS sip:[email protected] SIP/2.0 Via: IP/2.0/UDP Enabler_IP:5060;branch=z9hG4bK8q2as600rtj17j003S q2qj20 Call-ID: 2778312327@ Enabler_IP CSeq: 1 OPTIONS From: <sip:[email protected]>;tag=155 To: <sip: [email protected]> Max-Forwards: 70 Privacy: id Contact: <:Enabler.operatorBdomain.com:5060;transport=udp> P-Asserted-Identity: sip:Enabler.operatorBdomain.com Route: <sip:scscf.operatorBdomain.com:5060;lr>
Luego se reciben varios tipos de respuestas, pero se focaliza en dos de ellas, 200 OK (originadas por el agente de usuario B) y 480 Calling User Not Registered (respuesta de error de Núcleo del IMS).
En el caso en la respuesta sea un 200 OK:
SIP/2.0 200 OK
From: <sip:[email protected]>;tag=155 To: <sip: [email protected]>; tag=543 Call-ID: 2778312327@ Enabler_IP
CSeq: 1 OPTIONS Via: SIP/2.0/UDP scscf_IP:5060;branch=z9hG4bKj9nncp2028q03j0m3301.1 Via: SIP/2.0/UDP ASBC_IP:5060;branch=z9hG4bK1188903169smg Contact: <sip: [email protected]>;+g.3gpp.iari_ref=urn%3Aurn7%3A3gpp-application.ims.iari.gsma-is;+g.oma.sip-im;+g.3gpp.cs-voice P-Asserted-Identity: sip: [email protected] Las etiquetas de características están incluidas en la cabecera Contact después de URI del usuario separadas por “;”
• +g.oma.sip-im • +g.3gpp.cs-voice • +g.3gpp.iari-ref:urn:urn-xxx:3gpp-application.ims.iari.gsma-is
• Cualquier otra etiqueta de característica para futuros servicios aún no implementados o personalizaciones del operador.
•
Cuando se recibe esta respuesta 200OK a las OPTIONS, el Habilitador (ENABLER) la asignará con el SUBSCRIBE que originó este flujo y analizará
5 sintácticamente esta 200 Ok en un NOTIFY como parte de la suscripción que incluye las etiquetas de características del 200 Ok como parte del XML del mensaje NOTIFY.
En el caso en que la respuesta sea un 480 Calling User Not Registered:
10 SIP/2.0 480 Calling User Not Registered From: <sip:[email protected]>;tag=155 To: <sip: [email protected]>; tag=543 Call-ID: 2778312327@ Enabler_IP
15 CSeq: 1 OPTIONS Content-Length: 0 Via: SIP/2.0/UDP scscf_IP:5060;branch=z9hG4bKj9nncp2028q03j0m3301.1 Via: SIP/2.0/UDP ASBC_IP:5060;branch=z9hG4bK1188903169smg
20 Esta respuesta significa que el usuario B no está registrado para contestar a mensajes tipo OPTIONS (esto es un mecanismo entre iguales y, por lo tanto, si ambos no están disponibles esto no funcionaría). Cuando se recibe esta respuesta 480OK a las OPTIONS, el Habilitador (ENABLER) tendrá unas etiquetas de características predefinidas para incluir en el NOTIFY
25 dependiendo del Operador. Como esto significa principalmente que el usuario es un usuario RCS que no está registrado, entonces pueden incluirse todas las etiquetas de características.
Después de enviar la solicitud NOTIFY al Operador A, PS contestará a 30 un mensaje 200 Ok y la SUBSCRIPTION/OPTION eliminando dentro de la caché del habilitador será borrada.
En el caso en que la respuesta se otra distinta a las dos planteadas anteriormente, serán respuestas finales de error y en este caso no se enviará nada a la red del operador A.
En una segunda realización de la invención el mensaje OPTIONS se envía del Agente de usuario B al Agente de usuario A, para ello, el Agente de usuario B del Operador B (con el habilitador (ENABLER)) envía una OPTIONS al Agente de usuario A del Operador A con PS, luego la transformación será la opuesta.
Los mensajes tipo OPTIONS (no anónimos) llegarán al Habilitador (ENABLER) ya que el DNS/ENUM de la red del núcleo identifica que el destino es un usuario de un Operador que implementa una infraestructura de Servidor de presencia/XDMS.
OPTIONS sip: [email protected] SIP/2.0 Route: <sip:enabler.operatorBdomain.;lr> Contact: < sip: [email protected] > From: <sip: [email protected]>;tag=591708355 To: <sip: [email protected]> Call-ID: [email protected] CSeq: 1 OPTIONS Max-Forwards: 68 Via: SIP/2.0/UDP scscf.operatorBdomain.com:5060;branch=z9hG4bK2958541778smg Content-Length: 0
Esto se transferirá en un SUBSCRIBE anónimo
SUBSCRIBE sip:[email protected] SIP/2.0 Via: IP/2.0/UDP enabler_IP:5060;branch=z9hG4bK8q2qj200boj17j003S4r0.1 Call-ID: b9bbb83d968833d6718b49c30a0927d4@enabler_IPP CSeq: 1 SUBSCRIBE From: <sip:[email protected]>;tag=155
To: <sip: [email protected]> Max-Forwards: 70 Contact: <sip:userB@eanbler_IP:5060;transport=udp> Event: presence
5 Accept: application/pidf+xml,application/rlmi+xml,multipart/related Expires: 0 Privacy: id Content-Length: 0 P-Asserted-Identity: sip:[email protected]
10 Route: <sip:NNI_SBC_B_IP:5060;lr>
Este SUBSCRIBE será respondido con una respuesta 200Ok (o 202 Accepted) y el habilitador esperará durante el valor de Expires + 40 segundos una respuesta NOTIFY antes de borrar el diálogo de su memoria.
Cuando llega el NOTIFY, analizará sintácticamente la estructura XML que incluye las etiquetas de características dentro de una cabecera Contact de respuesta 200 Ok y la enviará al usuario B.

Claims (7)

  1. REIVINDICACIONES
    1.-Procedimiento de gestión mensajes de red entre al menos dos operadores de telefonía móvil caracterizado porque comprende:
    -
    implementar en al menos uno de los operadores de red, un habilitador (ENABLER) que comprende al menos un interfaz de señalización encargado de permanecer a la escucha de mensajes entrantes en el operador en el que se encuentra implementado dicho habilitador (ENABLER) ,
    -
    recibir mensajes de red entrantes en dicho operador en el cual se encuentra implementado habilitador (ENABLER),
    -
    realizar una primera traducción de mensajes de red de dichos mensajes entrantes mediante manipulaciones del protocolo SIP haciendo uso de habilitador (ENABLER),
    -
    enviar unos mensajes de red traducidos resultado del paso anterior desde el operador en el cual se encuentra implementado habilitador (ENABLER) hacia un operador generador del mensaje entrante,
    -
    generar un primer mensaje de respuesta de recepción de mensaje entrante al operador generador del mensaje entrante donde dicha respuesta de recepción comprende al menos una respuesta SIP,
    -
    enviar dicho primer mensaje de respuesta de recepción al operador generador del mensaje entrante desde el habilitador (ENABLER) manteniendo en el encabezamiento de dicho mensaje de respuesta de recepción el origen y destino, cambiando el tipo de mensaje mediante modificaciones de protocolo SIP,
    -
    recibir en el operador generador del mensaje entrante primer mensaje de respuesta de recepción,
    -
    enviar desde el operador generador un segundo mensaje de respuesta dependiente del primer mensaje de respuesta de recepción,
    -
    recibir el segundo mensaje de respuesta en el operador en el cual se encuentra implementado el habilitador (ENABLER) a través de dicho habilitador (ENABLER),
    -
    realizar una segunda traducción de mensajes de red del segundo mensaje de respuesta en el habilitador (ENABLER) mediante técnicas de manipulación de protocolo SIP, y
    -
    hacer llegar al operador en el cual se encuentra alojado el habilitador (ENABLER) un mensaje traducción resultante del paso anterior. 5
  2. 2.- Procedimiento según reivindicación 1 caracterizado porque la primera traducción de mensajes de red comprende convertir mensajes de red tipo SUBSCRIBE en mensajes de red tipo OPTIONS.
    10 3.- Procedimiento según reivindicación 1 caracterizado porque la primera traducción de mensajes de red comprende convertir mensajes de red tipo OPTIONS en mensajes de red tipo SUBSCRIBE.
  3. 4.- Procedimiento según reivindicación 2 caracterizado porque la 15 segunda traducción de mensajes de red comprende convertir unos mensajes de respuesta 2XX o 4XX a un mensaje de red NOTIFY
  4. 5.-Procedimiento según reivindicación 3 caracterizado porque comprende adicionalmente generar un mensaje de red tipo NOTIFY en 20 respuesta al SUBSCRIBE convertido.
  5. 6.-Procedimiento según reivindicación 5 caracterizado porque comprende realizar una tercera traducción mediante modificaciones de protocolo SIP del mensaje de red tipo NOTIFY a mensajes de red tipo 2XX.
    25 7.- Procedimiento según reivindicaciones 4 y 6 caracterizado porque los mensajes de red tipo 2XX son de tipo 200 OK.
  6. 8.- Procedimiento según reivindicación 5 caracterizado porque el 30 mensaje NOTIFY comprende una señalización SIP.
  7. 9.- Procedimiento según reivindicación 5 caracterizado porque el mensaje NOTIFY comprende adicionalmente un fichero XML.
ES201130188A 2011-02-11 2011-02-11 Procedimiento de gestión mensajes de red entre operadores de telefonía móvil Active ES2413194B1 (es)

Priority Applications (1)

Application Number Priority Date Filing Date Title
ES201130188A ES2413194B1 (es) 2011-02-11 2011-02-11 Procedimiento de gestión mensajes de red entre operadores de telefonía móvil

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201130188A ES2413194B1 (es) 2011-02-11 2011-02-11 Procedimiento de gestión mensajes de red entre operadores de telefonía móvil

Publications (3)

Publication Number Publication Date
ES2413194A2 true ES2413194A2 (es) 2013-07-15
ES2413194R1 ES2413194R1 (es) 2013-09-06
ES2413194B1 ES2413194B1 (es) 2014-07-30

Family

ID=48692891

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201130188A Active ES2413194B1 (es) 2011-02-11 2011-02-11 Procedimiento de gestión mensajes de red entre operadores de telefonía móvil

Country Status (1)

Country Link
ES (1) ES2413194B1 (es)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1940105A1 (en) * 2006-12-27 2008-07-02 France Télécom Controlling quality of service in communications networks
US20090300115A1 (en) * 2008-06-03 2009-12-03 Telefonaktiebolaget Lm Ericsson (Publ) Method, node and system for adapting a session initiation protocol (sip) message for an ip multimedia subsystem (ims)

Also Published As

Publication number Publication date
ES2413194R1 (es) 2013-09-06
ES2413194B1 (es) 2014-07-30

Similar Documents

Publication Publication Date Title
US8090840B2 (en) Methods and apparatus to provide a call-associated content service
US20140297879A1 (en) Method and system for telecom network providing session service to internet
US20090168758A1 (en) Methods for facilitating communication between internet protocol multimedia subsystem (ims) devices and non-ims devices and between ims devices on different ims networks and related electronic devices and computer program products
US10284640B2 (en) Systems and methods to achieve interworking between RCS and non-RCS networks
US8325707B2 (en) Session initiation from application servers in an IP multimedia subsystem
CN101208962A (zh) 用于服务控制的方法和单元
BRPI0906843B1 (pt) servidor para uso com um rede pessoal e método para o mesmo, e equipamento de usuário e método para o mesmo
US20110194554A1 (en) Systems and methods for implementing call pick up using gruu an ims network
US20100088374A1 (en) Supplementary Services in Communication Networks
CN106664287B (zh) 用于控制多媒体通信网络中的通信会话建立的方法和通信处理设备
US9699220B2 (en) System and method to provide combinational services to anonymous callers
JP2009542106A (ja) ローミング・ネットワークにおけるクライアントの登録をネットワーク・アプリケーションに通知する方法
KR20130041816A (ko) 호출 요청을 피호출 사용자 어드레스로 분기시키기 위한 방법 및 장치
EP3007401B1 (en) Integration of webrtc based clients into ims without sip registration
KR100922953B1 (ko) 인터넷 프로토콜 멀티미디어 서브시스템에서 호 변경 요청의 처리 방법 및 시스템
ES2385292T3 (es) Métodos, nodo de telecomunicaciones, y equipo de usuario para la transmisión de un identificador de usuario
JP2011049687A (ja) 通信ネットワークシステムとそのｓｉｐ信号中継方法及びｓｉｐアプリケーション・サーバ
US8620316B2 (en) Method and apparatus in a telecommunications network
US20170331861A1 (en) Service support for suspended and inactive subscribers
ES2413194A2 (es) Procedimiento de gestión mensajes de red entre operadores de telefonía móvil
CN107852577A (zh) 一种补充业务实现方法、终端设备和ims服务器
Koumaras et al. CC4IMS: A mobile-based open-source call center for IMS
US9350768B2 (en) Suppressing CAMEL service invocation for diverting users
EP2130347B1 (en) System and method to provide combinational services to anonymous callers
Onofrei et al. Emergency Services in IMS

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2413194

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20140730