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

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

Info

Publication number
ES2773546T3
ES2773546T3 ES16173001T ES16173001T ES2773546T3 ES 2773546 T3 ES2773546 T3 ES 2773546T3 ES 16173001 T ES16173001 T ES 16173001T ES 16173001 T ES16173001 T ES 16173001T ES 2773546 T3 ES2773546 T3 ES 2773546T3
Authority
ES
Spain
Prior art keywords
message
network node
sip message
sip
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.)
Active
Application number
ES16173001T
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 ES2773546T3 publication Critical patent/ES2773546T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error 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/2002—Error 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/2007—Error 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input 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/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1202—Dedicated interfaces to print systems specifically adapted to achieve a particular effect
    • G06F3/1203—Improving or facilitating administration, e.g. print management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/385—Uniform resource identifier for session initiation protocol [SIP URI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/212—Monitoring or handling of messages using filtering or selective blocking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key 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/083—Key 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 primer nodo (130) de red de un Subsistema Multimedia de Protocolo de Internet, IMS, Red, el método comprende: recibir en el primer nodo de red, un Identificador de Recursos Uniforme, URI, en un campo de encabezado en un primer Protocolo de Inicio de Sesión, SIP, mensaje (140); recibir en el primer nodo de red, una credencial en el campo de encabezado en el primer mensaje (140) de SIP, la credencial indicadora de un tipo de un nodo (120) de red en una ruta del primer mensaje (140) de SIP, en el que el primer mensaje de SIP es una solicitud de REGISTER de SIP presentada por un agente de usuario, UA; con base en la credencial recibida, enviar mediante el primer nodo de red, un segundo mensaje (150) de SIP que incluye el URI recibido, el segundo mensaje (150) que transmite información acerca del primer nodo (130) de red; y recibir un tercer mensaje de SIP activado por el primer mensaje de SIP, en el que el tercer mensaje de SIP activado por el primer mensaje de SIP es una solicitud de registro de un tercero que se configura por Criterio de Filtro inicial sobre una Función de Control de Sesión de Llamada en Servicio, S-CSCF.

Description

DESCRIPCIÓN
Sistema y método para determinar la confianza para mensajes de SIP
Antecedentes
El Subsistema Multimedia del IP (Protocolo de Internet) (IMS) es una arquitectura estandarizada para proporcionar servicios multimedia y llamadas de voz sobre IP para tanto agentes de usuarios (UA) móviles como fijos. El Protocolo de Inicio de Sesión (SIP) ha sido estandarizado y regido principalmente por el Grupo de Trabajo de Ingeniería de Internet (IETF) como un protocolo de señalización para crear, modificar y finalizar llamadas o sesiones basadas en IMS.
Como se utiliza en este documento, los términos “agente de usuario” y “UA” se pueden referir en algunos casos a dispositivos móviles tales como teléfonos móviles, asistentes digitales personales, ordenadores de mano o portátiles, y dispositivos similares que tienen capacidades de telecomunicaciones. Dicha UA podría ser parte de un UE (Equipo de Usuario). Un UE puede tener múltiples UA. Un UE puede tener un módulo de memoria extraíble asociado, tal como, pero no limitado a, una Tarjeta de Circuito Integrado Universal (UICC) que incluye una aplicación de Módulo de Identidad de Suscriptor (SIM), una aplicación del Módulo de Identidad del Suscriptor Universal (USIM), una aplicación del Módulo de Identidad de Servicios Multimedia de IP (ISIM), o una aplicación de Módulo de Identidad de Usuario Extraíble (R-UIM), etc. Ejemplos de dichos módulos pueden incluir, entre otros, Tarjeta de PC, CompactFlash I, CompactFlash II, SmartMedia, Tarjeta de Memoria, Tarjeta de Memoria Duo, Tarjeta de Memoria PRO Duo, Tarjeta de Memoria PRO-HG Duo, Tarjeta de Memoria Micro M2, Tarjeta Multimedia, Tarjeta Multimedia de Tamaño Reducido, Tarjeta MMCmicro, tarjeta de Seguro Digital, SxS, Almacenamiento Flash Universal, tarjeta miniSD, tarjeta microSD, Tarjeta xD-Picture, Memoria Inteligente, Módulo de Flash en Serie, tarjeta |j y Tarjeta NT. Cuando la información se almacena en un módulo de memoria extraíble, los contenidos del módulo se pueden visualizar en el UE.
Alternativamente, dicho UA podría consistir en el dispositivo mismo sin dicho módulo. En otros casos, el término “UA” se podría referir a dispositivos que tienen capacidades similares pero que no son transportables, tales como teléfonos de línea fija, ordenadores de escritorio, decodificadores o nodos de red. Cuando uno o más UA forman parte de un nodo de red, el nodo de red podría actuar a nombre de otra función, tal como un UA o un dispositivo de línea fija, y simular o emular el UA o dispositivo de línea fija. Por ejemplo, para algunos UA, el cliente de SIP de IMS que normalmente residiría en el dispositivo realmente reside en la red y transmite la información del mensaje de SIP al dispositivo utilizando protocolos optimizados. En otras palabras, algunas funciones que tradicionalmente se llevaban a cabo por un UA se pueden distribuir en forma de un UA remoto, en el que el UA remoto representa al UA en la red. El término “UA” también puede referirse a cualquier componente de hardware o software que pueda terminar una sesión de comunicación que podría incluir, pero no se limita a, una sesión de SIP. También, los términos “agente de usuario”, “UA”, “equipo de usuario”, “UE” y “nodo” se pueden utilizar como sinónimos en el presente documento. También, los términos “encabezado” y “campo de encabezado” se pueden utilizar como sinónimos en este documento. También, un mensaje de SIP es una solicitud de SIP o una respuesta de SIP.
Un UA se puede conectar a una red basada en SIP que incluye una pluralidad de otros componentes tales como una P-CSCF (Función de Control de Sesión de Llamada de Proxy), una S-CSCF (CSCF de Servicio), una IBCF (Función de Control en la Frontera de Interconexión)), un Servidor de Aplicaciones (AS) y otros componentes, cualquiera de los cuales se podría denominar nodos de red. Puede existir una relación de confianza entre los nodos en una red de SIP. Es decir, un grupo de nodos dentro de una red puede considerar todos los mensajes recibidos de otros nodos en el grupo como legítimos. Se puede decir que dicho grupo forma un dominio de confianza o una o más redes de confianza. IETF RFC 3325 titulado “Extensiones privadas al Protocolo de Inicio de Sesión (SIP) para la Asserted-Identity dentro de las Redes de Confianza” discute este tema más a fondo.
Los documentos WO 2009/033504 A1 y US 2009/077616 A1 divulgan un método para manejar la confianza en una red de Subsistema Multimedia de IP. Un nodo en la red del Subsistema Multimedia de IP recibe un mensaje del Protocolo de Inicio de Sesión desde un nodo remoto. El mensaje incluye un indicador que indica el nivel de confianza de una comunicación enviada desde el nodo remoto hasta el nodo del Subsistema Multimedia de IP. Teniendo como base el indicador, el nodo aplica una política de seguridad al mensaje.
El documento US 2005/068935 A1 divulga un método de comunicación entre una parte que llama en una primera red y una parte llamada en una segunda red. El método comprende determinar en la primera red una dirección asociada con la parte llamada. El método también comprende determinar, en función de la dirección, si la parte llamada está en una red confiable, y controlar la comunicación entre la parte llamada y la parte que llama en función de si la parte llamada está en una red confiable.
El documento WO 2008/049455 A1 divulga un método para transportar información de estado de conectividad de señalización en un Subsistema multimedia de IP.
Breve descripción de los dibujos
Para una comprensión más completa de esta divulgación, se hace referencia ahora a la siguiente breve descripción, tomada en relación con los dibujos acompañantes y la descripción detallada, en la que los números de referencia similares representan partes similares.
La Figura 1 es un diagrama de un sistema de comunicaciones que incluye una pluralidad de nodos de red de acuerdo con una realización de la divulgación.
La Figura 2 es un diagrama de flujo de llamadas que ilustra un método para que un UA recupere información de confianza de acuerdo con una realización de la divulgación.
La Figura 3 ilustra un método para determinar si se puede confiar en un nodo fuera de un dominio de confianza en una red de IMS de acuerdo con una realización de la divulgación.
La Figura 4 ilustra un método para determinar si se puede confiar en un nodo fuera de un dominio de confianza en una red de IMS de acuerdo con una realización alternativa de la divulgación.
La Figura 5 ilustra un procesador y componentes relacionados adecuados para implementar las diversas realizaciones de la presente divulgación.
Descripción detallada
La invención se define en las reivindicaciones independientes. Las realizaciones preferidas se definen en las reivindicaciones dependientes. Se debe entender desde el principio que, aunque a continuación se proporcionan implementaciones ilustrativas de una o más realizaciones de la presente divulgación, los sistemas y/o métodos divulgados se pueden implementar utilizando cualquier número de técnicas, ya sean actualmente conocidas o existentes. La divulgación no debe limitarse de ninguna manera a las implementaciones ilustrativas, dibujos y técnicas ilustradas a continuación, que incluyen los diseños e implementaciones de ejemplo ilustrados y descritos en este documento, sino que puede modificarse 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 de IMS podría recibir un mensaje de un nodo fuera del dominio de confianza. En algunos casos, dicho mensaje podría dirigir al nodo en el dominio de confianza a realizar una o más acciones que pueden no ser deseables para ese nodo. Por ejemplo, un mensaje se puede enviar maliciosamente a una pluralidad de UA informando falsamente a los UA que se ha producido un Tiempo de Espera del Servidor. Una UA que reciba dicho mensaje podría intentar volver a registrarse con un registrador de SIP, aunque en realidad no sea necesario volver a registrarse. Si una gran cantidad de UA intentan volver a registrarse, el registrador podría sobrecargarse y fallar. Esto podría ocasionar problemas importantes en la red, ya que otras UA podrían no poder registrarse.
En una realización, un mensaje enviado a un nodo de red desde fuera del dominio de confianza del nodo de red puede incluir un indicador de confianza que indica la confiabilidad del mensaje. Un indicador de confianza también puede ser una credencial de confianza, una guía de confianza o un indicador de confianza. Los indicadores de confianza pueden ser 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 envió el mensaje. El destinatario de un mensaje que contiene dicho indicador de confianza no necesita realizar ninguna verificación del indicador de confianza. Cuando el otro tipo de indicador de confianza está presente en un mensaje, el destinatario del mensaje compara el indicador de confianza con la información/base de datos de confianza almacenada internamente. Si el indicador de confianza coincide con la información de confianza almacenada, el indicador de confianza se verifica y el destinatario/receptor sabe que se puede confiar en el nodo de red que envió el mensaje.
Si el primer tipo de indicador de confianza está presente en un mensaje o si el segundo tipo está presente y se verifica, el nodo de red que recibe el mensaje realiza las acciones que normalmente están asociadas con la recepción del mensaje o el mensaje y su contenido. Si no hay un indicador de confianza presente o si el indicador de confianza no está verificado, el nodo de red que recibe el mensaje podría no realizar una o más de las acciones que normalmente están asociadas con la recepción del mensaje o el mensaje y su contenido.
En una realización, el nodo de red que recibe el mensaje es un UA que mantiene información de confianza relacionada con los nodos de red fuera del dominio de confianza del UA. Al recibir un mensaje desde fuera de su dominio de confianza, el UA puede comparar el indicador de confianza que podría incluirse con el mensaje con la información de confianza que mantiene el UA. Si el UA verifica que el indicador de confianza coincide con la información de confianza que mantiene, el UA realiza las acciones que normalmente están asociadas con la recepción del mensaje o el mensaje y su contenido. Si el UA no puede verificar que el indicador de confianza coincida con la información de confianza que mantiene, el UA no realiza al menos una acción que normalmente está asociada con la recepción del mensaje o el mensaje y su contenido.
Estas realizaciones se ilustran en la Figura 1, en el que 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 podrían ser componentes en una red basada en IMS, y el nodo A 120 de red y el nodo B 130 de red podrían estar fuera del dominio de confianza de la UA. Si bien solo se muestran otros dos nodos de red, otros números podrían estar presentes. En esta realización, el nodo A 120 de red genera un mensaje A 140 e incluye un indicador A 145 de confianza en el mensaje A 140. El nodo 120 de red luego envía el mensaje A 140 al nodo B 130 de red. La recepción del mensaje A 140 provoca que el nodo B 130 de red genere un mensaje B 150 que contiene un indicador B 155 de confianza, y luego se envía el mensaje B 150 al UA 110. El mensaje A 140 puede o no ser el mismo que el mensaje B 150, y el indicador A 145 de confianza puede o no ser lo mismo que el indicador B 155 de confianza. En otras palabras, el nodo B 130 de red podría simplemente pasar el indicador A 145 de confianza que se recibe del nodo A 120 de red, o el nodo B 130 de red podría generar un nuevo indicador B 155 de confianza basado en el indicador A 145 de confianza u otra información recibida del nodo A 120 de red y/u otros nodos de red.
En otras realizaciones, el nodo A 120 de red no incluye el 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 tener en cuenta ninguna información incluida en el mensaje A 140, y la red el nodo B 130 incluye el indicador B 155 de confianza en el mensaje B 150 enviado al UA 110. En otras palabras, el indicador de confianza que recibe el UA 110 podría haber sido generado por el nodo de red con el que el UA 110 está en comunicación directa, podría haber sido generado por otro nodo de red y luego transmitido sin modificación por el nodo de red con el que el UA 110 está en comunicación directa, o podría haber sido generado por otro nodo de red y luego transmitido con modificación por el nodo de red en el que el UA 110 está en comunicación directa.
En algunas realizaciones, al recibir un mensaje que contiene un indicador de confianza, el UA 110 realiza las acciones que están normalmente asociadas con la recepción del mensaje. En otras realizaciones, al recibir un mensaje que contiene un indicador de confianza, el UA 110 compara el indicador de confianza con la información 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 información 115 de confianza almacenada, el UA 110 realiza las acciones que normalmente están asociadas con la recepción del mensaje. Cuando no se encuentra una coincidencia entre el indicador de confianza y la información 115 de confianza almacenada, el UA 110 no realiza al menos una acción que normalmente está asociada con la recepción del mensaje.
En una realización, el indicador de confianza y/o la información 115 de confianza podría ser un Identificador de Recursos Uniforme (URI), o algún otro tipo de identificador, de un nodo de red confiable. Un nodo de red podría incluir su URI en un mensaje enviado al UA 110. El UA 110 podría haber recibido previamente información 115 de confianza en forma de una lista de URI confiables. Al recibir un mensaje con un indicador de confianza en forma de URI, el UA 110 podría comparar el URI en el mensaje con los u Ri en la lista de URI. Si se encuentra una coincidencia, el UA 110 podría confiar en el nodo de red que envió el mensaje.
El UA 110 podría no ser capaz de identificar si un URI pertenece a una P-CSCF, una S-SCSF, una IBCF o algún otro tipo de nodo de red. Algunos nodos de la red (tales como una IBCF) pueden incluir o no su información de URI. Por lo tanto, el UA puede no estar seguro de qué URI representa qué nodo de red. Para determinar esto, se pueden seguir algunas convenciones o se puede agregar un indicador adicional. Una solicitud REGISTER de SIP y su respuesta (y los valores de campo de encabezado incluidos en la respuesta o solicitud) generalmente no deben abandonar el dominio de confianza. Una solicitud REGISTER de un tercero activada por la solicitud REGISTER original puede abandonar el dominio de confianza. En una realización, se establecen medidas para evitar la contaminación de la información en las respuestas al REGISTER en tal caso. Por ejemplo, el hecho de que un URI representa un nodo de red conocido se podría indicar mediante un parámetro de URI a un mensaje de SIP. Por ejemplo, para una S-CSCF, se podría agregar el parámetro de URI scscf. Alternativamente, un parámetro de URI tal como “fe” se podría establecer en un valor o una lista de valores tales como fe = “scscf” o fe = “pcscf, scscf”. En este documento, un nodo de red se conoce como un elemento funcional, o “fe”. Cuando se utiliza el encabezado Service-Route de SIP, el mensaje puede adoptar una forma como la siguiente:
Service-Route: sip: orig@scscf1.home1.com; lr; scscf
o
Service-Route: sip: orig@pcscf1.home1.com; lr; fe = “pcscf, scscf”
en implementaciones en las que los elementos funcionales P-CSCF y S-CSCF (y posiblemente otros) se colocan sobre un equipo físico.
Como alternativa, después de recibir la información 115 de confianza en forma de una lista de URIs, el UA 110 podría consultar una base de datos u otro depósito de datos para determinar los nodos de la red y/o el indicador de confianza y/o la información de confianza que corresponde a los URI listados. La base de datos podría ser un nodo de red en la red o una base de datos en el dispositivo almacenada en la memoria interna o en un módulo de memoria extraíble.
En otra realización, el Marco de Configuración de SIP, el Marco de Política de SIP, un mecanismo de recuperación de política basado en EAP, un servidor basado en XCAP/HTTP o un objeto de gestión de dispositivos (DM) de Open Mobile Alliance (OMA) se podrían utilizar para transmitir indicadores de confianza y/o la información de confianza y/o los nodos de red que corresponden a los URIs enumerados al UA 110.
El UA 110 podría recibir la información 115 de confianza de una o más de varias maneras diferentes. En algunas realizaciones, la información 115 de confianza se podría proporcionar al UA 110 en respuesta a una solicitud REGISTER SIP presentada por el UA 110. En algunas variaciones de estas realizaciones, la respuesta podría ser una respuesta de SIP 200 OK, y la información 115 de confianza podría incluirse directamente en la respuesta 200 OK. La información 115 de confianza se podría incluir en la respuesta 200 OK de un nodo de red, como un servidor de aplicaciones, que recibió la solicitud REGISTER porque la solicitud fue enrutada a través de ella. Alternativamente, el servidor de aplicaciones podría haber recibido una solicitud de registro de un tercero según lo configurado por los Criterios de Filtro iniciales en una S-CSCF.
En otras variaciones de estas realizaciones, la respuesta 200 OK que recibe el UA 110 en respuesta a una solicitud REGISTER podría contener información que informa al UA 110 cómo se puede obtener la información 115 de confianza. Dicha realización se ilustra en la Figura 2. En el evento 210, el UA 110 se registra con una red de IMS al enviar una solicitud REGISTER al nodo B 130 de red, que podría ser una S-CSCF. Como parte del procedimiento 220 de registro, un servidor 200 de suscriptor doméstico (HSS), o un componente similar, puede descargar en el nodo B 130 de red la información 115 de confianza que utilizará el UA 110. En el evento 230, se completa el registro, y el nodo B 130 de red envía al UA 110 una respuesta 200 OK. En la realización de la Figura 2, la respuesta 200 OK podría contener un URI, o algún otro tipo de identificador, que identifique una ubicación en el que se pueda obtener la información 115 de confianza. En otras realizaciones, como se mencionó anteriormente, la respuesta 200 OK podría incluir directamente la información 115 de confianza.
Alternativamente, como se muestra en el evento 240, como parte del registro de SIP, el UA 110 se podría suscribir al paquete de Eventos Reg de SIP, que puede entregar información al UA 110. En respuesta al mensaje de Suscripción en el evento 240, el nodo B 130 de red, en el evento 250, podría devolver un mensaje como un mensaje de Notificación. El mensaje de Notificación puede contener la ubicación de la información 115 de confianza que se descargó del HSS 200 como se describió anteriormente.
Cuando el UA 110 ha recibido la ubicación de la información 115 de confianza, ya sea a través del mensaje 200 OK en el evento 230, a través del mensaje de Notificación en el evento 250, o mediante otro método de SIP, el UA 110 puede recuperar la información 115 de confianza desde la ubicación especificada. En este caso, la ubicación especificada es el nodo A 120 de red, pero en otros casos, la información 115 de confianza se podría recuperar de otros nodos de red. En el evento 260, el UA 110 envía un mensaje, tal como un mensaje HTTP GET, para recuperar la información 115 de confianza desde el nodo A 120 de red. En el evento 270, el nodo A 120 de red envía la información 115 de confianza al UA 110. El UA 110 puede almacenar la información 115 de confianza en la memoria interna o extraíble, en la que la información 115 de confianza estará disponible para uso futuro por el UA 110 para determinar si un nodo de red es de confianza.
En una realización alternativa, la información 115 de confianza se podría proporcionar durante el registro del UA 110 en uno o más campos en el encabezado Path de SIP o el encabezado Service-Route de SIP. Por ejemplo, una solicitud REGISTER de SIP originada por el UA 110 se podría enrutar a través de al menos una P-CSCf y una S-CSCF, en la que la S-CSCF desempeña la función REGISTRAR. La respuesta (tal como una respuesta 200 OK) que el UA 110 recibe a su solicitud REGISTER puede incluir un indicador (tal como un nuevo encabezado P, un encabezado existente o XML incorporado) que transmite información acerca de los nodos de la red (tales como una P-CSCF y una S-SCSF) sobre la ruta por la que se enrutó la solicitud REGISTER. Adicionalmente, uno o más campos en el encabezado Service-Route de SIP pueden contener al menos las direcciones de la P-CSCF o S-CSCF que realmente realizan cualquier servicio. La dirección de S-CSCF en el campo de encabezado Service-Route y la S-CSCF en el campo de encabezado Path no son necesariamente las mismas.
En algunos casos, una S-CSCF que actúa como REGISTRAR puede no ser la S-CSCF que responde a otras solicitudes del UA 110. Más generalmente, no se pueden incluir todos los nodos de red que son capaces de transmitir un mensaje confiable sobre la ruta por la cual se enruta la solicitud REGISTER o su respuesta. Sin embargo, si un nodo de red transmite un mensaje confiable, puede ser ventajoso llenar un campo de encabezado (tal como un campo de encabezado de Asserted-Identity P de SIP) o un parámetro de URI o una parte del cuerpo de SIP con un valor representativo del originador. Existen varios medios para permitir que el UA 110 determine que algún valor representativo del originador solo puede ser conocido o solo insertado por el originador. Por ejemplo, un valor en el campo de encabezado de Asserted-Identity P de SIP se podría comparar con un valor en el campo de encabezado Service-Route.
Cuando un indicador de confianza no está presente en un mensaje recibido por el UA 110 desde un nodo de red fuera del dominio de confianza del UA, o cuando está presente un indicador de confianza, pero no coincide con la información 115 de confianza almacenada del UA, el Ua 110 podría reaccionar de varias maneras diferentes. En algunos casos, el UA 110 puede negar, descartar o finalizar el mensaje. En otros casos, el UA 110 podría devolver un mensaje de error al nodo de red que envió el mensaje. En todavía otros casos, el UA 110 podría eliminar porciones del mensaje que podrían provocar acciones indeseables y procesar el resto del mensaje. En algunos casos, se pueden tomar varias combinaciones de estas acciones.
La Figura 3 ilustra una realización de un método 300 para determinar si se puede confiar en un nodo fuera de un dominio de confianza en una red de IMS. En el bloque 310, un UA recibe del 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 información de confianza almacenada en el UA. En el bloque 330, cuando el indicador de confianza coincide con la información de confianza almacenada en el UA, el UA realiza todas las acciones normalmente asociadas con la recepción del mensaje. En el bloque 340, cuando el indicador de confianza no coincide con la información de confianza almacenada en el UA, el UA se abstiene de realizar al menos una acción normalmente asociada con la recepción del mensaje.
La Figura 4 ilustra una realización alternativa de un método 400 para determinar si se puede confiar en un nodo fuera de un dominio de confianza en una red de IMS. En el bloque 410, un UA recibe un mensaje del nodo de red. En el bloque 420, el UA determina si un indicador de confianza está presente en el mensaje. En el bloque 430, cuando el indicador de confianza está presente en el mensaje, el UA realiza todas las acciones normalmente asociadas con la recepción del mensaje. En el bloque 440, cuando el indicador de confianza no está presente en el mensaje, el UA se abstiene de realizar al menos una acción normalmente asociada con la recepción del mensaje. Volviendo al ejemplo mencionado anteriormente en el que se envía un mensaje malicioso a una pluralidad de UA que informa falsamente a los UA que se ha producido un Tiempo de Espera del Servidor, las realizaciones descritas en este documento podrían evitar que los UA intenten volver a registrarse innecesariamente en la red. Cuando uno de los UA recibe el mensaje malicioso, el UA puede utilizar una técnica descrita en este documento para determinar si se puede confiar en el remitente del mensaje. Dado que, en este caso, no se confiará en el remitente, el UA no realizará una o más acciones normalmente asociadas con la recepción del mensaje. En este caso, la UA no se volvería a registrar.
Una posible reflexión para el UE podría ser la siguiente en 3GPP TS 24.229, subcláusula 5.1.2A.1.6, titulada “Casos anormales”:
En el evento de que el UE reciba una respuesta 504 (Tiempo de Espera del Servidor) que contiene:
- un campo de encabezado P-Asserted-Identity establecido en:
- un valor igual a un valor en el campo de encabezado Service-Route o Path recibido durante el registro; o
- un campo de encabezado Content-Type establecido de acuerdo con la subcláusula 7.6 (es decir, “aplication/3gppims+xml”), independiente del valor o la presencia del campo de encabezado Content-Disposition, independiente del valor o la presencia de parámetros de Content-Disposition, luego la disposición de contenido predeterminada, identificada como “3gpp-alternative-service”, se aplica de la siguiente manera:
- si la respuesta 504 (Tiempo de Espera del Servidor) incluye un cuerpo XML del subsistema CN de IM como se describe en la subcláusula 7.6 con el elemento de tipo establecido en “restauración” y el elemento de acción establecido en “registro inicial”, entonces el UE:
- iniciará los procedimientos de restauración al realizar un registro inicial como se especifica en la subcláusula 5.1.1.2; y
- puede proporcionar una indicación al usuario basada en la cadena de texto contenida en el elemento de razón. Una posible reflexión para la P-CSCF podría ser la siguiente en 3GPP TS 24.229, subcláusula 5.2.6.3.2A, titulada “Casos anormales”:
Cuando la P-CSCF no puede reenviar una solicitud inicial para un diálogo o una solicitud de una transacción independiente al siguiente salto en el encabezado Service-Route, según lo determinado por uno de los siguientes: - no hay respuesta a la solicitud de servicio y sus retransmisiones por la P-CSCF;
- se recibe una respuesta 3xx o 480 (temporalmente no disponible) para la solicitud; o
- por medios no especificados disponibles para la P-CSCF;
y:
- la P-CSCF admite procedimientos de restauración;
entonces la P-CSCF:
1) rechazará la solicitud al devolver una respuesta 504 (Tiempo de Espera del Servidor) al UE;
2) supondrá que el UE admite la versión 1 del Esquema XML para el cuerpo XML del subsistema CN de IM 3GPP si el soporte del cuerpo XML del subsistema CN de IM 3GPP como se describe en la subcláusula 7.6 en el campo de encabezado Accept no está indicado; y
3) incluirá en la respuesta 504 (Tiempo de Espera del Servidor):
a) un campo de encabezado Content-Type con el valor establecido en el tipo MIME asociado del cuerpo XML del subsistema CN de IM 3GPP como se describe en la subcláusula 7.6.1;
b) un campo de encabezado P-Asserted-Identity establecido en el valor del URI de SIP de la P-CSCF incluido en el campo de encabezado Path durante el registro del usuario cuyo UE envió la solicitud que provoca esta respuesta; y c) un cuerpo XML del subsistema CN de IM 3GPP que contiene:
i) un elemento <alternative-service>, configurado con los parámetros del servicio alternativo;
ii) un elemento secundario <type>, establecido en “restauración” para indicar que se admiten los procedimientos de restauración;
iii) un elemento secundario <reason>, establecido en un motivo configurable por el operador; y
iv) un elemento secundario <action>, establecido en “registro inicial”
NOTA: Estos procedimientos no impiden el uso de confiabilidad no especificada o técnicas de recuperación superiores a las especificadas en esta subcláusula.
Una posible reflexión para la S-CSCF podría ser la siguiente en 3GPP TS 24.229, subcláusula 5.4.3.2, titulada “Solicitudes iniciadas por el usuario servido”:
Cuando la S-CSCF recibe una solicitud iniciada por el usuario servido para el cual la S-CSCF no tiene el perfil de usuario o no confía en los datos que tiene (por ejemplo, debido al reinicio), la S-CSCF intentará recuperar el perfil de usuario del HSS. Si la S-CSCF no puede recuperar el perfil de usuario y la S-CSCF admite procedimientos de restauración, entonces la S-CSCF deberá:
1) rechazar la solicitud al devolver una respuesta 504 (Tiempo de Espera del Servidor) al UE;
2) asumir que el UE admite la versión 1 del Esquema XML para el cuerpo XML del subsistema CN de IM 3GPP si el soporte para el cuerpo XML del subsistema CN de IM 3GPP como se describe en la subcláusula 7.6 en el campo de encabezado Aceppt no está indicado; y
3) un campo de encabezado P-Asserted-Identity establecido en el valor del SIP URI de la S-CSCF incluido en el campo de encabezado Service-Route durante el registro del usuario cuyo UE envió la solicitud que provoca esta respuesta;
4) incluirá en la respuesta 504 (Tiempo de Espera del Servidor):
a) un campo de encabezado Content-Type con el valor establecido en el tipo MIME asociado del cuerpo XML del subsistema CN de IM 3GPP como se describe en la subcláusula 7.6.1; y
b) un cuerpo XML del subsistema CN de IM 3GPP:
i) un elemento <alternative-service>, ajustado a los parámetros del servicio alternativo;
ii) un elemento secundario <type>, establecido en “restauración” para indicar que se admiten los procedimientos de restauración;
iii) un elemento secundario <reason>, establecido en un motivo configurable por el operador; y
iv) un elemento secundario <action>, establecido en “registro inicial”
Adicionalmente, las siguientes modificaciones se podrían realizar en 3GPP TS 24.229, subcláusula 5.10.4.1, titulada “General”:
NOTA 1: La funcionalidad THIG se realiza en I-CSCF en la Versión-5 y la Versión-6 y es compatible con Los procedimientos especificados en esta subcláusula.
Los siguientes procedimientos solo se aplicarán si la red requiere el ocultamiento de la topología de la red. La red que requiere el ocultamiento de la topología de red se denomina red oculta.
NOTA 2: Las solicitudes y respuestas se manejan de manera independiente, por lo tanto, no se necesita información del estado red de ocultación para ese propósito dentro de una IBCF.
La IBCF aplicará la topología de red oculta a todos los campos de encabezado que revelen información de topología, tal como Via, Route, Record-Route, Service-Route, y Path.
Al recibir una solicitud REGISTER entrante para la cual se debe aplicar el ocultamiento de topología de red y que incluye un campo de encabezado Path, la IBCF agregará el URI de SIP enrutable de la IBCF a la parte superior del campo de encabezado Path. La IBCF puede incluir en el URI de SIP insertado un indicador que identifica la dirección de las solicitudes posteriores recibidas por la IBCF, es decir, desde la S-CSCF hacia la P-CSCF, para identificar el caso de terminación de UE. La IBCF puede codificar este indicador de diferentes maneras, tales como, por ejemplo, un parámetro único en el URI, una cadena de caracteres en la parte del nombre de usuario del URI o un número de puerto dedicado en el URI.
NOTA 3: Cualquier solicitud posterior que incluya el indicador de dirección (en el campo de encabezado Route) o llegue al número de puerto dedicado, indica que la solicitud se envió por la S-CSCF hacia la P-CSCF.
Al recibir una solicitud inicial entrante para la cual se debe aplicar el ocultamiento de topología de red, una solicitud de SIP o respuesta de SIP con un campo de encabezado P-Asserted-Identity establece el URI de SIP de un elemento funcional dentro de su dominio de confianza, la IBCF aplicará el ocultamiento de topología de red al campo de encabezado P-Asserted-Identity.
Al recibir una solicitud inicial entrante para la cual se debe aplicar el ocultamiento de la topología de red y que incluye un campo de encabezado Record-Route, la IBCF agregará su propio URI de SIP enrutable en la parte superior del campo de encabezado Record-Route.
El UE puede recibir un valor diferente al valor almacenado por el nodo de red, ya que la IBCF puede ocultar la ubicación y reemplazar los URI en el mensaje de SIP (tal como los campos de encabezado Path o Service-Route) con, por ejemplo, al menos uno de los valores del SIP URI de la IBCF. La IBCF tendría que realizar consistentemente esta ubicación ocultando o reemplazando los URI para no romper la confianza que se indica. Cuando el UA de SIP recibe un mensaje de SIP, analizará una tabla dentro de la función para ver si es necesario realizar alguna acción para ese mensaje de SIP, por ejemplo, una solicitud INVITE. La tabla o estructura de datos identifica los indicadores. Estos indicadores podrían ser, pero no se limitan a, campos de encabezado de SIP, valores específicos de SIP para buscar, etc. Para cada campo, también podría haber una acción o grupo de acciones que podrían realizarse, pero no se limitan a:
Eliminar Eliminar el elemento si no es de confianza
Ignorar Ignorar el elemento
Terminar Terminar el diálogo o rechazar el diálogo para continuar
Confiable Marque el campo como confiable
No confiable Marque el campo como no confiable
Confianza Marque el mensaje como confiable
Desconfianza Marque el mensaje como no confiable
Para los dos últimos elementos, “Confianza” y “Desconfianza”, todos los elementos en el método SIP tienen que ser confiables. El método para identificar el mensaje como confiable podría transmitirse como:
A) Nueva Etiqueta de Función: Aquí agregará una etiqueta de función al encabezado del contacto con un valor que indica la confiabilidad del mensaje.
B) Nuevo parámetro de URI
C) Parte del cuerpo (por ejemplo, en XML)
D) Nuevo campo de encabezado
Una realización de ejemplo de la estructura de datos está a continuación.
5IP Method
I
> INVITE
I I
|> Field 1 : Valué X
] I |> Action: Remove, ignore, termínate dialogue etc
I |> Field 2: Valué k, c
Figure imgf000009_0001
Valué....
El UA 110 y otros componentes descritos anteriormente podrían incluir un componente de procesamiento que sea capaz de ejecutar 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 más realizaciones divulgadas en este documento. Además del procesador 1310 (que se puede denominar unidad de procesador central o CPU), el sistema 1300 puede incluir dispositivos 1320 de conectividad de red, memoria 1330 de acceso aleatorio (RAM), memoria 1340 de solo lectura (ROM), almacenamiento 1350 secundario y dispositivos 1360 de entrada/salida (I/O). Estos componentes pueden comunicarse entre sí a través de un bus 1370. En algunos casos, algunos de estos componentes pueden no estar presentes o se pueden combinar en varias combinaciones entre sí o con otros componentes no mostrados. Estos componentes pueden estar ubicados en una sola entidad física o en más de una entidad física. Cualquier acción descrita en este documento como tomada por el procesador 1310 podría ser tomada por el procesador 1310 solo o por el procesador 1310 junto con uno o más componentes mostrados o no mostrados en el dibujo, como un procesador 1380 de señal digital (DSP). Aunque el DSP 1380 se muestra como un componente separado, el DSP 1380 se podría incorporar al procesador 1310.
El procesador 1310 ejecuta instrucciones, códigos, programas de ordenador o scripts a los que puede acceder desde los dispositivos 1320 de conectividad de red, RAM 1330, ROM 1340 o almacenamiento 1350 secundario (que puede incluir varios sistemas basados en disco tal como el disco duro, disquete o disco óptico). Si bien solo se muestra una CPU 1310, pueden estar presentes múltiples procesadores. Por lo tanto, aunque las instrucciones pueden ser discutidas como ejecutadas por un procesador, las instrucciones pueden ejecutarse simultáneamente, en serie o de otro modo por uno o múltiples procesadores. El procesador 1310 puede implementarse como uno o más chips de CPU.
Los dispositivos 1320 de conectividad de red pueden tomar la forma de módems, bancos de módems, dispositivos Ethernet, dispositivos de interfaz de bus serie universal (USB), interfaces en serie, dispositivos de anillo de credencial, dispositivos de interfaz de datos distribuidos por fibra (FDDI), dispositivos de red de área local inalámbrica (WLAN), dispositivos de transceptor de radio tales como dispositivos de acceso múltiple por división de código (CDMA), sistema global para dispositivos de transceptor de radio de comunicaciones móviles (GSM), dispositivos de interoperabilidad mundial para dispositivos de acceso de microondas (WiMAX) y/u otros dispositivos bien conocidos para conectarse a redes. Estos dispositivos 1320 de conectividad de red pueden permitir que el procesador 1310 se comunique con Internet o una o más redes de telecomunicaciones u otras redes desde las cuales el procesador 1310 podría recibir información o hacia las cuales el procesador 1310 podría enviar información. Los dispositivos 1320 de conectividad de red también pueden incluir uno o más componentes 1325 transceptores capaces de transmitir y/o recibir datos de forma inalámbrica.
La RAM 1330 podría utilizarse para almacenar datos volátiles y tal vez para almacenar instrucciones que se ejecutan por el procesador 1310. La ROM 1340 es un dispositivo de memoria no volátil que normalmente tiene una capacidad de memoria menor que la capacidad de memoria del almacenamiento 1350 secundario. La ROM 1340 se podría utilizar para almacenar instrucciones y tal vez datos que se leen durante la ejecución de las instrucciones. El acceso tanto a la RAM 1330 como a la ROM 1340 es normalmente más rápido que al almacenamiento 1350 secundario. El almacenamiento 1350 secundario normalmente está compuesto por una o más unidades de disco o cintas y se puede utilizar para el almacenamiento no volátil de datos o como un desbordamiento dispositivo de almacenamiento de datos si la RAM 1330 no es lo suficientemente grande como para contener todos los datos de trabajo. El almacenamiento 1350 secundario se puede utilizar para almacenar programas que se cargan en la RAM 1330 cuando dichos programas se seleccionan para su ejecución.
Los dispositivos 1360 de I/O pueden incluir pantallas de cristal líquido (LCD), pantallas táctiles, teclados, teclados, interruptores, diales, ratones, bolas de seguimiento, reconocedores de voz, lectores de tarjetas, lectores de cinta de papel, impresoras, monitores de video, u otros dispositivos de entrada o salida conocidos. Adicionalmente, el transceptor 1325 se podría considerar como un componente de los dispositivos 1360 de I/O en lugar de ser o además de un componente de los dispositivos 1320 de conectividad de red.
En una realización, se proporciona un método para determinar si se puede confiar en un nodo fuera de un dominio de confianza en una red de IMS. El método incluye un UA que recibe del nodo de red un mensaje que contiene un indicador de confianza. El método incluye adicionalmente el UA que determina si el indicador de confianza coincide con la información de confianza almacenada en el UA. El método incluye adicionalmente, cuando el indicador de confianza coincide con la información de confianza almacenada en el UA, el UA realiza todas las acciones normalmente asociadas con la recepción del mensaje. El método incluye adicionalmente, cuando el indicador de confianza no coincide con la información de confianza almacenada en el UA, el UA se abstiene de realizar al menos una acción normalmente asociada con la recepción del mensaje.
En otra realización, se proporciona un UA. El UA incluye un procesador configurado para recibir de un nodo fuera de un dominio de confianza en una red de IMS un mensaje que contiene un indicador de confianza. El procesador está configurado adicionalmente para determinar si el indicador de confianza coincide con la información de confianza almacenada en el UA. El procesador se configura adicionalmente, cuando el indicador de confianza coincide con la información de confianza almacenada en el UA, para realizar todas las acciones normalmente asociadas con la recepción del mensaje. El procesador se configura adicionalmente, cuando el indicador de confianza no coincide con la información de confianza almacenada en el UA, para abstenerse de realizar al menos una acción normalmente asociada con la recepción del mensaje.
En otra realización, se proporciona un método alternativo para determinar si se puede confiar en un nodo fuera de un dominio de confianza en una red de IMS. El método incluye un UA que recibe un mensaje del nodo de red. El método incluye adicionalmente el UA que determina si un indicador de confianza está presente en el mensaje. El método incluye adicionalmente, cuando el indicador de confianza está presente en el mensaje, el UA realiza todas las acciones normalmente asociadas con la recepción del mensaje. El método incluye adicionalmente, cuando el indicador de confianza no está presente en el mensaje, el UA se abstiene de realizar al menos una acción normalmente asociada con la recepción del mensaje.
En otra realización, se proporciona un UA. El UA incluye un procesador configurado para recibir un mensaje de un nodo fuera de un dominio de confianza en una red de IMS. El procesador está configurado adicionalmente para determinar si hay un indicador de confianza en el mensaje. El procesador está configurado adicionalmente, cuando el indicador de confianza está presente en el mensaje, para realizar todas las acciones normalmente asociadas con la recepción del mensaje. El procesador está configurado adicionalmente, cuando el indicador de confianza no está presente en el mensaje, para abstenerse de realizar al menos una acción normalmente asociada con la recepción del mensaje.
En otra realización, se proporciona un método para realizar el registro. El método incluye recibir un mensaje de Tiempo de Espera del Servidor, el mensaje de tiempo de espera del servidor incluye al menos un primer campo establecido en un valor igual a un valor recibido en un segundo campo durante un primer registro. El método incluye adicionalmente iniciar procedimientos de restauración al realizar un segundo registro en respuesta a la recepción del mensaje de tiempo de espera del servidor.
En otra realización, se proporciona un UA. El UA incluye uno o más procesadores configurados de manera tal que el UA recibe un mensaje de tiempo de espera del servidor que incluye al menos un primer campo establecido en un valor igual a un valor recibido en un segundo campo durante un primer registro, y configurado de tal manera que el UA inicia procedimientos de restauración al realizar un segundo registro en respuesta a la recepción del mensaje de tiempo de espera del servidor.
La siguiente Especificación Técnica (TS) del Proyecto de Asociación de 3ra Generación (3GPP) se incorpora en este documento como referencia: TS 24.229.
Si bien se han proporcionado varias realizaciones en la presente divulgación, se debe entender que los sistemas y métodos divulgados se pueden realizar de muchas otras formas específicas sin apartarse del espíritu o alcance de la presente divulgación. Los presentes ejemplos deben considerarse como ilustrativos y no restrictivos, y la intención no debe limitarse a los detalles proporcionados en este documento. Por ejemplo, los diversos elementos o componentes se pueden combinar o integrar en otro sistema o se pueden omitir o no implementar ciertas características.
También, las técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las diversas realizaciones como discretos o separados se pueden combinar o integrar con otros sistemas, módulos, técnicas o métodos sin apartarse del alcance de la presente divulgación. Otros elementos mostrados o discutidos como acoplados o directamente acoplados o comunicados entre sí pueden estar indirectamente acoplados o comunicarse a través de alguna interfaz, dispositivo o componente intermedio, ya sea eléctricamente, mecánicamente o de otro modo. Un experto en la técnica puede determinar otros ejemplos de cambios, sustituciones y alteraciones y podrían realizarse sin apartarse del alcance en este documento divulgado.

Claims (5)

REIVINDICACIONES
1. Un método realizado por un primer nodo (130) de red de un Subsistema Multimedia de Protocolo de Internet, IMS, Red, el método comprende:
recibir en el primer nodo de red, un Identificador de Recursos Uniforme, URI, en un campo de encabezado en un primer Protocolo de Inicio de Sesión, SIP, mensaje (140);
recibir en el primer nodo de red, una credencial en el campo de encabezado en el primer mensaje (140) de SIP, la credencial indicadora de un tipo de un nodo (120) de red en una ruta del primer mensaje (140) de SIP, en el que el primer mensaje de SIP es una solicitud de REGISTER de SIP presentada por un agente de usuario, UA;
con base en la credencial recibida, enviar mediante el primer nodo de red, un segundo mensaje (150) de SIP que incluye el URI recibido, el segundo mensaje (150) que transmite información acerca del primer nodo (130) de red; y recibir un tercer mensaje de SIP activado por el primer mensaje de SIP, en el que el tercer mensaje de SIP activado por el primer mensaje de SIP es una solicitud de registro de un tercero que se configura por Criterio de Filtro inicial sobre una Función de Control de Sesión de Llamada en Servicio, S-CSCF.
2. El método como se reivindica en la Reivindicación 1, en el que la credencial es un parámetro asociado con el URI recibido.
3. El método como se reivindica en la Reivindicación 1, en el que un segundo nodo (110) de red está en una ruta del primer mensaje (140) de SIP.
4. El método como se reivindica en la Reivindicación 1, en el que el segundo mensaje (150) de SIP es respuesta SIP 200 OK.
5. Un sistema, que comprende:
un primer nodo (130) de red de un Subsistema Multimedia de Protocolo de Internet, IMS, Red, el primer nodo (130) de red configurado para:
recibir un Identificador de Recursos Uniforme, URI, en un campo de encabezado en un primer Protocolo de Inicio de Sesión, SIP, mensaje (140)
recibir una credencial en el campo de encabezado en el primer mensaje (140) de SIP, la credencial indicadora de un tipo de un nodo de red en una ruta del primer mensaje (140) de SIP, en el que el primer mensaje de SIP es una solicitud de REGISTER de SIP presentada por un agente de usuario, UA;
con base en la credencial recibida, enviar un segundo mensaje (150) de SIP que incluye el URI recibido, el segundo mensaje (150) que transmite información acerca del primer nodo (130) de red; y
recibir un tercer mensaje de SIP activado por el primer mensaje de SIP, en el que el tercer mensaje de SIP activado por el primer mensaje de SIP es una solicitud de registro de un tercero que se configura por Criterio de Filtro inicial sobre una Función de Control de Sesión de Llamada en Servicio, S-CSCF.
6. Un producto de programa de ordenador que comprende un medio tangible de almacenamiento legible por ordenador que tiene instrucciones almacenadas en el mismo que, cuando se ejecuta por un dispositivo de procesamiento, implementan un método realizado por un primer nodo de red de un Subsistema Multimedia de Protocolo de Internet, IMS, Red, el método comprende:
recibir en el primer nodo de red, un Identificador de Recursos Uniforme URI, en un campo de encabezado en un primer Protocolo de Inicio de Sesión, SIP, mensaje (140), en el que el primer mensaje de SIP es una solicitud de REGISTER de SIP presentada por un agente de usuario, UA;
recibir en el primer nodo de red, una credencial en el campo de encabezado en el primer mensaje (140) de SIP, la credencial indicadora de un tipo de un nodo de red en una ruta del primer mensaje (140) de SIP; y
con base en la credencial recibida, enviar mediante el primer nodo de red, un segundo mensaje (150) de SIP que incluye el URI recibido, el segundo mensaje (150) que transmite información acerca del primer nodo (130) de red; y recibir un tercer mensaje de SIP activado por el primer mensaje de SIP, en el que el tercer mensaje de SIP activado por el primer mensaje de SIP es una solicitud de registro de un tercero que se configura por Criterio de Filtro inicial en una Función de Control de Sesión de Llamada en Servicio, S-CSCF.
ES16173001T 2009-04-13 2010-03-19 Sistema y método para determinar la confianza para mensajes de SIP Active ES2773546T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US16879809P 2009-04-13 2009-04-13

Publications (1)

Publication Number Publication Date
ES2773546T3 true ES2773546T3 (es) 2020-07-13

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 After (1)

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

Country Status (9)

Country Link
US (10) US8407354B2 (es)
EP (4) EP3754942B1 (es)
JP (1) JP5313395B2 (es)
KR (1) KR101333164B1 (es)
CN (2) CN102460453B (es)
CA (1) CA2758486C (es)
ES (2) ES2773546T3 (es)
HU (2) HUE051045T2 (es)
WO (1) WO2010120432A1 (es)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8407299B2 (en) * 2007-10-27 2013-03-26 Research In Motion Limited Content disposition system and method for processing message content in a distributed environment
WO2010120432A1 (en) 2009-04-13 2010-10-21 Research In Motion Limited System and method for determining 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
WO2011032611A1 (en) * 2009-09-17 2011-03-24 Telefonaktiebolaget L M Ericsson (Publ) Method and node in a telecommunications network
CN102480486B (zh) * 2010-11-24 2015-07-22 阿尔卡特朗讯公司 验证通信会话的方法、设备及系统
WO2012085624A1 (en) 2010-12-23 2012-06-28 Research In Motion 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
US9497227B2 (en) * 2012-12-19 2016-11-15 Unify Gmbh & Co. Kg Method of conveying a location information representing a physical location of a first communication device, a computer program product for executing the method, and the first communication device for conveying the location information
EP3866438A1 (en) * 2013-09-24 2021-08-18 Nec Corporation Methods and apparatuses for facilitating p-cscf restoration when a p-cscf failure has occured
CN105162747B (zh) 2014-01-10 2019-12-24 北京华夏创新科技有限公司 用于压缩设备与解压缩设备探索及握手的系统和方法
EP3869836A1 (en) * 2015-03-30 2021-08-25 Huawei Technologies Co., Ltd. Wireless communication method, remote user equipment, and relay user equipment
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
US20200364354A1 (en) * 2019-05-17 2020-11-19 Microsoft Technology Licensing, Llc Mitigation of ransomware in integrated, isolated applications
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
JP4806400B2 (ja) * 2004-05-03 2011-11-02 ノキア コーポレイション Ｉｐネットワークの信頼できるドメインにおけるアイデンティティの処理
GB0417296D0 (en) * 2004-08-03 2004-09-08 Nokia Corp User registration in a communication system
JP4782139B2 (ja) 2004-10-26 2011-09-28 テレコム・イタリア・エッセ・ピー・アー モバイルユーザーをトランスペアレントに認証してウェブサービスにアクセスする方法及びシステム
GB2435587B (en) 2004-12-13 2008-10-01 Transnexus Inc Method and system for securely authorizing VOIP interconnections between anonymous peers of VOIP networks
JP4700105B2 (ja) * 2005-05-27 2011-06-15 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｉｐマルチメディアサブシステム（ｉｍｓ）おける呼転送
US8933967B2 (en) 2005-07-14 2015-01-13 Charles D. Huston System and method for creating and sharing an event using a social network
CN101223754A (zh) * 2005-07-19 2008-07-16 艾利森电话股份有限公司 在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 日本電気株式会社 通信接続方法及びシステム並びにプログラム
WO2007045182A1 (en) * 2005-10-21 2007-04-26 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
US20080288458A1 (en) * 2005-12-08 2008-11-20 Nortel Networks Limited Session Initiation Protocol (Sip) Multicast Management Method
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
WO2007071269A1 (en) * 2005-12-19 2007-06-28 Telefonaktiebolaget Lm Ericsson (Publ) Technique for providing 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
JP4927879B2 (ja) * 2006-02-24 2012-05-09 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｉｐｔｖのための、ｉｍｓ対応のコントロールチャネル
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
US8364861B2 (en) * 2006-03-28 2013-01-29 Mosaid Technologies Incorporated Asynchronous ID generation
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
WO2008020644A1 (en) * 2006-08-18 2008-02-21 Nec Corporation Proxy server, communication system, communication method, and program
JP4470934B2 (ja) * 2006-10-20 2010-06-02 日本電気株式会社 プロキシ・サーバ、通信システム、通信方法及びプログラム
US8599833B2 (en) * 2006-10-23 2013-12-03 Telefonaktiebolaget L M Ericsson (Publ) Transport of connectivity status information in an IP multimedia subsystem network
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
WO2009002804A2 (en) * 2007-06-22 2008-12-31 Chumby Industries, Inc. Systems and methods for device registration
US8249561B2 (en) 2007-09-11 2012-08-21 Research In Motion Limited System and method for sharing a SIP communication service identifier
US9900347B2 (en) * 2007-09-14 2018-02-20 Telefonaktiebolaget Lm Ericsson (Publ) Handling trust in an IP multimedia subsystem communication network
WO2009033504A1 (en) * 2007-09-14 2009-03-19 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for handling trust in an ip multimedia subsystem communication network
CN101855860B (zh) * 2007-09-14 2013-01-09 安全第一公司 用于管理加密密钥的系统和方法
ES2426065T3 (es) * 2007-09-28 2013-10-21 Telefonaktiebolaget L M Ericsson (Publ) Recuperación tras un fallo en una red de subsistema de multimedios sobre 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
US8762553B2 (en) 2008-01-11 2014-06-24 Telefonaktiebolaget L M Ericsson (Publ) Message handling in an IP multimedia subsystem
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
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
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 株式会社日立製作所 通信ゲートウェイ装置及び中継方法
ES2373357T3 (es) 2008-02-29 2012-02-02 Telefonaktiebolaget L M Ericsson (Publ) Técnica para realizar la conversión de señalización entre los dominios http y sip.
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
EP2359561B1 (en) 2008-09-12 2018-07-18 Nokia Solutions and Networks Oy Method, apparatuses and computer program product for obtaining user credentials for an application from an 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
WO2010120432A1 (en) 2009-04-13 2010-10-21 Research In Motion Limited System and method for determining 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
US8407354B2 (en) 2013-03-26
CN104394146B (zh) 2017-10-20
HUE051045T2 (hu) 2021-03-01
US20230239331A1 (en) 2023-07-27
US8694660B2 (en) 2014-04-08
US20170251030A1 (en) 2017-08-31
CN102460453A (zh) 2012-05-16
HUE046329T2 (hu) 2020-03-30
US20120331163A1 (en) 2012-12-27
CA2758486C (en) 2017-01-17
JP2012523752A (ja) 2012-10-04
EP3142339B1 (en) 2020-10-21
US20190068656A1 (en) 2019-02-28
JP5313395B2 (ja) 2013-10-09
US20120331158A1 (en) 2012-12-27
US20160330249A1 (en) 2016-11-10
CN102460453B (zh) 2014-12-24
US8756330B2 (en) 2014-06-17
KR101333164B1 (ko) 2013-11-27
US7895302B2 (en) 2011-02-22
US20100262704A1 (en) 2010-10-14
CN104394146A (zh) 2015-03-04
EP3142339A1 (en) 2017-03-15
EP3754942A1 (en) 2020-12-23
US20100262699A1 (en) 2010-10-14
US20110047277A1 (en) 2011-02-24
US20210352117A1 (en) 2021-11-11
KR20110138282A (ko) 2011-12-26
US10135885B2 (en) 2018-11-20
US11956284B2 (en) 2024-04-09
EP2601612A1 (en) 2013-06-12
EP3754942B1 (en) 2024-09-04
EP3086532A1 (en) 2016-10-26
WO2010120432A1 (en) 2010-10-21
EP3086532B1 (en) 2019-11-06
US11082459B2 (en) 2021-08-03
US11659011B2 (en) 2023-05-23
CA2758486A1 (en) 2010-10-21
EP3754942C0 (en) 2024-09-04
US10805360B2 (en) 2020-10-13
US9401935B2 (en) 2016-07-26
EP2601612A4 (en) 2014-01-22
EP2601612B1 (en) 2017-02-08
HK1204402A1 (en) 2015-11-13
ES2623474T3 (es) 2017-07-11

Similar Documents

Publication Publication Date Title
ES2773546T3 (es) Sistema y método para determinar la confianza para mensajes de 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
CN107534649B (zh) 改变ims网络中的ims补充业务数据
HK1236292A1 (en) System and method for determining trust for sip messages
HK1204402B (en) System and method for determining trust for sip messages
HK1236292B (en) System and method for determining trust for sip messages
HK1224847A1 (en) System and method for determining trust for sip messages
HK1236292A (en) System and method for determining trust for sip messages
HK1224847B (en) System and method for determining trust for sip messages
HK1224847A (en) System and method for determining trust for sip messages