ES2623474T3 - Sistema y método para determinar la confianza de los mensajes SIP - Google Patents

Sistema y método para determinar la confianza de los mensajes SIP Download PDF

Info

Publication number
ES2623474T3
ES2623474T3 ES10764806.5T ES10764806T ES2623474T3 ES 2623474 T3 ES2623474 T3 ES 2623474T3 ES 10764806 T ES10764806 T ES 10764806T ES 2623474 T3 ES2623474 T3 ES 2623474T3
Authority
ES
Spain
Prior art keywords
message
timeout message
field
server timeout
value
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
ES10764806.5T
Other languages
English (en)
Inventor
Jan Hendrik Lucas Bakker
Adrian Buckley
Andrew Allen
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.)
BlackBerry Ltd
Original Assignee
BlackBerry Ltd
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 BlackBerry Ltd filed Critical BlackBerry Ltd
Application granted granted Critical
Publication of ES2623474T3 publication Critical patent/ES2623474T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1073Registration or de-registration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2002Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant
    • G06F11/2007Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where interconnections or communication control functionality are redundant using redundant communication media
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201Dedicated interfaces to print systems
    • G06F3/1202Dedicated interfaces to print systems specifically adapted to achieve a particular effect
    • G06F3/1203Improving or facilitating administration, e.g. print management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/30Types of network names
    • H04L2101/385Uniform resource identifier for session initiation protocol [SIP URI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/212Monitoring or handling of messages using filtering or selective blocking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]

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)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Un método realizado por un agente de usuario para realizar el registro, comprendiendo el método: recibir un mensaje de tiempo de espera del servidor, en el UA, incluyendo el mensaje de tiempo de espera del servidor al menos un primer campo establecido a un valor igual al valor recibido en un segundo campo durante un primer registro del UA, en donde el segundo campo es un campo de cabecera de Ruta de Servicio y el primer campo comprende un campo de cabecera de la Identidad Afirmada P; e iniciar los procedimientos de restauración, en el UA, mediante la realización de un segundo registro en respuesta a la recepción del mensaje de tiempo de espera del servidor.

Description

5
10
15
20
25
30
35
40
45
50
55
DESCRIPCION
Sistema y metodo para determinar la confianza de los mensajes SIP Antecedentes
El Subsistema Multimedia IP (Protocolo de Internet) (IMS) es una arquitectura estandarizada para proporcionar servicios multimedia y llamadas de voz sobre IP tanto a los agentes de usuario (UA) moviles como fijos. El Protocolo de Inicio de Sesiones (SIP) ha sido estandarizado y regulado principalmente por el Grupo de Trabajo de Ingeniena de Internet (IETF) como un protocolo de senalizacion para crear, modificar, y terminar llamadas o sesiones basadas en IMS.
Como se usa aqrn, los terminos “agente de usuario” y “UA” podnan referirse en algunos casos a dispositivos moviles tales como telefonos moviles, asistentes digitales personales, dispositivos portatiles u ordenadores portatiles, y dispositivos similares que tienen capacidades de telecomunicaciones. Dicho Ua podna ser parte de un UE (Equipo de Usuario). Un UE puede tener multiples UA. Un UE puede tener modulos de memoria extrafbles asociados, tales como pero no limitados a una Tarjeta de Circuito Integrado Universal (UICC) que incluye una aplicacion de Modulo de Identificacion de Abonado (SIM), una aplicacion de Modulo de Identificacion de Abonado Universal (USIM), una aplicacion de Modulo de Identificacion de Servicios Multimedia IP (ISIM), o una aplicacion de Modulo de Identificacion de Usuario Extrafole (R-UIM), etc. Ejemplos de dichos modulos podnan incluir, pero no estan limitados a, Tarjetas de PC, Compact Flash I, Compact Flash II, SmartMedia, Memory Stick, Memory Stick Duo, Memory Stick PRO Duo, Memory Stick PRO-HG Duo, Memory Stick Micro M2, Tarjeta Multimedia, Tarjeta Multimedia de Tamano Reducido, Tarjeta microMMC, tarjeta Secure Digital, SxS, Almacenamiento Flash Universal, tarjeta miniSD, tarjeta microSD, tarjeta xD-Picture, Intelligent Stick, Modulo Serial Flash, tarjeta p y tarjeta NT. Cuando la informacion se almacena en un modulo de memoria extrafble, los contenidos del modulo se pueden visualizar en el UE.
Alternativamente, dicho UA podna consistir en el dispositivo en sf sin dichos modulos. En otros casos, el termino “UA” podna referirse a dispositivos que tienen capacidades similares pero que no son transportables, tales como telefonos de lmea fija, ordenadores de sobremesa, decodificadores de television, o nodos de red. Cuando uno o mas UA son parte de un nodo de red, el nodo de red podna actuar en beneficio de otra funcion tal como un UA o un dispositivo de lmea fija y simular o emular el UA o el dispositivo de lmea fija. Por ejemplo, para algunos UA, el cliente SIP IMS que normalmente residina en el dispositivo realmente reside en la red y transmite la informacion del mensaje SIP al dispositivo usando protocolos optimizados. En otras palabras, algunas funciones que tradicionalmente eran llevadas a cabo por un UA pueden ser distribuidas en forma de un UA remoto, donde el UA remoto representa el UA en la red. El termino “UA” puede tambien referirse a cualquier componente de hardware o software que pueda terminar una sesion de comunicacion que podna incluir, pero no esta limitada a, una sesion SIP. Tambien, los terminos “agente de usuario”, “UA”, “equipo de usuario”, “UE”, y “nodo” podnan usarse como sinonimos aqrn. Tambien, los terminos “cabecera” y “campo de cabecera” podnan usarse como sinonimos aqrn. Tambien, un mensaje SIP es una solicitud SIP o una respuesta SIP.
Un UA podna conectarse a una red basada en SIP que incluya una pluralidad de otros componentes tales como una P-CSCF (Funcion de Control de Sesion de Llamada Proxy), un S-CSCF (CSCF servidora), un IBCF (Funcion de Control de Frontera de Interconexion), un Servidor de Aplicacion (AS), y otros componentes, cualquiera de los cuales podna ser referido como nodos de red. Podna existir una relacion de confianza entre los nodos en una red SIP. Esto es, un grupo de nodos dentro de una red podnan considerar todos los mensajes recibidos desde otros nodos en el grupo como legftimos. Dicho grupo se puede decir que forma un dominio de confianza o una o mas redes de confianza. La RFC 3325 IETF titulada “Extensiones Privadas al Protocolo de Inicio de Sesiones (SIP) para la Identidad Declarada dentro de Redes de Confianza” discute mas este tema. La TS 24.229 V8.7.0 3GPP, subclausula 5.2.6.3.2A describe una P-CSCF enviando una respuesta 504 a un UE.
Breve descripcion de los dibujos
Para una comprension mas completa de esta descripcion, se hace ahora referencia a la siguiente breve descripcion, tomada en relacion con los dibujos adjuntos y la descripcion detallada, en donde los mismos numeros de referencia representan las mismas partes.
La Figura 1 es un diagrama de un sistema de comunicaciones que incluye una pluralidad de nodos de red segun una realizacion de la descripcion.
La Figura 2 es un diagrama de flujo de una llamada que ilustra un metodo para un UA para recuperar la informacion de confianza segun una realizacion de la descripcion.
La Figura 3 ilustra un metodo para determinar si un nodo fuera de un dominio de confianza en una red IMS puede ser de confianza segun una realizacion de la descripcion.
La Figura 4 ilustra un metodo para determinar si un nodo fuera de un dominio de confianza en una red IMS puede ser de confianza segun una realizacion alternativa de la descripcion.
5
10
15
20
25
30
35
40
45
50
55
La Figura 5 ilustra un procesador y los componentes relacionados adecuados para implementar las varias realizaciones de la presente descripcion.
Descripcion detallada
La invencion se define en las reivindicaciones independientes 1 y 7. Debena ser entendido desde el inicio que aunque mas adelante se proporcionan las implementaciones ilustrativas de una o mas realizaciones de la presente descripcion, los sistemas y/o los metodos descritos se pueden implementar usando cualquier numero de tecnicas, ya sean actualmente conocidas o en existencia. La descripcion no debena limitarse de modo alguno a las implementaciones ilustrativas, los dibujos, y las tecnicas ilustradas mas adelante, que incluyen los disenos y las implementaciones ejemplares ilustradas y descritas aqm, pero se puede modificar dentro del alcance de las reivindicaciones adjuntas junto con su alcance completo de equivalentes.
Un nodo dentro de un dominio de confianza en una red IMS podna recibir un mensaje desde un nodo fuera del dominio de confianza. En algunos casos, dicho mensaje podna mandar al nodo en el dominio de confianza a realizar una o mas acciones que pueden no ser deseables para que las realice ese nodo. Por ejemplo, un mensaje podna ser enviado maliciosamente a una pluralidad de UA informando falsamente a los UA de que se ha superado un tiempo de espera del servidor. Un UA que recibe dicho mensaje podna intentar volver a registrarse con un registrador SIP incluso aunque el nuevo registro no es realmente necesario. Si un gran numero de UA intentan volver a registrarse, el registrador podna sobrecargarse y fallar. Esto podna llevar a problemas mayores en la red ya que otros UA podnan entonces ser incapaces de registrarse.
En una realizacion, un mensaje enviado a un nodo de red desde fuera del dominio de confianza de los nodos de la red puede incluir un indicador de confianza que indica la fiabilidad del mensaje. Un indicador de confianza puede ser tambien un elemento de confianza, un identificador de confianza o una bandera de confianza. Los indicadores de confianza pueden ser de uno de dos tipos. La presencia de un tipo de indicador de confianza en un mensaje indica que se puede confiar en el nodo de red que envfa el mensaje. El destinatario del mensaje que contiene dicho indicador de confianza no necesita realizar ninguna verificacion del indicador de confianza, Cuando el otro tipo de indicador de confianza esta presente en un mensaje, el destinatario del mensaje compara el indicador de confianza con la informacion/base de datos de confianza almacenada internamente. Si el indicador de confianza coincide con la informacion de confianza almacenada, se verifica el indicador de confianza, y el destinatario/receptor sabe que se puede confiar en el nodo de red que envio el mensaje.
Si el primer tipo de indicador de confianza esta presente en un mensaje o si el segundo tipo esta presente y se verifica, el nodo de red que recibe el mensaje realiza las acciones que se asocian normalmente con la recepcion del mensaje o del mensaje y su contenido. Si el indicador de confianza no esta presente o si el indicador de confianza no se verifica, el nodo de red que recibe el mensaje podna no realizar una o mas de las acciones que se asocian normalmente con la recepcion del mensaje o del mensaje y su contenido.
En una realizacion, el nodo de red que recibe el mensaje es un UA que mantiene la informacion de confianza relacionada con los nodos de red fuera del dominio de confianza del UA. Tras recibir un mensaje desde fuera del dominio de confianza, el UA puede comparar el indicador de confianza que debena estar incluido en el mensaje con la informacion de confianza que el UA mantiene. Si el UA verifica que el indicador de confianza coincide con la informacion de confianza que este mantiene, el UA realiza las acciones que se asocian normalmente con la recepcion del mensaje o del mensaje y su contenido. Si el UA no puede verificar que el indicador de confianza coincide con la informacion de confianza que mantiene, el UA no realiza al menos una accion de las que se asocian normalmente con la recepcion del mensaje o del mensaje y su contenido.
Estas realizaciones se ilustran en la Figura 1, donde un UA 110 es capaz de comunicarse con un nodo B 130 de red, que es capaz de comunicarse con un nodo A 120 de red. El UA 110, el nodo A 120 de red, y el nodo B 130 de red podnan ser componentes en una red basada en IMS, y el nodo A 120 de red y el nodo B 130 de red podnan estar fuera del dominio de confianza del UA. Aunque solo se muestran dos nodos de red, se podna presentar otro numero. En esta realizacion, el nodo A 120 de red genera un mensaje A 140 que incluye un indicador A 145 de confianza en el mensaje A 140. El nodo 120 de red entonces envfa el mensaje A 140 al nodo B 130 de red. La recepcion del mensaje A 140 provoca que el nodo B 130 genere un mensaje B 150 que contiene un indicador de confianza B 155, y el mensaje B 150 se envfa despues al UA 110. El Mensaje A 140 puede ser o no el mismo que el mensaje B 150, y el indicador de confianza A 145 puede ser o no el mismo que el indicador B 155 de confianza. En otras palabras, el nodo B 130 de red podna simplemente pasar el indicador A 145 de confianza que se recibe desde el nodo A 120 de red, o el nodo B 130 de red podna generar un nuevo indicador B 155 de confianza basandose en el indicador de confianza A 145 u otra informacion recibida desde el nodo A 120 de red y/u otros nodos de red.
En otras realizaciones, el nodo A 120 de red no incluye un indicador A 145 de confianza en el mensaje A 140. En cambio, el nodo B 130 de red genera el indicador B 155 de confianza sin considerar ninguna informacion incluida en el mensaje A 140, y el nodo B 130 de red entonces incluye el indicador B 155 de confianza en el mensaje B 150 enviado al UA 110. En otras palabras, el indicador de confianza que el UA 110 recibe podna haber sido generado por el nodo de red con el cual el UA 110 esta en comunicacion directa, podna haber sido generado por otro nodo de red y despues transmitido sin modificacion por el nodo de red con el cual el UA 110 esta en comunicacion directa, o
5
10
15
20
25
30
35
40
45
50
55
podna haber sido generado por otro nodo de red y despues transmitido con modificacion por el nodo de red con el cual el UA 110 esta en comunicacion directa.
En algunas realizaciones, tras recibir un mensaje que contiene un indicador de confianza, el UA 110 realiza las acciones que se asocian normalmente con la recepcion del mensaje. En otras realizaciones, tras recibir un mensaje que contiene un indicador de confianza, el UA 110 compara el indicador de confianza a la informacion 115 de confianza que el UA 110 ha recibido y almacenado previamente. Cuando se encuentra una coincidencia entre el indicador de confianza en el mensaje y la informacion 115 de confianza almacenada, el UA 110 realiza las acciones que normalmente se asocian con la recepcion del mensaje. Cuando no se encuentra una coincidencia entre el indicador de confianza y la informacion 115 de confianza almacenada, el UA 110 no realiza al menos una de las acciones que normalmente se asocia con la recepcion del mensaje.
En una realizacion, el indicador de confianza y/o la informacion 115 de confianza podna ser un Identificador de Recursos Uniforme (URI), o algun otro tipo de identificador, de un nodo de red de confianza. Un nodo de red podna incluir su URI en un mensaje enviado al UA 110. EL UA 110 podna haber recibido previamente la informacion 115 de confianza en forma de una lista de URI de confianza. Tras recibir un mensaje con un indicador de confianza en forma de URI, el UA 110 podna comparar el URI en el mensaje con los URI en la lista de URI. Si se encuentra una coincidencia, el UA 110 podna confiar en el nodo de red que envio el mensaje.
El UA 110 podna no ser capaz de identificar si un URI pertenece a una P-CSCF, a una S_CSCF, a una OBCF, o a algun otro tipo de nodo de red. Algunos nodos de red (tales como una IBCF) pueden incluir o no su informacion URI. Por lo tanto, el UA puede no estar seguro de que URI representa que nodo de red. Para determinar esto, se podnan seguir algunas convenciones o se puede anadir un indicador adicional. Una solicitud de REGISTRO SIP y su respuesta (y los valores del campo de cabecera incluidos en la respuesta o la solicitud) normalmente no debena abandonar el dominio de confianza. Una solicitud de registro de un tercero desencadenada por la solicitud de REGISTRO original puede abandonar el dominio de confianza. En una realizacion, se establecen medidas para evitar la contaminacion de la informacion en las respuestas al REGISTRO en tal caso. Por ejemplo, el hecho de que un URI representa un nodo de red conocido podna ser indicado por un parametro URI a un mensaje SIP. Por ejemplo, para una S-CSCF, se podna anadir el parametro URI scscf. Alternativamente, un parametro URI tale como “fe” se podna establecer a un valor o a una lista de valores tales como fe = “scscf” o fe=”pcscf, scscf”. Aqrn, un nodo de red es referido como un elemento funcional, o “fe”. Cuando se usa la cabecera de Ruta de Servicio SIP, el mensaje podna tomar una forma como la siguiente:
Ruta de Servicio: sip:[email protected];lr;scscf
o
Ruta de Servicio: sip:[email protected];lr;fe=”pcscf, scscf”
en despliegues donde la P-CSCF y la S-CSCF (y posiblemente otros) elementos funcionales son colocados en un equipo ffsico.
Como alternativa, despues de recibir la informacion 115 de confianza en forma de una lista de URI, el UA 110 podna consultar una base de datos u otro repositorio de datos para determinar los nodos de red y/o el indicador de confianza y/o la informacion de confianza que corresponde a los URI listados. La base de datos podna ser un nodo en la red o una base de datos en el dispositivo almacenada en una memoria que es bien interna o un modulo de memoria extrafble.
En otra realizacion, el Marco de Configuracion de SIP, el Marco de Polttica SIP, un mecanismo de recuperacion de polfticas basado en EAP, un servidor basado en XCAP/HTTP o un objeto de gestion de dispositivos (DM) de la Alianza Movil Abierta (OMA) podnan ser utilizados para transportar los indicadores de confianza y/o la informacion de confianza y/o los nodos de red que corresponden a los URI listados para el UA 110.
El UA 110 podna recibir la informacion 115 de confianza de una o mas de entre varias maneras diferentes. En algunas realizaciones, la informacion 115 de confianza se podna proporcionar al UA 110 en respuesta a una solicitud de REGISTRO SIP enviada por el UA 110. En algunas variaciones de estas realizaciones, la respuesta podna ser una respuesta 200 OK SIP, y la informacion 115 de confianza podna estar incluida directamente en la respuesta 200 OK. La informacion 115 podna estar incluida en la respuesta 200 OK por un nodo de red, tal como un servidor de aplicacion, que recibio la solicitud de REGISTRO ya que la solicitud fue enrutada a traves de este. Alternativamente, el servidor de aplicacion podna haber recibido una solicitud de registro de una tercera parte como configurada por los Criterios de Filtro iniciales en un S-CSCF.
En otras variaciones de estar realizaciones, la respuesta 200 OK que el UA 110 recibe en respuesta a una solicitud de REGISTRO podna contener informacion que informa al UA 110 de como se puede obtener la informacion 115 de confianza. Tal realizacion se ilustra en la Figura 2. En el evento 210, el UA 110 se registra en una red IMS mediante el envfo de una solicitud de REGISTRO al nodo B 130 de red, el cual podna ser un S-CSCF. Como parte del procedimiento 220 de registro, un servidor 200 de abonado local (HSS), o un componente similar, podna descargar al nodo B 130 de red la informacion 115 de confianza que ha de ser usada por el UA 110. En el evento 230, el
4
5
10
15
20
25
30
35
40
45
50
55
registro esta completo, y el nodo B 130 de env^a al UA 110 una respuesta 200 OK. En la realizacion de la Figura 2, la respuesta 200 OK podna contener un URI, o algun otro tipo de identificador, que identifique una ubicacion donde se pueda obtener la informacion 115 de confianza. En otras realizaciones, como se menciono anteriormente, la respuesta 200 OK podna incluir directamente la informacion 115 de confianza.
Alternativamente, como se muestra en el evento 240, como parte del registro SIP, el UA 110 podna abonarse al paquete de Eventos de Registro de SIP, el cual puede entregar informacion de vuelta al UA 110. En respuesta al mensaje de abono en el evento 240, el nodo B 130 de red, en el evento 250, podna devolver un mensaje tal como un mensaje de Notificacion. El mensaje de Notificacion podna contener la ubicacion de la informacion 115 de confianza que fue descargada desde el HSS 200 como se describio anteriormente.
Cuando el UA 110 ha recibido la ubicacion de la informacion 115 de confianza, bien a traves del mensaje 200 OK en el evento 230, a traves del mensaje de Notificacion en el evento 250, o a traves de otro metodo SIP, el UA 110 puede recuperar la informacion 115 de confianza de la ubicacion especificada. En este caso, la ubicacion especificada es un nodo A 120 de red, pero en otros casos, la informacion 115 de confianza podna ser recuperada de otros nodos de red. En el evento 260, el UA 110 envfa un mensaje, tal como un mensaje HTTP GET, para recuperar la informacion 115 de confianza del nodo A 120 de red. En el evento 270, el nodo A 120 de red envfa la informacion 115 de confianza al UA 110. El UA 110 puede entonces almacenar la informacion 115 de confianza en la memoria interna o extrafble, donde la informacion 115 de confianza estara disponible para su uso futuro por el UA 110 en la determinacion de si un nodo de red es de confianza.
En una realizacion alternativa, la informacion 115 de confianza podna ser proporcionada durante el registro del UA 110 en uno o mas campos en la cabecera de Camino SIP o en la cabecera de Ruta de Servicio SIP. Por ejemplo, una solicitud de REGISTRO SIP originada por el UA 110 podna ser enrutada a traves de al menos un P-CSCf y un S-CSCF, donde el S-CSCF realiza el rol del REGISTRADOR. La respuesta (tal como una respuesta 200 OK) que recibe el UA 110 a su solicitud de REGISTRO podna incluir un indicador (tal como una nueva cabecera P, una cabecera existente, o un XML incrustado) que transporta la informacion sobre los nodos de red (tales como un P- CSCF y un S-CSCF) en el camino sobre el cual fue enrutada la solicitud de REGISTRO. Ademas, uno o mas campos en la cabecera de la Ruta de Servicio SIP podnan contener al menos las direcciones del P-CSCF o S-CSCF que realmente realizan cualquier servicio. La direccion del S-CSCF en el campo cabecera de la Ruta de Servicio y del S-CSCF en el campo cabecera de Camino no es necesariamente la misma.
En algunos casos, un S-CSCF que actua como un REGISTRADOR puede no ser el S-CSCF que responda a otras solicitudes del UA 110. Mas generalmente, no todos los nodos de red que son capaces de transmitir un mensaje de confianza se puede incluir en el camino sobre el cual se enruta la solicitud de REGISTRO o su respuesta. Sin embargo, si un nodo de red transmite un mensaje de confianza, puede ser ventajoso completar un campo de cabecera (tal como un campo de cabecera de la Identidad Afirmada P SIP) o un parametro URI o una parte del cuerpo SIP con un valor representativo del iniciador. Existen varios medios para permitir al UA 110 determinar que algun valor representativo del iniciador podna solo ser conocido o solo ser insertado por el iniciador. Por ejemplo, un valor en el campo de cabecera de la Identidad Afirmada P SIP podna ser comparado con un valor en el campo de cabecera de la Ruta de Servicio.
Cuando un indicador de confianza no este presente en un mensaje recibido por el UA 110 de un nodo de red fuera del dominio de confianza del UA, o cuando un indicador de confianza esta presente pero no coincide con la informacion 115 de confianza almacenada del UA, el UA 110 podna reaccionar de varias maneras diferentes. En algunos casos el UA 110 podna denegar, descartar, o terminar el mensaje. En otros casos, el UA 110 podna devolver un mensaje de error al nodo de red que envio el mensaje. En otros casos, el UA 110 podna eliminar porciones del mensaje que pudieran causar que se tomen acciones indeseables y podna procesar el resto del mensaje. En algunos casos, podnan ser tomadas varias combinaciones de estas acciones.
La Figura 3 ilustra una realizacion de un metodo 300 para determinar si un nodo fuera del dominio de confianza en una red IMS puede ser de confianza. En el bloque 310, un UA recibe desde el nodo de red un mensaje que contiene un indicador de confianza. EN el bloque 320, el UA determina si el indicador de confianza coincide con la informacion de confianza almacenada en el UA. En el bloque 330, cuando el indicador de confianza coincide con la informacion almacenada en el UA, el UA realiza todas las acciones normalmente asociadas con la recepcion del mensaje. En el bloque 340, cuando el indicador de confianza no coincide con la informacion almacenada en el UA, el UA se abstiene de realizar al menos una accion de las normalmente asociadas con la recepcion del mensaje.
La Figura 4 ilustra una realizacion alternativa de un metodo 400 para determinar si un nodo fuera de un dominio de confianza en una red IMS puede ser de confianza. En el bloque 410, un UA recibe un mensaje desde el nodo de red. En el bloque 420, el UA determina si un indicador de confianza esta presente en el mensaje. En el bloque 430, cuando el indicador de confianza esta presente en el mensaje, el UA realiza todas las acciones normalmente asociadas con la recepcion del mensaje. En el bloque 440, cuando el indicador de confianza no esta presente en el mensaje, el UA se abstiene de realizar al menos una accion de las normalmente asociadas con la recepcion del mensaje.
5
10
15
20
25
30
35
40
45
Volviendo al ejemplo mencionada anteriormente donde un mensaje malicioso enviado a una pluralidad de UA informando falsamente a los UA de que se ha superado un tiempo de espera del servidor, las realizaciones descritas aqu podnan prevenir a los UA de innecesarios intentos de volver a registrarse en la red. Cuando uno de los UA recibe el mensaje malicioso, el UA podna usar una tecnica descrita aqu para determinar si el emisor del mensaje puede ser de confianza. Ya que, en este caso, el emisor no sena de confianza, el UA no realizana una o mas acciones de las normalmente asociadas con la recepcion del mensaje, En este caso, el UA no se volvena a registrar.
Una posible reflexion para el UE podna ser como sigue en la TS 24.229 3GPP, subclausula 5.1.2A.1.6, titulada “Casos anormales”:
En el evento el UE recibe una respuesta 504 (tiempo de espera del Servidor) que contiene:
- un campo de cabecera de la Identidad Afirmada P establecido a:
- un valor igual a un valor en campo cabecera de la Ruta de Servicio o del camino recibido durante el registro; o
- un campo de cabecera del Tipo de Contenido establecido segun a la subclausula 7.6 (esto es “aplicacion/3gpp-ims+xml”), independiente del valor o la presencia del campo de cabecera de la Disposicion de Contenido, independiente del valor o la presencia de los parametros de la Disposicion de Contenido, entonces la disposicion de contenido predeterminada, identificada como “3gpp-servicio-alternativo”, se aplica como sigue:
- si la respuesta 504 (tiempo lfmite del Servidor) incluye un cuerpo XML del subsistema CN IM como se describe en la subclausula 7.6 con el tipo de elemento establecido a “restauracion” y el elemento de accion establecido a “registro-inicial”, entonces el UE:
- iniciara los procedimientos de restauracion mediante la realizacion de un registro inicial como se especifica en la subclausula 5.1.1.2; y
- puede proporcionar una indicacion al usuario basandose en la cadena de texto contenida en el elemento de razon.
Una posible reflexion para la P-CSCF podna ser como sigue en la TS 24.229 3GPP, subclausula 5.2.6.3.2A, titulada “Casos anormales”:
Cuando la P-CSCF es incapaz de enviar una solicitud inicial para un dialogo o una solicitud para una transaccion autonoma al siguiente salto en la cabecera de la Ruta de Servicio, como se determina por uno de los siguientes:
- no hay respuesta a la solicitud de servicio y su retransmision por la P-CSCF;
- se recibe una respuesta 3xx o una respuesta 480 (Temporalmente No Disponible) para la solicitud; o
- por medios no especificados disponibles a la P-CSCF;
y:
- la P-CSCF soporta procedimientos de restauracion; entonces la P-CSCF:
1) rechazara la solicitud mediante la devolucion de una respuesta 504 (tiempo de espera del servidor) al UE;
2) asumira que el UE soporta la version 1 del esquema XML para el cuerpo XML del subsistema CN IM 3GPP si no se indica el soporte para el cuerpo XML del subsistema CN iM 3GPP como se describe en la subclausula 7.6 en el campo de cabecera de Aceptacion; e
3) incluira en la respuesta 504 (tiempo de espera del servidor):
a) un campo de cabecera del Tipo de Contenido con el valor establecido al tipo MIME asociado del cuerpo XML del subsistema CN IM 3GPP como se describe en la subclausula 7.6.1;
b) un campo de cabecera de la Identidad Afirmada P establecido al valor del URI SIP de la P-CSCF incluido en el campo de cabecera de Camino durante el registro del usuario cuyo UE envfa la solicitud que causa esta respuesta; y
c) un cuerpo XML del subsistema CN IM 3GPP que contiene:
5
10
15
20
25
30
35
40
45
i. un elemento <servicio alternativo>, establecido a los parametros del servicio alternativo
ii. un elemento hijo <tipo>, establecido a “restauracion” para indicar que se soportan procedimientos de restauracion;
iii. una elemento hijo <razon>, establecido a una razon configurable del operador; y
iv. un elemento hijo <accion>, establecido a un “registro inicial”
NOTA: estos procedimientos no impiden el uso de tecnicas de fiabilidad o de recuperacion no especificadas anteriormente y que esten mas alla de las especificadas en esta subclausula.
Una posible reflexion para la S-CSCF podna ser como sigue en la TS 24.229 3GPP, subclausula 5.4.3.2, titulada “Solicitudes iniciadas por el usuario servido”:
Cuando la S-CSCF recibe una solicitud iniciada por el usuario servido para la cual la S-CSCF no tiene el perfil de usuario o no conffa en los datos que este tiene (por ejemplo debido a un reinicio), el S-CSCF intentara recuperar el perfil de usuario del HSS. Si la S-CSCF falla al recuperar el perfil de usuario y la S-CSCF soporta los procedimientos de restauracion, entonces la S-CSCF:
1) rechazara la solicitud mediante la devolucion de una respuesta 504 (Tiempo lfmite del Servidor) al UE;
2) asumira que el UE soporta la version 1 del esquema XML para el cuerpo XML del subsistema CN IM 3GPP si no se indica el soporte para el cuerpo XML del subsistema CN IM 3GPP como se describe en la subclausula 7.6 en el campo de cabecera de Aceptacion; y
3) un campo de cabecera de la Identidad Afirmada P establecido al valor del URI SIP de la S-CSCF incluido en el campo de cabecera de Ruta de Servicio durante el registro del usuario cuyo UE envfa la solicitud que causa esta respuesta; e
4) incluira en la respuesta 504 (Tiempo lfmite del Servidor):
a) un campo de cabecera del Tipo de Contenido con el valor establecido al tipo de MIME asociado del cuerpo XML del subsistema CN IM 3GPP como se describe en la subclausula 7.6.1; y
b) un cuerpo XML del subsistema CN IM 3GPP:
i. un elemento <servicio alternativo>, establecido a los parametros del servicio alternativo
ii. un elemento hijo <tipo>, establecido a “restauracion” para indicar que se soportan procedimientos de restauracion;
iii. una elemento hijo <razon>, establecido a una razon configurable del operador; y
iv. un elemento hijo <accion>, establecido a un “registro inicial”
Ademas, se podnan hacer las siguientes modificaciones a la TS 24.229 3GPP, subclausula 5.10.4.1, titulada “General”:
NOTA 1: la funcionalidad THIG se realiza en la version 5 y la version 6 de la I-CSCF y es compatible con los procedimientos especificados en esta subclausula.
Los siguientes procedimientos solo se aplicaran si la ocultacion de la topologfa de red es requerida por la red. La red que requiere la ocultacion de la topologfa de red es llamada red de ocultacion.
NOTA 2: Las solicitudes y respuestas se manejan independientemente por lo tanto no se necesita informacion de estado para tal proposito dentro de una IBCF.
La IBCF aplicara la topologfa de red ocultandola a todos los campos de la cabecera que revelan informacion de la topologfa, tales como Via, Ruta, Ruta de Registro, Ruta de Servicio, y Camino.
Tras recibir una solicitud de REGISTRO entrante para la cual se ha de aplicar la ocultacion de la topologfa de red y la cual incluye un campo de cabecera de Camino, la IBCF anadira el URI SIP enrutable de la IBCF a la parte superior del campo de cabecera de Camino. La IBCF puede incluir en la URI SIP insertada un indicador que identifica la direccion de las posteriores solicitudes recibidas por la IBCF esto es, desde la S-CSCF hacia la P-CSCf, para identificar el caso de terminacion del UE. La IBCF puede codificar este indicador de diferentes maneras, tales
7
5
10
15
20
25
30
35
40
como, por ejemplo, un parametro unico en la URI, una cadena de caracteres en la parte del nombre de usuario del URI, o un numero de puerto dedicado en el URI.
NOTA 3: Cualquier solicitud posterior que incluya el indicador de direccion (en el campo de cabecera de Ruta) o llegue por el numero de puerto dedicado, indica que la solicitud fue enviada por la S-CSCF hacia la P-CSCF.
Tras recibir una solicitud inicial entrante para la cual se ha de aplicar la ocultacion de la topologfa de red una solicitud SIP o una respuesta SIP con un campo de cabecera de la Identidad Afirmada P establece el URI SIP de un elemento funcional dentro de su dominio de confianza, la IBCF aplicara la ocultacion de la topologfa de red al campo de cabecera de la Identidad Afirmada P
Tras recibir una solicitud inicial entrante para la cual se ha de aplicar la ocultacion de la topologfa de red y la cual incluye un campo de cabecera de Ruta de Registro, la IBCF anadira su propio URI SIP enrutable a la parte superior del campo de cabecera de Ruta de Registro.
El UE puede recibir un valor diferente del valor almacenado por el nodo de red como la IBCF puede realizar la ocultacion de la ubicacion y reemplazo de los URI en el mensaje SIP (tales como los campos de cabecera de Ruta de Servicio o Camino) con, por ejemplo, al menos uno de los valores del URI SIP de la IBCF. Consecuentemente la IBCF tendna que realizar esta ocultacion de la ubicacion o el reemplazo de estos URI para no romper la confianza que se indica.
Cuando el UA SIP recibe un mensaje SIP, este analizara una tabla dentro de la funcion para ver si se necesita realizar algunas acciones para ese mensaje SIP, por ejemplo, una solicitud de INVITACION. La tabla o la estructura de datos identifican los indicadores. Estos indicadores podnan ser, pero no estan limitados a, campos de la cabecera SIP, valores espedficos de SIP a buscar, etc. Para cada campo, podna haber tambien una accion o un grupo de acciones que podnan ser realizadas pero que no estan limitados a:
Eliminar
Ignorar
Terminar
Confianza
No confianza
Mensaje de confianza
Elimina el elemento si no es de confianza Ignora el elemento
Termina el dialogo o rechaza el dialogo para continuar Marca el campo como de confianza Marca el campo como de no confianza Marca el mensaje como de confianza
Mensaje de no confianza Marca el mensaje como de no confianza
Para los ultimos dos elementos, “Mensaje de confianza” y “Mensaje de no confianza”, todos los elementos en el metodo SIP tienen que ser de confianza. El metodo para identificar el mensaje como de confianza podna ser transportado como:
A. Etiqueta de nueva caractenstica Aqu se anadira una etiqueta de caractenstica a la cabecera de contacto con un valor que indica la fiabilidad del mensaje.
B. Nuevo parametro URI
C. Parte del cuerpo (por ejemplo, en XML)
D. Nuevo campo de cabecera
Una realizacion de ejemplo de la estructura de datos es la siguiente.
Metodo SIP
> INVITACION
I
|> Campo 1: Valor X
| |>Accion: Eliminar, ignorar, terminar, dialogar etc
|> Campo 2: Valor k, c
5
10
15
20
25
30
35
40
45
50
55
|>200 OK ||
| |>Campo 3: Valor....
El UA 110 y otros componentes descritos anteriormente podnan incluir un componente de procesamiento que sea capaz de ejecutar las instrucciones relacionadas con las acciones descritas anteriormente. La Figura 5 ilustra un ejemplo de un sistema 1300 que incluye un componente 1310 de procesamiento adecuado para implementar una o mas realizaciones descritas aqrn. Ademas del procesador 1310 (el cual puede ser referido como una unidad central de procesamiento o CPU), el sistema 1300 podna incluir dispositivos 1320 de conectividad de red, memoria de acceso aleatoria (RAM) 1330, memoria de solo lectura (ROM) 1340, un almacenamiento secundario 1350, y dispositivos 1360 de entrada/salida (I/O). Estos componentes podnan comunicarse los unos con los otros a traves de un bus 1370. En algunos casos, algunos de estos componentes pueden no estar presentes o pueden estar combinados los unos con los otros o con otros componentes no mostrados en varias combinaciones. Estos componentes se podnan ubicar en una entidad ffsica unica o en mas de una entidad ffsica. Cualquier accion descrita aqrn como que es tomada por el procesador 1310 podna ser tomada por el procesador 1310 solo o por el procesador 1310 en conjuncion con uno o mas componentes mostrados o no mostrados en los dibujos, tales como un procesador digital de la senal (DSP) 1380. Aunque el DSP 1380 se muestra como un componente separado, el DSP 1380 podna ser incorporado en el procesador 1310.
El procesador 1310 ejecuta las instrucciones, codigos, programas de ordenador, o scripts que se podnan acceder desde los dispositivos 1320 de conectividad de red, la RAM 1330, la ROM 1340 o el almacenamiento secundario 1350 (el cual podna incluir varios sistemas basados en disco tales como un disco duro, un disco flexible o un disco optico). Aunque solo se muestra una CPU 1310, pueden estar presentes multiples procesadores. Asf, aunque las instrucciones pueden ser discutidas como que son ejecutadas por un procesador, las instrucciones pueden ser ejecutadas simultaneamente, en serie, o de otra manera por uno o multiples procesadores. El procesador 1310 se puede implementar como uno o mas chips CPU.
Los dispositivos 1320 de conectividad de red pueden tomar la forma de modems, bancos de modems, dispositivos de Ethernet, dispositivos de interfaz de bus serie universal (USB), interfaces seriales, dispositivos token ring, dispositivos de la interfaz de datos distribuida por fibra (FDDI), dispositivos de red de area local inalambrica (WLAN), dispositivos transceptores de radio tales como los dispositivos de acceso multiple por division de codigo (CDMA), dispositivos transceptores de radio para las comunicaciones moviles (GSM), dispositivos de interoperabilidad mundial para el acceso por microondas (WiMAX), y/u otros dispositivos bien conocidos para conectarse a las redes. Estos dispositivos 1320 de conectividad de red pueden permitir al procesador 1310 comunicarse con Internet o una o mas redes de telecomunicaciones u otras redes desde las cuales el procesador 1310 podna recibir informacion o a las cuales el procesador 1310 podna emitir informacion. Los dispositivos 1320 de conectividad de red podnan tambien incluir uno o mas componentes 1325 transceptores capaces de transmitir y/o recibir datos inalambricamente.
La RAM 1330 se podna usar para almacenar datos volatiles y quizas para almacenar instrucciones que son ejecutadas por el procesador 1310. La ROM 1340 es un dispositivo de memoria no volatil que normalmente tiene una menor capacidad de memoria que la capacidad de memoria del almacenamiento secundario 1350. La ROM 1340 se podna usar para almacenar instrucciones y quizas datos que sean lefdos durante la ejecucion de las instrucciones. El acceso tanto a la RAM 1330 como a la ROM 1340 es normalmente mas rapido que al almacenamiento secundario 1350. El almacenamiento secundario 1350 esta comprendido normalmente de una o mas unidades de disco o unidades de cinta y podna ser usado por el almacenamiento no volatil de datos o como un dispositivo de almacenamiento de datos de desbordamiento si la RAM 1330 no es suficientemente grande para mantener todos los datos de trabajo. El almacenamiento secundario 1350 se puede usar para almacenar programas que se cargan en la RAM 1330 cuando dichos programas son seleccionados para su ejecucion.
Los dispositivos 1360 de I/O pueden incluir elementos de presentacion de cristal lfquido (LCD), pantallas tactiles, teclados, teclados numericos, conmutadores, diales, ratones, ruedas de desplazamiento, reconocedores de voz, lectores de tarjetas, lectores de cinta de papel, impresoras, monitores de video, u otros dispositivos de entrada o salida bien conocidos. Tambien, el transceptor 1325 podna ser considerado ser un componente de los dispositivos 1360 de I/O en lugar de o ademas de ser un componente de los dispositivos 1320 de conectividad de red.
En una realizacion, se proporciona un metodo para determinar si un nodo fuera de un dominio de confianza en una red IMS puede ser de confianza. El metodo incluye un UA que recibe un mensaje del nodo de red que contiene un indicador de confianza. El metodo ademas incluye al UA determinando si el indicador de confianza coincide con la informacion de confianza almacenada en el UA. El metodo ademas incluye, cuando el indicador de confianza coincide con la informacion de confianza almacenada en el UA, al UA realizando todas las acciones normalmente asociadas con la recepcion del mensaje. El metodo ademas incluye, cuando el indicador de confianza no coincide
5
10
15
20
25
30
35
40
45
con la informacion de confianza almacenada en el UA, al UA absteniendose de realizar al menos una accion de las normalmente asociadas con la recepcion del mensaje.
En otra realizacion, se proporciona un UA. El UA incluye un procesador configurado para recibir de un nodo fuera del dominio de confianza en una red IMS un mensaje que contiene un indicador de confianza. El procesador se configura ademas para determinar si el indicador de confianza coincide con la informacion de confianza almacenada en el UA. El procesador se configura ademas, cuando el indicador de confianza coincide con la informacion de confianza almacenada en el UA, para realizar todas las acciones normalmente asociadas con la recepcion del mensaje. El procesador se configura ademas, cuando el indicador de confianza no coincide con la informacion de confianza almacenada en el UA, para abstenerse de realizar al menos una accion de las normalmente asociadas con la recepcion del mensaje.
En otra realizacion, se proporciona un metodo alternativo para determinar si un nodo fuera del dominio de confianza en una red IMS puede ser de confianza. El metodo incluye un UA que recibe un mensaje del nodo de red. El metodo ademas incluye al UA determinando si un indicador de confianza esta presente en el mensaje. El metodo ademas incluye, cuando el indicador de confianza esta presente en el mensaje, al UA realizando todas las acciones normalmente asociadas con la recepcion del mensaje. El metodo ademas incluye, cuando el indicador de confianza no esta presente en el mensaje, al UA absteniendose de realizar al menos una accion de las normalmente asociadas con la recepcion del mensaje.
En otra realizacion, se proporciona un UA. El UA incluye un procesador configurado para recibir un mensaje de un nodo fuera del dominio de confianza en una red IMS. El procesador se configura ademas para determinar si un indicador de confianza esta presente en el mensaje. El procesador se configura ademas, cuando el indicador de confianza esta presente en el mensaje, para realizar todas las acciones normalmente asociadas con la recepcion del mensaje. El procesador se configura ademas, cuando el indicador de confianza no esta presente en el mensaje, para abstenerse de realizar al menos una accion de las normalmente asociadas con la recepcion del mensaje.
En otra realizacion, se proporciona un metodo para realizar el registro. El metodo incluye la recepcion de un mensaje de tiempo de espera del servidor, incluyendo el mensaje de tiempo de espera del servidor al menos un primer campo establecido a un valor igual al valor recibido en un segundo campo durante un primer registro. El metodo ademas incluye el inicio de los procedimientos de restauracion mediante la realizacion de un segundo registro en respuesta a la recepcion del mensaje de tiempo de espera del servidor.
En otra realizacion, se proporciona un UA. El UA incluye uno o mas procesadores configurados tales que el UA reciba un mensaje de tiempo de espera del servidor que incluye al menos un primer campo establecido a un valor igual al valor recibido en un segundo campo durante un primer registro, y configurado tal que el UA inicie los procedimientos de restauracion mediante la realizacion de un segundo registro en respuesta a la recepcion del mensaje de tiempo de espera del servidor.
La siguiente Especificacion Tecnica (TS) del Proyecto de Asociacion de 3a Generacion (3GPP) se incorpora aqrn por la referencia: tS 24.229
Los presentes ejemplos han de ser considerados como ilustrativos y no restrictivos, y la intencion no es estar limitado a los detalles dados aqrn. Por ejemplo, los diversos elementos o componentes se pueden combinar o integrar en otro sistema o ciertas caractensticas se pueden omitir, o no implementar.
Tambien, las tecnicas, los sistemas, los subsistemas y los metodos descritos e ilustrados en las diversas realizaciones como discretos o separados se pueden combinar o integrar con otros sistemas, modulos, tecnicas o metodos sin salir del alcance de la presente descripcion. Otros elementos mostrados o discutidos como acoplados o acoplados o que se comunican directamente los unos con los otros se pueden acoplar indirectamente o comunicarse a traves de alguna interfaz, dispositivo, o componente intermedio, bien electricamente, mecanicamente, o de otra manera. Otros ejemplos de cambios, sustituciones, y alteraciones son comprobables por alguien experto en la tecnica y podnan ser hechos sin salir del alcance aqrn descrito.

Claims (12)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    REIVINDICACIONES
    1. Un metodo realizado por un agente de usuario para realizar el registro, comprendiendo el metodo:
    recibir un mensaje de tiempo de espera del servidor, en el UA, incluyendo el mensaje de tiempo de espera del servidor al menos un primer campo establecido a un valor igual al valor recibido en un segundo campo durante un primer registro del UA, en donde el segundo campo es un campo de cabecera de Ruta de Servicio y el primer campo comprende un campo de cabecera de la Identidad Afirmada P; e
    iniciar los procedimientos de restauracion, en el UA, mediante la realizacion de un segundo registro en respuesta a la recepcion del mensaje de tiempo de espera del servidor.
  2. 2. El metodo como se reivindica en la reivindicacion 1, en donde el valor recibido en el mensaje de tiempo de espera del servidor es un protocolo de inicio de sesiones, SIP, un identificador de recurso uniforme, URI, de una Funcion de control de sesion de llamada servidora, S-CSCF.
  3. 3. El metodo como se reivindica en la reivindicacion 1, en donde, cuando el valor del mensaje de tiempo de espera del servidor incluye el primer campo establecido a un valor no igual al valor recibido durante el primer registro, no se realiza la restauracion.
  4. 4. El metodo de cualquiera de las reivindicaciones precedentes, en donde el mensaje de tiempo de espera del servidor se recibe de un nodo de red dentro de un dominio de confianza.
  5. 5. El metodo de cualquiera de las reivindicaciones precedentes, en donde el mensaje de tiempo de espera del servidor se recibe de un nodo de red que realiza servicios.
  6. 6. El metodo de cualquiera de las reivindicaciones precedentes, que comprende ademas la recepcion del mensaje de tiempo de espera del servidor en respuesta a un mensaje de solicitud.
  7. 7. Un agente de usuario, UA, que comprende:
    un procesador configurado tal que el UA recibe un mensaje de tiempo de espera del servidor, incluyendo el mensaje de tiempo de espera del servidor al menos un primer campo establecido a un valor igual al valor recibido en un segundo campo durante un primer registro, en donde el segundo campo es un campo de cabecera de Ruta de Servicio y el primer campo comprende un campo de cabecera de la Identidad Afirmada P, y configurado tal que el UA inicia los procedimientos de restauracion mediante la realizacion de un segundo registro en respuesta a la recepcion del mensaje de tiempo de espera del servidor.
  8. 8. El UA como se reivindica en la reivindicacion 7, en donde el valor recibido en el mensaje de tiempo de espera del servidor es un protocolo de inicio de sesion, SIP, un identificador de recurso uniforme, URI, de una funcion de control de sesion de llamada servidora, S-CSCF.
  9. 9. El UA como se reivindica en la reivindicacion 7, en donde cuando el valor del mensaje de tiempo de espera del servidor incluye el primer campo establecido a un valor no igual al valor recibido durante el primer registro, no se realiza la restauracion.
  10. 10. El UA de cualquiera de las reivindicaciones 7 a 9, en donde el mensaje de tiempo de espera del servidor se recibe desde un nodo de red dentro de un dominio de confianza.
  11. 11. El UA de cualquiera de las reivindicaciones 7 a 10, en donde el mensaje de tiempo de espera del servidor se recibe de un nodo de red que realiza servicios.
  12. 12. El UA de cualquiera de las reivindicaciones 7 a 11, en donde el procesador se configura ademas para recibir el mensaje de tiempo de espera del servidor en respuesta a un mensaje de solicitud.
ES10764806.5T 2009-04-13 2010-03-19 Sistema y método para determinar la confianza de los mensajes SIP Active ES2623474T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16879809P 2009-04-13 2009-04-13
US168798P 2009-04-13
PCT/US2010/027973 WO2010120432A1 (en) 2009-04-13 2010-03-19 System and method for determining trust for sip messages

Publications (1)

Publication Number Publication Date
ES2623474T3 true ES2623474T3 (es) 2017-07-11

Family

ID=42935217

Family Applications (2)

Application Number Title Priority Date Filing Date
ES16173001T Active ES2773546T3 (es) 2009-04-13 2010-03-19 Sistema y método para determinar la confianza para mensajes de SIP
ES10764806.5T Active ES2623474T3 (es) 2009-04-13 2010-03-19 Sistema y método para determinar la confianza de los mensajes SIP

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES16173001T Active ES2773546T3 (es) 2009-04-13 2010-03-19 Sistema y método para determinar la confianza para mensajes de SIP

Country Status (10)

Country Link
US (10) US8407354B2 (es)
EP (4) EP3754942A1 (es)
JP (1) JP5313395B2 (es)
KR (1) KR101333164B1 (es)
CN (2) CN104394146B (es)
CA (1) CA2758486C (es)
ES (2) ES2773546T3 (es)
HK (1) HK1204402A1 (es)
HU (2) HUE046329T2 (es)
WO (1) WO2010120432A1 (es)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2218242B1 (en) 2007-10-27 2019-09-11 BlackBerry Limited Content disposition system and method for processing message content in a distributed environment
EP3754942A1 (en) 2009-04-13 2020-12-23 BlackBerry Limited System and method for determing trust for sip messages
US8239705B2 (en) * 2009-06-30 2012-08-07 At&T Intellectual Property I, L.P. Method and apparatus for managing communication services for user endpoint devices
US9124597B2 (en) * 2009-09-17 2015-09-01 Telefonaktiebolaget Lm Ericsson (Publ) Method and node in a telecommunications network
CN102480486B (zh) * 2010-11-24 2015-07-22 阿尔卡特朗讯公司 验证通信会话的方法、设备及***
EP2512095B1 (en) 2010-12-23 2020-04-01 BlackBerry Limited Card toolkit support for ip multimedia subsystem
EP2840837B1 (en) * 2012-04-20 2017-06-07 Huawei Technologies Co., Ltd. Mtc device communication method, device and system
CN103517231B (zh) * 2012-06-20 2019-02-05 中兴通讯股份有限公司 Mtc设备及攻击防护的方法、短消息业务服务中心
US9319450B2 (en) * 2012-12-10 2016-04-19 At&T Intellectual Property I, L.P. Emergency alert messages via social media
CN104170352B (zh) 2012-12-19 2018-09-07 统一有限责任两合公司 传达表示第一通信设备的物理位置的位置信息的方法、用于执行该方法的计算机程序产品、以及用于传达位置信息的第一通信设备
JP6501084B2 (ja) * 2013-09-24 2019-04-17 日本電気株式会社 P−cscf障害が発生したときのp−cscf復旧を容易にする方法及び装置
US10050888B2 (en) * 2014-01-10 2018-08-14 Appex Networks Holding Limited System and method for compression and decompression devices discovery and handshake
WO2016154858A1 (zh) * 2015-03-30 2016-10-06 华为技术有限公司 一种无线通信的方法、远程用户设备和中继用户设备
EP3295618B1 (en) * 2015-05-15 2019-04-17 Telefonaktiebolaget LM Ericsson (publ) Routing in a multi-path network
US9986525B1 (en) * 2016-11-30 2018-05-29 T-Mobile Usa, Inc. Error handling during IMS subscription for registration status
US10051017B2 (en) * 2016-12-28 2018-08-14 T-Mobile Usa, Inc. Error handling during IMS registration
US10736070B2 (en) * 2017-07-26 2020-08-04 Blackberry Limited Method and system for use of a relay user equipment in an internet protocol multimedia subsystem
US10986501B2 (en) * 2019-01-08 2021-04-20 T-Mobile Usa, Inc. Secure telephone identity (STI) certificate management system
US11722595B2 (en) * 2019-02-04 2023-08-08 Comcast Cable Communications, Llc Systems and methods for processing calls
CN110430172B (zh) * 2019-07-18 2021-08-20 南京茂毓通软件科技有限公司 基于动态会话关联技术的互联网协议内容还原***及方法
US11416620B1 (en) * 2019-11-01 2022-08-16 Sprint Communications Company L.P. Data communication service in a trusted execution environment (TEE) at the network edge
CN113132337B (zh) * 2020-01-15 2022-06-07 成都鼎桥通信技术有限公司 一种集群终端的sip注册方法和装置
CN113382000A (zh) * 2021-06-09 2021-09-10 北京天融信网络安全技术有限公司 一种ua字符串的异常检测方法、装置、设备及介质

Family Cites Families (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5809230A (en) * 1996-01-16 1998-09-15 Mclellan Software International, Llc System and method for controlling access to personal computer system resources
US7013305B2 (en) * 2001-10-01 2006-03-14 International Business Machines Corporation Managing the state of coupling facility structures, detecting by one or more systems coupled to the coupling facility, the suspended state of the duplexed command, detecting being independent of message exchange
US7243370B2 (en) * 2001-06-14 2007-07-10 Microsoft Corporation Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication
GB0322891D0 (en) * 2003-09-30 2003-10-29 Nokia Corp Communication method
GB0324597D0 (en) * 2003-10-21 2003-11-26 Nokia Corp A communication system
US20050130647A1 (en) * 2003-10-22 2005-06-16 Brother Kogyo Kabushiki Kaisha Wireless lan system, communication terminal and communication program
US20050190772A1 (en) 2004-02-26 2005-09-01 Shang-Chih Tsai Method of triggering application service using filter criteria and IP multimedia subsystem using the same
KR100884314B1 (ko) 2004-05-03 2009-02-18 노키아 코포레이션 Ip 네트워크의 신뢰 도메인에서 아이덴티티들의 처리
GB0417296D0 (en) * 2004-08-03 2004-09-08 Nokia Corp User registration in a communication system
CN101069402B (zh) 2004-10-26 2010-11-03 意大利电信股份公司 透明地验证访问web服务的移动用户的方法和***
GB2435587B (en) 2004-12-13 2008-10-01 Transnexus Inc Method and system for securely authorizing VOIP interconnections between anonymous peers of VOIP networks
US8059633B2 (en) * 2005-05-27 2011-11-15 Telefonaktiebolaget Lm Ericsson (Publ) Call forwarding in an IP multimedia subsystem (IMS)
US8933967B2 (en) 2005-07-14 2015-01-13 Charles D. Huston System and method for creating and sharing an event using a social network
WO2007009498A1 (en) * 2005-07-19 2007-01-25 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for distributing application server addresses in an ims
CN1905472B (zh) * 2005-07-27 2010-05-05 华为技术有限公司 一种ims网络可靠性实现方法
US7899168B2 (en) * 2005-08-31 2011-03-01 Microsoft Corporation Controlling or monitoring PBX phone from multiple PC endpoints
JP4778282B2 (ja) * 2005-09-16 2011-09-21 日本電気株式会社 通信接続方法及びシステム並びにプログラム
EP1879337B1 (en) 2005-10-21 2012-08-29 Huawei Technologies Co., Ltd. A method for processing the register message in the ims network according to the initial filtering rules
GB2432748A (en) * 2005-11-25 2007-05-30 Ericsson Telefon Ab L M SIP messaging in an IP Multimedia Subsystem wherein a local user identity is added to message header as a basis for application server processing
CN101443749B (zh) * 2005-12-08 2012-11-14 北方电讯网络有限公司 会话启动协议(sip)多播管理方法
JP4635855B2 (ja) * 2005-12-13 2011-02-23 株式会社日立製作所 データ通信方法およびシステム
US20070150773A1 (en) * 2005-12-19 2007-06-28 Nortel Networks Limited Extensions to SIP signaling to indicate SPAM
DK1964349T3 (en) 2005-12-19 2016-03-07 Ericsson Telefon Ab L M Technology to provide interoperability between different protocol domains
US7630372B1 (en) 2005-12-30 2009-12-08 At&T Corp. Method and apparatus for providing access and egress uniform resource identifiers for routing
US7668183B2 (en) 2006-02-02 2010-02-23 Alcatel-Lucent Usa Inc. Flexible SIP profile for mixed networks
WO2007096001A1 (en) * 2006-02-24 2007-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Ims-enabled control channel for iptv
US8364861B2 (en) * 2006-03-28 2013-01-29 Mosaid Technologies Incorporated Asynchronous ID generation
US9419955B2 (en) 2006-03-28 2016-08-16 Inventergy Inc. System and method for carrying trusted network provided access network information in session initiation protocol
EP2030400B1 (en) 2006-05-15 2015-09-23 Telefonaktiebolaget L M Ericsson (publ) Method and apparatuses for establishing a secure channel between a user terminal and a sip server
US8121624B2 (en) * 2006-07-25 2012-02-21 Alcatel Lucent Message spoofing detection via validation of originating switch
US9258367B2 (en) 2006-08-01 2016-02-09 Cisco Technology, Inc. Technique for managing sessions with entities in a communication network
JP4336904B2 (ja) * 2006-08-18 2009-09-30 日本電気株式会社 プロキシ・サーバ、通信システム、通信方法及びプログラム
JP4470934B2 (ja) * 2006-10-20 2010-06-02 日本電気株式会社 プロキシ・サーバ、通信システム、通信方法及びプログラム
WO2008049455A1 (en) * 2006-10-23 2008-05-02 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for transporting signalling connectivity status information relating to the signalling connection between a terminal and p-cscf in ims
CN101170553B (zh) 2006-10-24 2011-07-20 华为技术有限公司 实现互联网协议多媒体子***容灾的方法和装置
EP1916821B1 (en) 2006-10-24 2018-02-07 Nokia Solutions and Networks GmbH & Co. KG Method and apparatus for re-assignment of S-CSCF services to registered IMS users of a Home Subscriber Server HSS
WO2008061570A1 (en) * 2006-11-24 2008-05-29 Telefonaktiebolaget Lm Ericsson (Publ) Authentication in a communications network
US8929360B2 (en) 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
US8041331B2 (en) 2007-01-05 2011-10-18 Research In Motion Limited System and method for conditionally attempting an emergency call setup
US20080182575A1 (en) 2007-01-30 2008-07-31 Motorola, Inc. Ims reliability mechanisms
CN101237336B (zh) * 2007-02-01 2011-10-05 华为技术有限公司 进行多方通信的方法、***及装置
US7961849B2 (en) * 2007-02-26 2011-06-14 Genband Us Llc Implementing an emergency services solution
US7668159B2 (en) 2007-04-25 2010-02-23 Research In Motion Limited Methods and apparatus for obtaining variable call parameters suitable for use in originating a SIP call via a circuit-switched network from a user equipment device
EP1990750A1 (en) * 2007-05-09 2008-11-12 Nokia Siemens Networks Oy Method and device for data processing and communication system comprising such device
US20090002333A1 (en) * 2007-06-22 2009-01-01 Chumby Industries, Inc. Systems and methods for device registration
WO2009036184A2 (en) 2007-09-11 2009-03-19 Research In Motion Limited System and method for sharing a sip communication service identifier
CN101796797A (zh) * 2007-09-14 2010-08-04 艾利森电话股份有限公司 在ip多媒体子***通信网络中处理信任的方法和设备
US9900347B2 (en) * 2007-09-14 2018-02-20 Telefonaktiebolaget Lm Ericsson (Publ) Handling trust in an IP multimedia subsystem communication network
CN103152170A (zh) * 2007-09-14 2013-06-12 安全第一公司 用于管理加密密钥的***和方法
CN101809961B (zh) 2007-09-28 2013-03-27 爱立信电话股份有限公司 Ip多媒体子***网络中的故障恢复
US20090103518A1 (en) 2007-10-18 2009-04-23 Motorola, Inc. Call origination by an application server in an internet protogol multimedia core network subsystem
WO2009067459A1 (en) * 2007-11-19 2009-05-28 Research In Motion Limited System and method for processing settlement information in a network environment including ims
EP2253121B1 (en) 2008-01-11 2012-07-04 Telefonaktiebolaget L M Ericsson (publ) Message handling in an ip multimedia subsystem
US9241253B2 (en) * 2008-01-24 2016-01-19 At&T Intellectual Property I, L.P. System and method of providing a user with a registration review in IMS system
US8134956B2 (en) 2008-01-24 2012-03-13 At&T Intellectual Property I, L.P. System and method of providing registration alert in an IMS system
EP2083547A1 (en) * 2008-01-25 2009-07-29 Hewlett-Packard Development Company, L.P. Improvements in or relating to communications
JP4940163B2 (ja) * 2008-02-05 2012-05-30 株式会社日立製作所 通信ゲートウェイ装置及び中継方法
ATE524008T1 (de) 2008-02-29 2011-09-15 Ericsson Telefon Ab L M Technik zur durchführung einer signalisierungsumsetzung zwischen http- und sip- domänen
US8478226B2 (en) 2008-06-02 2013-07-02 Research In Motion Limited Updating a request related to an IMS emergency session
WO2009146739A2 (en) 2008-06-03 2009-12-10 Telefonaktiebolaget Lm Ericsson (Publ) Identifying user role in ip multimedia subsystem
US9749309B2 (en) 2008-09-12 2017-08-29 Nokia Solutions And Networks Oy Identity management system
US8359643B2 (en) * 2008-09-18 2013-01-22 Apple Inc. Group formation using anonymous broadcast information
US20100082972A1 (en) * 2008-09-29 2010-04-01 Benco David S Method to allow targeted advertising on mobile phones while maintaining subscriber privacy
US9166960B2 (en) * 2008-11-04 2015-10-20 Telefonaktiebolaget L M Ericsson (Publ) Mobile radio access information validation
EP3754942A1 (en) 2009-04-13 2020-12-23 BlackBerry Limited System and method for determing trust for sip messages
US20110299442A1 (en) * 2010-06-04 2011-12-08 Sairamesh Nammi Methods and apparatus for controlling location for starting decoding of sub-packets of a communication packet

Also Published As

Publication number Publication date
US20190068656A1 (en) 2019-02-28
EP3142339A1 (en) 2017-03-15
US20210352117A1 (en) 2021-11-11
US8694660B2 (en) 2014-04-08
JP5313395B2 (ja) 2013-10-09
US20110047277A1 (en) 2011-02-24
EP2601612B1 (en) 2017-02-08
EP3142339B1 (en) 2020-10-21
KR20110138282A (ko) 2011-12-26
ES2773546T3 (es) 2020-07-13
EP3086532B1 (en) 2019-11-06
US20100262704A1 (en) 2010-10-14
US11659011B2 (en) 2023-05-23
US10135885B2 (en) 2018-11-20
CN102460453B (zh) 2014-12-24
US8407354B2 (en) 2013-03-26
US9401935B2 (en) 2016-07-26
EP2601612A1 (en) 2013-06-12
HK1204402A1 (en) 2015-11-13
KR101333164B1 (ko) 2013-11-27
CA2758486C (en) 2017-01-17
US11956284B2 (en) 2024-04-09
CA2758486A1 (en) 2010-10-21
US20160330249A1 (en) 2016-11-10
CN102460453A (zh) 2012-05-16
US11082459B2 (en) 2021-08-03
EP3754942A1 (en) 2020-12-23
US10805360B2 (en) 2020-10-13
HUE046329T2 (hu) 2020-03-30
CN104394146A (zh) 2015-03-04
EP2601612A4 (en) 2014-01-22
EP3086532A1 (en) 2016-10-26
US20170251030A1 (en) 2017-08-31
US20120331158A1 (en) 2012-12-27
US8756330B2 (en) 2014-06-17
US20120331163A1 (en) 2012-12-27
JP2012523752A (ja) 2012-10-04
US20100262699A1 (en) 2010-10-14
CN104394146B (zh) 2017-10-20
US20230239331A1 (en) 2023-07-27
HUE051045T2 (hu) 2021-03-01
US7895302B2 (en) 2011-02-22
WO2010120432A1 (en) 2010-10-21

Similar Documents

Publication Publication Date Title
ES2623474T3 (es) Sistema y método para determinar la confianza de los mensajes SIP
BRPI0913427B1 (pt) codificação e compartimento quando se recebe um indicador de sessão de emergência de ims a partir de uma fonte autorizada
US9723029B2 (en) Providing session initiation protocol request contents method and system
ES2393301T3 (es) Sistema y método para gestionar solicitudes de emergencia
CA2612847C (en) Exchange and use of globally unique device identifiers for circuit-switched and packet switched integration
CN102150412A (zh) 用于基于独特装置标识符的实例标识符的方法和设备
BRPI0714195A2 (pt) mÉtodo e equipamento para registro e estabelecimento de chamada de emergÊncia em paralelo
BRPI0717609A2 (pt) Sistema e método para fornecer serviços combinacionais a chamadores anônimos
ES2374058T3 (es) Subsistema multimedia ip (ims) y método para enviar un mensaje http a través de un ims.
Rebahi et al. Security in the Emergency Services Support for the IP Multimedia Subsystem (IMS)